CVE-2026-45918: ovpn: tcp - don't deref NULL sk_socket member after tcp_close()
In the Linux kernel, the following vulnerability has been resolved:
ovpn: tcp - don't deref NULL sksocket member after tcpclose()
When deleting a peer in case of keepalive expiration, the peer is removed from the OpenVPN hashtable and is temporary inserted in a "release list" for further processing.
This happens in: ovpnpeerkeepalivework() unlockovpn(releaselist)
This processing includes detaching from the socket being used to talk to this peer, by restoring its original proto and socket ops/callbacks.
In case of TCP it may happen that, while the peer is sitting in the release list, userspace decides to close the socket. This will result in a concurrent execution of:
tcpclose(sk) tcpclose(sk) sockorphan(sk) sksetsocket(sk, NULL)
The last function call will set sk->sksocket to NULL.
When the releasing routine is resumed, ovpntcpsocketdetach() will attempt to dereference sk->sksocket to restore its original ops member. This operation will crash due to sk->sksocket being NULL.
Fix this race condition by testing-and-accessing sk->sksocket atomically under sk->skcallbacklock.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OpenVPN (ovpn)to a version that resolves this vulnerability.Patch ovpn: tcp - don't deref NULL sk_socket member after tcp_close()
Event History
Frequently Asked Questions
Which deployments are affected in practice?
Systems using the Linux kernel's OpenVPN TCP peer handling are exposed when a peer is deleted after keepalive expiration and the associated TCP socket is closed by userspace during the peer-release window. The race can cause a kernel crash, resulting in denial of service.
What conditions are needed to trigger the crash?
An attacker would need to trigger or coincide with deletion of an OpenVPN peer due to keepalive expiration while userspace closes that peer's TCP socket. The CVSS vector indicates local attack access and low privileges; no user interaction is required.
What mitigation is available before applying the fix?
The fix makes access to the socket pointer atomic under sk->sk_callback_lock before restoring the socket operations and callbacks. If patching cannot occur immediately, avoiding concurrent userspace closure of TCP sockets while peers are being released after keepalive expiration reduces exposure, though the provided data does not describe a complete workaround.