CVE-2026-52936

What it actually does

This Linux kernel flaw is a denial-of-service condition in the jitterentropy cryptographic random-number generator path. The affected code serializes access to shared jitterentropy state with a spinlock while performing expensive entropy collection and SHA3 conditioning. When multiple callers request entropy concurrently, waiting CPUs can spin for an extended period in a non-preemptible context, causing CPU starvation, kernel stalls, RCU stall warnings, soft lockups, or degraded system responsiveness. The upstream fix changes the long-held spinlock to a mutex so contending callers sleep instead of consuming CPU while waiting.

Why it matters to the business

Successful exploitation can make affected Linux systems slow, unstable, or temporarily unavailable, especially under workloads that trigger concurrent kernel cryptographic random-number generation. The practical risk is currently lower because EPSS is low, the issue is not in the CISA KEV catalog, it is not known to be used in ransomware campaigns, and no public exploit maturity was reported; however, kernel denial-of-service flaws still warrant routine patching because they can disrupt shared servers, appliances, container hosts, and latency-sensitive services.

How an attack unfolds

An attacker who can cause repeated or parallel use of the kernel jitterentropy RNG path attempts to generate enough concurrent entropy requests that one caller holds the jitterentropy lock while performing expensive collection and conditioning work. Other callers contend on the same lock and spin rather than sleep. If sustained, this can waste CPU cycles, block forward progress on affected CPUs, and produce kernel watchdog, RCU stall, or soft-lockup symptoms. Exploitation is expected to be local or workload-adjacent rather than a typical unauthenticated remote code execution path, and it depends on whether the affected kernel exposes or uses the vulnerable jitterentropy crypto API path in a way the attacker can drive.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the jitterentropy locking fix that replaces the long-held spinlock with a mutex in the kernel crypto jitterentropy code. Because no product-specific fixed versions were provided, use the relevant distribution, appliance, cloud image, or kernel-maintainer advisory to identify the exact patched kernel package. Reboot systems after kernel upgrade so the fixed kernel is running. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, constraining container workloads, applying CPU and process limits to untrusted workloads, disabling unnecessary interfaces that expose kernel crypto APIs where operationally feasible, and monitoring for kernel stall symptoms. Treat mitigations as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is at or above the vendor-fixed version and that the kernel changelog includes the jitterentropy lock change. Use distribution tooling such as package manager history, kernel package metadata, advisory identifiers, and `uname -r` after reboot to confirm the patched kernel is active. In a non-production test environment, run a controlled concurrent RNG/crypto workload and verify that the system does not produce soft-lockup, hard-lockup, RCU-stall, or hung-task messages and that CPU usage remains bounded. Review kernel logs after the test and after production rollout for absence of new jitterentropy-related stall messages.

Typical attack path

1. Identify a Linux system running an affected kernel build with the vulnerable jitterentropy implementation.
2. Obtain a way to execute code locally, run an untrusted workload, abuse a containerized workload, or otherwise trigger kernel crypto RNG activity repeatedly.
3. Create many concurrent entropy/RNG requests through available kernel or user-space interfaces that exercise the jitterentropy RNG path.
4. Force contention on the shared jitterentropy state so waiters spin while another caller performs expensive entropy collection and SHA3 conditioning.
5. Sustain the request pressure until CPUs experience high system time, scheduling delays, RCU stalls, soft lockups, or service degradation.
6. Stop activity or let watchdog/recovery behavior determine whether the host returns to normal or requires operator intervention.

How to detect it

To assess possible prior exploitation, review host telemetry for symptoms of induced kernel lock contention rather than traditional compromise artifacts. Primary sources are kernel logs, system journal, syslog, dmesg output, EDR performance telemetry, container runtime telemetry, and hypervisor or cloud monitoring for CPU saturation and host unresponsiveness. Look for bursts of soft lockups, hard lockups, RCU stall messages, hung-task warnings, watchdog events, and unusually high system CPU time that correlate with many concurrent processes or containers performing cryptographic or random-number operations. If available, use eBPF, ftrace, perf, or kernel function tracing to identify unusually frequent or long-latency calls involving jitterentropy RNG functions such as `jent_kcapi_random` or related crypto RNG paths. Also review process accounting and container/audit logs around the same timestamps for untrusted workloads spawning many threads or repeatedly opening crypto/RNG interfaces. There are no reliable file, registry, persistence, or network IOCs because this is a kernel denial-of-service condition, not a code-execution vulnerability.

• watchdog: BUG: soft lockup
• NMI watchdog: Watchdog detected hard LOCKUP
• rcu: INFO: rcu_sched self-detected stall
• rcu: INFO: rcu_preempt self-detected stall
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• jent_kcapi_random
• jitterentropy
• crypto: jitterentropy
• jitterentropy_rng

What your security team should do

• Inventory Linux systems and appliances using vendor kernels that include the kernel crypto jitterentropy RNG implementation, prioritizing shared compute, container hosts, internet-facing appliances, and high-availability infrastructure.
• Track vendor advisories and upgrade to the first kernel build that contains the jitterentropy spinlock-to-mutex fix; schedule reboots because kernel fixes require booting into the patched kernel.
• Prioritize normally rather than emergency unless affected systems run untrusted local workloads or have previously shown kernel stall/lockup symptoms; the CVE has low EPSS, no KEV listing, no known ransomware use, and no reported public exploit maturity.
• Add monitoring for kernel soft lockups, hard lockups, RCU stalls, hung tasks, and abnormal system CPU usage on affected Linux hosts until patching is complete.
• Restrict or resource-limit untrusted local users, CI jobs, containers, and sandboxed workloads that could intentionally generate high-concurrency kernel crypto/RNG activity.
• After patching, verify the running kernel version and retain evidence of reboot and advisory compliance for audit or vulnerability management closure.