Description

In the Linux kernel, the following vulnerability has been resolved: ovpn: fix NULL dereference when killing missing key ovpn_crypto_kill_key assumes both crypto slots are populated and dereferences each slot before checking it. That is not guaranteed: a peer can have only one installed key, and the kill path may be asked to remove a key that is not present. Read each slot once while holding the crypto state lock, check for NULL before looking at key_id, and only replace the slot that actually matches.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-26T15:17:05.553Z",
  "pubdate": "2026-08-26T15:17:05.553Z",
  "executiveSummary": "A NULL pointer dereference vulnerability exists within the Linux kernel ovpn (OpenVPN data channel offload) subsystem, specifically residing in the ovpn_crypto_kill_key function.\nThe vulnerability arises due to improper validation of crypto slots when attempting to invalidate or remove keys. Because the kernel assumes both crypto slots are occupied and dereferences them prematurely, a kernel panic (Denial of Service) can be triggered if a peer configuration involves only a single installed key or if a removal request targets a missing key.\nThis issue impacts the stability of the system by enabling an attacker or a malformed control sequence to force a crash. Successful exploitation results in a Denial of Service via system instability. While this does not inherently lead to remote code execution, it represents a significant availability risk in environments relying on the ovpn kernel module. No specific authentication beyond the ability to trigger the key destruction path within the kernel driver is required.",
  "technicalDetails": "The root cause of this vulnerability is an unsafe pointer dereference pattern within the ovpn_crypto_kill_key function. The implementation incorrectly assumed that both crypto slots within the peer object were guaranteed to be populated. Consequently, the function performed pointer dereferences on these slots to access the internal key_id member prior to validating whether the slots contained valid pointers.\nIn the context of the ovpn data structure, a peer may maintain one or two crypto slots depending on the state of the session and the negotiation of keys. If a process invokes the key destruction path for a slot that remains uninitialized (NULL), the kernel attempts to access memory at a null-offset address, triggering an immediate NULL pointer dereference exception and subsequent kernel panic.\nThe attack flow occurs when the kernel receives a command to remove a specific key from a peer object. If the internal state tracking for the crypto slots is inconsistent with the request—such as when a user-space process requests the removal of a missing key or a key residing in a non-populated slot—the flawed logic executes the following sequence: 1) The system enters ovpn_crypto_kill_key; 2) The code dereferences the crypto slot pointers without prior NULL checks; 3) The CPU encounters a segmentation fault at the kernel level due to the dereferencing of a NULL address; 4) The kernel invokes the panic handler, leading to a system-wide crash and Denial of Service.\nThis vulnerability is particularly sensitive because the dereference occurs before the function evaluates the key_id match. By failing to perform a safe 'check-before-use' operation while holding the necessary crypto state lock, the kernel exposes a crash vector. Secure implementation requires capturing the slot state into local variables while under the protection of the crypto state lock and explicitly verifying that the pointer is non-NULL before inspecting the key_id field for matching criteria.\nThe vulnerability affects the ovpn module in the Linux kernel where key lifecycle management is performed. Exposure is inherent to the use of the ovpn subsystem, and the exploitability depends on the ability of an attacker to influence or trigger the key destruction path within the kernel driver via standard interaction with the driver's interface."
}