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

  - erofs修复了具有 directio 选项的文件支持的挂载的 UAF 问题 [ 9.269940][ T3222] 调用跟踪[9.269948][ T3222] ext4_file_read_iter+0xac/0x108 [ 9.269979][ T3222] vfs_iocb_iter_read+0xac /0x198 [9.269993][ T3222] erofs_fileio_rq_submit+0x12c/0x180 [ 9.270008][ T3222] erofs_fileio_submit_bio+0x14/0x24 [ 9.270030][ T3222] z_erofs_runqueue+0x834/0x8ac [ 9.270054][ T3222] z_erofs_read_folio +0x120/0x220 [9.270083][ T3222] filemap_read_folio+0x60/0x120 [ 9.270102][ T3222] filemap_fault+0xcac/0x1060 [9.270119][ T3222] do_pte_missing+0x2d8/0x1554 [ 9.270131][ T3222] handle_mm_fault+0x5ec/0x70c [ 9.270142][T3222] do_page_fault+0x178/0x88c [ 9.270167][ T3222] do_translation_fault+0x38/0x54 [ 9.270183][ T3222] do_mem_abort+0x54/0xac [ 9.270208][ T3222] el0_da+0x44/0x7c [ 9.270227][ T3222] el0t_64_sync_handler+0x5c/0xf4 [ 9.270253][ T3222] el0t_64_sync+0x1bc/0x1c0 EROFS 在启用带 directio 挂载选项的文件支持挂载时可能会遇到上述错误根本原因是其可能在下列争用条件中遭受 UAF- z_erofs_read_folio wq s_dio_done_wq - z_erofs_runqueue - erofs_fileio_submit_bio - erofs_file io_rq_submit - vfs_iocb_iter_read - ext4_file_read_iter - ext4_dio_read_iter - iomap_dio_rw
    bio 已提交并返回 -EIOCBQUEUED - dio_aio_complete_work - dio_complete - dio->iocb->ki_complete (erofs_fileio_ki_complete()) - kfree(rq) 它释放 iocb, iocb.ki_filp 可以是 file_accessed() 中的 UAF。 - file_accessed 访问空文件点在结构 erofs_fileio_rq 中引入引用计数并将其初始化为二erofs_fileio_ki_complete() 和 erofs_fileio_rq_submit() 都将减少引用计数最后一个将引用计数减少至零将释放 rq。 (CVE-2026-23224)

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

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

  - nilfs2修复 可能造成系统挂起的块溢出 用户执行 FITRIM 命令时如果 end_block 太小则在计算 nblocks 时可能发生下溢。由于 nblocks 的类型为ector_t即 u64负的 nblocks 值将变成一个非常大的正整数。这最终导致区块层函数 __blkdev_issue_discard() 花费过长的时间来处理 bio 链并且 ns_segctor_sem 锁定长时间保持保持状态。这会阻止其他任务获取 ns_segctor_sem 锁定从而导致 [1] 中的 syzbot 报告的挂起。如果结束块太小通常小于 4KiB 范围根据段 0 的使用情况可能尝试丢弃超出设备大小的请求从而导致挂起。成功退出并将丢弃的大小（在本例中为 0）分配给 range->len。虽然用户输入范围中的 start 和 len 值过小但此处采用保守策略可以安全地忽略它们这等同于 no-op它不会执行任何裁剪也不会抛出错误。 [1] task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000 调用跟踪
    rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [内联] nilfs_segctor_thread+0x6ec/0xe020 fs/nlfs20 segment.c:2684 [ryusuke已修正关于后果的部分提交消息] (CVE-2025-71237)

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

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

  - wifirtw88修复了 rtw_core_enable_beacon() 中的对齐错误 rtw_core_enable_beacon() 从不是 4 的倍数的地址读取 4 个字节。这会导致在某些系统上崩溃。改为执行 1 字节读取/写入。无法处理虚拟地址 ffff8000827e0522 Mem abort info: ESR = 0x0000000096000021 EC = 0x25DABT当前 ELIL = 32 位 SET = 0FnV = 0 EA = 0S1PTW = 0 FSC = 0x21对齐Fault Data 中止信息ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000005492000 [ffff8000827e0522] pgd=0000000000000000, p4d=10000001021d9403, pud=10000001021da403, pmd=100000011061c403, pte=00780000f3200f13 内部错误Oops: 0000000096000021 [#1] SMP Modules 中链接的问题[...] rtw88_8822ce rtw88_8822c rtw88_pci rtw88_core [...] CPU0 UID0 PID73 Commkworker/u32:2 受感染的 GW 6.17.9 #1-NixOS VOLUNTARY 受感染的 [W]=WARN 硬件名称FriendlyElec nanoPC-T6 LTS (DT) 工作队列phy0 rtw_c2h_work [rtw88_core] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc rtw_pci_read32+0x18/0x40 [rtw88_pci] lr : rtw_core_enable_beacon+0xe0/0x148 [rtw88_core] sp
    ffff800080cc3ca0 x29: ffff800080cc3ca0 x28: ffff0001031fc240 x27: ffff000102100828 x26: ffffd2cb7c9b4088 x25: ffff0001031fc2c0 x24: ffff000112fdef00 x23: ffff000112fdef18 x22: ffff000111c29970 x21:
    0000000000000001 x20: 0000000000000001 x19: ffff000111c22040 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12:
    0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffd2cb6507c090 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 :
    0000000000000000 x2 : 0000000000007f10 x1 : 0000000000000522 x0 : ffff8000827e0522 调用跟踪
    rtw_pci_read32+0x18/0x40 [rtw88_pci] (P) rtw_hw_scan_chan_switch+0x124/0x1a8 [rtw88_core] rtw_fw_c2h_cmd_handle+0x254/0x290 [rtw88_core] rtw_c2h_work+0x50/0x98 [rtw88_core] process_one_work+0x178/0x3f8 worker_thread+0x208/0x418 kthread+0x120/0x220 ret_from_fork+0x10/0x20 代码
    d28fe202 8b020000 f9524400 8b214000 (b9400000) ---[ 结束跟踪 0000000000000000 ]--- (CVE-2025-71229)

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

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

  - gpioloongson-64bit修复 devm_kcalloc() 之后错误的空检查 修复 loongson_gpio_init_irqchip() 中错误的空检查。该函数检查chip->parent 而非chip->irq.parents。
    (CVE-2026-23218)

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

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

  - btrfs如果 fs 为完全只读则拒绝新事务 [BUG] 在缺陷报告中使用所有急救挂载选项挂载了严重模糊的 fs可能会在卸载期间出现以下警告
    BTRFS事务中止错误 -22模块中的链接CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) 硬件名称QEMU Standard PC i440FX + PIIX、1996、BIOS 1.15.0-1 04/01/2014 RIP0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent- tree.c:4611 调用跟踪 <TASK> btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs /ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/sup er.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/ namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [内联] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit .c:1112 __do_sys_exit_group kernel/exit.c:1123 [内联]
    __se_sys_exit_group kernel/exit.c:1121 [内联] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/ syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:0033:0x44f639 代码无法访问位于 0x44f60f 的 opcode 字节。RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI:
    0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15:
    0000000000000001 </TASK> 由于 rescue 挂载选项将标记完全 fs 只读因此应该不会触发新的事务。但是在卸载期间我们将逐出所有 inode这可触发新事务并在严重损坏的 fs 上触发警告。[原因] 即使在只读 fs 上Btrfs 也允许新事务这是为了即使在只读挂载上也允许发生日志重播就像 ext4/xfs 一样。
    但是使用 rescue 挂载选项时fs 为完全只读且无法重新挂载以进行读写因此在这种情况下我们还应拒绝任何新事务。[修复] 如果发现 fs 具有 rescue 挂载选项我们应将此 fs 视为错误以便启动任何新事务。 (CVE-2026-23214)

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

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

  - drm/exynosvidi使用 ctx->lock 保护与内存分配/释放相关的 struct vidi_context 成员变量 Exynos 虚拟显示驱动程序在没有锁定保护的情况下执行内存分配/释放操作这容易造成并发问题。例如在像这样的争用场景中可能会发生释放后使用
    `` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // 假 ... vidi_connection_ioctl() if (vidi->connection) // 假 drm_edid_free(ctx->raw_edid); // 释放 drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF ... `为了防止这些漏洞至少在 vidi_context 中与内存分配/释放相关的成员变量应使用 ctx->lock 保护。 (CVE-2026-23227)

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

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

  - smb服务器修复 ksmbd_tcp_new_connection() 中的 active_num_conn 泄露 当 ksmbd_tcp_new_connection() 中的 kthread_run() 失败时通过 free_transport() 释放传输不会减少 active_num_conn进而泄露此计数器。将 free_transport() 替换为 ksmbd_tcp_disconnect()。
    (CVE-2026-23228)

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

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

  - drm/amd/pm在 SMU 模式 1 重置期间禁用 MMIO 访问在模式 1 重置期间ASIC 会进入重置周期并暂时无法通过 PCIe 访问。在此窗口期间任何访问 MMIO 寄存器的尝试例如来自中断处理程序或其他驱动程序线程都可能导致 PCIe 事务未完成从而导致 NMI 错误或系统挂起。若要防止此问题发生请在触发重置之后立即将“no_hw_access”标记设置为 true。这会向其他驱动程序组件发出信号，要求其在设备脱机时跳过寄存器访问。已添加内存屏障“smp_mb()”以确保在驱动程序进入休眠/等待状态之前标记更新对所有核心全局可见。从提交 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4 中精选出的内容(CVE-2026-23213)

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

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

  - 在低于 6.2.1的universal-ctags ctags 中发现一个漏洞。受影响的元素是组件 V Language Parser 的 parsers/vc 文件的 parseExpression/parseExprList 函数。执行操纵可导致不受控制的递归。可以在本地主机上发起攻击。
    漏洞利用已公之于众可被用于攻击。及早通过问题报告将该问题告知项目但尚未回应。 (CVE-2026-2641)

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

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

  - 1.3.2 之前版本的 zlib 允许通过 crc32_combine64 和 crc32_combine_gen64 消耗 CPU因为x2nmodp 可在不具有终止条件的循环内右移。 (CVE-2026-27171)

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

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

  - 在最高 2.2.0的niklasso minisat 中发现一个漏洞。此问题会影响组件 DIMACS 文件解析器的库 core/SolverTypes.h 中的函数 Solver::value。这种对输入 2147483648 的参数变量索引的操纵导致越界读取。攻击需在本地启动。漏洞利用已公之于众可被用于攻击。及早通过问题报告将该问题告知项目但尚未回应。
    (CVE-2026-2644)

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

远程主机上安装的 AHV 版本低于 AHV-10.3.1.3。因此如公告 NXSA-AHV-10.3.1.3 所述受到多个漏洞的影响。

  - 在低于 3.0的OpenSSL 版本构建的 libssh 中发现一个缺陷尤其是在负责密钥导出的 ssh_kdf() 函数中。由于对返回值的不一致解释OpenSSL 使用 0 表示失败而 libssh 使用 0 表示成功此函数可能会错误地返回成功状态即使密钥派生失败。如此会导致在后续通信中使用未初始化的加密密钥缓冲区从而可能危害 SSH 会话的机密性、完整性和可用性。 (CVE-2025-5372)

  - 当与 LUKS1 磁盘加密格式配合使用时在 luksmeta 实用工具中发现数据损坏漏洞。具有必要权限的攻击者可通过将大量元数据写入加密设备以利用此缺陷。实用工具无法正确验证可用空间从而导致元数据覆盖和损坏用户的加密数据。此操作会导致存储的信息永久丢失。使用 LUKS1 以外的 LUKS 格式的设备不受此问题的影响。 (CVE-2025-11568)

  - 2.7.2 之前的 Expat 中的 libexpat 允许攻击者通过提交用于解析的小文档来触发大型动态内存分配。 (CVE-2025-59375)

  - 在某些情况下BIND 在接受来自答案的记录时过于宽松允许攻击者将伪造的数据注入缓存。此问题会影响 BIND 9 版本 9.11.0 至 9.16.50、 9.18.0 至 9.18.39、 9.20.0 至 9.20.13、 9.21.0 至 9.21.12、9.11.3-S1 至 9.16.50-S1、9.18.11-S1 至 9.18。 39-S1 以及 9.20.9-S1 至 9.20.13-S1。 (CVE-2025-40778)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

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

  - Apache Tomcat Native、Apache Tomcat 中的不当输入验证漏洞。使用 OCSP 响应器时Tomcat Native以及 Tomcat Native 代码的 Tomcat 的 FFM 端口未对 OCSP 响应完成验证或最新性检查可允许绕过证书吊销。该问题影响 Apache Tomcat Native 从 1.3.0 到 1.3.4、从 2.0.0 到 2.0.11Apache Tomcat
    从 11.0.0-M1 到 11.0.17、从 10.1.0-M7 到 10.1.51、从 9.0.83 到 9.0.114。创建 CVE 时以下版本的生命周期已终止但已知会受到影响 从 1.1.23 到 1.1.34从 1.2.0 到 1.2.39。较旧的 EOL 版本不受影响。建议 Apache Tomcat Native 用户升级到版本 1.3.5 或更高版本或者升级到 2.0.12 或更高版本这些版本修复了该问题。建议 Apache Tomcat 用户升级到版本 11.0.18 或更高版本、 10.1.52 或更高版本或 9.0.115 或更高版本这些版本修复了该问题。 (CVE-2026-24734)

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

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

  - mmcsdhci-of-dwcmshc防止 HS200/HS400 模式中的非法时钟降低。在 HS200 或 HS400 时序模式下操作时将时钟频率降低到 52 MHz 以下将导致链接中断因为 Rockchip DWC MSHC 控制器需要维护这些模式下的最小时钟为 52 MHz。添加检查以防止通过 debugfs 非法降低时钟 root@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clock root@debian:/# [ 30.090146] mmc0运行 CQE 恢复 mmc0: cqhci失败停止 mmc0: cqhci标签 0 的虚假 TCN 警告: drivers/mmc/host/cqhci-core.c:797 at cqhci_irq+0x254/0x818、 CPU#1: kworker/1:0H/24 模块中链接的CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT 硬件名称：Rockchip RK3588 EVB1 V10 Board (DT) Workqueue: kblockd blk_mq_run_work_fn pstate: 604000c9 nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc
    cqhci_irq+0x254/0x818 lrcqhci_irq+0x254/0x818 ... (CVE-2025-71200)

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

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

  - 在 30.2.2之前的 OpenStack Nova 、 31.2.1之前的 OpenStack Nova 31 和 32.1.1之前的 OpenStack Nova 32 中发现一个问题。通过将恶意 QCOW 标头写入根磁盘或临时磁盘然后触发调整大小用户可诱使 Nova 的 Flat 图像后端调用无格式限制的 qemu-img进而导致不安全的图像调整大小操作可破坏主机上的数据有关的矢量影响可用性。仅使用平面图像后端通常配置为 use_cow_images=False的计算节点会受到影响。 (CVE-2026-24708)

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

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

  - 中断新选项卡页面加载的恶意脚本可造成地址栏和页面内容不同步从而允许攻击者在受信任的域下伪造任意 HTML。此漏洞影响 iOS < 的 Firefox 147.2.1。 (CVE-2026-2032)

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

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

  - netwwant7xx修复 RX 路径中潜在的 skb->frags 溢出在 DPMAIF RX 路径中接收数据时t7xx_dpmaif_set_frag_to_skb() 函数会将页面碎片添加到 skb且不会检查碎片数是否超过 MAX_SKB_FRAGS。这可能导致 skb_shinfo(skb)->frags[] 数组中发生缓冲区溢出进而破坏邻近内存并可能造成内核崩溃或其他不明行为。是通过静态代码分析通过与 mt76 驱动程序提交 b102f0c522cf 中修复的类似漏洞进行比较发现此问题是 mt76修复接收数据包碎片过多时的数组溢出。
    调制解调器固件发送的数据包含有过多碎片时可触发此漏洞。虽然在正常协议条件下（MTU 3080 字节，BAT 缓冲区 3584 字节）单个数据包不应需要额外的碎片，但内核不应盲目信任固件行为。恶意、有缺陷或遭到破坏的固件可能会构建具有比内核预期更多的碎片的数据包。修复此问题的方法是在调用 skb_add_rx_frag() 之前添加边界检查以确保 nr_frags 不超过 MAX_SKB_FRAGS。必须在取消映射之前执行检查，以避免设备拆卸期间发生页面泄漏和双重 DMA 取消映射。 (CVE-2026-23172)

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

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

  - drm/amdgpu修复 amdgpu_gmc_filter_faults_remove 中的空指针取消引用 在 Raven 和 Renoir 等 APU 上GC 9.1.0、 9.2.2、 9.3.0] 中ih1 和 ih2 中断环缓冲区未初始化。这是设计使然，因为这些辅助 IH 环仅在独立的 GPU 上可用。请参阅 vega10_ih_sw_init()其在设置 AMD_IS_APU 时明确跳过 ih1/ih2 初始化。但是amdgpu_gmc_filter_faults_remove() 会无条件使用 ih1 来获取上一个中断条目的时间戳。当 APU 上启用重试错误 (noretry=0) 时将从 SVM 页面错误恢复路径调用此函数导致 amdgpu_ih_decode_iv_ts_helper() 尝试访问 ih->ring[] 时发生空指针取消引用。崩溃表现为缺陷内核空指针取消引用地址0000000000000004 RIP
    0010amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu] 调用跟踪
    amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu] svm_range_restore_pages+0xae5/0x11c0 [amdgpu] amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu] gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu] amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu] amdgpu_ih_process+0x84/0x100 [amdgpu] This issue由提交 1446226d32a4drm/amdgpu从 noretry=1 中删除 GC HW IP 9.3.0 暴露出其将 Renoir APU 的默认值从 noretry=1 更改为 noretry=0从而启用重试错误处理并因此使用有缺陷的代码路径。通过在尝试使用 ih1.ring_size 之前添加检查来修复此问题。还从提交 dd299441654fdrm/amdgpu返工 retry 错误删除中还原 soft_ih 支持。如果硬件不支持辅助 HW IH 环则需要执行此操作。 v2其他更新 (Alex)从提交 6ce8d536c80aa1f059e82184f0d1994436b1d526 中精选出的内容(CVE-2026-23163)

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

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

  - 序列修复未设置 tty->port 的争用条件恢复提交 bfc467db60b7序列号删除冗余的 tty_port_link_device()因为 tty_port_link_device() 非冗余必须在调用 uart_configure_port() 之前配置 tty->port否则会出错用户空间可在 TTY 未链接到驱动程序的情况下打开控制台。已明确添加此 tty_port_link_device() 以避免提交 fb2b90014d78tty链接 tty 和端口在将其配置为控制台之前的此问题因此有问题的提交基本上还原了补丁称其为多余而没有解决此处显示的实际争用条件。
    在禁用了大多数设备的 Qualcomm SoC 上始终可重现为 tty->port 警告因此启动非常快并且将一个串行设备作为控制台printk旧控制台 [ttyMSM0] 已启用 printk旧控制台 [ttyMSM0] 已启用 printk旧bootconsole [qcom_geni0] 已禁用 printk旧的 bootconsole [qcom_geni0] 已禁用 ------------[ 在此处切出 ]------------ tty_init_devttyMSM 驱动程序未设置 tty- >port。这会使内核崩溃。修复驱动程序! 警告 drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c、 CPU#2: systemd/1 模块socinfo tcsrcc_elza gcc_elza sm3_ce fuse ipv6 CPU: 2 UID: 0 PID: 1 Comm: systemd受感染的 GS 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT 受感染的[S]=CPU_OUT_OF_SPEC 硬件名称 Qualcomm Technologies, Inc. Eliza (DT) ...
    tty_init_dev.part.0 (drivers/tty/tty_io.c:1414标识符 11) (P) tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95标识符 3) drivers/tty/tty_io.c 2073标识符 3drivers/tty/tty_io.c:2120标识符 3) chrdev_open (fs/char_dev.c:411) do_dentry_open (fs/open.c:962) vfs_open (fs/open.c:1094) do_open (fs/namei.c:4634) path_openat (fs/namei.c:4793) do_filp_open (fs/namei.c:4820) do_sys_openat2 (fs/open.c:1391标识符 3) ... 正在启动网络名称解析... 显然这个基于 Yocto 的小型 ramdisk 用户空间的流程为driver (qcom_geni_serial.c): user-space: ======================== ==== =========== qcom_geni_serial_probe() uart_add_one_port() serial_core_register_port() serial_core_add_one_port() uart_configure_port() register_console() | == |打开控制台 | ... tty_init_dev() | tty_init_dev() | driver->ports[idx] 为空 | tty_port_register_device_attr_serdev() tty_port_link_device() <- set driver->ports[idx] (CVE-2026-23115)

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

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

  - btrfszlib修复 S390 硬件加速 [缺陷] 提交 aa60fe12b4f4 之后上的对开泄漏btrfs
    zlib重构 S390x HW 加速缓冲区准备中我们不再释放 folio 的页面缓存作品集由 btrfs_compress_filemap_get_folio() 返回用于 S390 硬件加速路径。[原因] 在该提交之前我们会在处理每个 folio 后调用 kumap_local() 和 folio_put()。尽管时间安排并不理想（它在循环开始时释放之前的 folio，并依赖于循环外的某些额外清理），但它至少可以正确处理 folio 释放。同时重构的代码更易于阅读它缺少对释放 filemap folio 的调用。[修复] 为 copy_data_into_buffer() 添加缺少的 folio_put()。 (CVE-2026-23147)

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

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

  - ext4修复 ext4_xattr_inode_update_ref 中的 iloc.bh 泄漏 ext4_xattr_inode_update_ref 的错误分支忘记释放 iloc.bh 的 refcount。检查代码时请找到此项。 (CVE-2026-23145)

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

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

  - 缺少环 0 内某些 Intel(R) 平台的 Intel(R) 平台的备用硬件接口的保护机制：内核可能允许权限升级。系统软件攻击者将特权用户与低复杂性攻击相结合可实现权限提升。
    当攻击要求具有特殊的内部知识且无需用户交互时可能会通过本地访问出现此结果。潜在的漏洞可能会影响易受攻击系统的机密性（高）、完整性（高）和可用性（无），从而对后续系统的机密性（无）、完整性（无）和可用性（无）造成影响。
    (CVE-2025-35998)

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

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

  - gpiovirtuser修复了 configfs 版本路径中的 UAF gpio-virtuser configfs 版本路径使用 guard(mutex) 来保护设备结构。但是在防护清除运行之前已释放设备从而导致 mutex_unlock() 在释放的内存上进行操作。具体来说gpio_virtuser_device_config_group_release() 会破坏互斥体并当仍在 guard(mutex) 范围内时释放设备。当函数返回时保护清除会调用 mutex_unlock(&dev->lock)从而导致 slab 释放后使用。仅在激活检查周围使用 scoped_guard() 来限制互斥体生命周期以便在调用 mutex_destroy() 和 kfree() 之前释放锁定。 (CVE-2026-23158)

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

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

  - 已修复 Linux 内核中的下列漏洞：slab: fix kmalloc_nolock() context check for PREEMPT_RT On PREEMPT_RT kernels, local_lock becomes a sleeping lock. The current check in kmalloc_nolock() only verifies we're not in NMI or hard IRQ context, but misses the case where preemption is disabled. When a BPF program runs from a tracepoint with preemption disabled (preempt_count > 0), kmalloc_nolock() proceeds to call local_lock_irqsave() which attempts to acquire a sleeping lock, triggering: BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128 preempt_count: 2, expected: 0 Fix this by checking !preemptible() on PREEMPT_RT, which directly expresses the constraint that we cannot take a sleeping lock when preemption is disabled.
    This encompasses the previous checks for NMI and hard IRQ contexts while also catching cases where preemption is disabled. (CVE-2026-23134)

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

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

  - platform/x86hp-bioscfg修复空属性名称的 kobject 警告 HP BIOS 返回含空名称字符串的属性时hp-bioscfg 驱动程序尝试注册含空名称的 kobject。这会造成多个内核警告kobject: (00000000135fb5e6): attempt to be register with empty name! WARNING: CPU14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310 在 hp_init_bios_buffer_attribute() 中添加验证以检查属性名称在从 WMI 缓冲区解析之后是否为空。如果为空则记录调试消息并跳过该属性的注册允许模块继续处理其他有效属性。 (CVE-2026-23131)

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

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

  - nfcnci修复了 rfkill 和 nci_unregister_device() 之间的争用。 syzbot 在无重现的情况下报告了低于 [0] 的 splat。这表示在通过 rfkill 调用 nci_close_device() 之前结构 nci_dev.cmd_wq 已遭到破坏。 nci_dev.cmd_wq 仅在 nci_unregister_device() 中损坏我认为当 syzbot close()d virtual_ncidev 的 fd 时从 virtual_ncidev_close() 调用该函数。问题在于 nci_unregister_device() 先破坏 nci_dev.cmd_wq然后调用 nfc_unregister_device()这将通过 rfkill_unregister() 从 rfkill 删除设备。因此即使在破坏 nci_dev.cmd_wq 之后设备仍可通过 rfkill 可见。我们首先在 nci_unregister_device() 中从 rfkill 取消注册设备。请注意我们无法在 nci_close_device() 之前调用 nfc_unregister_device()因为 1) nfc_unregister_device() 调用 device_del()后者释放由 devm_kzalloc() 分配并链接到 ndev->conn_info_list 的所有内存 2) nci_rx_work() 可尝试将 nci_conn_info 排入 ndev 队列->可能遭到泄露的conn_info_list 因此nfc_unregister_device() 被拆分为两个函数所以只能删除 nci_close_device() 之前的 rfkill 接口。 [0]DEBUG_LOCKS_WARN_ON(1) 警告
    kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline] CPU#0syz.0.8675/6349 警告kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep .c:4854 [内联] CPU#0
    syz.0.8675/6349 警告kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187 CPU#0: syz.0.8675/6349 模块中链接的CPU:0 UID:0 PID：6349 Comm
    syz.0.8675 未受感染 syzkaller #0 PREEMPT(full) 硬件名称 Google Google Compute Engine/Google Compute Engine、BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP
    0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 代码18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 ff 1f 2 RSP0018:ffffc9000c767680 EFLAGS00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RffBPff80000 RFFCAFF8dI:ffff8bff8d:
     R080000000000000003  : ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS:
    00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: <TASK> lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue. c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block +0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write。 c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/ 0x7f RIP0033:0x7fa59b39acb9 代码 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4c 4c 4f 89 08 08 08 08 0 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff f f f7 d8 64 89 01 48 RSP002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb
    0000000000000008 RSI0000200000000080 RDI0000000000000007 RBP00007fa59b408bf7 R08---truncated--- (CVE-2026-23167)

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

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

  - virtio_net修复 virtnet_info 结构中的未对齐缺陷 使用新的 TRAILING_OVERLAP() 帮助程序修复未对齐的缺陷和以下警告drivers/net/virtio_net.c:429:46:warning:structure含有一个灵活的数组成员另一个结构的结尾 [-Wflex-array-member-not-at-end] 此帮助程序在弹性数组成员 (FAM) 和本应跟随在其后的一组成员之间创建并集在本例中为“u8 rss_hash_key_data [VIRTIO_NET_RSS_MAX_KEY_SIZE]`)。这会将尾部成员 (rss_hash_key_data) 叠加到 FAM (hash_key_data) 上，同时保持 FAM 和 MEMBERS 的开头对齐。static_assert() 可确保保持这种一致性。请注意由于灵活结构 virtio_net_rss_config_trailer 中的尾部填充因此“rss_trailer.hash_key_data”（在结构 virtnet_info 中的偏移 83 处）和“rss_hash_key_data”（在结构 virtnet_info 中的偏移 84 处）偏移一个字节。
    请参阅下文 struct virtio_net_rss_config_trailer { __le16 max_tx_vq; /* 0 2 */ __u8 hash_key_length; /* 2 1
    */ __u8 hash_key_data[]; /* 3 0 */ /* size: 4, cachelines: 1,members: 3 */ /* padding: 1 */ / * 最后一个 cacheline: 4 字节 */ } struct virtnet_info { ... struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */ /* XXX last struct has 1 byte of padding */ u8 rss_hash_key_data[40]; /* 84 40 */ ... /* size: 832, cachelines: 13,members: 48 */ /*summembers:801,holes:8,sumholes:31*/ /*paddings:2,sumpaddings: 5 */ }变更之后这些成员在偏移 795 处正确对齐 struct virtnet_info {... union { struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */ struct { unsigned char
    __offset_to_hash_key_data[3] ； /* 792 3 */ u8 rss_hash_key_data[40]; /* 795 40 */ } /* 792 43 */ } /* 792 44 */ ... /* size: 840, cachelines: 14,members: 47 */ /*summembers:801,holes:8,sumholes:35*/ /*padding:4*/ /* paddings: 1,sum paddings:4 */ /* last cacheline:8 字节 */ }因此传递到设备的 RSS 密钥会移动 1 个字节最后一个字节被截断而是在开头添加一个可能未初始化的字节。最后需要注意的是“struct virtio_net_rss_config_hdr *rss_hdr;”也被移动到末尾因为这三个成员似乎应该保留在一起。 :) (CVE-2026-23143)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/bridge: synopsys: dw-dp: fix error paths of dw_dp_bind Fix several issues in dw_dp_bind() error handling: 1. Missing return after drm_bridge_attach() failure - the function continued execution instead of returning an error. 2. Resource leak: drm_dp_aux_register() is not a devm function, so drm_dp_aux_unregister() must be called on all error paths after aux registration succeeds. This affects errors from: - drm_bridge_attach() - phy_init() - devm_add_action_or_reset() - platform_get_irq() - devm_request_threaded_irq() 3. Bug fix:
    platform_get_irq() returns the IRQ number or a negative error code, but the error path was returning ERR_PTR(ret) instead of ERR_PTR(dp->irq). Use a goto label for cleanup to ensure consistent error handling. (CVE-2026-23132)

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

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

  - drm/imx/tve修复探测设备泄漏。在探测失败例如探测延迟和驱动程序取消绑定时确保终止对 DDC 设备的引用。 (CVE-2026-23170)

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

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

  - 已修复 Linux 内核中的下列漏洞：firewire: core: fix race condition against transaction list The list of transaction is enumerated without acquiring card lock when processing AR response event. This causes a race condition bug when processing AT request completion event concurrently. This commit fixes the bug by put timer start for split transaction expiration into the scope of lock. The value of jiffies in card structure is referred before acquiring the lock. (CVE-2026-23153)

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

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

  - Debian Linux - rust-rpm-sequoia - 无 Red Hat Enterprise Linux - rust-rpm-sequoia: rust-rpm-sequoia
    在签名验证期间通过特制的 RPM 文件造成拒绝服务 Ubuntu Linux - [描述未知] (CVE-2026-2625)

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

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

  - nfcllcp修复 nfc_llcp_send_ui_frame() 中的内存泄漏。 syzbot 报告了与 NFC、struct nfc_llcp_sock、sk_buff、nfc_dev 等相关的多个内存泄漏。[0] 主要日志暗示 nfc_llcp_send_ui_frame() 无法分配 skb这是因为 sock_error(sk) 为 -ENXIO 所致。当 local_cleanup() 破坏 struct nfc_llcp_local 时nfc_llcp_socket_release() 设置 ENXIO。问题在于 nfc_llcp_send_ui_frame() 和 local_cleanup() 之间无同步而在 local_cleanup() 中清除 skb 之后可能将其放入 local->tx_queueCPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup () |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | 。 | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | | |- skb_queue_tail(&local->tx_queue, pdu); | ... |- pdu = nfc_alloc_send_skb(..., &err) | ^.______。”只有在 nfc_llcp_remove_local() 取消与 llcp_devices 的链接之后才会为结构 nfc_llcp_local 调用 local_cleanup()。如果随后保持 local->tx_queue.lock则可同步线程和 nfc_llcp_send_ui_frame()。让我们执行此操作并在 nfc_llcp_send_ui_frame() 中将 skb 排入 local->tx_queue 之前检查 list_empty(&local->list)。 [0][56.074943[ T6096] llcpnfc_llcp_send_ui_frame无法分配 PDU (error=-6) [ 64.318868][ T5813] kmemleak6 个新的可疑内存泄漏请参阅 /sys/kernel/debug/kmemleakBUG内存泄漏未引用对象 0xffff8881272f6800 (大小 1024): comm syz.0.17, pid 6096, jiffies 4294942766 十六进制转储 (前 32 字节): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....... 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@....... 回溯 (crc da58d84d)kmemleak_alloc_recursive include/ linux/kmemleak.h:44 [内联] slab_post_alloc_hook mm/slub.c:4979 [内联] slab_alloc_node mm/slub.c:5284 [内联] __do_kmalloc_node mm/slub.c:5645 [内联] __kmalloc_noprof+0x3e3/0x6b0 mm/ slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/ 0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0 x340 net/socket.c:1605 sock_create net/socket.c:1663 [内联]
    __sys_socket_create net/socket.c:1700 [内联] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [内联] __se_sys_socket net/socket.c:1759 [内联] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG内存泄漏未引用对象 0xffff88810fbd9800 (size 240)comm syz.0.17, pid 6096, jiffies 4294942850 hex dump前 32 字节68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h.。 ...... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff......h/'.... 回溯 (crc 6cc652b1)kmemleak_alloc_recursive include/linux/kmemleak. h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff .c:660 alloc_skb include/linux/skbuff.h:1383 [内联] alloc_skb_with_frags+0x69/0x3f0 net/c ore/sk ---truncated--- (CVE-2026-23150)

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

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

  - Tcpreplay v4.5.1 中的问题允许本地攻击者通过构建的文件对 src/tcpedit/plugins/dlt_utils.c 中的 tcpedit_dlt_getplugin 函数造成拒绝服务。 (CVE-2024-54192)

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

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

  - Debian Linux - glib-networking - None (CVE-2026-2574)

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

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

  - 适用于 Perl 的 0.410.55 之前的 Crypt::URandom 版本在 XS 函数 crypt_urandom_getrandom() 中容易受到堆缓冲区溢出影响。函数未验证长度参数是否为非负值。如果提供负值例如 -1表达式长度 + 1u 将造成整数回绕从而导致零字节分配。对 getrandom(data, length, GRND_NONBLOCK) 的后续调用会传递原始负值该负值会隐式转换为大型无符号值通常为 SIZE_MAX。这可导致写入超出分配的缓冲区从而导致堆内存损坏和应用程序崩溃拒绝服务。在常见用法中，长度参数通常由调用程序进行硬编码，这可降低攻击者控制漏洞的可能性。将不受信任的输入传递到此参数的应用程序可能会受到影响。 (CVE-2026-2474)

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

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

  - sfc修复 RSS config 中的死锁读取自引用的提交以来核心在处理 ethtool -x 命令时锁定 net_device 的 rss_lock因此驱动程序的实现不应再次锁定。删除后者。
    (CVE-2026-23165)

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

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

  - Debian Linux - gegl - None Ubuntu Linux - [ZDI-CAN-28266rgbe.c 的新漏洞报告] (CVE-2026-2050)

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

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

  - nvmet修复 nvmet_bio_done() 中导致空指针取消引用的争用。nvmet_bio_done() 中存在一个争用条件可导致 blk_cgroup_bio_start() 中发生空指针取消引用。1. 当 bio 完成时会调用 nvmet_bio_done() 2. nvmet_req_complete(调用则会引发 req->ops->queue_response(req) 3. queue_response 回调可重新排队并重新提交相同的请求 4. 重新提交会重复使用 nvmet_req 中相同的 inline_bio 5. 同时nvmet_req_bio_put(在 nvmet_req_complete 后调用导致 inline_bio 调用 bio_uninit()从而将 bio->bi_blkg 设置为空 6. 重新提交的 bio 进入 submit_bio_noacct_nocheck() 7. blk_cgroup_bio_start() 取消引用 bio->bi_blkg导致崩溃BUG内核空指针取消引用地址0000000000000028 #PF内核模式下存在主管读取访问权限 RIP0010:blk_cgroup_bio_start+0x10/0xd0 调用跟踪
    submit_bio_noacct_nocheck+0x44/0x250 nvmet_bdev_execute_rw+0x254/0x370 [nvmet] process_one_work+0x193/0x3c0 worker_thread+0x281/0x3a0 通过重新排序 nvmet_bio_done() 调用 nvmet_req_bio_put() 在 nvmet_req_complete() 之前调用 nvmet_req_bio_put() 可以修复此问题。这可确保在重新提交请求之前清除 bio，从而防止争用条件。 (CVE-2026-23148)

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

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

  - mm/damon/sysfs清除上下文 dir 中的 attrs 子目录设置失败如果在 attrs/ 目录设置后上下文 DAMON sysfs 目录设置失败则不会清除 attrs/ 目录的子目录。因此在系统重新启动之前DAMON sysfs 接口几近崩溃且未删除目录的内存泄露。清理此类故障下的目录。 (CVE-2026-23144)

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

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

  - Debian Linux - gegl - None Ubuntu Linux - [ZDI-CAN-28618rgbe.c 的新漏洞报告] (CVE-2026-2049)

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

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

  - libvpx 中的堆缓冲区溢出。此漏洞影响 Firefox < 147.0.4、Firefox ESR < 140.7.1、Firefox ESR < 115.32.1、Thunderbird < 140.7.2和 Thunderbird < 147.0.2。 (CVE-2026-2447)

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

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

  - mm/shmem、swap修复截断争用和交换条目拆分 shmem 交换释放的帮助程序未正确处理交换条目的顺序。它使用 xa_cmpxchg_irq 擦除交换条目但使用无锁定保护的 xa_get_order 时会获得在交换条目之前的条目顺序并且如果在 xa_get_order 之后 xa_cmpxchg_irq 之前以其他方式拆分或更改条目或可能获得过时的顺序值。
    此外序列可能增长且大于预期并造成截断从而删除超出末端边界的数据。例如如果换入或释放目标条目和后续条目然后使用相同的条目在适当的位置添加和换出大型作品集xa_cmpxchg_irq 仍将成功尽管这种情况不太可能发生。要修复此问题请开放代码 Xarray cmpxchg 并将顺序检索和值检查放在同一个关键部分中。此外，请确保顺序不会超过结束边界，如果条目超过边界，则跳过此顺序。此处跳过大型交换条目越过末端边界是安全的。Shmem 截断会迭代范围两次在第一次迭代中find_lock_entries 已过滤掉这些条目shmem 将交换越过端边界并部分截断 folio拆分 folio 或至少其中的零部分的条目。因此在第二个循环中如果发现交换条目超出结束顺序则其内容至少已经被擦除。使用 shmem 对 ZSWAP 进行压力测试时我发现了随机 swapoff 挂起和内核错误。应用此修补程序后所有问题均消失。 (CVE-2026-23161)

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

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

  - wifiath12k修复刷新管理框架时的死锁 Commit [1] 将管理传输工作项目转换为 wiphy 工作。由于 wiphy 工作只能在 wiphy 锁定保护下运行在以下情况下会发生争用条件1. 管理帧排队等待传输。 2.
    调用 ath12k_mac_op_flush() 以刷新与硬件相关的待定帧即 vif 为空。然后进程在 ath12k_mac_flush() 中等待传输完成。 3. 由于刷新进程已获取 wiphy 锁定因此传输工作项目没有机会运行从而导致死锁。
    >在用户视图中此死锁会导致以下问题wlp8s0使用 xxxxxx 进行认证本地 address=xxxxxxwlp8s0将认证发送到 xxxxxx (try 1/3) wlp8s0使用 xxxxxx 进行认证本地 address=xxxxxx] wlp8s0将认证发送到xxxxxx尝试 1/3 wlp8s0已认证 wlp8s0与 xxxxxx 尝试 1/3相关联 wlp8s0通过本地选择中止与 xxxxxx 的关联原因3=DEAUTH_LEAVING ath12k_pci 0000:08:00.0未能刷新 mgmt 传输队列、 mgmt pkts pending 1 通过调用 wiphy_work_flush() 主动运行排队的工作项目可避免死锁。请注意实际上它已存在于 ath12k_mac_op_flush() 中但不能保护 vif 为空的情况。因此将其向前移动以也涵盖这种情况。已在以下平台上测试 WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 (CVE-2026-23130)

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

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

  - Debian Linux - evolution-data-server - 无 Red Hat Enterprise Linux - evolution-data-serverEvolution Data Server通过不一致的 URI 处理任意文件删除 Ubuntu Linux - 不安全的本地缓存文件删除 (CVE-2026-2604)

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

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

  - rocker修复 rocker_world_port_post_fini() 中的内存泄漏 在 rocker_world_port_pre_init() 中rocker_port->wpriv 通过 kzalloc(wops->port_priv_size, GFP_KERNEL) 进行分配。然而在 rocker_world_port_post_fini() 中只有在设置 wops->port_post_fini 回调时才会释放内存 if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv);由于 rocker_ofdpa_ops 未实现 port_post_fini 回调为空因此当删除端口时为每个端口分配的 wpriv 内存永远不会释放。这会导致在每次删除设备时每个端口发生 sizeof(struct ofdpa_port) 字节的内存泄漏。通过始终调用 kfree(rocker_port->wpriv) 来修复此问题而不管 port_post_fini 回调是否存在。 (CVE-2026-23164)

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

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

  - netfilter: nf_conncount仅在执行了 GC 时更新 last_gc 当前last_gc 每次跟踪新连接时都会更新这意味着即使未执行 GC也会更新它。如果数据包速率足够高，则可能始终绕过 GC，从而导致列表无限增长。仅在实际执行过 GC 时才更新 last_gc 值。 (CVE-2026-23139)

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

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

  - netfs修复 EOF 在中间的页面的提前读取解锁 在某些情况下缓冲读取的读取结果集合似乎在子请求完成之前完成运行这一点可以在以下日志片段中看到9p_client_res客户端 18446612686390831168 响应 P9_TREAD 标签0 err 0 ...
    netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004 read-done netfs_folio i=157f3 ix=00004-00004 read-unlock netfs_collect_folioR=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio
    i=157f3 ix=00005-00005 read-done netfs_folio i=157f3 ix=00005-00005 read-unlock ... netfs_collect_stream
    R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln= 6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0 netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/ 4e s=5 e=0 “cto=5fb2”表示我们已将结果收集到 pos 的已收集文件 - 但仍有 0x4e 个字节需要处理 - 因此我们尚未应收集 folio ix=00005 。我们解锁 folio 之后会发生可清除尾部的“ZERO”子req从而允许应用程序通过 mmap 查看未清除的尾部。问题在于 netfs_read_unlock_folios() 将解锁一个作品集，其中收集的读取结果数量达到 EOF 位置 - 但 ZERO subreq 在此范围之外发生因此之后会发生。通过将结束检查更改为始终作为作品集的结尾而非文件的结尾来修复此问题。以后我应该考虑清除到此处作品集的末尾而不是添加 ZERO subreq 来实现此目的。另一方面ZERO subreq 可与 async READ subreq 并行运行。此外可能仍然需要 ZERO subreq例如处理 ceph 文件中没有任何后备存储因此隐式全零的盘区。通过创建大小与页面边界未对齐如 24998 (0x5fb2) 字节的文件可重现此问题然后执行类似以下的操作 xfs_io -c mmap -r 0 0x6000 -c madvise -d 0 0x6000 \ -c mread -v 0 0x6000 /xfstest.test/x 最后 0x4e 字节应全部为 00但如果尚未清除尾部则可能会在该处看到垃圾。通过修改内核以禁用对 netfs_read_subreq_progress() 的调用并停止 afs_issue_read()执行 NETFS_READAHEAD 的异步调用可以使用 kafs 重现此问题。对于 ZERO-subreq 的情况在 netfs_issue_read() 中插入 mdelay(100)可让重现变得更容易。AFS 和 CIFS 通常不太可能显示此问题，因为它们以异步方式调度 READ ops，这允许 ZERO-subreq 首先完成。 9P 的 READ 操作是完全同步的因此 ZERO-subreq 之后将始终发生。但该图标并非始终可见，因为可能会在工作线程中完成收集。 (CVE-2025-71201)

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

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

  - octeon_ep修复 octep_device_setup() 中的内存泄漏。在 octep_device_setup() 中如果 octep_ctrl_net_init() 失败函数会直接返回而不会取消映射的资源映射和释放分配的配置内存。通过跳至 unsupported_dev 标签来修复此问题该标签会执行必要的清理。这与此函数中其他路径的错误处理逻辑一致。仅限编译测试。
    使用原型静态分析工具和代码审查发现的问题。 (CVE-2026-23160)

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

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

  - Bluetoothhci_uart修复 hci_uart_write_work 中的 null-ptr-derefhci_uart_set_proto() 在调用 hci_uart_register_dev() 之前设置 HCI_UART_PROTO_INIT从而调用 proto->open() 来初始化 hu->priv。但是如果在此窗口期间发生 TTY 写入唤醒hci_uart_tx_wakeup() 可能会在 hu->priv 初始化之前计划 write_work从而当 proto->dequeue() 访问 hu->priv 时导致 hci_uart_write_work() 中发生空指针取消引用。争用条件为CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) 通过在 proto->open() 成功后移动 set_bit(HCI_UART_PROTO_INIT) 修复此问题从而确保 hu-> priv 会在计划任何工作之前初始化。 (CVE-2026-23146)

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

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

  - bonding提供指向 __skb_flow_dissect() 的 net 指针。3cbf4ffba5eenet将网络命名空间插入 __skb_flow_dissect之后必须通过 skb->dev、skb->sk 或提供的用户提供指向 __skb_flow_dissect() 的 net 指针指针。在以下情况中syzbot 能够cook 裸机 skb。警告：
    net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131 CPU#1
    syz.2.1418/11053 调用跟踪 <TASK> bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [内联]
    __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [内联] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [内联] bond_xdp_get_xmit_slave/ 0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run. c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/ syscall.c:6274 [内联] __se_sys_bpf kernel/bpf/syscall.c:6272 [内联] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94 (CVE-2026-23119)

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

ID	名称	严重性
299433	Linux Distros 未修补的漏洞：CVE-2026-23224	medium
299432	Linux Distros 未修补的漏洞：CVE-2025-71237	medium
299431	Linux Distros 未修补的漏洞：CVE-2025-71229	medium
299430	Linux Distros 未修补的漏洞：CVE-2026-23218	medium
299429	Linux Distros 未修补的漏洞：CVE-2026-23214	high
299428	Linux Distros 未修补的漏洞：CVE-2026-23227	medium
299427	Linux Distros 未修补的漏洞：CVE-2026-23228	high
299426	Linux Distros 未修补的漏洞：CVE-2026-23213	medium
299393	Linux Distros 未修补的漏洞：CVE-2026-2641	low
299392	Linux Distros 未修补的漏洞：CVE-2026-27171	medium
299391	Linux Distros 未修补的漏洞：CVE-2026-2644	medium
299385	Nutanix AHV 多个漏洞 (NXSA-AHV-10.3.1.3)	high
299376	Linux Distros 未修补的漏洞：CVE-2026-24734	high
299349	Linux Distros 未修补的漏洞：CVE-2025-71200	medium
299348	Linux Distros 未修补的漏洞：CVE-2026-24708	high
299344	Linux Distros 未修补的漏洞：CVE-2026-2032	medium
299343	Linux Distros 未修补的漏洞：CVE-2026-23172	high
299342	Linux Distros 未修补的漏洞：CVE-2026-23163	medium
299341	Linux Distros 未修补的漏洞：CVE-2026-23115	medium
299330	Linux Distros 未修补的漏洞：CVE-2026-23147	medium
299329	Linux Distros 未修补的漏洞：CVE-2026-23145	high
299328	Linux Distros 未修补的漏洞：CVE-2025-35998	high
299327	Linux Distros 未修补的漏洞：CVE-2026-23158	medium
299326	Linux Distros 未修补的漏洞：CVE-2026-23134	medium
299321	Linux Distros 未修补的漏洞：CVE-2026-23131	medium
299320	Linux Distros 未修补的漏洞：CVE-2026-23167	medium
299319	Linux Distros 未修补的漏洞：CVE-2026-23143	high
299318	Linux Distros 未修补的漏洞：CVE-2026-23132	medium
299317	Linux Distros 未修补的漏洞：CVE-2026-23170	high
299316	Linux Distros 未修补的漏洞：CVE-2026-23153	medium
299315	Linux Distros 未修补的漏洞：CVE-2026-2625	medium
299314	Linux Distros 未修补的漏洞：CVE-2026-23150	medium
299311	Linux Distros 未修补的漏洞：CVE-2024-54192	medium
299305	Linux Distros 未修补的漏洞：CVE-2026-2574	critical
299287	Linux Distros 未修补的漏洞：CVE-2026-2474	high
299238	Linux Distros 未修补的漏洞：CVE-2026-23165	high
299237	Linux Distros 未修补的漏洞：CVE-2026-2050	critical
299236	Linux Distros 未修补的漏洞：CVE-2026-23148	medium
299235	Linux Distros 未修补的漏洞：CVE-2026-23144	medium
299234	Linux Distros 未修补的漏洞：CVE-2026-2049	high
299233	Linux Distros 未修补的漏洞：CVE-2026-2447	high
299232	Linux Distros 未修补的漏洞：CVE-2026-23161	medium
299231	Linux Distros 未修补的漏洞：CVE-2026-23130	medium
299230	Linux Distros 未修补的漏洞：CVE-2026-2604	high
299225	Linux Distros 未修补的漏洞：CVE-2026-23164	medium
299224	Linux Distros 未修补的漏洞：CVE-2026-23139	medium
299223	Linux Distros 未修补的漏洞：CVE-2025-71201	medium
299222	Linux Distros 未修补的漏洞：CVE-2026-23160	medium
299221	Linux Distros 未修补的漏洞：CVE-2026-23146	medium
299220	Linux Distros 未修补的漏洞：CVE-2026-23119	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

medium

high

medium

high

medium

low

medium

medium

high

high

medium

high

medium

high

medium

medium

medium

high

high

medium

medium

medium

medium

high

medium

high

medium

medium

medium

medium

critical

high

high

critical

medium

medium

high

high

medium

medium

high

medium

medium

medium

medium

medium

medium