Description

In the Linux kernel, the following vulnerability has been resolved: ovpn: defer key slot crypto freeing to workqueue Key slots are released through a kref and the existing release path frees the AEAD transforms from an RCU callback. That is not safe for all crypto implementations: crypto_free_aead can sleep, for example when an async or hardware implementation has teardown work to complete. Use queue_rcu_work for key-slot release. This keeps the RCU grace period needed by lockless key-slot readers, but runs the actual crypto teardown from workqueue context where sleeping is allowed. Once the rcu_work callback runs, pre-existing RCU readers are gone, and the final kref put already proves that no transform user remains, so the worker can release the AEAD transforms and free the slot directly. The previous patch drains ovpn_wq during module exit, so queued key-slot teardown work cannot outlive module text.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-26T15:16:54.050Z",
  "pubdate": "2026-08-26T15:16:54.050Z",
  "executiveSummary": "This vulnerability involves an improper implementation of kernel object teardown within the ovpn (OpenVPN data plane) module. The issue arises from attempting to execute sleepable operations, specifically crypto_free_aead, within an RCU callback context, which strictly prohibits sleeping.\nThe vulnerability type is a kernel-level concurrency/scheduling violation. If triggered, this could result in a kernel panic, system instability, or potential use-after-free conditions if the execution context is violated during cryptographic transform cleanup.\nThe affected system is the Linux kernel's ovpn module. While this is a local kernel-level defect, successful exploitation or unintended triggering of this code path during high-load cryptographic teardown operations can lead to a denial-of-service (DoS) via system crash.\nThe flaw stems from the design assumption that cryptographic transform release is non-blocking. Attackers who can trigger frequent key rotations or teardowns under specific conditions involving async or hardware-backed cryptographic implementations may influence the stability of the kernel memory management subsystem.\nExploitation requires triggering the specific cleanup path of a key slot, necessitating the presence of hardware or asynchronous crypto drivers that perform blocking operations during teardown.",
  "technicalDetails": "The root cause of this vulnerability is a violation of execution context requirements in the ovpn key-slot management system. In the Linux kernel, RCU callbacks are invoked in contexts where sleeping (blocking) is prohibited. The ovpn module previously utilized an RCU callback to trigger the release of AEAD (Authenticated Encryption with Associated Data) transforms via crypto_free_aead.\nThe crypto_free_aead function is not guaranteed to be atomic or non-blocking. Specifically, when utilizing asynchronous cryptographic drivers or hardware-accelerated engines, the teardown process frequently necessitates waiting for pending hardware requests or performing sleepable memory allocations. Invoking this function within an RCU callback violates the atomic context constraint, leading to an illegal schedule-while-atomic bug.\nThe attack flow involves: 1) Initializing a cryptographic key slot in ovpn that utilizes a hardware-backed AEAD transform. 2) Triggering the key slot release process through the established kref mechanism. 3) The existing code queues an RCU callback to finalize the cleanup. 4) The RCU subsystem executes the callback in an atomic context. 5) The crypto_free_aead function attempts to sleep, causing a kernel warning or crash due to the invalid scheduling context.\nThe patched implementation mitigates this by transitioning from pure RCU callbacks to queue_rcu_work. By utilizing a workqueue, the system ensures that the RCU grace period has elapsed—guaranteeing that no lockless key-slot readers remain—before offloading the crypto_free_aead invocation to a kernel thread context where sleeping is permissible. This decoupling allows the kernel to safely manage the teardown of hardware-bound cryptographic resources without violating the restrictions of the RCU subsystem.\nThe vulnerability impacts any deployment of the ovpn module where cryptographic operations are backed by sleepable kernel modules or hardware drivers. As the ovpn driver manages encrypted data plane traffic, the lifecycle of key slots is dynamic, making the instability risk persistent during active VPN sessions that undergo frequent re-keying or tunnel teardowns."
}