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

  - mm/damon/sysfs：检查 repeat_call_fn damon_sysfs_repeat_call_fn（） 调用 damon_sysfs_upd_tuned_intervals（）、damon_sysfs_upd_schemes_stats（） 和 damon_sysfs_upd_schemes_effective_quotas（） 中的 contexts->nr，而不检查 context->nr。如果在 DAMON 运行时通过 sysfs 将 nr_contexts 设置为 0，这些函数将取消引用 contexts_arr[0] 并造成空指针取消引用。添加缺少的检查。例如，可以使用 DAMON sysfs 接口和 DAMON 用户空间工具 （damo） [1] 重现该问题，如下所示。$ sudo damo start --refresh_interval 1s $ echo 0 | sudo tee \ /sys/kernel/mm/damon/admin/kdamonds/0/contexts/nr_contexts （CVE-2026-31457）

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

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

  - DOM中的缓解绕过：postMessage组件。该漏洞在Firefox 150和Thunderbird 150中已修复。（CVE-2026-6755）

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

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

  - 已修复 Linux 内核中的下列漏洞：cxl/region: Fix leakage in
    __construct_region() Failing the first sysfs_update_group() needs to explicitly kfree the resource as it is too early for cxl_region_iomem_release() to do so. (CVE-2026-31529)

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

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

  - writeback：不阻断没有数据完整性保证的文件系统的同步。为无法保证同步时数据持久性的文件系统添加SB_I_NO_DATA_INTEGRITY超级块标记（例如 fuse）。对于设置了此标记的超级块，sync 会启动脏 inode 的回写，但不会等待刷新线程完成回写。这会替换在提交 f9a49aa302a0 中添加的每个 inode AS_NO_DATA_INTEGRITY映射标记（fs/writeback：跳过 wait_sb_inodes（）） 中的AS_NO_DATA_INTEGRITY映射）。该标志属于超级块级别，因为数据完整性是文件系统范围的属性，而不是每个 inode 的属性。在超级块级别拥有此标志还允许我们跳过必须迭代 wait_sb_inodes（） 中的每个脏 inode，而只是单独跳过每个 inode。在此提交之前，无数据完整性保证的映射会跳过等待回写完成，但仍会等待刷新器线程完成发起回写。无需等待刷新器线程。此提交会启动回写，但不会等待刷新器线程。此更改正确解决了最近的报告 [1] 中关于在 fuse-overlayfs 上发现的 suspend-to-RAM 挂起，该挂起是由于等待刷新器线程完成而造成：
    工作队列：pm_fs_sync pm_fs_sync_work_fn 呼叫跟踪： <TASK> __schedule+0x457/0x1720 schedule+0x27/0xd0 wb_wait_for_completion+0x97/0xe0 sync_inodes_sb+0xf8/0x2e0 __iterate_supers+0xdc/0x160 ksys_sync+0x43/0xb0 pm_fs_sync_work_fn+0x17/0xa0 process_one_work+0x193/0x350 worker_thread+0x1a1/0x310 kthread+0xfc/0x240 ret_from_fork+0x243/0x280 ret_from_fork_asm+0x1a/0x30 </TASK> 在 fuse 上，这是有问题的，因为有些路径可导致刷新线程阻断（例如，如果 systemd 在调用内核暂停之前，先冻结用户会话 cgroups，这会冻结 fuse 后台程序）。内核暂停会触发
    ->write_node（），其在 fuse 上发出同步 setattr 请求，该请求因后台程序已冻结而无法处理。或者，如果后台程序有缺陷且无法正确完成回写，则在已经处于回写下的脏作品集上启动回写会导致writeback_get_folio（） -> folio_prepare_writeback（） ->无条件等待回写完成，这将造成挂起。此提交将 fuse 恢复到删除 tmp folio 之前的行为，其中同步本质上是无操作的。[1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1(CVE-2026-31465）

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

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

  - igb：移除igb_down（）中的napi_synchronize（）。当AF_XDP零拷贝应用突然终止（例如，kill -9）时，XSK缓冲池被销毁，但NAPI轮询仍继续。igb_clean_rx_irq_zc（）反复返回全部预算，阻止napi_complete_done（）清算NAPI_STATE_SCHED。
    igb_down（） 在每个队列向量的 napi_disable（） 之前调用 napi_synchronize（） 。napi_synchronize（）旋转等待NAPI_STATE_SCHED清除，但从未发生。igb_down（） 无限期封锁，TX 监控机构触发，TX 队列永久停滞。napi_disable（）已经正确处理了这一点：它设置了NAPI_STATE_DISABLE。在全预算民调后，__napi_poll（）检查napi_disable_pending（）。如果设置为，它会强制完成并清除NAPI_STATE_SCHED，从而打破napi_synchronize（）无法实现的循环。napi_synchronize（）在提交41f149a285da中添加（igb：修复接口关闭时Rx流量到达可能引发的紧急情况）。napi_disable（）提供了更强的保证：它阻止进一步调度，并等待任何活跃轮询退出。其他Intel驱动（ixgbe、ice、i40e）则使用napi_disable（），其下行路径中没有前置napi_synchronize（）。移除冗余的napi_synchronize（）调用，并在igb_set_queue_napi（）前重新排序napi_disable（），这样只有在轮询完全停止后，队列到NAPI的映射才被清除。（CVE-2026-31691）

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

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

  - ksmbd：修复 smb_grant_oplock（） 中的释放后使用和空取消引用 smb_grant_oplock（） 在 oplock 发布序列中存在两个问题：1） 在调用 add_lease_global_list（） 之前，opinfo 会（通过 opinfo_add）链接到 ci->m_op_list。如果 add_lease_global_list（） 失败（kmalloc 返回 NULL），错误路径会在 ci->m_op_list 中仍链接 opinfo 时，通过 __free_opinfo（） 释放 opinfo。并发m_op_list阅读器（opinfo_get_list或 smb_break_all_levII_oplock 中的直接迭代）取消引用已释放的节点。
    2） 在 add_lease_global_list（） 在全局租用列表中发布 opinfo 后分配 opinfo->o_fp。并行 find_same_lease_key（） 可遍历租用列表，并在 o_fp 仍为 NULL 时取消引用 opinfo->o_fp->f_ci。通过重构发布顺序来修复，以消除发布后失败：- 在任何列表发布前设置 opinfo->o_fp（修复空取消引用）。- 在 opinfo_add（） 之前通过 alloc_lease_table（） 预先分配lease_table，这样 add_lease_global_list（） 在发布后将不会正确。- 保留原始m_op_list发布顺序（opinfo_add在租赁列表之前），以便通过 same_client_has_lease（） 和 opinfo_get_list（） 的并发打开仍会看到正在进行的授予。- 使用 opinfo_put（） 而不是
    __free_opinfo（） err_out以便使用 RCU 延迟的自由路径。这也需要拆分 add_lease_global_list（） 以获取预分配的lease_table并将其返回类型从 int 更改为 void，因为它不会再失败。（CVE-2026-31444）

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

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

  - mm/kasan：修复 kasan pXds 的双重释放 kasan_free_pxd（） 假设页表始终与结构页面对齐。但并非所有架构都如此。例如对于具有 64K 页面大小的 powerpc，PUD 表（大小为 4096）来自名为 pgtable-2^9 的 slab 缓存。因此，我们只直接传递作为第一个参数传递的 pxd 表的开头，而不是 page_to_virt（pxd_page（））。这修复了以下以 PMEM 为主的双重释放 kasan 问题：radix-mmu：与 MiB 页面映射 2.00 的 0x0000047d10000000-0x0000047f90000000 ================================================================== 缺陷：KASAN：kasan_remove_zero_shadow+0x9c4/0xa20 中的双重释放 通过任务 ndctl/2164 释放 addr c0000003c38e0000 CPU：34 UID：0 PID：
    2164 comm：ndctl 未受感染 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY 硬件名称：IBM，9080-HEX POWER10 （architected） 0x800200 0xf000006 of：IBM，FW1060.00 （NH1060_012） hv：phyp pSeries 调用跟踪：
    dump_stack_lvl+0x88/0xc4（不可靠）print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- 中断：3000 at 0x7fff93b3d3f4 NIP：00007fff93b3d3f4 LR：00007fff93b3d3f4 CTR：000000000000000000 REGS：c0000003f1b07e80 陷阱：3000 未受感染 （6.19.0-rc1-00048-gea1013c15392） MSR：800000000280f033 <SF，VEC，VSX，EE，PR，FP，ME，IR，DR，RI，LE> CR：48888208 XER：00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ----中断：3000 有缺陷的地址属于位于 c0000003c38e00000 的对象，该对象属于大小为 4096 的缓存 pgtable-2^9 有缺陷的地址位于 4096 字节区域内的 0 字节处 [c0000003c38e0000， c0000003c38e1000） 有缺陷的地址属于物理页面：page： refcount：0 mapcount：0 mapping：000000000000000 index：0x0 pfn：0x3c38c head：
    order：2 mapcount：0 entire_mapcount：0 nr_pages_mapped：0 pincount：0 memcg：c0000003bfd63e01 flags：
    0x63ffff800000040（head|node=6|zone=0|lastcpupid=0x7ffff） page_type： f5（slab） raw： 063ffff800000040 c000000140058980 5deadbeef0000122 00000000000000000 raw： 00000000000000000 0000000080200020 00000000f50000000 c0000003bfd63e01 head： 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000000 head：
    00000000000000000 0000000080200020 00000000f50000000 c00000003bfd63e01 head： 063ffff800000002 c00c000000f0e301 00000000ffffffffff 00000000ffffffff head： ffffffff 00000000000000000000000000000ff ffffff 0000000000000004 页面转储，因为：kasan：检测到错误访问 [ 138.953636] [ T2164] 错误地址周围的内存状态： [ 138.953643] [ T2164] c0000003c38dff00： fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80： fc fc fc fc [ 138.953661] [] >c0000003c38e0000： FC FC FC [ 138.953669] [ T2164] ^ [ 138.953675T2164] [ ] C0000003C38E0080： FC FC FC [138.953684] T2164C0000003C38E0100： FC FC FC [ 138.953692] [T2164] ================================================================== [ 138.953701T2164] [ ] 由于内核感染 （CVE-2026-31686） 禁用锁定调试T2164

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

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

  - 之前 1.0.1 的uriparser在文本范围比较中具有数值截断，如果应用程序接受长度为吉字节的URI。（CVE-2026-42371）

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

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

  - rxrpc：修复 rxgk_verify_response（） 中 rxgk 上下文的泄漏 修复 修复 修复 rxgk_verify_response（） 以清理它创建的 rxgk 上下文。（CVE-2026-31632）

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

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

  - Axios 是基于 Promise 的 HTTP 客户端，用于浏览器和Node.js。低于 和 0.31.1的版本1.15.1之前，Axios 库容易遭受 Prototype Pollution Gadget 攻击，该攻击允许任何 Object.prototype 污染静默禁止所有 HTTP 错误响应（401、403、500 等），从而造成其被视为成功响应。这完全绕过应用程序级认证和错误处理。根本原因是 validateStatus 是唯一使用 mergeDirectKeys 合并策略的配置属性，该策略使用 JavaScript 的运算符，该运算符本质上遍历原型链。当 Object.prototype.validateStatus 被 （） => true 污染时，所有 HTTP 状态代码都会被接受为成功。此漏洞已在 1.15.1 和 0.31.1 中修复。(CVE-2026-42041)

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

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

  - xfrm：清除 build_polexpire（） 中的尾部填充 build_expire（） 在通过 memset_after（） 设置硬字段后清除 struct xfrm_user_expire 的尾部填充字节，但类似函数 build_polexpire（） 不会对 struct xfrm_user_polexpire执行此操作。__u8硬字段之后的填充字节未从堆分配中初始化，然后通过 netlink 多播发送到XFRMNLGRP_EXPIRE监听器的用户空间，从而泄漏内核堆内存内容。添加缺失的 memset_after（） 调用，与 build_expire（） 匹配。（CVE-2026-31664）

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

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

  - lxml 指使用 Python 语言处理 XML 和 HTML 的库。在 之前 6.1.0，默认配置中使用两个解析器中的任一（resolve_entities=True）允许不受信任的XML输入读取本地文件。将resolve_entities选项明确设置为resolve_entities='internal'或 resolve_entities=False，则禁用本地文件访问。此漏洞已在 6.1.0 中修复。
    (CVE-2026-41066)

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

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

  - rust-openssl 为 Rust 编程语言提供 OpenSSL 绑定。从 0.9.24 至 0.10.78 之前的版本，SslContextBuilder::set_psk_client_callback、set_psk_server_callback、set_cookie_generate_cb 和 set_stateless_cookie_generate_cb 后面的 FFI trampoline 将用户闭包的返回 usize 直接转发给 OpenSSL，而未针对传递给闭包的 &mut [u8] 检查它。这会导致缓冲区溢出和其他意想不到的后果。此漏洞已在 0.10.78 中修复。
    (CVE-2026-41898)

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

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

  - WiFi：rt2x00usb：修复Devres的终身USB驱动绑定到USB接口，任何设备管理的资源应将其生命周期绑定到接口，而非父USB设备。这样可以避免驱动程序在未物理断开的情况下解绑时（如探针延迟或配置更改时）内存泄漏等问题。修正USB锚点寿命，使其在驱动解绑时释放。
    (CVE-2026-31672)

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

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

  - idpf：修复PREEMPT_RT raw/bh 旋转锁嵌套问题，用于异步 VC 处理。将使用完备的原始自旋锁切换为 idpf_vc_xn 结构体中的本地锁。转换是安全的，因为 complete/_all（） 是在锁之外调用的，当前逻辑中没有理由共享完成锁。这避免了内核报告的无效等待上下文，因为异步处理程序采用了 BH 旋转锁： [805.726977] ============================= [ 805.726991] [ 错误：无效等待上下文 ] [ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 受污染： G S OE [ 805.727026] ----------------------------- [ 805.727038] kworker/u261：0/572 正在尝试锁定： [ 805.727051] ff190da6a8dbb6a0 （&vport_config->mac_filter_list_lock）{+...}-{3:3}， at： idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [805.727099] 其他可能帮助我们调试的信息： [ 805.727111] 上下文-{5:5} [ 805.727119] kworker/u261：0/572 持有的3个锁： [ 805.727132] #0： ff190da6db3e6148 （（wq_completion）idpf-0000：83：00.0-mbx）{+.+.}-{0:0}， at： process_one_work+0x4b5/0x730 [ 805.727163] #1：
    ff3c6f0a6131fe50 （（work_completion）（&（&adapter->mbx_task）->work））{+.+.}-{0:0}，在：
    process_one_work+0x1e5/0x730 [ 805.727191] #2： ff190da765190020 （&x->wait#34）{+.+.}-{2:2}，在：
    idpf_recv_mb_msg+0xc8/0x710 [idpf] [ 805.727218] 栈回溯：...[ 805.727238] 工作队列：
    idpf-0000：83：00.0-mbx idpf_mbx_task [idpf] [ 805.727247] 呼叫追踪：[ 805.727249] <TASK> [ 805.727251] dump_stack_lvl+0x77/0xb0 [ 805.727259] __lock_acquire+0xb3b/0x2290 [ 805.727268] ？
    __irq_work_queue_local+0x59/0x130 [ 805.727275] lock_acquire+0xc6/0x2f0 [ 805.727277] ？ idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727284] ？ _printk+0x5b/0x80 [ 805.727290]
    _raw_spin_lock_bh+0x38/0x50 [ 805.727298] ？ idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf] [805.727317] process_one_work+0x226/0x730 [ 805.727322] worker_thread+0x19e/0x340 [ 805.727325] ？
    __pfx_worker_thread+0x10/0x10 [ 805.727328] kthread+0xf4/0x130 [ 805.727333] ？ __pfx_kthread+0x10/0x10 [805.727336] ret_from_fork+0x32c/0x410 [ 805.727345] ？ __pfx_kthread+0x10/0x10 [ 805.727347] ret_from_fork_asm+0x1a/0x30 [ 805.727354] </TASK> （CVE-2026-31647）

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

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

  - rust-openssl 为 Rust 编程语言提供 OpenSSL 绑定。在 0.10.78 之前，aes::unwrap_key() 包含一个错误的断言：它检查 out.len() + 8 <= in_.len()，但此情况是相反的。预期的不变量为 out.len() >= in_.len() - 8，以确保输出缓冲区足够大。由于存在反向检查，该函数只接受等于或小于所需最小大小的缓冲区，并拒绝较大的缓冲区。如果提供较小的缓冲区，该函数将在超出 out 末尾的 in_.len() - 8 - out.len() 字节处写入，从而导致从安全公共函数发生越界写入。
    此漏洞已在 0.10.78 中修复。(CVE-2026-41678)

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

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

  - OpenPrinting CUPS 是适用于 Linux 及其他类 Unix 操作系统的开源打印系统。之前 2.4.17，网络邻近攻击者可向 CUPS SNMP 后端发送构建的 SNMP 响应，从而造成通过堆栈缓冲区的最多 176 字节的越界读取。泄漏的内存由 UTF-16 转换为 UTF-8 并存储为打印机耗材描述字符串，随后通过 IPP Get-Printer-Attributes 响应和 CUPS Web 界面查看经认证的用户可查看这些字符串。此漏洞已在 2.4.17 中修复。(CVE-2026-41079)

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

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

  - ALSA：烟花：绑定设备提供的状态，在字符串阵列查找前 EFW响应中的状态字段是Firewire设备提供的32位值。 efr_status_names[] 有17条条目，所以超出这个范围的状态值在看%值时会被忽略。更糟的是，状态可能会返回EFR_STATUS_INCOMPLETE，而这其实是0x80000000，显然不在那个潜在字符串的范围内。通过正确地将索引与数组大小绑定，如果未被识别，则打印未知。（CVE-2026-31619）

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

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

  - UUID 用于创建 RFC9562 （以前称为 RFC4122）UUID。低于 v3、v5 和 v6 的版本 14.0.0接受外部输出缓冲区，但不拒绝超出范围的写入（小缓冲区或大偏移）。这允许对调用程序提供的缓冲区进行静默部分写入。此漏洞已在 14.0.0 中修复。
    (CVE-2026-41907)

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

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

  - Axios 是一个基于承诺的 HTTP 客户端，适用于浏览器和Node.js。从 1.0.0 到之前 1.15.2，Axios 库容易受到原型污染设备攻击，该攻击允许应用程序依赖树中的任何 Object.prototype 污染被升级为对所有 JSON API 响应进行外科手术式、隐形修改，包括权限提升、平衡操作和授权绕过。lib/defaults/index.js：124 的默认 transformResponse 函数调用 JSON.parse（data， this.parseReviver），这里是合并后的配置对象。由于 parseReviver 不存在于 Axios 默认设置中，也未通过 assertOptions 验证，且不受任何约束约束，因此在每个 JSON 响应中，每个键值对都会调用一个污染的 Object.prototype.parseReviver 函数，允许攻击者选择性地修改单个值，而保留其余响应内容。此漏洞已在 1.15.2 中修复。
    (CVE-2026-42044)

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

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

  - Vim 是一个开源命令行文本编辑器。在之前的版本 9.2.0357中，Vim 的标签文件处理中存在命令注入漏洞。解析标签时，通过通配符扩展传递标签文件中的文件名字段，以解析环境变量和通配符。如果 filename 字段包含反引号语法（如“command”），Vim 会通过系统 shell 以运行用户的完整权限执行嵌入命令。（CVE-2026-41411）

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

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

  - rxrpc：proc：大小 %pISpc 输出的地址缓冲区 AF_RXRPC procfs 帮助程序使用 %pISpc 将本地和远程套接字地址格式化为固定的 50 字节堆栈缓冲区。对于格式化程序可以生成的最长当前树 IPv6-with-port 表单来说，这太小了。在 lib/vsprintf.c 中，压缩的 IPv6 路径不仅对 v4mapped 地址使用点式四边形末尾，还对通过 ipv6_addr_is_isatap（） 的 ISATAP 地址使用。因此，使用当前格式化程序可能出现诸如 [ffff：ffff：ffff：ffff：0：5efe：255.255.255.255]：65535 之类的情况。也就是说，有 50 个可见字符，即包括末尾的 NUL 在内的 51 字节，这不适合 net/rxrpc/proc.c 使用的现有 char[50] 缓冲区。从格式化程序的最大文本形式调整缓冲区大小并将调用站点切换为 scnprintf（）。v1 以来的变更： - 修正变更日志以明确引用实际的最大当前树情况 - 围绕 ISATAP 格式路径而不是之前的 mapped-v4 示例 （CVE-2026-31630） 构建证明

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

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

  - Axios 是一个基于承诺的 HTTP 客户端，适用于浏览器和Node.js。在 和 1.15.10.31.1之前，当 Object.prototype 被 Object.prototype 与 axios 读取且没有 hasOwnProperty 保护的密钥共依赖污染时，攻击者可以（a） 在应用程序看到之前悄无声息地拦截并修改每个 JSON 响应，或 （b） 完全劫持底层 HTTP 传输，获得请求凭据、头部和正文的访问权限。前提条件是同一工艺中来自不同来源的原型污染。此漏洞已在 1.15.1 和 0.31.1 中修复。(CVE-2026-42033)

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

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

  - media：em28xx：修复 em28xx_v4l2_open（） 中的释放后使用 em28xx_v4l2_open（） 在不保留 dev->lock 的情况下读取 dev->v4l2，从而与 em28xx_v4l2_init（） 的错误路径和 em28xx_v4l2_fini（） 产生争用，两者都会释放em28xx_v4l2 struct 并将 dev->v4l2 在 dev->lock 下设置为空。此争用导致两个问题：- 访问 vdev->ctrl_handler 时，v4l2_fh_init（） 中存在释放后使用，因为video_device嵌入在释放的 em28xx_v4l2 结构中。- 由于 dev->v4l2 设置为 NULL，访问 v4l2->norm 时，em28xx_resolution_set（） 中存在空指针取消引用。通过在 dev->v4l2 读取之前移动 mutex_lock（），并在锁定下添加 dev->v4l2 的空检查，来修复此问题。（CVE-2026-31583）

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

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

  - xfrm：将 dev ref 保留至transport_finish NF_HOOK后 异步加密完成后，xfrm_input_resume（） 在重新输入时立即调用 dev_put（），然后 skb 到达transport_finish。skb->dev 指针随后在 NF_HOOK 及其 okfn 内部使用，其可与设备拆卸争用。请从异步恢复条目中删除dev_put，而是在 transport_finish 中的 NF_HOOK 调用之后使用保存的设备指针丢弃引用，因为NF_HOOK可能会消耗 skb。这涵盖了跳过 okfn 的 NF_DROP、NF_QUEUE 和 NF_STOLEN 路径。对于非传输退出（decaps、gro、drop）和辅助异步返回点，在设置异步时释放引用内联。（CVE-2026-31663）

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

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

  - rxrpc：修复 RxGK 令牌加载以检查边界 rxrpc_preparse_xdr_yfs_rxgk（） 读取 XDR 令牌的原始密钥长度和工单长度为 u32 值，并在使用四舍五入值进行验证和分配前，分别通过 round_up（x， 4）。当原始长度为>= 0xfffffffd时，round_up（）包裹为0，因此边界检查和kzalloc都使用0，而后续的memcpy仍复制原始~4 GiB值，产生可通过非add_key特权调用访问的堆缓冲区溢出。解决方法是：（1）在四舍五入前拒绝超过AFSTOKEN_GK_KEY_MAX的原始密钥长度和超过AFSTOKEN_GK_TOKEN_MAX的原始工单长度，这与RxKAD路径通过AFSTOKEN_RK_TIX_MAX强制执行的上限一致。
    （2） 通过struct_size_t（）而非四舍五入值，从验证过的原始密钥长度对灵活数组分配进行调整。（3） 缓存原始长度，使后续字段赋值和 memcpy 调用不会从令牌中重新读取，从而消除了 TOCTOU 重新解析的一类。控制路径（长度在范围内的有效令牌）不受影响。（CVE-2026-31641）

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

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

  - OP-TEE 是一个可信执行环境 （TEE），旨在作为 Arm 上运行的不安全 Linux 内核的配套产品;使用 TrustZone 技术的 Cortex-A 核心。从 3.8.0 to 4.10，在 core/drivers/crypto/crypto_api/acipher/rsassa.c 的函数 emsa_pkcs1_v1_5_encode（） 中，所需的填充量 PS 大小是通过从密钥模数大小中减去 EMA-PKCS1-v1_5 编码所需的摘要和其他字段的大小来计算的。通过选择足够小的模数，此减法可以溢出。填充添加为包含 memset（） 调用的 0xFF 字节字符串，下溢的整数将导致 memset（） 调用被覆盖，直到 OP-TEE 崩溃。这仅影响注册 RSA 加速的平台。（CVE-2026-33662）

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

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

  - rxrpc：修正调用移除以使用 RCU 安全删除 修复从 rxnet->calls 列表中移除 rxrpc 调用时使用list_del_rcu（） 而非 list_del_init（），以防止读取 /proc/net/rxrpc/调用时出现无限循环。然而，这意味着list_empty（）不再适用于已删除列表中的条目，这使得检测先前删除变得更加困难。解决方法是：首先，只让rxrpc_destroy_all_calls（）倾倒意外仍在列表中的前十个调用。
    限制步数意味着无需调用cond_resched（）或从列表中移除调用，从而消除了rxrpc_put_call（）检查这些请求的必要。rxrpc_put_call（） 可以被修正为无条件删除该调用，因为删除是唯一发生的地方。
    (CVE-2026-31642)

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

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

  - ALSA：6fire：修复断开连接时的释放后使用 在 usb6fire_chip_abort（） 中，芯片结构被分配为卡的隐私数据（通过带有 sizeof（struct sfire_chip）） 的snd_card_new）。调用 snd_card_free_when_closed（） 且未打开任何文件句柄时，卡和嵌入式芯片会同步释放。随后的 chip->card = NULL 写入会攻击释放的 slab 内存。调用跟踪：
    usb6fire_chip_abort sound/usb/6fire/chip.c：59 [内联] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c：182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c：458 ...
    hub_event+0x1a04/0x4518 drivers/usb/core/hub.c：5953 通过将卡生命周期从 usb6fire_chip_abort（） 移至 usb6fire_chip_disconnect（） 来修复。在任何拆卸之前，卡指针保存在本地，首先调用 snd_card_disconnect（） 以防止新的打开，在芯片仍然有效时中止 URB，最后调用 snd_card_free_when_closed（），这样在释放卡之后永远不会访问芯片。（CVE-2026-31581）

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

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

  - mm： filemap： fix filemap_map_pages nr_pages 计算溢出问题 ） 在我的 Arm64 机器上运行 stress-ng 时，内核为 v7.0-rc3，我遇到了一些非常奇怪的崩溃问题，显示为页面状态不良：
     [ 734.496287] BUG：进程中页面状态异常 stress-ng-env pfn：415735fb [ 734.496427] page： refcount：0 mapcount：1 mapping：00000000000000000000000000000 index：0x4cf316 pfn：0x415735fb [ 734.496434] flags：
    0x57fffe000000800（owner_2|node=1|zone=2|lastcpupid=0x3ffff）[ 734.496439] 原始代码：057fffe0000000800 0000000000000000 dead000000000122 00000000000000000 [ 734.496440] 原始代码：0000000000004cf316 0000000000000000000000000000000000000000000 [ 734.496442] 页面被倾弃原因：非零地图计数 分析该页面状态后，很难理解为何地图计数不是0而参考计数为0，因为该页面并非问题最初发生的地方。通过启用CONFIG_DEBUG_VM配置，我也能重现崩溃，并捕捉到了问题出现的第一个警告：[ 734.469226] page： refcount：33 mapcount：0 mapping：00000000bef2d187 index：0x81a0 pfn：0x415735c0 [ 734.469304] head： order：5 mapcount：0 entire_mapcount：0 nr_pages_mapped：0 pincount：0 [ 734.469315] memcg：ffff000807a8ec00 [ 734.469320] aops：ext4_da_aops ino：100b6f dentry name（？）：stress-ng-mmaptorture-9397-0-2736200540 [ 734.469335] 旗帜：
    0x57fffe400000069（locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff） ......[ 734.469364] 页面被倾倒，原因如下：VM_WARN_ON_FOLIO（（_Generic（（page + nr_pages - 1），const struct page *： （const struct folio
    *）_compound_head（页面 + nr_pages - 1）， struct 页面 *： （struct folio *）_compound_head（page + nr_pages - 1））！= folio） [ 734.469390] ------------[ 此处切割 ]------------ [ 734.469393] 警告：
    ./include/linux/rmap.h：351 在 folio_add_file_rmap_ptes+0x3b8/0x468， CPU#90： stress-ng-mlock/9430 [734.469551] folio_add_file_rmap_ptes+0x3b8/0x468 （P） [ 734.469555] set_pte_range+0xd8/0x2f8 [ 734.469566] filemap_map_folio_range+0x190/0x400 [ 734.469579] filemap_map_pages+0x348/0x638 [ 734.469583] do_fault_around+0x140/0x198 ......[ 734.469640] el0t_64_sync+0x184/0x188 触发警告的代码为：VM_WARN_ON_FOLIO（page_folio（page + nr_pages - 1） ！= folio， folio），表示 set_pte_range（） 尝试映射到大开本尺寸之外。通过添加更多调试信息，我发现 filemap_map_pages（） 中的“nr_pages”溢出，导致 set_pte_range（） 建立了超出对开本大小范围的映射，可能导致不属于该开本的页面字段（例如 page->_mapcount）。经过以上分析，我认为可能的竞赛如下：CPU 0 CPU 1 filemap_map_pages（） ext4_setattr（） //用旧的inode->i_size next_uptodate_folio（） ....... //shrink inode->i_size i_size_write（inode， attr->ia_size）;end_pgoff计算新的Inode->i_size file_end = DIV_ROUND_UP（i_size_read（映射->host），PAGE_SIZE）- 1;end_pgoff = min（end_pgoff， file_end）;...... //nr_pages 可能溢出，因为xas.xa_index > end_pgoff 结尾 =  folio_next_index（开页）- 1;nr_pages = 最小（末，end_pgoff）- xas.xa_index + 1;...... //map 大对开本filemap_map_folio_range（） ...... //截断对开本 truncate_pagecache（inode， inode->i_size）;要解决这个问题，请将“end_pgoff”计算移到next_uptodate_folio（），这样检索到的开本与文件端保持一致，以避免 ---truncated--- （CVE-2026-31648）

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

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

  - x86/CPU：修复 Zen1 上的 FPDSS Zen1 的硬件分频器在某些情况下，可能会留下之前操作的部分结果。这些结果可能会被另一个攻击者线程泄露。用鸡肉块解决这个问题。（CVE-2026-31628）

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

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

  - seg6：seg6 lwtunnel 中输入和输出路径的独立dst_cache seg6 lwtunnel 每个封装路由使用单一dst_cache，由 seg6_input_core（） 和 seg6_output_core（） 共享。这两条路径可以在不同的路由上下文下执行封装后的SID查找（例如，入口接口上的IP规则匹配，或VRF表分离）。先运行的路径填充缓存，另一条路径盲目重复使用，绕过自身查找。通过将缓存拆分为cache_input和cache_output来解决这个问题，使每条路径独立维护自己的缓存DST来解决这个问题。（CVE-2026-31668）

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

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

  - 已修复 Linux 内核中的下列漏洞：rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace:
    skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload. (CVE-2026-31635)

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

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

  - KVM：x86：使用 MMIO 片段中的暂存字段保存较小的写入值 退出到用户空间以提供仿真 MMIO 写入时，如果数据负载的大小小于或等于 8 字节（即可以容纳到单个区块中），而不是将片段直接指向源值，则将待写入值复制到 MMIO 片段中的暂写字段。这修复了一类释放后使用缺陷，当仿真器使用堆栈上的本地变量作为源来启动写入，写入拆分页面边界时，*并且*两个页面都是 MMIO 页面时，就会发生这些缺陷。由于 KVM 的 ABI 仅允许物理上连续的 MMIO 请求，拆分 MMIO 页面的访问被分成两个片段，并且一次发送到一个用户空间。KVM 尝试完成用户空间 MMIO 以响应第一个片段之后的KVM_RUN时，KVM 将检测第二个片段并生成第二个用户空间退出，并引用堆栈上的变量。如果单独的任务执行第二个KVM_RUN，则此问题最为明显，在这种情况下，启动任务的堆栈会显示为真正释放的数据。
    ==================================================================缺陷：KASAN：complete_emulated_mmio+0x305/0x420 中的释放后使用 任务 syz-executor417/984 在地址 ffff888009c378d1 处读取大小为 1 CPU：1 PID：984 通信：syz-executor417 未受感染 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 硬件名称：QEMU Standard PC （i440FX + PIIX， 1996），BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 2014 年 4 月 1 日调用跟踪：dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170
    __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20
    __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP：
    0033：0x42477d 代码： <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP：
    002b：00007faa8e6890e8 EFLAGS： 00000246 ORIG_RAX： 0000000000000010 RAX： ffffffffffffffda RBX：
    00000000004d7338 RCX： 000000000042477d RDX： 00000000000000000 RSI： 0000000000000ae80 RDI： 0000000000000005 RBP： 00000000004d7330 R08： 00007fff28d546df R09： 00000000000000000 R10： 0000000000000000 R11：
    0000000000000246 R12： 0000000000004d733c R13： 00000000000000000 R14： 0000000000040a200 R15： 00007fff28d54720 有缺陷的地址属于 page： page：： 0000000029f6a428 refcount：0 mapcount：0 mapping：0000000000000000 index：0x0 pfn：0x9c37 flags：0xfffffc0000000（node=0|zone=1|lastcpupid=0x1fffff） raw： 000fffffc000000000000000000000 ffffea00000270dc8 0000000000000000000 raw： 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000周围有缺陷的地址：ffff888009c37780： ff ff ffff888009c37800： ff ff ff >ff ff ff ff ffff888009c37980： ff ff ff ================================================================== 也可以通过破解 KVM 填充 complete_emulated_mmio（） 中的大型堆栈上变量，使用目标 KVM-Unit-Test 重现该缺陷， 即
    通过用垃圾覆盖数据值。将暂存字段的使用限制为 8 字节或更小的访问，并且仅限于写入，因为由于仿真器中的实现详细信息，较大的访问和读取不受到影响，但请添加健全性检查以确保这些详细信息未来不会发生更改。
    具体而言，KVM 从不将堆栈上的变量用于大于 8 字节的访问，例如在仿真器上下文中使用操作数，以及 *al ---truncated--- （CVE-2026-31588）

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

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

  - 已修复 Linux 内核中的下列漏洞：arm64: mm: Handle invalid large leaf mappings correctly It has been possible for a long time to mark ptes in the linear map as invalid. This is done for secretmem, kfence, realm dma memory un/share, and others, by simply clearing the PTE_VALID bit.
    But until commit a166563e7ec37 (arm64: mm: support large block mapping when rodata=full) large leaf mappings were never made invalid in this way. It turns out various parts of the code base are not equipped to handle invalid large leaf mappings (in the way they are currently encoded) and I've observed a kernel panic while booting a realm guest on a BBML2_NOABORT system as a result: [ 15.432706] software IO TLB:
    Memory encryption is active and system is using DMA bounce buffers [ 15.476896] Unable to handle kernel paging request at virtual address ffff000019600000 [ 15.513762] Mem abort info: [ 15.527245] ESR = 0x0000000096000046 [ 15.548553] EC = 0x25: DABT (current EL), IL = 32 bits [ 15.572146] SET = 0, FnV = 0 [15.592141] EA = 0, S1PTW = 0 [ 15.612694] FSC = 0x06: level 2 translation fault [ 15.640644] Data abort info: [ 15.661983] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 [ 15.694875] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 15.723740] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 15.755776] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081f3f000 [ 15.800410] [ffff000019600000] pgd=0000000000000000, p4d=180000009ffff403, pud=180000009fffe403, pmd=00e8000199600704 [ 15.855046] Internal error: Oops:
    0000000096000046 [#1] SMP [ 15.886394] Modules linked in: [ 15.900029] CPU: 0 UID: 0 PID: 1 Comm:
    swapper/0 Not tainted 7.0.0-rc4-dirty #4 PREEMPT [ 15.935258] Hardware name: linux,dummy-virt (DT) [15.955612] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 15.986009] pc :
    __pi_memcpy_generic+0x128/0x22c [ 16.006163] lr : swiotlb_bounce+0xf4/0x158 [ 16.024145] sp :
    ffff80008000b8f0 [ 16.038896] x29: ffff80008000b8f0 x28: 0000000000000000 x27: 0000000000000000 [16.069953] x26: ffffb3976d261ba8 x25: 0000000000000000 x24: ffff000019600000 [ 16.100876] x23:
    0000000000000001 x22: ffff0000043430d0 x21: 0000000000007ff0 [ 16.131946] x20: 0000000084570010 x19:
    0000000000000000 x18: ffff00001ffe3fcc [ 16.163073] x17: 0000000000000000 x16: 00000000003fffff x15:
    646e612065766974 [ 16.194131] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [16.225059] x11: 0000000000000000 x10: 0000000000000010 x9 : 0000000000000018 [ 16.256113] x8 :
    0000000000000018 x7 : 0000000000000000 x6 : 0000000000000000 [ 16.287203] x5 : ffff000019607ff0 x4 :
    ffff000004578000 x3 : ffff000019600000 [ 16.318145] x2 : 0000000000007ff0 x1 : ffff000004570010 x0 :
    ffff000019600000 [ 16.349071] Call trace: [ 16.360143] __pi_memcpy_generic+0x128/0x22c (P) [ 16.380310] swiotlb_tbl_map_single+0x154/0x2b4 [ 16.400282] swiotlb_map+0x5c/0x228 [ 16.415984] dma_map_phys+0x244/0x2b8 [ 16.432199] dma_map_page_attrs+0x44/0x58 [ 16.449782] virtqueue_map_page_attrs+0x38/0x44 [ 16.469596] virtqueue_map_single_attrs+0xc0/0x130 [ 16.490509] virtnet_rq_alloc.isra.0+0xa4/0x1fc [ 16.510355] try_fill_recv+0x2a4/0x584 [ 16.526989] virtnet_open+0xd4/0x238 [ 16.542775] __dev_open+0x110/0x24c [ 16.558280] __dev_change_flags+0x194/0x20c [16.576879] netif_change_flags+0x24/0x6c [ 16.594489] dev_change_flags+0x48/0x7c [ 16.611462] ip_auto_config+0x258/0x1114 [ 16.628727] do_one_initcall+0x80/0x1c8 [ 16.645590] kernel_init_freeable+0x208/0x2f0 [ 16.664917] kernel_init+0x24/0x1e0 [ 16.680295] ret_from_fork+0x10/0x20 [ 16.696369] Code: 927cec03 cb0e0021 8b0e0042 a9411c26 (a900340c) [ 16.723106] ---[ end trace 0000000000000000 ]--- [ 16.752866] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 16.792556] Kernel Offset: 0x3396ea200000 from 0xffff8000800000 ---truncated--- (CVE-2026-31600)

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

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

  - KDE Arianna 中的 26.04.1 bookserver，允许攻击者通过猜测 URL 读取文件。（CVE-2026-42095）

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

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

  - WiFi：RTW88：修复探头故障时的设备泄漏驱动核心在接口绑定驱动时保留对USB接口及其父USB设备的引用，除非断开连接后结构需要，否则无需额外引用。该驱动程序在探针过程中会引用 USB 设备，但不会在所有探针错误时（例如描述符解析失败时）释放该代码。
    去除冗余设备引用以修复泄漏，减少货物挖掘，更容易识别需要额外引用的驱动程序，并降低进一步内存泄漏的风险。（CVE-2026-31604）

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

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

  - netfilter：nft_ct：修复超时对象破坏中的释放后使用 nft_ct_timeout_obj_destroy（） 在 nf_ct_untimeout（） 之后立即使用 kfree（） 释放超时对象，而无需等待 RCU 宽限期。
    其他 CPU 上的并行数据包处理可能仍保留对通过 nf_ct_timeout_data（） 中的 rcu_dereference（） 获取的超时对象的 RCU 保护引用。添加 struct nf_ct_timeout 的 rcu_head 并使用 kfree_rcu（） 将释放延迟到 RCU 宽限期过后，这与 nfnetlink_cttimeout.c 中已使用的方法相匹配。KASAN 报告：缺陷：KASAN：在 nf_conntrack_tcp_packet+0x1381/0x29d0 中的释放后使用 在 addr ffff8881035fe19c 处的大小为 4 的 slab-use-after-free by task exploit/80 调用跟踪：nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100
    __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 按任务 75 分配：
    nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 由任务 26 释放：nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0 （CVE-2026-31665）

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

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

  - rxrpc：修复 rxgk_do_verify_authenticator（） 中的缓冲区越界读取 修复 rxgk_do_verify_authenticator（） 以在检查临时信息之前检查缓冲区大小。（CVE-2026-31631）

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

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

  - rxrpc：修正在比较排队中的RESP挑战串时使用错误的SKB问题。在rxrpc_post_response（），代码应在决定切换到更新响应前，先比较缓存响应中的挑战序列号，但实际上会查看较新的数据包私有数据，使得比较总是错误。
    解决方法是切换到旧的数据包。进一步修正[1]，如果是新包，用新包替换旧包，并且释放我们不使用的包。（CVE-2026-31640）

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

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

  - mm：blk-cgroup：修复 cgwb_release_workfn（） 中的释放后使用 cgwb_release_workfn（） css_put（wb->blkcg_css） 然后通过 blkcg_unpin_online（） 再次访问 wb->blkcg_css。如果 css_put（） 丢弃最后一个引用，则可在 blkcg_unpin_online（） 取消引用指针以访问 blkcg->online_pin 之前异步释放 blkcg （css_free_rwork_fn -> blkcg_css_free -> kfree），从而导致释放后使用： 缺陷：KASAN：blkcg_unpin_online 中的 slab-use-after-free （./include/linux/instrumented.h：112 ./include/linux/atomic/atomic-instrumented.h：400 ./include/linux/refcount.h：389 ./include/linux/refcount.h：432 ./include/linux/refcount.h：450 block/blk-cgroup.c：1367） 任务 kworker/71:1/531 在地址 ff11000117aa6160 处写入大小为 4 的工作队列： cgwb_release cgwb_release_workfn 调用跟踪：
    <TASK> blkcg_unpin_online （./include/linux/instrumented.h：112 ./include/linux/atomic/atomic-instrumented.h：400 ./include/linux/refcount.h：389 ./include/linux/refcount.h：432 ./include/linux/refcount.h：450 block/blk-cgroup.c：1367） cgwb_release_workfn （mm/backing-dev.c：629） process_scheduled_works （kernel/workqueue.c：3278 kernel/workqueue.c：3385） 由任务 1016 释放：kfree （./include/linux/kasan.h：235 mm/slub.c：2689 mm/slub.c：6246 mm/slub.c：6561） css_free_rwork_fn （kernel/cgroup/cgroup.c：5542） process_scheduled_works （kernel/workqueue.c：3302 kernel/workqueue.c：3385） ** 基于提交 66672af7a095 的堆栈（为 20260410 添加 linux-next 特定文件）我在多个内核版本的 Meta fleet 中偶尔看到此崩溃。完整的复制品可在以下网址获得：
    https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh （比赛窗口很窄。为了使其易于重现，请在 cgwb_release_workfn（） 的 css_put（） 和 blkcg_unpin_online（） 之间注入 msleep（100）。有了该延迟和启用了 KASAN 的内核，复制器可以在不到一秒的时间内可靠地触发 splat。通过将 blkcg_unpin_online（） 移动到 css_put（） 之前修复此问题，这样 cgwb 的 CSS 引用在 blkcg_unpin_online（） 访问 blkcg 时使其保持活动状态。（CVE-2026-31586）

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

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

  - WireGuard：设备：在pre_exit wg_netns_pre_exit（）中使用exit_rtnl回调而非手动rtnl_lock，手动获取pernet.pre_exit回调中的rtnl_lock（）。当另一线程持有rtnl_mutex时，会导致任务卡顿——cleanup_net工作队列（或setup_net故障回滚路径）在wg_netns_pre_exit（）中无限期阻塞，等待获取锁。转换为.exit_rtnl，该代码在提交7a60d91c690b中引入（net：向struct pernet_operations.添加->exit_rtnl（）钩子），该框架已保留RTNL，并将所有回调处理在单一的rtnl_lock（）/rtnl_unlock（）对下，消除争用窗口。rcu_assign_pointer（wg->creating_net， NULL）可以安全地从.pre_exit移动到.exit_rtnl（在synchronize_rcu（）之后运行），因为所有creating_net的RCU读卡器要么使用maybe_get_net（）——该地址返回一个引用计数为零的濒死命名空间的NULL——要么访问net->user_ns，后者在整个ops_undo_list序列中始终有效。[杰森：补充__net_exit
    __read_mostly缺少的注释。]（CVE-2026-31579）

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

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

  - Axios 是一个基于承诺的 HTTP 客户端，适用于浏览器和Node.js。在 和 1.15.10.31.1之前，对于流请求体，当 maxRedirects 设为 0（本地 http/https 传输路径）时，maxBodyLength 会被绕过。即使来电者设定严格的观众人数限制，超大批量的直播上传也会完整发送。此漏洞已在 1.15.1 和 0.31.1 中修复。(CVE-2026-42034)

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

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

  - rxrpc：在rxgk_verify_response（）中修正整数溢出，rxgk_verify_response（），由于在检查前向上取整token_len，可能存在整数溢出，从而绕过长度检查。通过对照 len 进行未四舍五入的值来解决这个问题（len 受限，因为响应必须容纳在单个 UDP 包中）。（CVE-2026-31633）

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

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

  - smb：客户端：修复 check_wsl_eas（） 中的差 8 边界检查 边界检查使用 （u8 *）ea + nlen + 1 + vlen 作为 EA 名称和值的结尾，但ea_data位于 EA 的偏移 sizeof（struct smb2_file_full_ea_info） = 8，而不是偏移 0。strncmp（） 稍后会读取 ea->ea_data[0..nlen-1]，值字节位于 ea_data[nlen+1..nlen+vlen]，所以实际结束是 ea->ea_data + nlen + 1 + vlen。指针数学不是很有趣吗？较早的检查 （u8 *）ea> end - sizeof（*ea） 仅保证 8 字节标头在界内，但由于最后一个 EA 位于响应末尾的 8 字节内，因此名称和值字节会在 iov 末尾之后进行读取。通过使用 ea->ea_data 作为边界检查的基础来修复所有这些混乱。不受信任的服务器可利用此问题将最多 8 字节的内核堆泄露到 EA 名称比较中，并影响将数据解释为哪个 WSL xattr。（CVE-2026-31614）

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

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

  - wifi：brcmsmac：fix dma_free_coherent（） 大小 dma_alloc_consistent（） 可能会改变大小以对齐。新尺寸会被保存在分配中。将自由分配的大小调整为匹配。（CVE-2026-31661）

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

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

  - Axios 是一个基于承诺的 HTTP 客户端，适用于浏览器和Node.js。在 和 1.15.10.31.1之前，Axios HTTP 适配器（lib/adapters/http.js）中存在一个原型污染装置，允许攻击者向发出请求注入任意 HTTP 头。该漏洞利用了数据载荷的鸭式检查，即如果 Object.prototype 被 getHeaders、append、pipe， on、once 和 Symbol.toStringTag 污染，Axios 会将任何普通对象有效载荷误判为 FormData 实例，调用攻击者控制的 getHeaders（） 函数，将返回的头合并到发出请求中。易受攻击的代码仅存在于库/适配器/http.js中。原型污染源不必来自Axios本身，任何在应用依赖树中任何依赖节点中的原型污染都足以触发该装置。该漏洞在 和 0.31.1中被固定。1.15.1
    (CVE-2026-42035)

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

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

  - KVM：SEV：在KVM_MEMORY_ENCRYPT_REG_REGION时在大容量时丢弃WARN。对于n页中溢出int时，将WARN以sev_pin_memory（）中丢弃，因为WARN在用户空间触发简直滑稽，例如：
    struct kvm_enc_region range = { .addr = 0， .size = -1ul， };__vm_ioctl（vm， KVM_MEMORY_ENCRYPT_REG_REGION， &range）;注意，sev_mem_enc_register_region（）中可能存在的验证地址+大小的检查完全无用，因为加法和大小都是u64，SEV仅为64位，即
    他们_can t_比ULONG_MAX更伟大。那个疣很快就会被清理干净。如果 （range->addr > ULONG_MAX || range->size > ULONG_MAX） 返回 -EINVAL;机会主义地添加注释，解释为什么代码用硬的方式计算页数，比如而不是直接@ulen。(CVE-2026-31590)

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

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

  - rxrpc：修复密钥解析 memleak 在 rxrpc_preparse_xdr_yfs_rxgk（） 中，分配给令牌>rxgk的内存在分配后可能会在几条错误路径中泄漏。通过释放它在reject_token：保护箱中来解决这个问题。
    (CVE-2026-31643)

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

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

  - KVM：SEV：用kvm->lock保护*所有*sev_mem_enc_register_region（）。在检查sev_mem_enc_register_region（）中的sev_guest（）之前，先取并保持kvm->lock，因为除非保持kvm->锁（或KVM保证KVM_SEV_INIT{2}已完成且无法rollack状态），否则sev_guest（）不稳定。如果KVM_SEV_INIT{2}失败，KVM可能会尝试添加尚未初始化的sev->regions_list，例如触发 #GP 哎呀：一般保护故障，可能是非正规地址 0xdffffc0000000000： 0000 [#1] SMP KASAN NOPTI KASAN： null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU： 110 UID： 0 PID： 72717 通讯： syz.15.11462 受污染： G U W O 6.16.0-SMP-DEV #1 无污染：[U]=用户，[W]=WARN，[O]=OOT_MODULE硬件名称：谷歌公司 Arcadia_IT_80/Arcadia_IT_80，BIOS 12.52.0-0 2024年10月28日 RIP：
    0010：sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h：83 代码： <41> 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00 RSP：0018：ffff88838647fbb8 EFLAGS：00010256 RAX：dffffc000000000000000 RBX：1ffff92015cf1e0b RCX：dffffc00000000000000000 RDX：000000000000000000000 RSI：0000000000001000 RDI：
    FFFF888367870000 RBP：ffffc900ae78f050 R08： ffffea000d9E0007 R09： 1ffffd4001b3C0000 R10： DFFFFFC000000000000000 R11： FFFFF94001B3C001 R12： R14R150000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 R13
    0000000000000000 FS： 00007f34e9dc66c0（0000） GS：ffff89ee64d33000（0000） knlGS：000000000000000000000000000000 CS： 0010 DS：
    0000 ES： 0000 CR0： 0000000080050033 CR2： 00007fe180adef98 CR3： 000000047210e000 CR4： 0000000000350ef0 呼叫追踪： <TASK> kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c：7371 kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c：5363 __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c：51 do_syscall_x64 ../arch/x86/entry/syscall_64.c：63 [内联] do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP： 0033：0x7f34e9f7e9a9 代码： <48> 3d 01 f0 ff ff ff 73 01 c3 48 c7 c1 a8 ff ff ff ff f7 d8 64 89 01 48 RSP： 002b：00007f34e9dc6038 EFLAGS： 00000246 ORIG_RAX： 0000000000000010 RAX： ffffffffda RBX： 00007f34ea1a6080 RCX： 00007f34e9f7e9a9 RDX： 0000200000000280 RSI：
    0000000008010aebb RDI： 0000000000000007 RBP： 00007f34ea000d69 ： 00000000000000000 R09： 0000000000000000000000000000000000000000000000000 R11R10： 0000000000000246 R12： 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 R13R14R08
    00007f34ea1a6080 R15： 00007ffce77197a8 </TASK> 搭配一个看起来像：
    syz_kvm_add_vcpu$x86（0x0， &（0x7f0000000040）={0x0， &（0x7f0000000180）=ANY=[]， 0x70}） （异步） syz_kvm_add_vcpu$x86（0x0， &（0x7f0000000080）={0x0， &（0x7f0000000180）=ANY=[@ANYBLOB=...]， 0x4f}） （异步） r0 = openat$kvm（0xffffffffffffff9c， &（0x7f0000000200）， 0x0， 0x0） r1 = ioctl$KVM_CREATE_VM（r0， 0xae01， 0x0） r2 = openat$kvm（0xffffffffffffff9c， &（0x7f0000000240）， 0x0， 0x0） r3 = ioctl$KVM_CREATE_VM（r2， 0xae01， 0x0） ioctl$KVM_SET_CLOCK（r3， 0xc008aeba， &（0x7f0000000040）={0x1， 0x8， 0x0， 0x5625e9b0}）（异步） ioctl$KVM_SET_PIT2（r3， 0x8010aebb， &（0x7f0000000280）={[...]， 0x5}） （异步） ioctl$KVM_SET_PIT2（r1， 0x4070aea0， 0x0） （异步） r4 = ioctl$KVM_CREATE_VM（0xffffffffffffffff， 0xae01， 0x0） openat$kvm（0xffffffffffffff9c， 0x0， 0x0， 0x0） （异步） ioctl$KVM_SET_USER_MEMORY_REGION（r4， 0x4020ae46， &（0x7f0000000400）={0x0， 0x0， 0x0， 0x2000， &（0x7f0000001000/0x2000）=nil}） （异步） r5 = ioctl$KVM_CREATE_VCPU（r4， 0xae41， 0x2） close（r0） （异步） openat$kvm（0xffffffffffffff9c， &（0x7f0000000000）， 0x8000， 0x0） （异步） ioctl$KVM_SET_GUEST_DEBUG（r5， 0x4048ae9b， &（0x7f0000000300）={0x4376ea830d46549b， 0x0， [0x46， 0x0， 0x0， 0x0， 0x0， 0x1000]}）（async） ioctl$KVM_RUN（r5， 0xae80， 0x0） 机会性地使用 guard（） 以避免定义新的错误标签和 goto 使用。（CVE-2026-31592）

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

ID	名称	严重性
310608	Linux Distros 未修补的漏洞：CVE-2026-31457	medium
310607	Linux Distros 未修补的漏洞：CVE-2026-6755	medium
310606	Linux Distros 未修补的漏洞：CVE-2026-31529	medium
310605	Linux Distros 未修补的漏洞：CVE-2026-31465	medium
310604	Linux Distros 未修补的漏洞：CVE-2026-31691	medium
310603	Linux Distros 未修补的漏洞：CVE-2026-31444	critical
310602	Linux Distros 未修补的漏洞：CVE-2026-31686	high
310600	Linux Distros 未修补的漏洞：CVE-2026-42371	medium
310529	Linux Distros 未修补的漏洞：CVE-2026-31632	medium
310528	Linux Distros 未修补的漏洞：CVE-2026-42041	medium
310527	Linux Distros 未修补的漏洞：CVE-2026-31664	medium
310526	Linux Distros 未修补的漏洞：CVE-2026-41066	high
310525	Linux Distros 未修补的漏洞：CVE-2026-41898	high
310524	Linux Distros 未修补的漏洞：CVE-2026-31672	medium
310523	Linux Distros 未修补的漏洞：CVE-2026-31647	medium
310522	Linux Distros 未修补的漏洞：CVE-2026-41678	critical
310521	Linux Distros 未修补的漏洞：CVE-2026-41079	medium
310520	Linux Distros 未修补的漏洞：CVE-2026-31619	medium
310519	Linux Distros 未修补的漏洞：CVE-2026-41907	critical
310518	Linux Distros 未修补的漏洞：CVE-2026-42044	critical
310517	Linux Distros 未修补的漏洞：CVE-2026-41411	medium
310516	Linux Distros 未修补的漏洞：CVE-2026-31630	high
310515	Linux Distros 未修补的漏洞：CVE-2026-42033	high
310514	Linux Distros 未修补的漏洞：CVE-2026-31583	high
310513	Linux Distros 未修补的漏洞：CVE-2026-31663	high
310512	Linux Distros 未修补的漏洞：CVE-2026-31641	high
310511	Linux Distros 未修补的漏洞：CVE-2026-33662	high
310510	Linux Distros 未修补的漏洞：CVE-2026-31642	medium
310509	Linux Distros 未修补的漏洞：CVE-2026-31581	high
310508	Linux Distros 未修补的漏洞：CVE-2026-31648	high
310507	Linux Distros 未修补的漏洞：CVE-2026-31628	medium
310506	Linux Distros 未修补的漏洞：CVE-2026-31668	critical
310505	Linux Distros 未修补的漏洞：CVE-2026-31635	high
310504	Linux Distros 未修补的漏洞：CVE-2026-31588	high
310503	Linux Distros 未修补的漏洞：CVE-2026-31600	high
310502	Linux Distros 未修补的漏洞：CVE-2026-42095	medium
310501	Linux Distros 未修补的漏洞：CVE-2026-31604	medium
310500	Linux Distros 未修补的漏洞：CVE-2026-31665	high
310499	Linux Distros 未修补的漏洞：CVE-2026-31631	high
310498	Linux Distros 未修补的漏洞：CVE-2026-31640	high
310496	Linux Distros 未修补的漏洞：CVE-2026-31586	high
310495	Linux Distros 未修补的漏洞：CVE-2026-31579	medium
310494	Linux Distros 未修补的漏洞：CVE-2026-42034	medium
310493	Linux Distros 未修补的漏洞：CVE-2026-31633	critical
310492	Linux Distros 未修补的漏洞：CVE-2026-31614	high
310491	Linux Distros 未修补的漏洞：CVE-2026-31661	medium
310490	Linux Distros 未修补的漏洞：CVE-2026-42035	high
310489	Linux Distros 未修补的漏洞：CVE-2026-31590	medium
310488	Linux Distros 未修补的漏洞：CVE-2026-31643	medium
310487	Linux Distros 未修补的漏洞：CVE-2026-31592	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

critical

high

medium

medium

medium

medium

high

high

medium

medium

critical

medium

medium

critical

critical

medium

high

high

high

high

high

high

medium

high

high

medium

critical

high

high

high

medium

medium

high

high

high

high

medium

medium

critical

high

medium

high

medium

medium

medium