Look up another CVE · open CVE-2026-64045 in the interactive tracker
CVE-2026-64045
ovpn: tcp - use cached peer pointer in ovpn_tcp_close()
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-64045 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ovpn/tcp.c
- What this is
- OPENVPN DATA CHANNEL OFFLOADMAINTAINERS section matched on drivers/net/ovpn/ · openvpn-devel@lists.sourceforge.net · Supported
- Kernel module
- ovpn
Check it on the machine
grep -w CONFIG_OVPN /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w ovpnPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release with an answer below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidm
- ?
- not established - no Makefile entry for the affected file
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_OVPN
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 8.4 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.19%, higher than 8.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.16 | 6.18.34 | e5460eb7238c |
| 6.16 | 7.0.11 | d3ef441907fc |
| 6.16 | 7.1 | 775d8d7ad02a |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable code runs only in ovpn_tcp_close(), reached via the close() syscall path (inet_release() -> sk_prot->close) on a TCP socket attached to the ovpn driver. Remote network packets do not directly invoke this function.
- AC:LAttack complexity, low
- The reproducer is a race between closing the TCP fd and concurrent peer removal (keepalive expiry or OVPN_CMD_DEL_PEER). The attacker controls both sides by timing close() against peer deletion, and can retry until the window is hit.
- PR:NPrivileges required, none
- On an internet-facing OpenVPN server with kernel TCP offload, a remote VPN peer needs no Linux credentials: stopping traffic triggers kernel keepalive expiry and ovpn_socket_release(), while the local daemon concurrently closes the TCP socket as part of normal teardown.
- UI:NUser interaction, none
- Exploitation does not require any victim user action beyond normal automated VPN server operation reacting to peer timeout or disconnect.
- S:UScope, unchanged
- Impact is confined to kernel memory corruption and privilege escalation within the host kernel; it does not cross a VM, container, or IOMMU security boundary.
- C:HConfidentiality impact, high
- This is a use-after-free: after RCU ends, ovpn_tcp_close() re-dereferences sock->peer on a freed ovpn_socket, enabling reads of attacker-influenced freed heap contents and potential information disclosure.
- I:HIntegrity impact, high
- The stale sock->peer pointer is passed to ovpn_peer_del(), which operates on peer structures and locks; corrupted pointers can cause arbitrary kernel memory corruption exploitable for control-flow hijacking.
- A:HAvailability impact, high
- The UAF can cause kernel oops/panic during peer deletion or TCP close, and use-after-free on kmalloc objects routinely causes system crashes even when not fully weaponized.