CVE-2026-64044
Last modified
CVE-2026-64044 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. 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. EPSS estimates a 0.17% chance of exploitation in the next 30 days.
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.
Metrics
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Affected Software
Source: CNA advisory (CVE.org). NVD analysis pending.
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux | >= 11851cbd60ea1e5abbd97619d69845ead99303d6, < 8298834912d76dbc82c12b6b4ab7590ed2bb8ae5; >= 11851cbd60ea1e5abbd97619d69845ead99303d6, < 0c3ef71879c0264de6c42463031d9e057da87840; >= 11851cbd60ea1e5abbd97619d69845ead99303d6, < 1fef6614673ff0846d30acdeeaf3cf98bb5f6116 |
| Linux | Linux | 6.16 |
References
Timeline
- Published
- Last Modified
- Status
- Awaiting Analysis
Frequently Asked Questions
What is CVE-2026-64044?
How severe is CVE-2026-64044?
How do I fix CVE-2026-64044?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2026
- CVE-2026-64039In the Linux kernel, the following vulnerability has been re…7.7
- CVE-2026-6404The Anomify AI – Anomaly Detection and Alerting plugin for W…4.4
- CVE-2026-64040In the Linux kernel, the following vulnerability has been re…
- CVE-2026-64041In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-64042In the Linux kernel, the following vulnerability has been re…8.8
- CVE-2026-64043In the Linux kernel, the following vulnerability has been re…
- CVE-2026-64045In the Linux kernel, the following vulnerability has been re…8.4
- CVE-2026-64046In the Linux kernel, the following vulnerability has been re…9.8
- CVE-2026-64047In the Linux kernel, the following vulnerability has been re…9.8
- CVE-2026-64048In the Linux kernel, the following vulnerability has been re…7.5
- CVE-2026-64049In the Linux kernel, the following vulnerability has been re…
- CVE-2026-6405The Anomify AI – Anomaly Detection and Alerting plugin for W…4.3
Are you affected by CVE-2026-64044?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
