Linux Kernel CVE-2026-52936

Requires local shell access with at minimum low-privilege credentials (CVSS PR:L, AV:L) - any standard user account on the target system is sufficient. The vulnerability is only triggerable when the jitterentropy driver is active as an entropy source, which is the default on Linux systems compiled with CONFIG_CRYPTO_JITTERENTROPY and lacking a preferred hardware RNG. Exploitation requires the ability to spawn multiple concurrent threads or processes making simultaneous entropy requests via getrandom() or /dev/urandom reads; this is available to all unprivileged users by default. Limiting factors: attack surface is entirely local - no network reachability, no container escape, no privilege escalation, and no scope change to other systems (S:U). The impact is CPU stall and entropy starvation, not code execution or data disclosure. Systems with a hardware RNG taking priority over jitterentropy in the kernel's entropy pool management may see reduced impact.

The CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H scores 5.5 (Medium), accurately reflecting local-only attack surface, low-privilege requirement, and purely availability-class impact with no confidentiality or integrity consequence. EPSS at 0.16% (5th percentile) is consistent with the attack profile: the bug produces a kernel CPU stall rather than code execution or data exfiltration, sharply limiting its attractiveness as an exploitation target. No KEV listing and no public exploit code confirm no active exploitation at time of analysis. Notably, the 'Information Disclosure' tag from the ENISA EUVD dataset is inconsistent with both the CVE description and the CVSS C:N metric - this appears to be a platform tagging error with no basis in the described impact; analysts should not weight it. Real-world priority is low for most deployments: exploitation requires local shell access and the ability to spawn concurrent threads, limiting it to insiders or already-compromised hosts. Environments with high entropy contention - HSMs, TLS termination at scale, key generation services, multi-tenant cloud VMs - face the most meaningful exposure, as the spinlock contention can degrade getrandom() throughput to serial, blocking cryptographic operations systemwide. SSVC assessment: exploitation is not automatable remotely (AV:L), no public exploit exists, technical impact is partial system availability - operator-pace patching is appropriate.

A local low-privileged user on a shared cloud VM or multi-tenant container host launches a high-thread-count process that continuously calls getrandom() in parallel across all available CPU cores. The first thread to acquire jent_kcapi_random()'s spinlock begins milliseconds-long SHA3 conditioning work while all other CPUs spin at full utilization waiting for lock release, stalling kernel scheduling and blocking all entropy-dependent operations - including TLS handshakes and in-kernel key generation - for the duration of the attack. No exploit code beyond standard POSIX threading and the getrandom() syscall is required to reproduce the stall condition.