CVE-2026-64044: ovpn: respect peer refcount in CMD_NEW_PEER error path
In the Linux kernel, the following vulnerability has been resolved:
ovpn: respect peer refcount in CMD_NEW_PEER error path
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.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can let a low-privileged local user trigger memory corruption in the ovpn subsystem during a failed TCP peer creation path. The reported impact is high because successful exploitation could compromise confidentiality, integrity, and availability of the host.
Executive priority
Treat as high priority for Linux fleets where low-privileged users, containers, or shared workloads exist. Patch through normal emergency kernel channels once vendor packages are available; escalate faster for systems using ovpn functionality.
Technical view
The error path in ovpn_nl_peer_new_doit() called ovpn_peer_release() directly instead of ovpn_peer_put(), bypassing kref handling. For TCP, userspace and strparser paths can still hold peer references through sk_user_data, creating a use-after-free when the failed setup path destroys the peer prematurely.
Likely exposure
Exposure is most relevant to Linux systems with the affected ovpn kernel code enabled or reachable by low-privileged local users. The source bundle lists Linux as affected, but version data is not sufficient to map every distribution kernel.
Exploitation context
The CVSS vector is local, low complexity, low privileges, and no user interaction. The bundle does not report active exploitation, and KEV is false. No remote unauthenticated exploitation is supported by the provided evidence.
Researcher notes
The key bug is a reference-counting error specific to the TCP path after ovpn_socket_new() publishes ovpn_sock. The fix replaces direct destruction with ovpn_peer_put(), preserving kref semantics and deferring peer cleanup until all references are dropped.
Mitigation direction
Apply Linux distribution kernel updates that include the referenced stable fixes.
If patching is delayed, check vendor guidance for supported ovpn workarounds.
Reduce untrusted local user access on affected systems until remediated.
Prioritize multi-user hosts and systems running ovpn-related functionality.
Validation and detection
Inventory running kernel versions across Linux systems.
Check vendor advisories for CVE-2026-64044 coverage and fixed package versions.
Confirm whether referenced stable commits are present in deployed kernels.
Assess whether ovpn kernel functionality is enabled or used.
Review local shell, container, and service-account access on exposed hosts.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-64044 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.