CVE-2026-52936: Linux Kernel Race Condition Vulnerability

CVE-2026-52936 Overview

CVE-2026-52936 affects the Linux kernel's jitterentropy random number generator subsystem. The jent_kcapi_random() function serializes access to shared jitterentropy state using a spinlock held across the entire jent_read_entropy() call. That path performs expensive jitter collection and SHA3 conditioning operations. Parallel readers contending for the lock trigger stalls because waiters spin in non-preemptible context while the lock holder completes lengthy entropy generation. The fix replaces the spinlock with a mutex so contended readers sleep instead of spinning. This vulnerability falls under the Denial of Service category through resource contention in kernel cryptographic subsystems.

Critical Impact
Concurrent readers of the jitterentropy RNG can experience CPU stalls and reduced system responsiveness due to long-held non-preemptible spinlocks across expensive entropy collection paths.

Affected Products

Linux kernel (jitterentropy crypto subsystem)
Stable kernel branches receiving the referenced backports
Distributions shipping vulnerable kernel versions prior to the fix commits

Discovery Timeline

2026-06-24 - CVE-2026-52936 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52936

Vulnerability Analysis

The Linux kernel jitterentropy driver exposes a kernel crypto API random number generator. The jent_kcapi_random() function uses rng->jent_lock, a spinlock, to serialize concurrent access to shared jitterentropy state. Spinlocks in Linux are non-preemptible primitives intended for short critical sections.

The critical section in this code path encompasses the full jent_read_entropy() call. That function performs CPU timing jitter collection and SHA3 conditioning of collected entropy. Both operations are computationally expensive and can take significant time to complete.

When multiple threads request random bytes concurrently, contending callers spin on the lock without yielding the CPU. This produces measurable stalls, scheduler latency spikes, and degraded throughput on systems where multiple processes or kernel subsystems request entropy through the crypto API.

Root Cause

The root cause is the use of a spinlock to guard a long-running critical section. Spinlocks disable preemption while held. Holding one across SHA3 conditioning and jitter sampling violates the convention that spinlock-protected sections remain short. Contending readers cannot sleep and must busy-wait, wasting CPU cycles and blocking higher-priority work on the same core.

Attack Vector

Local unprivileged users or processes that legitimately consume kernel crypto API randomness can trigger contention by issuing concurrent reads against the jitterentropy RNG. No special privileges or exploit primitives are required beyond the ability to request random bytes. The result is resource exhaustion and degraded scheduling rather than memory corruption or privilege escalation. Refer to the upstream patches for technical specifics:

Detection Methods for CVE-2026-52936

Indicators of Compromise

Kernel soft-lockup or RCU stall warnings referencing jent_read_entropy or jent_kcapi_random in dmesg output.
Elevated system CPU time on processes performing frequent getrandom() or crypto API calls that route to the jitterentropy backend.
Scheduler latency anomalies correlated with concurrent cryptographic workloads requesting kernel-supplied entropy.

Detection Strategies

Audit installed kernel package versions against distribution advisories referencing the listed stable commits.
Inspect /proc/crypto to confirm whether jitterentropy_rng is active and exposed to crypto API consumers.
Use perf or ftrace to identify long lock-hold times within the jitterentropy code path under load.

Monitoring Recommendations

Forward kernel ring buffer logs to a centralized log platform and alert on soft-lockup, hung-task, or RCU stall messages.
Track per-host scheduler latency metrics and correlate spikes with cryptographic workload activity.
Maintain an inventory of kernel versions across Linux estate and flag hosts running unpatched releases.

How to Mitigate CVE-2026-52936

Immediate Actions Required

Identify all Linux hosts running kernel versions that predate the fix commits listed in the references.
Schedule kernel updates through your distribution vendor's patched stable release channel.
Prioritize systems performing high-volume cryptographic operations or running latency-sensitive workloads.

Patch Information

The upstream fix replaces rng->jent_lock with a mutex so contended readers sleep rather than spin during entropy collection and SHA3 conditioning. Apply the kernel update from your Linux distribution that incorporates one of the referenced stable commits: 01d798e9, 18216b8a, 4c03e6eb, ec427dc5, or ff734dbd. Reboot the host after installation so the patched kernel becomes active.

Workarounds

Reduce concurrent consumers of the jitterentropy crypto API where feasible by serializing entropy requests at the application layer.
Prefer getrandom(2) against the primary kernel CSPRNG, which does not traverse the contended jitterentropy crypto API path on most configurations.
If the jitterentropy crypto module is not required, evaluate unloading it on affected hosts after validating dependencies.

bash

# Verify running kernel version and jitterentropy module status
uname -r
grep -A2 jitterentropy /proc/crypto
lsmod | grep jitterentropy

# After distribution kernel update, reboot to activate the patched kernel
sudo reboot