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

  - procfs避免在保持 VMA 锁定的情况下提取版本 ID 修复 PROCMAP_QUERY 以便仅在放置 mmap_lock 或每个 VMA 的锁定（以用于锁定相关 VMA 的任何一个）之后提取可选的版本 ID 以避免 syzbot 报告的死锁-> #1 (&mm ->mmap_lock){++++}-{4:4}__might_fault+0xed/0x170
    _copy_to_iter+0x118/0x1720 copy_page_to_iter+0x12d/0x1e0 filemap_read+0x720/0x10a0 blkdev_read_iter+0x2b5/0x4e0 vfs_read+0x7f4/0xae0 ksys_read+0x12a/0x250 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&sb->s_type- >i_mutex_key#8){++++}-{4:4}:
    __lock_acquire+0x1509/0x26d0 lock_acquire+0x185/0x340 down_read+0x98/0x490 blkdev_read_iter+0x2a7/0x4e0
    __kernel_read+0x39a/0xa90 freader_fetch+0x1d5/0xa80 __build_id_parse.isra.0+0xea/0x6a0 do_procmap_query+0xd75/0x1050 procfs_procmap_ioctl+0x7a/0xb0 __x64_sys_ioctl+0x18e/0x210 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this可能不安全的锁定情况CPU0 CPU1 ---- ---- rlock(&mm->mmap_lock);
    lock(&sb->s_type->i_mutex_key#8) lock(&mm->mmap_lock); rlock(&sb->s_type->i_mutex_key#8) *** 死锁
    *** 这种情况似乎因最近的
    777a8560fd29 (lib/buildid将 __kernel_read() 用于可休眠环境为确保此问题我们需要在 VMA 仍处于锁定状态时获取文件引用计数但除此之外一切都非常简单。
    内部 build_id_parse() API 假设 VMA 已传递但由于仅需要基础文件引用因此只需添加另一个预期文件会直接传递的 build_id_parse_file() 变体。 [akpm@linux-foundation.org修复 kerneldoc] (CVE-2026-23199)

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

检测

Linux Distros 未修补的漏洞：CVE-2026-23199

medium Nessus 插件 ID 299123

版本 1.18