Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - af_unix不保留连续使用的 OOB skb。Jann Horn 报告了 unix_stream_read_generic() 中的释放后使用。以下序列重现此问题$ python3 from socket import * s1, s2 = socketpair(AF_UNIX, SOCK_STREAM) s1.send(b'x', MSG_OOB) s2.recv(1, MSG_OOB) # keep a Consumer OOB skb s1。 send(b'y', MSG_OOB) s2.recv(1, MSG_OOB) # 保留使用过的 OOB skb s1.send(b'z', MSG_OOB) s2.recv(1) # 非法接收“z”s2.recv( 1、MSG_OOB# 访问“z”skb释放后使用即使用户读取了 OOB 数据，保存数据的 skb 仍会留在 recv 队列中，以标记 OOB 边界并中断下一个 recv()。在上述情况中的最后一个 send() 之后sk2 的 recv 队列有 2 个主要消耗的 OOB skb和 1 个实际的 OOB skb。然后在下一个没有 MSG_OOB 1 的 recv() 期间发生以下情况。
    unix_stream_read_generic() 查看第一个消耗的 OOB skb 2. Manage_oob() 返回下一个消耗的 OOB skb 3. unix_stream_read_generic() 获取下一个未消耗的 OOB skb 4. unix_stream_read_generic() 读取并释放 OOB skb最后一个recv(MSG_OOB) 触发 KASAN splat。3. 发生上述情况是因为 SO_PEEK_OFF 代码未预期 unix_skb_len(skb) 为 0但对于此类消耗的 OOB skb 而言即是如此。 while (skip >= unix_skb_len(skb)) { skip -= unix_skb_len(skb); skb = skb_peek_next(skb, &sk->sk_receive_queue); ... } 除了此释放后使用错误还存在一个问题即 ioctl(SIOCATMARK) 无法对连续使用的 OOB skb 正常工作。因此这种情况不会有任何好处。我们不应通过引入连续消耗的 OOB skb 的循环来使 managed_oob()、ioctl() 处理和下一个 ECONNRESET 补丁复杂化而是不要不必要地保留此类连续 OOB。现在在 unix_stream_recv_urg() 中接收 OOB skb 时如果其先前的 skb 是已消耗的 OOB skb则会将其释放。 [0]BUGKASANunix_stream_read_actor (net/unix/af_unix.c:3027) 在 addr ffff888106ef2904 处大小为 4 的读取由任务 python3/315 CPU: 2 UID: 0 PID:
    315 Commpython3 Not tainted 6.16.0-rc1-00407-gec315832f6f9 #8 PREEMPT(自主) Hardware nameQEMU Standard PC (i440FX + PIIX,1996)BIOS 1.16.3-4.fc42 04/01/2014 Call Trace <TASK> dump_stack_lvl (lib/dump_stack.c:122) print_report mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:636) unix_stream_read_actor (net/unix/af_unix.c:3027) unix_stream_read_generic (net/unix/af_unix .c:2708 net/unix/af_unix.c:2847) unix_stream_recvmsg (net/unix/af_unix.c:3048) sock_recvmsg (net/socket.c:1063标识符 20) net/socket.c:1085标识符 20 ) __sys_recvfrom (net/socket.c:2278) __x64_sys_recvfrom (net/socket.c:2291标识符 1) net/socket.c:2287标识符 1net/socket.c:2287标识符 1) do_syscall_64 (arch /x86/entry/syscall_64.c:63标识符 1arch/x86/entry/syscall_64.c:94标识符 1entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f8911fcea06 代码::5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP002b:00007fffdb0dccb0 EFLAGS00000202 ORIG_RAX
    000000000000002d RAX: ffffffffffffffda RBX: 00007fffdb0dcdc8 RCX: 00007f8911fcea06 RDX: 0000000000000001 RSI: 00007f8911a5e060 RDI: 0000000000000006 RBP: 00007fffdb0dccd0 R08: 0000000000000000 R09:
     R100000000000000000  : 0000000000000001 R11: 0000000000000202 R12: 00007f89119a7d20 R13: ffffffffc4653600 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 315: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/ common.c:60标识符 1mm/kasan/common.c:69标识符 1) __kasan_slab_alloc (mm/kasan/common.c:348) kmem_cache_alloc_ ---truncated--- (CVE-2025-38236)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2025-38236

high Nessus 插件 ID 249865

版本 1.6