CVE-2026-64109— Linux kernel 安全漏洞
一分钟漏洞结论
影响对象
Linux Linux
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
Linux kernel是美国Linux基金会开源的一款操作系统内核。 Linux kernel 4.2版本存在释放后重用漏洞，该漏洞源于unix_stream_data_wait()函数在读取接收队列时未持有锁，可能导致释放后重用。
可能的 ATT&CK 技术 1 AI
T1203 · Exploitation for Client Execution影响版本矩阵 12
| 厂商 | 产品 | 版本范围 | 状态 |
|---|---|---|---|
| Linux | Linux | 2b514574f7e88c8498027ee366fd6e7aae5aa4b5< 26342087fac93b3932e6af61dc91ec029cb8a623 |
affected |
2b514574f7e88c8498027ee366fd6e7aae5aa4b5< 38bccb927d83d7d52e5b20015a172a0b6101d11e |
affected | ||
2b514574f7e88c8498027ee366fd6e7aae5aa4b5< acdff9907478e82208475b1151700d0b71dcdc63 |
affected | ||
2b514574f7e88c8498027ee366fd6e7aae5aa4b5< 5f162f95a95834f06a8ec6140889272ad12e842f |
affected | ||
2b514574f7e88c8498027ee366fd6e7aae5aa4b5< be309f8eae8b474a4a617eaae01324da996fc719 |
affected | ||
4.2 |
affected | ||
< 4.2 |
unaffected | ||
6.6.143≤ 6.6.* |
unaffected | ||
| … +4 条更多 | |||
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2026-64109 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
af_unix: Fix UAF read of tail->len in unix_stream_data_wait()
来源: CVE Program / CVE List V5
Vulnerability Description
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.
来源: CVE Program / CVE List V5
CVSS Information
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
来源: CVE Program / CVE List V5
Vulnerability Type
N/A
来源: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
来源: 中国国家信息安全漏洞库 CNNVD
Vulnerability Description
Linux kernel是美国Linux基金会开源的一款操作系统内核。 Linux kernel 4.2版本存在释放后重用漏洞，该漏洞源于unix_stream_data_wait()函数在读取接收队列时未持有锁，可能导致释放后重用。
来源: 中国国家信息安全漏洞库 CNNVD
CVSS Information
N/A
来源: 中国国家信息安全漏洞库 CNNVD
Vulnerability Type
N/A
来源: 中国国家信息安全漏洞库 CNNVD
受影响产品
二、漏洞 CVE-2026-64109 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2026-64109 的情报信息
请登录查看更多情报信息。
CVE-2026-64109 补丁与修复 (5)
同批安全公告 · Linux · 2026-07-19 · 共 429 条
| CVE-2026-63795 | 10.0 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64102 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-53399 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-53398 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64089 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64025 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64091 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64113 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64037 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-63984 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-63800 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-63888 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-63887 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64136 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-63979 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64035 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64055 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64125 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64061 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64033 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
显示前 20 条，共 429 条。 查看全部 → →
IV. Related Vulnerabilities
V. Comments for CVE-2026-64109
暂无评论