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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 媒体：EM28XX：修复 em28xx_v4l2_open（） 中的 use-after-free。em28xx_v4l2_open（） 读取 dev->v4l2 而不按住 dev->lock，导致与 em28xx_v4l2_init（） 的错误路径和 em28xx_v4l2_fini（ 发生竞赛），这两者都释放了 em28xx_v4l2 struct，并将 dev->v4l2 在 dev->lock 下设置为 NULL。这种竞争导致两个问题：- 访问 vdev->ctrl_handler 时，v4l2_fh_init（ ）中 use-after-free，因为video_device嵌入在释放的 em28xx_v4l2 结构中。- 访问 v4l2->norm 时，em28xx_resolution_set（） 中的 NULL 指针被引用，因为 dev->v4l2 已设置为 NULL。解决方法是将 mutex_lock（） 移到 dev->v4l2 读取前，并在锁下添加 dev->v4l2 的 NULL 检查。（CVE-2026-31583）

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

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

  - xfrm：保持开发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路径。对于非传输出口（除帽、格罗、丢弃）和次级异步返回点，设异步时释放参考线。（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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - rxrpc：修复过大响应认证器长度检查 rxgk_verify_response（） 解码数据包auth_len，旨在验证其是否适合剩余字节。现有的校验是反转的，因此接受过大的响应认证器并传递给rxgk_decrypt_skb（），后者可能以不可能的长度达到skb_to_sgvec（），并击中BUG_ON（len）。从原始最新网络重现日志中解码，脚本/decode_stacktrace.sh： RIP： __skb_to_sgvec（） [net/core/skbuff.c：5285 （discriminator 1）] 调用追踪： 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] 拒绝超过剩余数据包有效载荷的认证器长度。（CVE-2026-31635）

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

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

  - KVM：x86：在MMIO片段中使用scratch字段来存储较小的写值。当退出用户空间处理模拟MMIO写入时，如果数据负载大小不超过8字节，即能容纳在一个区块内，则将待写入值复制到MMIO片段中的scratch字段，而不是直接指向源值。这修复了一类“释放后使用”错误，即模拟器使用栈上的本地变量作为源，写入分割了页面边界，且两个页面都是MMIO页面时，就会出现的漏洞。由于KVM的ABI只允许物理连续的MMIO请求，拆分MMIO页面的访问被分成两个片段，一次发送到用户空间。当KVM尝试完成用户空间MMIO以响应第一个片段后的KVM_RUN时，KVM会检测第二个片段并生成第二个用户空间出口，并引用栈上变量。问题最明显的是第二个KVM_RUN由独立任务执行，此时启动任务的堆栈可能显示为真正释放的数据。
    ================================================================== bug：KASAN：在 complete_emulated_mmio+0x305/0x420 在 addr ffff888009c378d1 任务 syz-executor417/984 读取大小为 1 的 d_fff888009c378d1 任务 CPU：1 PID：984 通讯：syz-executor417 未受污染 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 硬件名称：QEMU 标准 PC（i440FX + PIIX，1996），BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 2014/04/01 呼叫追踪：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 ff f7 d8 64 89 01 48 RSP：
    002b：00007faa8e6890e8 EFLAGS： 00000246 ORIG_RAX： 0000000000000010 RAX： ffffffffffffda RBX：
    00000000004d7338 RCX： 000000000042477d RDX： 000000000000000000 RSI： 00000000000ae80 RDI： 0000000000000005 RBP： 000000000004d7330 R08： 00007fff28d546df R09： 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 R10R11
    0000000000000246 R12： 00000000004d733c R13： 000000000000000000 R14： 000000000040a20 R15： 00007fff28d54720 有bug的地址属于页面：page： 0000000029F6A428 refcount：0 mapcount：0 mapping：000000000000000000 index：0x0 pfn：0x9c37 flags： 0xfffffc0000000（node=0|zone=1|lastcpupid=0x1fffff） RAW： 000FFFFFC0000000 000000000000000 ffffea00000270dc8 00000000000000000000000 RAW： 000000000000000000000000000000000000000000000FFFFFFFF 000000000000000000000000000000000000000马车周围地址：FFFF888009C37780： FF FF FF ffff ff888009c378009c37800： FF FF ff >ffff88009c37880： FF FF ff ^ FFFF888009C37900： FF FF FF FF ffff888009c37980： FF FF FF ================================================================== 该漏洞也可以通过针对 KVM 单元测试（Unit-Test）重现，通过破解 KVM 填充 complete_emulated_mmio（） 中的大型堆栈变量， 即
    通过用垃圾覆盖数据值。将 scratch 字段的使用限制在 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（） 中修正 off-by-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作为边界检查的基础，解决了所有问题。不可信服务器可以利用这一点向EA名称比较泄露最多8字节的内核堆，从而影响数据被解释为哪个WSL xatr。（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 依赖供应商报告的程序包是否存在进行判断。

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

  - Axios 是一个基于承诺的 HTTP 客户端，适用于浏览器和Node.js。在 和 1.15.10.31.1之前，当使用 responseType： 'stream' 时，Axios 返回响应流且不强制执行 maxContentLength。这绕过了已配置的响应大小限制，允许无限制的下游消费。此漏洞已在 1.15.1 和 0.31.1 中修复。(CVE-2026-42036)

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

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

  - KVM：SEV：在同步 VMSA 进行 SNP 启动时锁定所有 结束 在同步和加密 VMSA 进行 SNP 访客 VMSA 时锁定所有 vCPU，因为允许用户在 vCPU 状态同步时操作和/或运行 vCPU 状态，充其量会导致 vCPU 状态损坏，最坏情况下会导致主机内核崩溃。
    机会主义地断言，在同步其VMSA时会保留vcpu->mutex（SEV-ES路径已经锁定了vCPU）。（CVE-2026-31591）

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

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

  - btrfs：修复更改 lookup_extent_data_ref（） 中的叶后错误的返回值 提交 1618aa3c2e01（btrfs：简化 lookup_extent_data_ref（） 中的返回变量）后，err 和 ret 变量被合并为一个 ret 变量。但是，当 btrfs_next_leaf（） 返回 0（成功）时，ret 将从 -ENOENT 覆盖为 0。如果下一个叶中的第一个键不匹配（不同的 objectid 或类型），该函数会返回 0 而不是 -ENOENT，从而使调用程序相信查找成功，但实际上没有。这可导致对错误的区段树项目进行操作，从而可能造成区段树损坏。当密钥不匹配时直接返回 -ENOENT，而非依赖 ret 变量，可修复此问题。（CVE-2026-31666）

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

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

  - NET：stmmac：修复链模式中的整数下溢 jumbo_frm（） 链模式实现无条件计算 len = nopaged_len - bmax;其中 nopaged_len = skb_headlen（skb）（仅线性字节），bmax 为 BUF_SIZE_8KiB 或 BUF_SIZE_2KiB。然而，调用者stmmac_xmit（）根据skb->len（包含页面片段的总长度）决定调用jumbo_frm（）：is_jumbo = stmmac_is_jumbo_frm（priv， skb->len， enh_desc）;当数据包线性部分较小（nopaged_len <= bmax）但由于页面片段导致总长度较大（skb->len > bmax）时，减法以无符号整数形式包裹，产生巨大的 len 值（~0xFFFFxxxx）。这导致while （len ！= 0） 循环执行数十万次迭代，将 skb->data + bmax * i 指针传递到远超 skb 缓冲区的 dma_map_single（）。在无IOMMU的SoC（stmmac的典型部署）上，这会将任意内核内存映射到DMA引擎，从而暴露内核内存并可能引发硬件损坏。通过引入一个buf_len局部变量，并夹在 min（nopaged_len， bmax） 上来解决这个问题。计算len = nopaged_len - buf_len总是安全的：当线性部分符合单一描述符时，它为零，导致while（len ！= 0）循环自然跳过，stmmac_xmit（）中的片段循环处理后续页面片段。
    (CVE-2026-31649)

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

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

  - rxrpc：只有在已获得呼叫引用时才添加调用引用rxrpc_input_packet_on_conn（ ） 可以在当前客户端呼叫已被拆除后处理客户端数据包。在这种情况下，chan->调用是NULL，rxrpc_try_get_call（）返回NULL，且没有丢弃的引用。客户端隐式端错误路径不考虑这些，且无条件调用 rxrpc_put_call（）。这会将协议错误路径变成内核崩溃，而不是拒绝数据包。只有当一个真的被收购时才要放弃这个呼号。保持现有的协议错误处理不变。（CVE-2026-31638）

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

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

  - HID： alps： fix alps_raw_event 中的 NULL 指针引用 （） 提交 ecfa6f34492c（HID： 在raw_event回调中添加 HID_CLAIMED_INPUT 守卫，未完成的 HID 驱动）尝试修复 2ff5baa9b527 中未完成的之前修复的 HID 驱动程序（HID： appleir： fix 原始事件处理处潜在的 NULL 取消引用），但未检测到该 alps 驱动。在尝试处理原始事件之前，先正确检查hid-alps驱动确认该信息被正确申报。（CVE-2026-31625）

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

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

  - usb：gadget：f_ncm：验证 ncm_unwrap_ntb（） 中的最小block_len 系统会检查从主机提供的 NTB 标头读取的block_len是否ntb_max，但没有下界。当block_len小于 opts->ndp_size 时，以下项的边界检查：ndp_index > （block_len - opts->ndp_size） 将下溢，生成一个ndp_index永远无法超过的巨大无符号值，从而完全破坏检查。在针对block_len opts->dpe_size 的数据报索引检查中也会发生相同的下溢。将这些检查中性化后，恶意 USB 主机可选择指向实际传输之后的ndp_index和数据报偏移，并且 skb_put_data（） 会将相邻的内核内存复制到网络 skb 中。通过拒绝不能至少容纳 NTB 标头和一个 NDP 的区块长度来修复此问题。这将使 block_len - opts->ndp_size 和 block_len - opts->dpe_size 得到明确定义。提交 8d2b1a1ec9f5（CDC-NCM：避免健全性检查中的溢出） 修复了 NCM 主机端的相关类问题。（CVE-2026-31617）

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

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

  - rust-openssl 为 Rust 编程语言提供 OpenSSL 绑定。从 0.10.39 到 0.10.78之前的 ，EVP_DigestFinal() 始终将 EVP_MD_CTX_size(ctx) 写入输出缓冲区。如果 out 小于该值，MdCtxRef::digest_final() 写入会超过其末尾，这通常会损坏堆栈。可从安全的 Rust 访问此漏洞。此漏洞已在 0.10.78 中修复。(CVE-2026-41681)

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

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

  - Axios 是基于 Promise 的 HTTP 客户端，用于浏览器和Node.js。在 和 0.31.1之前1.15.1，能够影响 Axios 请求的目标 URL 的攻击者可以使用 /8 范围内的任何地址127.0.0.0（127.0.0.1除外）完全绕过NO_PROXY保护。此漏洞是由 的 不CVE-2025-62718完整造成的，此漏洞已在 和 0.31.1中1.15.1修复。（CVE-2026-42043）

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

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

  - 提示bc_ackers：修复重复GRP_ACK_MSG的溢出 tipc_group_proto_rcv（）中的GRP_ACK_MSG处理程序目前会在每个入站组ACK上减少bc_ackers，即使同一成员已确认当前广播轮次。由于bc_ackers是u16，在最后一个合法ACK之后收到的重复ACK会包裹到65535。一旦封包，tipc_group_bc_cong（）会持续报告拥塞，后续受影响套接字上的组广播会被阻塞，直到组重新建立。
    通过在触摸bc_acked或bc_ackers之前忽略重复或过期的ACK来解决这个问题。这使得重复GRP_ACK_MSG处理成为幂等，防止下溢路径。（CVE-2026-31662）

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

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

  - rust-openssl 为 Rust 编程语言提供 OpenSSL 绑定。从 0.9.0 到 以前 0.10.78，*_from_pem_callback API 未验证用户回调返回的长度。返回值大于指定缓冲区的密码回调，可造成某些 OpenSSL 版本过度读取此缓冲区。OpenSSL 3.x 不受此漏洞影响。此漏洞已在 0.10.78 中修复。
    (CVE-2026-41677)

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

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

  - NET：RFKILL：防止无限数量的RFKILL事件被创建。如果系统配置如此，用户空间可以创建无限数量的RFKILL事件，同时不从rfkill文件描述符中消耗它们，从而导致潜在的内存不足情况。防止此限制将待处理的rfkill事件数量限制在很大数量（即1000）以防此类滥用。（CVE-2026-31670）

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

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

  - 已修复 Linux 内核中的下列漏洞：ALSA: usx2y: us144mkii: fix NULL deref on missing interface 0 A malicious USB device with the TASCAM US-144MKII device id can have a configuration containing bInterfaceNumber=1 but no interface 0. USB configuration descriptors are not required to assign interface numbers sequentially, so usb_ifnum_to_if(dev, 0) returns will NULL, which will then be dereferenced directly. Fix this up by checking the return value properly. (CVE-2026-31620)

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

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

  - Axios 是基于 Promise 的 HTTP 客户端，用于浏览器和Node.js。在 和 0.31.1之前1.15.1，他针对主机名标准化绕过no_proxy补丁不完整。当设置 no_proxy=localhost 时，对 和 [：：1] 的 127.0.0.1 请求仍通过代理进行路由，而非绕过代理。shouldBypassProxy（） 函数执行纯字符串匹配，但未解析 IP 别名或环回等效项。此漏洞已在 1.15.1 和 0.31.1 中修复。(CVE-2026-42038)

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

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

  - rxrpc：拒绝不可解密的rxkad响应票rxkad_decrypt_ticket（）解密RXKAD响应票，然后解析缓冲区为明文，不检查crypto_skcipher_decrypt（）是否成功。因此，一个格式不佳的响应可以使用非块对齐的工单长度，使解密操作失败，同时仍能用攻击者控制的字节驱动工单解析器。当票务解密失败时，检查解密结果并用RXKADBADTICKET终止连接。（CVE-2026-31637）

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

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

  - mptcp：修复 __inet_lookup_established 中 slab-use-after-free 的修正 ehash 表查找无锁，依赖SLAB_TYPESAFE_BY_RCU保证 RCU 读端关键段的套接字内存稳定性。tcp_prot和tcpv6_prot都通过 proto_register（） 创建了带有该标志的板缓存。然而，MPTCP的 mptcp_subflow_init（） 在 inet_init（） （fs_initcall，5 级）期间，在 inet6_init（）（module_init/device_initcall，6 级）调用 proto_register（&tcpv6_prot）之前，会将tcpv6_prot复制到tcpv6_prot_override中。此时，tcpv6_prot.slab仍然是NULL，因此tcpv6_prot_override.slab永久保持NULL。这使得MPTCP v6子流套接字通过kmalloc分配（即kmalloc-4k），而不是TCPv6板缓存。kmalloc-4k 缓存缺乏 SLAB_TYPESAFE_BY_RCU，因此当这些套接字被释放时没有SOCK_RCU_FREE（设计上子套接字会被清除），内存可以立即被重复使用。rcu_read_lock下的并发ehash查找可以访问已释放的内存，触发释放__inet_lookup_established后使用的Slab-use-for。解决方法是将IPv6专用初始化从mptcp_subflow_init（）拆分成一个新的mptcp_subflow_v6_init（），该在协议注册前从mptcp_proto_v6_init（）调用。这确保了 tcpv6_prot_override.slab 正确继承 SLAB_TYPESAFE_BY_RCU 的 slab 缓存。（CVE-2026-31669）

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

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

  - rxrpc：修复rxrpc_server_keyring（）中的引用计数泄漏，该补丁通过检查rx->securities是否已设置，修复rxrpc_server_keyring（）中的引用计数泄漏。（CVE-2026-31634）

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

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

  - Axios 是一个基于承诺的 HTTP 客户端，适用于浏览器和Node.js。从 1.0.0 到 之前 1.15.1，lib/helpers/formDataToStream.js 中的 FormDataPart 构造函数直接插值 value.type 到每个多部分部分的 Content-Type 头部，而不净化 CRLF （\r\n） 序列。控制 Blob/File类对象 .type 属性的攻击者（例如通过 Node.js 代理服务中用户上传的文件）可以向多部分表单数据体注入任意 MIME 部分头。这绕过了Node.js v18+内置的头部保护，因为注入针对的是多部分体结构，而非HTTP请求头。此漏洞已在 1.15.1 中修复。(CVE-2026-42037)

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

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

  - Axios 是一个基于承诺的 HTTP 客户端，适用于浏览器和Node.js。在 和 0.31.1之前，Axios 库的 XSRF 令牌保护逻辑使用 1.15.1 JavaScript 的真实/伪语义，而非严格的布尔比较，适用于 withXSRFToken 配置属性。当该属性被设置为任何真实的非布尔值（通过原型污染或配置错误）时，同源检查（isURLSameOrigin）会短路，导致XSRF令牌被发送到所有请求目标，包括由攻击者控制的跨源服务器。此漏洞已在 1.15.1 和 0.31.1 中修复。(CVE-2026-42042)

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

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

  - xfrm_user：修复 build_report（） 中的信息泄漏 struct xfrm_user_report 是一个__u8 proto 字段，后跟一个 struct xfrm_selector，这意味着有三个空字节的填充，但是在复制到用户空间之前永远不会将填充归零。通过在设置各个成员变量之前将结构清零来修复此问题。（CVE-2026-31671）

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

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

  - KVM：SEV：拒绝尝试同步已启动/加密的vCPU的VMSA;如果vCPU已经启动，即VMSA已被加密，则拒绝同步vCPU状态与其关联的VMSA。在启用SNP的主机上，访问访客私有内存会产生RMP的操作 #PF，使主机陷入恐慌。BUG：无法处理地址：ff1276cbfdf36000 #PF：内核模式下的监督写入访问 #PF：error_code（0x80000003） - RMP违规 PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163 SEV-SNP：PFN 0x40fdf36，RMP条目：[0x6010fffffffff001 - 0x000000000000001f] 哎呀：哎呀：0003 [#1] SMP NPP CPU：33 UID：0 PID：996180 通讯：qemu-system-x86 受污染：G OE 受污染： [O]=OOT_MODULE， [E]=UNSIGNED_MODULE 硬件名称：Dell Inc. PowerEdge R7625/0H1TJT，BIOS 1.5.8 2023年7月21日 RIP： 0010：sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd] 呼叫追踪： <TASK> snp_launch_update_vmsa+0x19d/0x290 [kvm_amd] snp_launch_finish+0xb6/0x380 [kvm_amd] sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd] kvm_arch_vm_ioctl+0x837/0xcf0 [kvm] kvm_vm_ioctl+0x3fd/0xcc0 [kvm]
    __x64_sys_ioctl+0xa3/0x100 x64_sys_call+0xfe0/0x2350 do_syscall_64+0x81/0x10f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP： 0033：0x7ffff673287d </TASK> 注意，KVM漏洞自提交ad73109ae7ec（KVM：提供启动和运行SEV-ES访客的支持）以来就存在，但自加入SNP支持后才对主机构成实际威胁。对于 SV-E，KVM 只需 clobber 访客状态，从主机内核角度来看完全没问题，因为用户空间可以在 sev_launch_update_vmsa（） 之前随时掠夺访客状态。（CVE-2026-31593）

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

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

  - Poetry 是 Python 的依赖管理器。在此之前 2.3.4，src/poetry/utils/helpers.py：410-426 中的 extractall（） 函数在无法使用 Python tarfile.data_filter版本中提取无路径遍历保护的 sdist tarball。仅考虑仍被 Poetry 支持的 Python 版本，这些分别是 3.10.0 - 3.10.12 和 3.11.0 - 3.11.4。此漏洞已在 2.3.4 中修复。
    (CVE-2026-41140)

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

ID	名称	严重性
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
310486	Linux Distros 未修补的漏洞：CVE-2026-42036	medium
310485	Linux Distros 未修补的漏洞：CVE-2026-31591	medium
310484	Linux Distros 未修补的漏洞：CVE-2026-31666	high
310483	Linux Distros 未修补的漏洞：CVE-2026-31649	critical
310482	Linux Distros 未修补的漏洞：CVE-2026-31638	high
310481	Linux Distros 未修补的漏洞：CVE-2026-31625	medium
310480	Linux Distros 未修补的漏洞：CVE-2026-31617	medium
310479	Linux Distros 未修补的漏洞：CVE-2026-41681	critical
310478	Linux Distros 未修补的漏洞：CVE-2026-42043	critical
310477	Linux Distros 未修补的漏洞：CVE-2026-31662	high
310476	Linux Distros 未修补的漏洞：CVE-2026-41677	medium
310475	Linux Distros 未修补的漏洞：CVE-2026-31670	medium
310474	Linux Distros 未修补的漏洞：CVE-2026-31620	medium
310473	Linux Distros 未修补的漏洞：CVE-2026-42038	high
310472	Linux Distros 未修补的漏洞：CVE-2026-31637	critical
310471	Linux Distros 未修补的漏洞：CVE-2026-31669	critical
310470	Linux Distros 未修补的漏洞：CVE-2026-31634	medium
310469	Linux Distros 未修补的漏洞：CVE-2026-42037	medium
310468	Linux Distros 未修补的漏洞：CVE-2026-42042	medium
310467	Linux Distros 未修补的漏洞：CVE-2026-31671	medium
310466	Linux Distros 未修补的漏洞：CVE-2026-31593	medium
310465	Linux Distros 未修补的漏洞：CVE-2026-41140	low

检测

Nessus 的 Misc. 系列

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

medium

medium

high

critical

high

medium

medium

critical

critical

high

medium

medium

medium

high

critical

critical

medium

medium

medium

medium

medium

low