CVE-2026-80871 Overview
CVE-2026-80871 affects the Linux kernel's xilinx-trng cryptographic driver. The vulnerability stems from two defects in the driver's crypto_rng interface implementation. First, xtrng_trng_generate() sometimes returned success even when it failed to fill the requested output buffer with random bytes. Second, broken locking in xtrng_hwrng_trng_read() allowed concurrent execution with xtrng_trng_generate(), causing the two paths to interfere with each other. The upstream fix removes the unused crypto_rng interface entirely, retaining only the hwrng interface that is actually used by consumers.
Critical Impact
Consumers of the Xilinx True Random Number Generator (TRNG) driver may receive partially populated random buffers reported as successful, weakening cryptographic operations that depend on the entropy returned.
Affected Products
- Linux kernel builds including the xilinx-trng driver with the crypto_rng interface
- Xilinx Zynq UltraScale+ and related platforms consuming the TRNG driver
- Downstream distributions shipping affected stable kernel branches
Discovery Timeline
- 2026-09-04 - CVE-2026-80871 published to NVD
- 2026-09-04 - Last updated in NVD database
Technical Details for CVE-2026-80871
Vulnerability Analysis
The xilinx-trng driver exposed two interfaces to kernel consumers: the generic crypto_rng API and the hardware random number generator (hwrng) API. According to the upstream commit message, the crypto_rng implementation was not used in practice and contained defects that produced incorrect results.
The function xtrng_trng_generate() could return a success status code even when it had not populated the entire output buffer. Consumers trusting the return value would then use uninitialized or partially initialized memory as if it were random output. This breaks the contract expected of a cryptographic random source.
A separate defect involved broken synchronization. The locking used in xtrng_hwrng_trng_read() did not correctly serialize access relative to xtrng_trng_generate(). Concurrent callers on the crypto_rng and hwrng interfaces could interleave hardware accesses and corrupt each other's results.
Root Cause
The root cause is twofold: incomplete error handling in the crypto_rng generate path and inadequate mutual exclusion between the two driver interfaces sharing a single hardware TRNG. The fix removes the unused crypto_rng interface rather than repairing it, eliminating the concurrent access path and the flawed return semantics in one change.
Attack Vector
This is a kernel driver correctness defect rather than a directly exploitable memory-safety flaw. Any kernel subsystem or module requesting randomness through the crypto_rng interface backed by xilinx-trng could receive weak or predictable output. Cryptographic keys, nonces, or IVs derived from such output would inherit the weakness.
The vulnerability manifests in the Xilinx TRNG driver's dual-interface design. Refer to the upstream fix commit for the exact removed code and the second and third stable backports.
Detection Methods for CVE-2026-80871
Indicators of Compromise
- No runtime indicators of compromise are published for this defect; it is a correctness bug in a kernel driver, not an active exploitation primitive.
- Cryptographic material generated on affected Xilinx platforms during the vulnerable window should be treated as suspect.
Detection Strategies
- Inventory Linux hosts running on Xilinx Zynq UltraScale+ or related SoCs and identify kernel versions that expose the xilinx-trngcrypto_rng interface.
- Query loaded kernel modules for xilinx-trng and compare against the fixed commit hashes referenced in the kernel.org stable tree.
- Audit in-house kernel modules and drivers for calls to crypto_rng APIs that could be backed by the Xilinx TRNG.
Monitoring Recommendations
- Track kernel package versions across the fleet and alert when hosts remain on pre-patch stable branches.
- Monitor kernel build pipelines for inclusion of the corrective commits before signing production images.
How to Mitigate CVE-2026-80871
Immediate Actions Required
- Update affected Linux kernels to the stable release that includes commits 32b4d29280ed, 83f29da85dc9, or 9634db561e15.
- Rebuild and redeploy custom kernels for Xilinx platforms with the patched xilinx-trng driver.
- Rotate cryptographic material generated by consumers of the crypto_rng interface on affected systems where feasible.
Patch Information
The fix is available in the upstream Linux stable tree. The corrective change removes the crypto_rng interface from the xilinx-trng driver, leaving only the hwrng interface. See the kernel.org commits: 32b4d29280ed, 83f29da85dc9, and 9634db561e15. The change is tagged Cc: stable and is being backported across supported stable branches.
Workarounds
- Where patching is delayed, route entropy consumers through the hwrng interface or the kernel's core RNG rather than the Xilinx crypto_rng implementation.
- Avoid loading or binding kernel modules that call crypto_rng APIs against the Xilinx TRNG on affected builds.
# Verify running kernel version and inspect the xilinx-trng module
uname -r
modinfo xilinx-trng | grep -E 'filename|version|srcversion'
lsmod | grep xilinx_trng
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

