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… (CVE-2026-64044)
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.
AI Analysis
Technical Summary
The Linux kernel's ovpn_nl_peer_new_doit() function had an error path that called ovpn_peer_release() directly, bypassing the kernel reference counting (kref) mechanism. While this was safe for UDP peers due to their lifecycle and lookup methods, TCP peers are fully wired to userspace file descriptors and can be concurrently accessed. This improper handling can cause the peer object to be destroyed while still referenced by userspace, leading to use-after-free scenarios. The patch replaces the direct call to ovpn_peer_release() with ovpn_peer_put(), ensuring that destruction is deferred until no references remain. This change also confines ovpn_peer_release() usage to peer.c, making it static and removing its header declaration.
Potential Impact
The vulnerability can cause use-after-free conditions in the Linux kernel's OpenVPN TCP peer handling code. This may lead to kernel memory corruption or crashes if a peer object is destroyed while still referenced by userspace operations. No known exploits are reported in the wild. The impact is limited to systems running the affected Linux kernel code with OpenVPN TCP peers in use.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability description indicates that a code fix has been implemented to replace ovpn_peer_release() calls with ovpn_peer_put() to properly manage reference counting. Users should monitor official Linux kernel advisories and update to a kernel version that includes this fix once available.
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… (CVE-2026-64044)
Description
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.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's ovpn_nl_peer_new_doit() function had an error path that called ovpn_peer_release() directly, bypassing the kernel reference counting (kref) mechanism. While this was safe for UDP peers due to their lifecycle and lookup methods, TCP peers are fully wired to userspace file descriptors and can be concurrently accessed. This improper handling can cause the peer object to be destroyed while still referenced by userspace, leading to use-after-free scenarios. The patch replaces the direct call to ovpn_peer_release() with ovpn_peer_put(), ensuring that destruction is deferred until no references remain. This change also confines ovpn_peer_release() usage to peer.c, making it static and removing its header declaration.
Potential Impact
The vulnerability can cause use-after-free conditions in the Linux kernel's OpenVPN TCP peer handling code. This may lead to kernel memory corruption or crashes if a peer object is destroyed while still referenced by userspace operations. No known exploits are reported in the wild. The impact is limited to systems running the affected Linux kernel code with OpenVPN TCP peers in use.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability description indicates that a code fix has been implemented to replace ovpn_peer_release() calls with ovpn_peer_put() to properly manage reference counting. Users should monitor official Linux kernel advisories and update to a kernel version that includes this fix once available.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-52jg-m8r4-36g9
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64044"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27a92a4a8d598912ceed
Added to database: 07/19/2026, 19:38:17 UTC
Last enriched: 07/19/2026, 19:56:36 UTC
Last updated: 07/20/2026, 19:41:22 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.