Look up another CVE · open CVE-2026-64044 in the interactive tracker
CVE-2026-64044
ovpn: respect peer refcount in CMD_NEW_PEER error path
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-64044 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_nl_peer_new_doit()'s error path calls ovpn_peer_release() directly rather than ovpn_peer_put(), bypassing the kref. The accompanying comment ("peer was not yet hashed, thus it is not used in any context") holds for UDP but not for TCP. For UDP, the ovpn_socket union uses the .ovpn arm and never points back at a peer; UDP encap_recv looks up peers via the not-yet-populated hashtables, so the new peer is unreachable until ovpn_peer_add() publishes it. For TCP, ovpn_socket_new() sets ovpn_sock->peer and ovpn_tcp_socket_attach() publishes ovpn_sock via rcu_assign_sk_user_data(). From that moment until ovpn_socket_release() detaches in the error path, the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll on the fd, as well as the strparser-driven ovpn_tcp_rcv() path, can reach the peer through sk_user_data -> ovpn_sock->peer and bump its refcount via ovpn_peer_hold(). ovpn_tcp_socket_wait_finish() (called inside ovpn_socket_release()) drains strparser and the tx work, but does not synchronize with userspace syscall callers that already hold a peer reference. If ovpn_nl_peer_modify() or ovpn_peer_add() returns an error while such a caller is in flight - notably an ovpn_tcp_recvmsg() blocked in __skb_recv_datagram() on peer->tcp.user_queue - the direct ovpn_peer_release() destroys the peer while the caller still holds the reference, and the eventual ovpn_peer_put() from that caller operates on freed memory. Replace the direct destructor call with ovpn_peer_put() so the kref correctly defers destruction until the last reference is dropped. In the common case where no concurrent user is present, behaviour is unchanged: the kref hits zero immediately and ovpn_peer_release_kref() runs the same destructor. With this conversion ovpn_peer_release() has no callers outside peer.c - ovpn_peer_release_kref() in the same translation unit is the only remaining user - so make it static and drop its declaration from peer.h.
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/netlink.c
drivers/net/ovpn/peer.c
drivers/net/ovpn/peer.h
- 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
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.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 | 8298834912d7 |
| 6.16 | 7.0.11 | 0c3ef71879c0 |
| 6.16 | 7.1 | 1fef6614673f |
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 bug is triggered from the OVPN_CMD_PEER_NEW genetlink handler reached only via local netlink syscalls; remote TCP data can participate in the race but cannot alone reach the premature ovpn_peer_release() error path.
- AC:LAttack complexity, low
- Exploitation requires a race between a failing CMD_NEW_PEER netlink message and a concurrent local holder of a peer reference, and the attacker controls both sides by blocking recvmsg on the TCP fd while issuing the failing netlink command.
- PR:LPrivileges required, low
- All OVPN genetlink operations require GENL_ADMIN_PERM (CAP_NET_ADMIN), and creating the ovpn interface requires the same capability, which an unprivileged user can obtain inside a user namespace.
- UI:NUser interaction, none
- No victim interaction is required; the attacker configures the ovpn interface, TCP socket, and concurrent threads themselves to trigger the error-path UAF.
- S:UScope, unchanged
- The UAF corrupts kernel heap memory and enables standard kernel privilege escalation within the same security authority, not a cross-boundary escape such as guest-to-host or IOMMU bypass.
- C:HConfidentiality impact, high
- Use-after-free of struct ovpn_peer allows an attacker to read freed slab memory and obtain arbitrary kernel memory disclosure primitives.
- I:HIntegrity impact, high
- Use-after-free of struct ovpn_peer enables heap grooming and control of freed object contents, providing a path to arbitrary kernel memory writes and code execution.
- A:HAvailability impact, high
- The UAF causes ovpn_peer_put() to operate on freed memory, which can trigger kernel oops, panic, or crash during reference decrements on corrupted kref state.