Medium [CVE-2026-68122] fix peer refcount leak in TCP error paths

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.

A race condition in the TCP error handling paths can lead to a reference count leak. This occurs when an internal object's reference count is incremented twice but decremented only once, preventing the object from being properly released.

Over time, this resource exhaustion could lead to a Denial of Service (DoS) condition.