PT-2026-61362 · Linux · Linux
CVE-2026-64045
·
Published
2026-07-19
·
Updated
2026-07-19
CVSS v3.1
8.4
High
| Vector | AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
In the Linux kernel, the following vulnerability has been resolved:
ovpn: tcp - use cached peer pointer in ovpn tcp close()
ovpn tcp close() loads the ovpn socket via rcu dereference sk user data()
under rcu read lock(), takes a reference on sock->peer, caches the peer
pointer in a local, and drops the read lock. It then passes sock->peer
(rather than the cached local) to ovpn peer del(), re-dereferencing the
ovpn socket after the RCU read section has ended.
Unlike ovpn tcp sendmsg(), which uses the same "load under RCU, use
after unlock" pattern but is protected by lock sock() held across the
function, ovpn tcp close() runs without the socket lock: inet release()
invokes sk prot->close() without taking lock sock first.
ovpn socket release() can therefore complete its kref put -> detach ->
synchronize rcu -> kfree(sock) sequence concurrently, in the window
after ovpn tcp close() drops rcu read lock() but before it dereferences
sock->peer. The synchronize rcu() in ovpn socket release() protects
readers that use the dereferenced pointer inside the RCU read section,
not those that escape the pointer to a local and use it afterwards.
A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp -
don't deref NULL sk socket member after tcp close()"): trigger a peer
removal (keepalive expiration or netlink OVPN CMD DEL PEER) at the same
moment userspace closes the TCP fd. That commit fixed the detach-side
of the same race window; this one fixes the close-side at a different
victim.
Tighten the entry block to read sock->peer exactly once into the cached
peer local, and route all subsequent uses (the hold check, the
ovpn peer del() call, and the prot->close() invocation) through that
local. sock->peer is only ever written once in ovpn socket new() under
lock sock(), before rcu assign sk user data() publishes the ovpn socket,
and is never reassigned afterwards - but the previous multi-read pattern
made that invariant implicit rather than explicit. The same multi-read
shape exists in ovpn tcp recvmsg(), ovpn tcp sendmsg(),
ovpn tcp data ready() and ovpn tcp write space(); those will be cleaned
up via a dedicated helper in a follow-up net-next series.
Fix
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux