Skip to main content

Linux Kernel EUVDEUVD-2026-45794

| CVE-2026-64109 HIGH
Use After Free (CWE-416)
2026-07-19 Linux GHSA-mh36-g5h5-fxqc
8.8
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Gain local user access on host
  2. Delivery
    Create AF_UNIX stream socket with SO_PEEK_OFF
  3. Exploit
    Race MSG_PEEK recv() against normal recv()+shutdown()
  4. Execution
    Peer thread frees tail SKB mid-wait
  5. Persist
    UAF read of tail->len in kernel
  6. Impact
    Kernel memory disclosure or crash (DoS)

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory lifecycle management
MITRE ATT&CK

2 techniques across 2 tactics: Execution, Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires local code execution as an unauthenticated-to-the-service but authenticated-to-the-system local user (CVSS PR:L), and depends on a specific runtime pattern rather than default idle behavior: the target AF_UNIX SOCK_STREAM socket must be exercised with a peeking recv() using MSG_PEEK/SO_PEEK_OFF concurrently with a normal recv() that dequeues and frees the tail SKB, so the attacker must win a timing race between two operations on the same socket. Limiting factors: the kernel must contain commit 2b514574f7e8 (roughly 6.5+; earlier kernels are not affected), access is local only (AV:L - no network reachability), and success is probabilistic because it hinges on hitting the narrow race window, which in practice is closer to high attack complexity than the vector's AC:L. The primitive is a read-only UAF, so realistic outcomes are kernel information disclosure or a crash rather than straightforward code execution.

Impact

The signals point to a real-but-low-priority local issue rather than a broadly exploitable one. The published CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, score 8.8) reflects the conventional inflated scoring applied to kernel UAFs, but it understates the difficulty: exploitation requires winning a tight race between two threads on the same socket, which realistically warrants AC:H, and the fix merely removes a read of tail->len, so the practical impact is a kernel-memory information disclosure (aligned with the 'Information Disclosure' tag) or a crash/DoS rather than full C:H/I:H/A:H. EPSS agrees this is not mass-exploited (0.17%, 6th percentile), the vulnerability is not in CISA KEV, and no weaponized public exploit is known. There is a discrepancy worth flagging: the vector claims AC:L while the description explicitly describes a narrow, timing-dependent race, and it claims I:H/A:H for what the maintainer characterizes as a read-only UAF whose earlier non-splice consequence was 'probably not a real problem.' Net assessment: patch in normal cycles; it is not an emergency for most fleets, but matters for multi-tenant hosts where untrusted local code runs.

Exploit ScenarioDerived

A local, low-privileged user on a shared Linux host creates an AF_UNIX SOCK_STREAM socketpair, sets SO_PEEK_OFF, then runs two threads that race a MSG_PEEK recv() against a normal recv()+shutdown(); if the normal path frees the tail SKB at the right instant, the peeking thread dereferences tail->len on freed memory, leaking kernel data or crashing the kernel. No weaponized public exploit is identified at time of analysis, but the fix commit publishes a concise reproducer demonstrating the race, and the local, low-complexity nature of the primitive makes reliable triggering plausible for an attacker willing to iterate the race.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jul 20, 2026

Use-after-free read in the Linux kernel's AF_UNIX stream socket handler (unix_stream_data_wait()) lets a local user leak or corrupt kernel memory state and potentially crash the system by racing a peeking recv() against a normal recv() on the same socket. The flaw affects kernels from ~6.5 onward, where unix_stream_data_wait() dereferences tail->len from an SKB read via skb_peek_tail() without a lock preventing that SKB from being concurrently dequeued and freed. EPSS is low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis, though the fix commit includes a race reproducer; the issue is fixed in stable releases.

RemediationAI

Vendor-released patch: upgrade to a fixed Linux stable release - 6.6.143, 6.12.92, 6.18.34, 7.0.11, or 7.1 (or later) matching your branch - and reboot into the patched kernel, since this is a core net/unix change with no runtime toggle. The fix simply removes the read of tail->len in unix_stream_data_wait(); apply your distribution's kernel update once it ships the corresponding commit (26342087fac9 / 38bccb927d83 / acdff9907478 / 5f162f95a958 / be309f8eae8b, see https://git.kernel.org/stable/c/). No standalone configuration workaround fully neutralizes the flaw because it is inherent to AF_UNIX stream/splice receive handling; as a compensating control on unpatched multi-tenant hosts, restrict the ability to run untrusted local code and consider containment (per-tenant VMs or seccomp/namespace restrictions on untrusted workloads) to reduce who can trigger the race - with the trade-off that AF_UNIX stream sockets are ubiquitous and cannot practically be disabled. Prioritize patching over mitigation.

Affected VersionsENISA

Linux patch: 6.18.34
Linux 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 <26342087fac93b3932e6af61dc91ec029cb8a623
Linux 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 <be309f8eae8b474a4a617eaae01324da996fc719
Linux patch: 6.6.143
Linux patch: 0
Linux 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 <acdff9907478e82208475b1151700d0b71dcdc63
Linux 4.2
Linux 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 <38bccb927d83d7d52e5b20015a172a0b6101d11e
Linux patch: 6.12.92
Linux patch: 7.1
Linux 2b514574f7e88c8498027ee366fd6e7aae5aa4b5 <5f162f95a95834f06a8ec6140889272ad12e842f
Linux patch: 7.0.11

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The vulnerability lives in the AF_UNIX stream socket receive path of the Linux networking stack (net/unix/af_unix.c). unix_stream_data_wait() calls skb_peek_tail(&sk->sk_receive_queue) to obtain the tail socket buffer (SKB) but does not hold sk_receive_queue.lock, so another thread executing unix_stream_read_generic() can __skb_unlink() and consume_skb() that same SKB concurrently. This is a classic use-after-free (CWE-416, though the input lists CWE as N/A) triggered by insufficient locking around a shared queue. The historical need to read tail->len came from commit 869e7c62486e (stream sendpage support), which allowed data to be appended to the last SKB; commits a0dbf5f818f9 (MSG_SPLICE_PAGES) and 57d44a354a43 removed that behavior so data now always lands in a new SKB, making the length re-check both unnecessary and dangerous. The dereference bug was introduced by commit 2b514574f7e8 (splice for stream AF_UNIX sockets), which is why the fix does not apply to kernels before 6.5. CPE data identifies the affected component simply as cpe:2.3:a:linux:linux.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (Linux) PRIMARY 8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI 5.3 MEDIUM

Local low-priv trigger (AV:L/PR:L), race condition forces AC:H; read-only UAF yields limited info leak (C:L) with the dominant impact being a kernel crash/DoS (A:H).

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE HIGH
Red Hat 7.0 MEDIUM

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

4
CVSS changed
Jul 20, 2026 - 15:22 NVD
8.8 (HIGH)
Patch available
Jul 19, 2026 - 17:03 EUVD
CVE Published
Jul 19, 2026 - 15:40 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 19, 2026 - 15:40 cve.org
HIGH 8.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

af_unix: Fix UAF read of tail->len in unix_stream_data_wait()

unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without holding any lock that prevents SKBs on that queue from being dequeued and freed. This has been the case since commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). The first consequence of this is that the pointer comparison tail != last can be false even if last semantically refers to an already-freed SKB while tail is a new SKB allocated at the same address; which can cause unix_stream_data_wait() to wrongly keep blocking after new data has arrived, but only in a weird scenario where a peeking recv() and a normal recv() on the same socket are racing, which is probably not a real problem.

But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets"), tail is actually dereferenced, which can cause UAF in the following race scenario (where test_setup() runs single-threaded, and afterwards, test_thread1() and test_thread2() run concurrently in two threads:

static int socks[2];
void test_setup(void) {
  socketpair(AF_UNIX, SOCK_STREAM, 0, socks);
  send(socks[1], "A", 1, 0);
  int peekoff = 1;
  setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff));
}
void test_thread1(void) {
  char dummy;
  recv(socks[0], &dummy, 1, MSG_PEEK);
}
void test_thread2(void) {
  char dummy;
  recv(socks[0], &dummy, 1, 0);
  shutdown(socks[1], SHUT_WR);
}

when racing like this:

thread1                       thread2
unix_stream_read_generic
  mutex_lock(&u->iolock)
  skb_peek(&sk->sk_receive_queue)
  skb_peek_next(skb, &sk->sk_receive_queue)
  mutex_unlock(&u->iolock)
                              unix_stream_read_generic
                                unix_state_lock(sk)
                                skb_peek(&sk->sk_receive_queue)
                                unix_state_unlock(sk)
  unix_stream_data_wait
    unix_state_lock(sk)
    tail = skb_peek_tail(&sk->sk_receive_queue)
                                spin_lock(&sk->sk_receive_queue.lock)
                                __skb_unlink(skb, &sk->sk_receive_queue)
                                spin_unlock(&sk->sk_receive_queue.lock)
                                consume_skb(skb) [frees the SKB]
    `tail != last`: false
    `tail`: true
    `tail->len != last_len` ***UAF***

Fix the UAF by removing the read of tail->len; checking tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no longer happen.

Kuniyuki explained:

> When commit 869e7c62486e ("net: af_unix: implement stream sendpage > support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > > That's why we needed to check if the length of the last skb was changed > while waiting for new data in unix_stream_data_wait(). > > However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and > commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use > MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added > to a new skb.

That means this fix is not suitable for kernels before 6.5.

Executive ViewAI

Why It Matters

A use-after-free vulnerability in Linux kernels version 6.5 and later enables local users to trigger kernel memory leaks or system crashes, exposing production infrastructure to operational disruption and data exposure. Affected systems span servers, workstations, and containerized environments across enterprises relying on vulnerable kernel versions. Immediate patching is critical to eliminate the local attack surface.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 94% exploitable
Prevalence
Ubiquitous
Linux kernel runs on nearly all Linux servers, cloud, and Android devices
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact
High

Priority Score

44
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Use-after-free vulnerabilities occur when a program continues to access memory through a pointer after that memory has been deallocated.

Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy