CVE-2026-80835
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A flaw in how certain hardware random number generators were exposed on Linux systems could have produced unreliable random values when used in two ways at once, but the unused exposure method has been removed to prevent the problem.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Concurrent unsynchronized access to shared hardware RNG registers between the crypto_rng and hwrng interfaces allows race conditions that can produce repeated or non-random output values.
Why it matters to the business
Potential weakening of cryptographic operations relying on hardware randomness on affected Qualcomm-based Linux systems, though the affected interface sees no practical use and overall risk remains low with no known exploitation.
How an attack unfolds
An attacker with local access would attempt to trigger simultaneous RNG generation calls through both interfaces to induce register conflicts and obtain predictable or duplicated random values for downstream attacks.
How to fix it
Update to a Linux kernel version that removes the crypto_rng interface from the qcom-rng driver; disable or avoid use of the AF_ALG rng algorithm type if patching is delayed.
How to confirm the fix worked
Confirm the qcom-rng driver source no longer registers a crypto_rng implementation and that only the hwrng path remains active; test for absence of concurrent access paths in the driver.
Typical attack path
- Gain local execution on a system exposing the qcom-rng driver
- Invoke concurrent operations on crypto_rng and hwrng interfaces
- Observe or capture non-random or repeated RNG output for use in further attacks
How to detect it
Review kernel logs and driver initialization for references to qcom_rng_generate and qcom_hwrng_read executing concurrently; examine any user-space processes invoking AF_ALG with rng algorithm type around the time of RNG-dependent operations.
What your security team should do
- Prioritize kernel updates on all Qualcomm-based devices within standard patch cycles given low EPSS and absence from KEV
- Audit for any custom code paths using the AF_ALG rng algorithm type
- Monitor upstream kernel changelogs for related RNG driver simplifications
The record
In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Remove crypto_rng interface qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc. Fortunately, there's actually no point in hardware RNG drivers implementing the crypto_rng interface. It's not actually used by anything besides the "rng" algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support. Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|