CVE-2026-68122 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
ovpn: fix peer refcount leak in TCP error paths
When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object.
The race window:
CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed
Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability exists within the openvpn kernel module in the linux operating system where a reference count leak occurs during TCP error handling operations. The issue manifests when either the receive or transmit error paths invoke ovpn_peer_hold() followed by schedule_work() to queue a deferred deletion work item, creating a race condition that results in improper reference counting and eventual memory leaks.
The technical flaw stems from a race condition in the kernel's openvpn implementation where two separate CPU threads can simultaneously process TCP errors through different code paths. When either path calls ovpn_peer_hold() to increment the peer reference count followed by schedule_work(), the work item gets queued for execution. However, if the same work item is already pending from the other error path, the second call to schedule_work() returns false and does not queue the work again, leading to a scenario where one of the reference increments remains unreleased.
The operational impact of this vulnerability extends beyond simple memory leaks as it creates persistent resource consumption that can degrade system performance over time. The race window occurs when both CPU cores attempt to process error conditions simultaneously, with each path taking an additional reference but only one of them actually executing the cleanup work item. This results in peer objects remaining allocated in memory indefinitely, consuming kernel resources and potentially leading to system instability or resource exhaustion under sustained load conditions.
The fix implemented addresses this by modifying both error paths to check the return value of schedule_work() and conditionally call ovpn_peer_put() when the work was already pending, thereby ensuring proper reference counting regardless of which path executes first. This solution follows established kernel development practices for handling race conditions in concurrent environments and aligns with common security principles for preventing resource leaks that could be exploited by malicious actors to cause denial of service conditions.
This vulnerability can be classified under CWE-401 as a failure to release memory and relates to the broader category of resource management issues within kernel space. The flaw demonstrates characteristics consistent with ATT&CK technique T1499.004 which involves resource exhaustion through improper handling of system resources, potentially allowing adversaries to consume excessive memory or CPU cycles. The fix ensures proper reference counting mechanisms maintain system stability and prevents potential exploitation scenarios where attackers could leverage such memory leaks for persistent denial of service attacks against openvpn services running on linux systems.