CVE-2026-80834 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: sun8i-ce - Remove crypto_rng interface
Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones.
Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters.
As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel has addressed a specific issue within the sun8i-ce cryptographic engine driver by removing its support for the crypto_rng interface. This change reflects a broader architectural decision in the Linux ecosystem to deprecate hardware random number generator interfaces that duplicate functionality already provided by higher-level system components. The crypto_rng API was historically intended to allow drivers to expose their internal pseudo-random number generators directly to the kernel's cryptographic subsystem. However, this approach has proven redundant because modern kernels rely on a centralized entropy pool managed by the Linux RNG framework, which aggregates input from various sources including hardware random number generators exposed via the hwrng interface. By removing the crypto_rng support for sun8i-ce, developers are aligning with industry best practices that favor standardized interfaces over driver-specific implementations, thereby reducing code complexity and potential points of failure within the kernel's cryptographic infrastructure.
The technical flaw associated with this removal was a use-after-free vulnerability located in the generate function of the driver. This bug manifested when the wait_for_completion_interruptible_timeout function returned due to an interrupt signal rather than completing normally. In such scenarios, the original code failed to properly terminate or clean up ongoing Direct Memory Access operations before proceeding. Consequently, if the DMA engine continued writing data after the buffer had been freed by the calling context, it would result in memory corruption and potential system instability. This specific error pattern is a classic example of improper resource management during asynchronous operation cancellation, where the lifecycle of hardware resources is not correctly synchronized with software state transitions.
From an operational perspective, while this vulnerability existed within code that was ultimately being removed, its presence highlights significant risks related to concurrent execution and signal handling in kernel-space drivers. If similar patterns were present in other active components or if the driver had remained in use without proper fixes, it could have been exploited by local users with sufficient privileges to trigger cryptographic operations under specific timing conditions involving signals. The vulnerability effectively allowed for a denial of service through system crashes or potentially more severe impacts depending on memory layout and exploitation techniques available at runtime. By marking this commit as fixing the issue and targeting stable kernel branches, maintainers ensure that any downstream distributions relying on older versions of the sun8i-ce driver are protected against these specific race conditions even if they have not yet migrated to the updated codebase where the interface is entirely absent.
This remediation aligns with established security standards regarding memory safety and resource lifecycle management. The underlying issue corresponds closely to CWE-416, Use After Free, which describes situations where a program continues to use a pointer after it has been freed, leading to undefined behavior. Furthermore, in the context of attack vectors, this type of vulnerability can facilitate local privilege escalation or system compromise if combined with other weaknesses, fitting into ATT&CK techniques related to exploitation for defense evasion or impact through denial of service. The decision to remove rather than patch reflects a strategic shift toward simplifying the kernel surface area by eliminating redundant interfaces that are prone to implementation errors and offer little unique value compared to standard alternatives like hwrng.
Mitigation strategies primarily involve ensuring systems are updated with this kernel revision, which eliminates the vulnerable code path entirely. For environments where immediate updates are not feasible, administrators should monitor for any custom modifications or out-of-tree patches that might reintroduce similar patterns of asynchronous DMA handling without proper signal interruption checks. Additionally, enforcing strict memory protection mechanisms such as Kernel Page Table Isolation and stack canaries can help mitigate the impact of potential use-after-free conditions in other parts of the system. Long-term resilience requires adhering to secure coding practices that prioritize explicit resource cleanup upon all exit paths, particularly those triggered by external signals or timeouts, ensuring that hardware operations are fully synchronized with software state before memory is released.