CVE-2026-80519 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
ovpn: finish crypto callback cleanup before peer release
Crypto completion callbacks hold both key-slot and peer references. The peer reference pins the netdev, and dropping the last peer reference can let netdev unregistration and module removal make progress.
Do not release that peer reference before the callback has finished its own cleanup. If ovpn_crypto_key_slot_put runs after ovpn_peer_put, it can schedule an RCU callback backed by module text after ovpn_cleanup rcu_barrier has already run. The TX error path also freed the remaining skb after ovpn_peer_put, leaving callback cleanup outside the peer/netdev lifetime window.
Release the key slot and free any remaining skb first, then drop the peer reference as the last callback action.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in the OpenVPN over GRE implementation within the Linux kernel involves a critical race condition related to resource lifecycle management during cryptographic operations. Specifically, the issue arises from an incorrect ordering of cleanup procedures when handling crypto completion callbacks and peer object release. In this context, crypto completion callbacks maintain references to both key slots and network peers. The peer reference is particularly significant because it pins the underlying network device structure, preventing its unregistration or removal until all active references are dropped. When a cryptographic operation completes, the system must ensure that all associated resources are safely cleaned up before allowing the peer object itself to be released. Failure to adhere to this sequence creates a window where kernel memory management operations can proceed incorrectly, leading to potential use-after-free scenarios and module unloading conflicts.
The technical flaw centers on the execution order of two specific functions: ovpn_crypto_key_slot_put and ovpn_peer_put. Under normal circumstances, these calls must be coordinated so that key slot cleanup occurs before the peer reference is dropped. However, in certain error paths or race conditions, ovpn_peer_put may execute first, thereby dropping the last peer reference to a network device. This action can trigger netdev unregistration and allow module removal processes to advance. If ovpn_crypto_key_slot_put subsequently runs after this point, it attempts to schedule an RCU callback that relies on code residing in the kernel module text segment. Since the rcu_barrier associated with the module cleanup has already executed by this time, the scheduled callback may attempt to execute instructions from a memory region that is no longer valid or mapped, resulting in undefined behavior and potential system instability.
Furthermore, the transmission error path exacerbates this issue by freeing remaining socket buffers after ovpn_peer_put has been called. This action effectively detaches the cleanup of cryptographic callbacks from the lifetime window of the peer object and its associated network device. Consequently, any deferred work scheduled via RCU mechanisms during callback processing may access freed memory or execute code in an unloaded module. This misalignment between resource allocation and deallocation violates fundamental kernel safety principles regarding reference counting and asynchronous task execution. The vulnerability is classified under CWE-416, Use After Free, as it allows for the potential dereferencing of pointers to objects that have already been destroyed due to improper sequencing of cleanup routines.
The operational impact of this vulnerability includes system crashes, data corruption, or privilege escalation if an attacker can trigger the specific race condition through crafted network traffic. An adversary might exploit this by inducing rapid connection teardowns and cryptographic operations simultaneously, forcing the kernel into a state where module unloading occurs while deferred callbacks are still pending execution. This could lead to denial of service conditions as the system attempts to handle invalid memory accesses or execute code in unmapped regions. In severe cases, such vulnerabilities can be chained with other flaws to achieve arbitrary code execution within the kernel space, compromising the integrity and confidentiality of the entire host system.
To mitigate this vulnerability, it is essential to enforce strict ordering during cleanup operations. The key slot must be released and any remaining socket buffers freed before dropping the peer reference. This ensures that all RCU callbacks associated with cryptographic processing complete their execution within the valid lifetime window of the network device and its underlying module code. Developers should review the ovpn_crypto_key_slot_put function to ensure it is called prior to ovpn_peer_put in all exit paths, including error handling branches. Additionally, implementing robust reference counting checks and ensuring that RCU callbacks are properly synchronized with module lifecycle events can prevent these race conditions from manifesting. System administrators should apply kernel updates provided by their distribution vendors as soon as they become available to patch this flaw.
From a defensive perspective, monitoring for unusual patterns in network device unregistration or cryptographic operation failures may help detect exploitation attempts early. Security teams should also ensure that kernel hardening features such as KASLR and stack canaries are enabled to reduce the likelihood of successful exploitation even if the race condition is triggered. Regular auditing of kernel code changes related to reference counting and asynchronous callback handling can further strengthen resilience against similar vulnerabilities in other subsystems. Adherence to established coding standards for Linux kernel development, particularly those emphasizing safe resource management and synchronization primitives, remains critical for maintaining system stability and security integrity over time.