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

  - net：ti：icssm-prueth：修复探测中的eth_ports_node泄漏 icssm_prueth_probe（） 内部的 of_property_read_u32（） 失败的错误路径返回而不放置eth_ports_node，该错误路径是在 for_each_child_of_node（） 循环之前获取的。返回前将其丢弃。（CVE-2026-64161）

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

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

  - batman-adv：mcast：修复 RCU 版本orig_node释放后使用 batadv_mcast_purge_orig（） 从 RCU 保护的 hlists 中删除条目，但不会等待 RCU 宽限期后返回。并发 RCU 读取者可能仍可在删除时访问对这些条目的引用。尝试操作 orig->mcast_want_all_ipv6_node 等条目时受 RCU 保护的阅读器随后将访问已释放的内存。
    通过在 call_rcu（） 调用之前将 batadv_mcast_purge_orig（） 移动到 batadv_orig_node_release（） 来修复此问题。这可确保在回收orig_node内存之前，清除时处于活动状态的 RCU 读取器已经耗尽。（CVE-2026-64096）

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

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

  - hwmon：（pmbus/adm1266） 在读取缓冲区中包含 PEC 字节pmbus_block_xfer adm1266_pmbus_block_xfer（） 以 .buf = data->read_buf、.len = ADM1266_PMBUS_BLOCK_MAX + 2 设置读取事务，但 struct adm1266_data 中的read_buf声明为 u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1];对于最大长度块响应（长度字节 = 255 + 最多 1 PEC 字节），i2c 控制器接到指示将 257 字节写入 256 字节缓冲区，将 1 字节放在 read_buf 结尾之外。如果 （crc ！= msgs[1].buf[msgs[1].buf[0] + 1]） 读取超出数组的字节，则相同的响应也会使后续 PEC 进行比较。将 read_buf 声明升级到 ADM1266_PMBUS_BLOCK_MAX + 2，以便缓冲区可以容纳长度字节（最多 255 个负载字节）以及i2c_msg长度已经占用的 PEC 字节。（CVE-2026-64086）

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

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

  - spi：ep93xx：修复 DMA 设置失败后的错误指针取消引用 如果探测期间 DMA 设置失败，驱动程序会回退到 PIO 模式。确保清除设置失败时的 DMA 通道指针，以免在后续探测错误或驱动程序取消绑定时取消引用错误指针。Sashiko 在查看 devres 分配转换修补程序时标记了此问题。（CVE-2026-64169）

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

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

  - net：tls：修复封装的 sk_msg 环的条目计数sg_chain差一问题 当sk_msg scatterlist 环封装 （sg.end < sg.start） 时，tls_push_record（） 使用 sg_chain（） 将环的末尾部分链接到头部。sg 数组中的一个额外条目为此保留： struct sk_msg_sg { [...] /* 额外的两个元素：* 1） 用于在列表变为 * 分区（如结束<开始）时链接前面和部分。crypto API 需要 * 链接;* 2） 在消息之后链接尾随 SG 条目。*/ 结构 scatterlist data[MAX_MSG_FRAGS + 2];当前代码使用 MAX_SKB_FRAGS + 1 作为环大小：
    sg_chain（&msg_pl->sg.data[msg_pl->sg.start]， MAX_SKB_FRAGS - msg_pl->sg.start + 1， msg_pl->sg.data）;这会将链接指针置于 sg_chain（data[start]， （MAX_SKB_FRAGS - msg_start + 1） .. = &data[start] + （MAX_SKB_FRAGS - msg_start + 1） - 1 = data[start + （MAX_SKB_FRAGS - start + 1） - 1] = data[MAX_SKB_FRAGS] 而不是真正的最后一条。这很可能是由于在接近提交 031097d9e079 的补丁着陆时存在提交争用（bpf：sk_msg，psock down 时的 zap 入口队列） 转换为 ARRAY_SIZE 并终止 data[start] / - start（按照 Sabrina 的建议）。（CVE-2026-64047）

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

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

  - USB：serial：keyspan：修复缺少的 indat 传输健全性检查。添加对 usa49wg indat 传输大小缺少的健全性检查，以避免解析过时或未初始化的 slab 数据。（CVE-2026-63900）

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

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

  - memfd：暗示 SEAL_WRITE 时拒绝可写映射 添加 SEAL_EXEC 时，暗示SEAL_WRITE 造成 W^X。但隐含的密封是在检查后设置的，确保 memfd 不能有任何可写入的映射。这意味着人们可以使用SEAL_EXEC应用SEAL_WRITE同时具有可写入的映射。这破坏了 SEAL_WRITE 提供的合约，并可被攻击者用于传递看似写密封但仍可被任意修改的 memfd。通过在完成对 mapping_deny_writable（） 的调用之前添加隐含密封来修复此问题。（CVE-2026-63952）

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

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

  - USB：serial：cypress_m8：修复小端点的内存损坏 确保中断输出端点数据包大小上限至少为 8 字节，以避免在恶意设备报告较小大小时发生用户控制的 slab 损坏或空指针取消引用。（CVE-2026-63956）

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

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

  - ixgbevf：修复 VEPA 多播源修剪中的释放后使用 ixgbevf_clean_rx_irq（） 通过释放 skb 并继续进行下一个描述符，删除源 MAC 匹配 VF 自有地址的帧（VEPA 多播变通方案）：dev_kfree_skb_irq（skb）;继续;skb 指针在 while 循环之外声明，并且在迭代之间持续存在。由于 continue 会跳过循环底部的 skb = NULL 重置，因此下一个迭代会进入 else if （skb） 路径，并在释放的 skb 上调用 ixgbevf_add_rx_frag（），从而取消引用 skb_shinfo（skb）->nr_frags - NAPI softirq 上下文中的释放后使用。同级驱动程序 iavf 已通过在继续之前将指针为空来正确处理此操作。在这里应用相同的模式。
    我没有 ixgbevf 硬件;该缺陷是通过静态分析发现的（scan_drop_continue_loops.py + semgrep drop_continue_in_loop，扫描中得分最高的多工具佐证）。UAF 通过加载可重现确切代码模式（alloc skb、kfree_skb，然后读取 skb_shinfo（skb）->nr_frags）的测试模块，在 KASAN 下得到确认： 缺陷：KASAN：ixgbevf_uaf_test_init+0x100/0x1000 中的释放后使用 任务 insmod/30 在地址 0000000006163ae78 读取的大小为 8 释放的 208 字节区域 [0000000006163adc0， 000000006163ae90） QEMU 模拟 igb （82576） 但不模拟 ixgbe （82599）， 并且 igbvf VF 驱动程序不包含 VEPA 源修剪路径，因此无法使用仿真硬件进行完整的端到端再现。（CVE-2026-64113）

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

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

  - net：devmem：拒绝具有非页面对齐大小或 SG 长度的 dma-buf bind net_devmem_bind_dmabuf（） 会信任 dmabuf->size 和 sg_dma_len（） 为PAGE_SIZE倍数，而不检查： - tx_vec 的大小为 dmabuf->size/PAGE_SIZE，而 net_devmem_get_niov_at（） 仅在编制索引前virt_addr < dmabuf->size 边界检查 tx_vec[virt_addr / PAGE_SIZE]。由于大小 = N*PAGE_SIZE + r （1 <= r < PAGE_SIZE），则 iov_base = N*PAGE_SIZE 的 sendmsg（） 通过边界检查，并读取 tx_vec[N] -- 过去一次。- owner->area.num_niovs = len / PAGE_SIZE 而 gen_pool_add_owner（） 覆盖整个字节 len，因此非页多个非最终 sg 会从 RX 和 TX 上每个后续 sg 的 gen_pool 区域取消num_niovs同步。dma-buf 不需要页面对齐大小，因此 bind 路径必须强制执行其自己的索引假设。使用 -EINVAL 拒绝两者。
    大小检查仅针对 TX（仅 tx_vec大小与 dmabuf->size 相差）;SG 长度检查涵盖两个方向。（CVE-2026-64124）

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

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

  - mm/memory：修复取消映射 device-private/exclusive 页面时的虚假警告 仅匿名作品集支持设备私有和独占条目。使用 folio_test_anon（） 在 __migrate_device_pages（） 和 make_device_exclusive（） 中对此条件进行测试。但是，取消映射路径使用 vma_is_anonymous（） 测试此假设。这是错误的，因为虽然匿名 VMA 只能包含 folio_test_anon（） 为真的作品集，但相反的关系不成立。folio_test_anon（） 为真的对开本并不意味着 vma_is_anonymous（） 为 true。例如，如果作品集是私有文件备份映射的一部分，则可发生此类情况。在这种情况下，由于映射是文件备份，vma_is_anonymous（） 为 false，但 folio_test_anon（） 可能是 true，从而允许设备将作品集迁移到设备私有内存。这可在进程拆卸期间导致以下虚假警告： [ 772.737706] ------------[ cut here]------------ [ 772.739201] WARNING： mm/memory.c：1754 at unmap_page_range.cold+0x26/0x18a， CPU#17： hmm-tests/2041 [ 772.742050] 模块链接： test_hmm nvidia_uvm（O） nvidia（O） [ 772.743959] CPU： 17 UID： 0 PID： 2041 Comm： hmm-tests Tainted： G W O 7.0.0+ #387 PREEMPT（full） [ 772.747104] Tainted： [W]=WARN， [O]=OOT_MODULE [ 772.748509] 硬件名称： QEMU Standard PC （Q35 + ICH9， 2009）， BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 772.752117] RIP：
    0010：unmap_page_range.cold+0x26/0x18a [ 772.753780] 代码： 7e fe ff ff 48 89 4c 24 78 4c 89 44 24 38 e8 f2 ff b1 00 48 8b 4c 24 78 4c 8b 44 24 38 48 8b 44 24 18 48 83 78 48 00 74 04 90 <0f> 0b 90 48 89 ca b8 ff ff 37 00 48 c1 ea 03 48 c1 e0 2a 80 3c 02 [ 772.759602] RSP： 0018：ffff888112607550 EFLAGS： 00010286 [772.761310] RAX： ffff88811bbf4dc0 RBX： dffffc0000000000 RCX： ffffea03e9bfffd8 [ 772.763583] RDX：
    1ffff1102377e9c1 RSI：0000000000000008 RDI：ffff88811bbf4e08 [ 772.765914] RBP：0000000000000006 R08：
    ffff8881059f7448 R09： ffffed10224c0e68 [ 772.768184] R10： ffff888112607347 R11： 0000000000000001 R12：
    0000000000000001 [ 772.770461] R13： ffffea03e9bfffc0 R14： ffff888112607908 R15： ffffea03e9bfffc0 [772.772782] FS： 00007f327caa2780（0000） GS：ffff888427b7d000（0000） knlGS：0000000000000000 [ 772.775328] CS：
    0010 DS：0000 ES：0000 CR0： 0000000080050033 [ 772.777187] CR2： 00007f327ca89000 CR3： 00000001994d5000 CR4： 000000000000006f0 [ 772.779135] 调用跟踪： [ 772.779792] [ <TASK>772.780317] ？ dmirror_interval_invalidate+0x1a3/0x290 [test_hmm] [ 772.781873] ？ vm_normal_page_pud+0x2b0/0x2b0 [772.782992] ？ __rwlock_init+0x150/0x150 [ 772.784006] ？ lock_release+0x216/0x2b0 [ 772.785008] ？
    __mmu_notifier_invalidate_range_start+0x505/0x6e0 [ 772.786522] ？ lock_release+0x216/0x2b0 [ 772.787498] ？ unmap_single_vma+0xb6/0x210 [ 772.788573] unmap_vmas+0x27d/0x520 [ 772.789506] ？ unmap_single_vma+0x210/0x210 [ 772.790607] ？ mas_update_gap.part.0+0x620/0x620 [ 772.791834] unmap_region+0x19e/0x350 [ 772.792769] ？ remove_vma+0x130/0x130 [ 772.793684] ？ mas_alloc_nodes+0x1f2/0x300 [ 772.794730] vms_complete_munmap_vmas+0x8c1/0xe20 [ 772.795926] ？ unmap_region+0x350/0x350 [ 772.796917] do_vmi_align_munmap+0x36a/0x4e0 [ 772.798018] ?lock_release+0x216/0x2b0 [ 772.799024] ？ vma_shrink+0x620/0x620 [ 772.799983] do_vmi_munmap+0x150/0x2c0 [772.800939] __vm_munmap+0x161/0x2c0 [ 772.801872] ？ expand_downwards+0xd60/0xd60 [ 772.802948] ？ clockevents_program_event+0x1ef/0x540 [ 772.804217] ？ lock_release+0x216/0x2b0 [ 772.805158]
    __x64_sys_munmap+0x59/0x80 [ 772.805776] do_syscall_64+0xfc/0x670 [ 772.806336] ？ irqentry_exit+0xda/0x580 [ 772.806976] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 772.807772] RIP： 0033：0x7f327cbb2717 [772.808323] 代码： 73 01 c3 48 8b 0d f9 76 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ---truncated--- （CVE-2026-64131）

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

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

  - drm/msm：修复 iommu_map_sgtable（） 返回值检查并避免 WARN 提交 iommu：返回来自 iommu_map_sg[_atomic]（） 更改的 iommu_map_sgtable（） 的完整错误代码，以便在错误情况下返回ssize_t值和负值，而非size_t和零。将返回值存储在适当的类型中，如果出错，返回该值而不是 WARNing。Patchwork： https://patchwork.freedesktop.org/patch/719685/(CVE-2026-64153）

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

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

  - ethtool：cmis：需要确切的 CDB 回复长度 恶意 SFP 模块的响应时间可能比 cmis_cdb_process_reply（） 预期的rpl_len长，从而导致越界写入。恶意 HW 有点理论问题，但某些模块可能只是有缺陷和/或读取可能偶尔会损坏，因此让我们保护内核。
    现有检查可防止简短回复。我们也需要保护免受长期攻击。所有传递非零rpl_exp_len的调用方都会将回复负载转换为固定布局结构，并以固定偏移读取字段，无需版本协商或短回复处理：- cmis_cdb_validate_password（） - cmis_cdb_module_features_get（） - cmis_fw_update_fw_mng_features_get（） 因此，我们假设此处不必妥善处理比预期长的响应。添加一条警告消息以使调试更容易，以防我的理解错误...... 请注意，page_data->length（kmalloc 的参数）来自最后一个参数到 ethtool_cmis_page_init（），后者是rpl_exp_len。注意 2 AI 也喜欢指出 args->req.payload 本身（堆栈上固定大小为 120 B 的缓冲区）中的溢出，但调用者应该读取标准定义的结构，因此防止对超过最大数据的请求似乎是防御性编程。（CVE-2026-63996）

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

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

  - ethtool：coalesce：在 NET_DIM_PARAMS_NUM_PROFILES ethnl_update_profile（） 处的端点配置文件更新遍历使用索引“i”的ETHTOOL_A_PROFILE_IRQ_MODERATION嵌套列表，写入 new_profile[i++]而不限制边界 i。目标在NET_DIM_PARAMS_NUM_PROFILES条目 （5） 处为 kmemdup（），但 Netlink 嵌套计数完全由用户控制。Netlink 策略不支持限制嵌套条目数（或多属性条目数）。（CVE-2026-63987）

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

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

  - iommu：处理启用了 iommu_debug 时的取消映射错误 Sashiko 注意到一个潜在缺陷，即映射错误流调用 iommu_unmap（），调用 iommu_debug_unmap_begin（）/iommu_debug_unmap_end（），但是由于这是错误路径，映射流从未实际建立原始iommu_debug_map（），因此它将发生故障。将取消映射错误处理提升到 iommu_map_nosync（） 中并对其重新排序，以便 trace_map（）/iommu_debug_map（） 记录部分映射，然后立即取消映射。这可避免创建不平衡的跟踪，并提供更健全的跟踪，而不是与任何映射都不匹配的取消映射。
    (CVE-2026-64152)

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

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

  - net：mana：在拆卸路径中添加空防护以防止附加失败时的错误 当队列分配中途失败时，错误清理将释放 apc->tx_qp 和 apc->rxqs 并产生 NULL 权限。多个拆卸路径，例如 mana_remove（）、mana_change_mtu（） 恢复和 mana_alloc_queues（） 中的内部错误处理，）之后可调用取消引用这些指针的函数，而不需要 NULL 检查： - mana_chn_setxdp（） 取消引用 apc->rxqs[0]，从而造成空指针取消引用错误（CR2：00000000000000000000 at mana_chn_setxdp+0x26）。- mana_destroy_vport（） 在不进行 NULL 检查的情况下迭代 apc->rxqs。- mana_fence_rqs（） 在不进行 NULL 检查的情况下迭代 apc->rxqs。- mana_dealloc_queues（） 在不进行 NULL 检查的情况下迭代 apc->tx_qp。
    为 mana_fence_rqs（）、mana_destroy_vport（） 中和 mana_chn_setxdp（） 调用之前的 apc->rxqs 添加空保护。为 mana_dealloc_queues（） 中的 apc->tx_qp 添加空防护，以在从未分配 TX 队列或尚未释放 TX 队列时跳过 TX 队列耗尽。（CVE-2026-63973）

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

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

  - 低于 1.3.9c 和 1.3.10rc3 的 ProFTPD 在 mod_sftp 模块的 SCP 大小记录解析器中包含有符号的整数溢出漏洞，允许经认证的低权限攻击者通过发送构建的文件大小值 UINT64_MAX 绕过 ASLR，从而导致负的off_t值。攻击者可利用后续转换为 uint32_t，造成大约 4 GB 的请求读取长度，并强制服务器读取超过 SSH 通道数据结尾，并将过度读取的进程内存写入已上传的文件中。在测试的配置中，泄露的数据包含的 libc、libcrypto 和 PIE 指针足以派生其随机基址，从而绕过 ASLR，并能够在同一进程中可靠利用内存损坏漏洞。（CVE-2026-63091）

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

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

  - netfs：修复 DIO 和单一读取子请求的取消 当准备新的读取子请求失败时，如果已将子请求添加到 stream->subrequests 列表，则不能像收集器可能看到的那样简单地放置和放弃它。此外，如果它还没有排队，则它有两个未完成的引用，都需要放置它们。DIO 读取和单读调度都无法解决此问题;此外，两者在处理缓冲读取工作方式的顺序上也有所不同。通过以下步骤修复准备失败的 DIO 读取和单读取子请求的取消：（1） 在准备子req 之前，协调所有三个读取（缓冲的、dio的、单一的）以将子req 排队。（2） 使所有三个人都调用 netfs_queue_read（） 进行排队。（3） 独立于排队设置 NETFS_RREQ_ALL_QUEUED，因为此时我们不知道子 req 的长度。（4）在所有情况下，在子req上设置错误和NETFS_SREQ_FAILED标记，然后调用netfs_read_subreq_terminated（）进行处理。这会将责任转嫁给处理它的收集者。（CVE-2026-64069）

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

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

  - vfio/pci：在导出 DMABUF 之前检查 BAR 资源。DMABUF 会导出对 BAR 资源的访问权限，尽管在启动时请求这些资源，但我们仍需要确保在导出之前确实保留了这些资源。
    否则，可以通过导出访问未预留的资源。为 DMABUF-creation 路径添加检查。（CVE-2026-64042）

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

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

  - nfc：llcp：修复 nfc_llcp_recv_cc（） 中的释放后使用争用 NFC LLCP 连接状态机中存在一个争用条件，其中连接接受数据包 （CC） 可与套接字释放同时处理。这可导致套接字对象释放后使用。当 nfc_llcp_recv_cc（） 将套接字从connecting_sockets列表移动到套接字列表时，它不会保留套接字锁定。
    如果 llcp_sock_release（） 并发执行，可能已经取消套接字链接并丢弃其引用，导致 nfc_llcp_recv_cc（） 将释放的套接字链接到实时列表中。通过在 nfc_llcp_recv_cc（） 中的状态转换和列表移动期间按住 lock_sock（），修复此问题。取得锁定之后，检查套接字是否仍受哈希处理，以确保其尚未被释放路径取消链接及标记为要销毁。这会使锁定模式与 recv_hdlc（） 和 recv_disc（） 保持一致。（CVE-2026-64010）

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

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

  - uio：uio_pci_generic_sva：修复 devm_kzalloc（） 内存的双重释放 uio_pci_sva在 probe（） 中使用 devm_kzalloc（） 分配结构uio_pci_sva_dev，但随后在 probe（） 错误路径（标签 out_free）上和在 remove（） 中再次调用 kfree（udev）。由于 devm_kzalloc（） 分配由 devres 管理，并且会在分离设备时自动释放（包括 probe（） 失败之后和驱动程序取消绑定期间），因此显式 kfree（） 可导致双重释放。如果 probe（） 在 devm_kzalloc（） 后发生失败，错误路径将释放 udev，而当核心展开部分绑定的设备时，devres cleanup 将再次释放它。在正常删除驱动程序时，remove（） 会释放 udev，且当设备分离时，devres 将再次释放它。这个问题是由我开发的静态分析工具发现的，并通过人工审查确认。通过删除手动 kfree（） 调用并删除现在未使用的标签进行修复。（CVE-2026-63907）

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

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

  - net：tls：防止明文中的链后链 SG Sashiko 指出，如果 end = 0 （start ！= 0），当前代码将立即在环绕链接之后创建指向内容类型的链： 这将创建一条链，其中封装链接直接指向另一个链节。scatterlist API sg_next迭代器不会以递归方式解析连续的链链接。这意味着这是对加密货币的非法输入。如果 end = 0，则不需要封装链接。end 是最后一个使用的条目之后的条目，因此 end = 0 表示封装后没有任何推送内容：end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap] 在此情况下跳过封装。如果 end = 0，则 TLS 1.3 可使用封装槽进行链接。这避免了链后链的情况。
    在标记 END 和链接内容类型之前移动封装链，这对我来说感觉更合乎逻辑的顺序，但从功能的角度来看应该无关紧要。（CVE-2026-64046）

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

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

  - 输入：atmel_mxt_ts - 修复mxt_prepare_cfg_mem中的边界检查 配置文件提供的对象大小大于驱动程序的已知mxt_obj_size（对象）时，驱动程序打算丢弃额外的字节。循环使用 for （i = 0; i < size; i++） 进行迭代。在循环中，跳过处理额外字节的条件是：if （i > mxt_obj_size（object）） continue;由于 i 是从 0 开始的索引，因此对象的有效索引为 0 到 mxt_obj_size（对象） - 1。当 i == mxt_obj_size（object） 时，条件的计算结果为 false，代码会处理字节，而不是丢弃它。这会导致代码计算 byte_offset = reg + i - cfg->start_ofs 并将字节写入其中，从而恰好覆盖相邻实例或对象的一个字节。通过使用 >= 更新边界检查以正确地跳过额外字节。（CVE-2026-63908）

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

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

  - sysfs：更新失败时不删除现有目录 为指定群组调用 sysfs_update_group（） 而 create_files（） 失败（例如 -ENOMEM）时，internal_create_group（） 会在群组目录上调用 kernfs_remove（kn）。在更新路径中，kn 通过 kernfs_find_and_get（） 获取，它指向在此调用之前已存在的目录。将其删除会以静默的方式破坏并非调用程序创建的 sysfs 组。仅自行创建目录时才删除该目录。更新失败时，目录将保持由 create_files（） 内的 remove_files（） 留空，但可以通过重试来重新填充。
    (CVE-2026-64185)

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

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

  - net/handshake：耗尽 net 命名空间退出中的待定请求 handshake_net_exit（） 中 list_splice_init（） 的参数颠倒。该调用会将本地空请求列表移动到 hn->hn_requests 上，使本地列表留空，因此后续的漏循环会运行零迭代。销毁网络命名空间时，尚未接受的待定握手请求不会拆散;每个选项都在套接字文件和handshake_req分配中保留一个引用。按记录的顺序传递源和目标（list_splice_init（list， head） 将列表移动到 head），以便将待定列表传输到本地暂存列表并通过 handshake_complete（） 耗尽。修复 splice 方向会暴露列表损坏争用。在 splice 之后，每个 req->hr_list 仍有非空链接指针，用于串接堆栈本地擦除列表，而不是hn_requests。并行 handshake_req_cancel（） -- 例如，来自未采用 netns 引用的内核套接字上的 sunrpc 的 TLS 超时 -- 通过 rhashtable 查找请求，调用 remove_pending（），并看到 ！list_empty（&req->hr_list）。然后，__remove_pending_locked（） 在漏迭代时从暂存列表中list_del_init（） 一个条目，从而使其损坏。漏循环在条目上运行 list_del（） 之后到达的相同调用会改为命中LIST_POISON。让 remove_pending（） 检查 hn_lock 下的HANDSHAKE_F_NET_DRAINING，并在耗尽正在进行时报告“找不到”。排水管已经拥有所有权;handshake_complete（） 在 HANDSHAKE_F_REQ_COMPLETED 上的现有test_and_set仍然会针对调用使用者hp_done的用户在 drain 和 cancel 之间进行仲裁。在漏中使用 list_del_init（） 而不是 list_del（），这样在漏释放条目之后 req->hr_list 就不会携带LIST_POISON。remove_pending（） 中的 DRAINING 防护使 cancel 返回 false，但 cancel 仍会失败至 HANDSHAKE_F_REQ_COMPLETED 上的 test_and_set_bit 并丢失请求的 hr_file 引用。如果这是最后一个引用，则在没有其他引脚的情况下，sk_destruct释放请求，前提是该请求仍链接在漏循环的本地列表中。在释放列表之前，将每个请求的hr_file固定在hn_lock下，并在循环完成请求后删除该漏引脚。
    (CVE-2026-63978)

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

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

  - ksmbd：smb_check_perm_dacl（） ACE-walk 循环中的 OOB 读取回归 Commit d07b26f39246（ksmbd：要求 smb_check_perm_dacl（） 中的 ACE 大小下限）引入了转置的边界检查：if （offsetof（struct smb_ace， sid） + aces_size < CIFS_SID_BASE_SIZE） Since offsetof（..sid） 为 8，CIFS_SID_BASE_SIZE 为 8，计算结果为“aces_size < 0”。由于“aces_size”始终为非负值，因此此检查会成为死代码并且永远不会中断循环。更糟糕的是，该提交删除了旧的 4 字节保护，这意味着即使“aces_size”为 0-3 字节，循环现在也会读取“ace->size”（偏移 2）。这会在后续SMB2_CREATE操作期间重新打开经过 pntsd 分配的 2 字节堆越界 （OOB） 读取。通过正确转置比较要求至少 16 字节（8 字节偏移 + 8 字节 SID 基本）来修复此问题，并匹配 smb_inherit_dacl（） 中使用的正确形式。（CVE-2026-63909）

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

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

  - zram：修复 zram_writeback_endio 中的释放后使用 在 zram_writeback_endio 中发现一个崩溃问题，这是因为 wake_up 中的空指针取消引用所导致。根本原因是 bio 完成处理程序 （zram_writeback_endio） 和回写任务之间存在争用条件。在 zram_writeback_endio 中，wake_up（） 在释放 wb_ctl->done_lock 之后在 &wb_ctl->done_wait 上调用。这将创建一个争用窗口，在zram_writeback_endio调用 wake_up（） 之前，回写任务可以看到num_inflight变为 0、返回和释放wb_ctl。CPU 0 （zram_writeback_endio） CPU 1 （writeback_store） ============================ ============================ zram_writeback_slots zram_submit_wb_request zram_submit_wb_request wait_event（wb_ctl->done_wait） spin_lock（&wb_ctl->done_lock）;list_add（&req->entry， &wb_ctl->done_reqs）;spin_unlock（&wb_ctl->done_lock）;
    wake_up（&wb_ctl->done_wait）;zram_complete_done_reqs spin_lock（&wb_ctl->done_lock）;list_add（&req->entry， &wb_ctl->done_reqs）;spin_unlock（&wb_ctl->done_lock）;while （num_inflight） > 0） spin_lock（&wb_ctl->done_lock）;list_del（&req->entry）;spin_unlock（&wb_ctl->done_lock）;num_inflight变为 0 atomic_dec（num_inflight）;离开 zram_writeback_slots // 释放 wb_ctl release_wb_ctl（wb_ctl）;
    UAF 坠毁！wake_up（&wb_ctl->done_wait）;此修补程序通过使用 RCU 修复此争用。我们通过在 zram_writeback_endio 中使用 rcu_read_lock（） 保护wb_ctl并使用 kfree_rcu（） 将其释放，确保wb_ctl在执行zram_writeback_endio期间保持有效。(CVE-2026-63951)

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

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

  - drm/amdgpu/vcn：为 VCN v5.0.0 enc 环设置no_user_fence VCN 编码器和解码器环不支持 64 位用户隔离写入，拒绝有用户隔离的 CS 提交。（从提交 49b1fbbb5a071197ee71e2d70959b1cb29bdc317 中精选出的内容）（CVE-2026-63850）

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

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

  - btrfs：tracepoints：修复在 btrfs_sync_file（） 中处于原子上下文中的休眠 在原子上下文（所有跟踪事件都是）中调用跟踪事件 btrfs_sync_file（），由于调用 dget_parent（） 而需要对 dput（） 的调用）可休眠，从而触发内核 splat。例如，启用跟踪事件并从 fstests 运行 btrfs/056 可对此重现此情况。dmesg 中显示的崩溃如下：[53.919] BUG：sleeping 函数从 fs/dcache.c：970 的无效上下文中调用 [53.947] in_atomic（）：1， irqs_disabled（）： 0， non_block： 0， PID： 32773，名称：xfs_io [53.988] preempt_count：2，预期：0 [53.967] RCU 嵌套深度：0，预期：0 [53.943] 在以下位置禁用抢占：[53.944] [<0000000000000000>] 0x0 [54.078] CPU：0 UID：0 PID：32773 通信：xfs_io 受感染： G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT（full） [54.070] Tainted： [W]=WARN [54.071] 硬件名称： QEMU Standard PC （i440FX + PIIX， 1996）， BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] 调用跟踪： [54.074] [54.076] <TASK> dump_stack_lvl+0x56/0x80 [54.079] __might_resched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] trace_event_raw_event_btrfs_sync_file+0x75/0x140 [btrfs] [54.089] btrfs_sync_file+0x1ed/0x530 [btrfs] [54.087] ？ __handle_mm_fault+0x8ae/0xed0 [54.089] btrfs_do_write_iter+0x172/0x210 [btrfs] [54.091] vfs_write+0x21f/0x450 [54.094]
    __x64_sys_pwrite64+0x8d/0xc0 [54.096] ？ do_user_addr_fault+0x20c/0x670 [54.099] do_syscall_64+0x60/0xf20 [54.092] ？ clear_bhb_loop+0x60/0xb0 [54.094] entry_SYSCALL_64_after_hwframe+0x76/0x7e 因此请停止使用 dget_parent（） 和 dput（），并以 dentry->d_parent 的形式直接访问父 dentry。这也是 ext4 在其等效跟踪事件 ext4_sync_file_enter（） 中执行的操作。（CVE-2026-64164）

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

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

  - ethtool：cmis：验证模块的start_cmd_payload_size CMIS 固件更新代码从模块的固件管理功能 CDB 回复中读取start_cmd_payload_size，并将其直接用作 memcpy 的字节计数。目标缓冲区为 112 字节 （ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8）。因此，恶意模块（或损坏的响应）稍后可在 cmis_fw_update_start_download（） 中造成 OOB 写入。让我们出错吧。如果确实存在需要更长 LPL 写入的模块，我们应该重新访问。struct cmis_cdb_start_fw_download_pl 的定义必须移动，不能更改。
    (CVE-2026-63995)

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

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

  - net/handshake：将 spin_lock_bh 用于 hn_lock nvmet_tcp_state_change（），这是一种在 BH 上下文中运行的套接字回调，可通过 nvmet_tcp_schedule_release_queue（） 和 tls_handshake_cancel（） 到达 handshake_req_cancel（）。handshake_req_cancel（） 通过普通 spin_lock（） 获取 hn->hn_lock。如果当 softirq 调用取消路径时，同一 CPU 上的进程上下文线程持有 hn->hn_lock，则锁定尝试会死锁。这是唯一从 BH 上下文中调用 tls_handshake_cancel（） 的调用程序;所有其他使用者都从进程上下文中调用它。延迟取消以处理 NVMe 目标中的上下文并不简单：nvmet_tcp_schedule_release_queue（） 必须以原子方式调用 tls_handshake_cancel（），并将其状态转换为 DISCONNECTING。如果取消被延迟，握手完成回调可在取消运行之前在窗口中触发，观察意外状态并返回而不将其 kref 放在队列中。重做该联锁比强化握手锁更具侵入性。将所有 hn->hn_lock 采集从 spin_lock/spin_unlock 转换为 spin_lock_bh/spin_unlock_bh这样就永远不会在启用 softirqs 的情况下进行锁定。（CVE-2026-63980）

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

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

  - bpf：sockmap：修复 bpf_msg_push_data 中的末尾碎片偏移 当 bpf_msg_push_data（） 在 scatterlist 条目中间插入数据时，会将原始条目拆分为左碎片和右碎片。正确的片段偏移量是页面偏移量，但代码通过“start”推进它，此是消息全局插入点。对于插入到非第一个 SG 条目中，这会过度推进偏移量并使拆分布局不一致。将右侧片段偏移前推进片段本地增量“start - offset”，与从原始条目前面删除的长度匹配。（CVE-2026-63926）

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

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

  - wifi：ath11k：修复某些 WMI WOW 调用中的错误路径泄漏 修复过去直接返回 ath11k_wmi_cmd_send（...） 结果的两个实例。由于未检查返回值，因此也未释放错误路径中的 skb。（CVE-2026-64155）

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

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

  - drm/gpusvm：修复 drm_gpusvm_scan_mm（） 中不平衡的解锁 gpusvm 通知程序锁定存在不平衡的锁定/解锁： [ 931.045868] ===================================== [ 931.046509] 警告：检测到错误的解锁平衡！[ 931.047149] 6.19.0-rc6+xe-**************** #9 污染：G U [ 931.048150]
    ------------------------------------- [ 931.048790] kworker/u5：0/51 正尝试释放锁定 （&gpusvm->notifier_lock）：[ 931.049801]<ffffffffa090c0d8> [] drm_gpusvm_scan_mm+0x188/0x460 [drm_gpusvm_helper] [ 931.050802] 但没有更多锁定可释放！[ 931.051463] drm_gpusvm_notifier_unlock（） 位于err_free标签下，而第一次跳转到 err_free 就在调用 drm_gpusvm_notifier_lock（） 之前，可能会造成不平衡的解锁。（CVE-2026-63863）

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

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

  - drm/i915：修复 TTM 对象清除中潜在的 UAF TLDR：bo->ttm 对象可通过调用 ttm_bo_validate（） 进行更改，稍后将其转换到i915_tt对象以实际获得正确的指针。一位用户报告在大量使用 DG2 时遇到以下缺陷：[26620.095550] 哎呀：一般保护错误，可能针对非规范地址 0xa56b6b6b6b6b6b8b：0000 1 SMP NOPTI [26620.095556] CPU：2 UID：0 PID：
    631 通信：Xorg 未受 6.18.8 #1 污染 PREEMPT（lazy） [26620.095558] 硬件名称：华擎 B850M Steel Legend WiFi/B850M Steel Legend WiFi，BIOS 3.50 09/18/2025 [26620.095559] RIP：0010：i915_ttm_purge+0x84/0x100 [i915] [26620.095604] 代码：00 00 00 48 8d 54 24 10 48 89 e6 48 89 FB E8 83 AA AE FF 85 C0 75 6F 48 83 BB A8 01 00 00 00 74 2C 48 8B 45 78 48 85 C0 74 23 <48> 8B 78 20 48c7 c2 ff ff ff ff 31 f6 e8 7a 73 e3 e0 48 8b 7d 78 [26620.095605] RSP：0018：ffffc90005fd7430 EFLAGS： 00010282 [26620.095607] RAX： a56b6b6b6b6b6b6b6b RBX： ffff8881f46c3dc0 RCX： 0000000000000000 [26620.095608] RDX： 00000000000000000 RSI： 0000000000000246 RDI： 000000000ffffffff [26620.095609] RBP： ffff888289610f00 R08： 0000000000000001 R09： ffff88823b022000 [26620.095609] R10： ffff888103029b28 R11： ffff8881fc7f3800 R12： ffff88810b6150d0 [26620.095609] R13：
    ffff888289610f00 R14：000000000000000 R15：ffff8881f46c3dc0 [26620.095610] FS：00007f1004d86900（0000） GS：ffff88901c858000（0000） knlGS：0000000000000000 [26620.095611] CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 [26620.095611] CR2： 00007f0fdf489000 CR3： 000000035b0c1000 CR4： 0000000000750ef0 [26620.095612] PKRU： 55555554 [26620.095612] 调用跟踪： [26620.095615] []26620.095615<TASK> i915_ttm_move+0x2b9/0x420 [i915] [26620.095642] ？ ttm_tt_init+0x65/0x80 [ttm] [26620.095644] ？ i915_ttm_tt_create+0xc6/0x150 [i915] [26620.095667] ttm_bo_handle_move_mem+0xb6/0x160 [ttm] [26620.095669] ttm_bo_evict+0x100/0x150 [ttm] [26620.095671] ？ preempt_count_add+0x64/0xa0 [26620.095673] ？
    _raw_spin_lock+0xe/0x30 [26620.095675] ？ _raw_spin_unlock+0xd/0x30 [26620.095675] ？ i915_gem_object_evictable+0xb7/0xd0 [i915] [26620.095704] ttm_bo_evict_cb+0x6e/0xd0 [ttm] [26620.095705] ttm_lru_walk_for_evict+0xa6/0x200 [ttm] [26620.095708] ttm_bo_alloc_resource+0x185/0x4f0 [ttm] [26620.095709] ？ init_object+0x62/0xd0 [26620.095712] ttm_bo_validate+0x7a/0x180 [ttm] [26620.095713] ？
    _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095714] __i915_ttm_get_pages+0xb0/0x170 [i915] [26620.095737] i915_ttm_get_pages+0x9f/0x150 [i915] [26620.095759] ？ i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095786] ？ alloc_debug_processing+0xd0/0x100 [26620.095787] ？ _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095788] ？ i915_vma_instance+0xa0/0x4e0 [i915] [26620.095822] __i915_gem_object_get_pages+0x2f/0x40 [i915] [26620.095848] i915_vma_pin_ww+0x706/0x980 [i915] [26620.095875] ？ i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095904] eb_validate_vmas+0x170/0xa00 [i915] [26620.095930] i915_gem_do_execbuffer+0x1201/0x2b40 [i915] [26620.095953] ？ alloc_debug_processing+0xd0/0x100 [26620.095954] ？ _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095955] ？ i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.095977] ？ __wake_up_sync_key+0x32/0x50 [26620.095979] ？ i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.096001] ？ __slab_alloc.isra.0+0x67/0xc0 [26620.096003] i915_gem_execbuffer2_ioctl+0x11a/0x240 [i915] decode_stacktrace.sh指向取消引用 i915 TTM 页面向量容器的文件指针字段的结果，该容器与逐出时要清除的对象相关联。当对象标记为不再需要时，便会采用该路径。代码分析显示，i915 TTM 页面矢量容器可能会在函数仍然忙碌时，换成可清除对象内容的函数内的新实例。该函数通过更改对象放置和缓存策略的更通用的函数间接调用 ---truncated--- （CVE-2026-63884）

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

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

  - wifi：iwlwifi：mld：修复禁用 AMSDU 时的 TSO 分段爆炸 当 TLC 通知为 TID 禁用 AMSDU 时，MLD 驱动程序会将 max_tid_amsdu_len 设置为 sentinel 值 1。iwl_mld_tx_tso_segment（） 中的 TSO 分段路径检查零，但不检查此哨兵，从而使其能够达到num_subframes计算：num_subframes = （max_tid_amsdu_len + pad） / （subf_len + pad） = （1 + 2） / （1534 + 2） = 0 此 0 传播到 iwl_tx_tso_segment（），后者设置：gso_size = num_subframes * mss = 0 调用 gso_size=0 的 skb_gso_segment（） 会从单个 GSO skb 创建超过 32000 个微小的段。
    这会用 ~1024 微帧淹没 TX 环（其余的将被清除），从而产生大量 TX 完成事件，可导致内存损坏以及随后在 TCP 的重传队列中出现释放后使用（tcp_shifted_skb中存在 refcount 下溢，tcp_rack_detect_loss中存在空取消引用）。MVM 驱动程序不受影响，因为它会在进行num_subframes计算之前检查 mvmsta->amsdu_enabled。MLD 驱动程序没有等效的位图检查，仅依赖无法捕获 sentinel 值的 max_tid_amsdu_len。通过在现有检查中检测 sentinel 值 （max_tid_amsdu_len == 1） 并回退到非 AMSDU TSO 分段来修复此问题。此外，还在num_subframes除法后添加一个WARN_ON_ONCE防护作为纵深防御，以便捕获未来通过其他机制产生零的任何代码路径。（CVE-2026-64037）

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

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

  - KVM：SEV：计算 GHCB 内擦除区域的正确最大长度 设置 GHCB 擦除区域的长度并且该区域位于 GHCB 共享缓冲区中时，请将擦除区域的有效长度设置为给定客户机提供的指针的起始位置和共享缓冲区结束位置的最大可能大小。最初引入时代码还不错，因为 KVM 在仿真 MMIO 时不会咨询缓冲区的长度，因为传入的@len始终指定所需的 *max* 大小。但对于 PSC 请求，传入的@len只是最小长度（用于处理标头），并且 KVM 需要知道暂存区域的完整大小以避免缓冲区溢出（剧透警告）。适时重命名 @len => @min_len 以更好地反映其角色。（CVE-2026-63939）

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

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

  - ipv6：修复 rt6_fill_node（） 中可能的无限循环 Sashiko 报告了此问题 [1]。应用与提交 f8d8ce1b515a 相同的补丁（ipv6：修复 fib6_info_uses_dev（）） 中可能的无限循环）。持有 tb6_lock 的写入器可以在不等待 RCU 读取器的情况下list_del_rcu（&rt->fib6_siblings）;rt->fib6_siblings.next 随后仍指向旧环，而此 softirq-side 遍历器永远不会到达 &rt->fib6_siblings，进而造成 CPU 停止。fib6_del_route（） 始终在 list_del_rcu（） 之前WRITE_ONCE（）的 rt->fib6_nsiblings 到 0，因此内部循环检查是可靠的分离信号。[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev （CVE-2026-63969）

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

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

  - Bluetooth：ISO：序列化带有套接字锁定的 iso_sock_clear_timer iso_sock_close（） 在获取 lock_sock（sk） 之前会调用 iso_sock_clear_timer（）。iso_sock_clear_timer（） 在未保留套接字锁定的情况下读取 iso_pi（sk）->conn 两次：if （！iso_pi（sk）->conn） return;
    cancel_delayed_work（&iso_pi（sk）->conn->timeout_work）;同时，iso_conn_del（） 在 lock_sock（sk） 下执行并调用 iso_chan_del（），这会将 iso_pi（sk）->conn 设置为 NULL，并可能导致对连接的最终引用被丢弃：CPU0 CPU1 ---- ---- iso_sock_clear_timer（） if （conn ！= NULL） ...lock_sock（sk） iso_chan_del（） iso_pi（sk）->conn = NULL cancel_delayed_work（conn） /* NULL 取消引用或 UAF */ iso_pi（sk）->conn 在解锁窗口中不稳定，从而导致空指针取消引用或释放后使用。通过将套接字锁定的 iso_sock_clear_timer（） 移动到 lock_sock（）/release_sock（） 内部对其进行序列化，从而匹配 iso_conn_del（） 和所有其他调用站点中使用的模式。
    (CVE-2026-63945)

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

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

  - net/tcp-ao：修复 del_async 路径中密钥的释放后使用 在 tcp_ao_delete_key（） 中del_async，假设同步路径中存在的current_key和rnext_key有效性检查，假设这些指针在监听套接字上始终为空。但是，如果在套接字处于 CLOSE 状态时添加了 set_current=1/set_rnext=1 的密钥，则在 listen（） 将套接字转换为 LISTEN 之后，current_key 和 rnext_key 将不是 NULL。在 del_async=1 的情况下删除此类密钥时，hlist_del_rcu（） 和 call_rcu（） 会释放密钥，而不清除悬摆指针。在 RCU 宽限期过后，getsockopt（TCP_AO_INFO） 会从已释放的 slab 内存中取消引用 current_key->sndid 和 rnext_key->rcvid。当del_async路径引用正在删除的密钥时清除current_key和rnext_key。（CVE-2026-53389）

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

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

  - 9p：避免将 oldfid 放入 p9_client_walk（） 错误路径 通过将 clone 设置为 false 调用 p9_client_walk（） 时，fid 将别名 oldfid。如果在发送请求后遍历失败，则错误路径会跳至当前无条件调用 p9_fid_put（fid） 的 clunk_fid。这会终止对 oldfid 的引用，即使 oldfid 的所有权仍属于调用者。如果这是最后一个引用，则 oldfid 可能会在调用方仍预期其有效时被 cluk 并销毁。随后对 oldfid 的使用或放置可触发释放后使用或引用计数下溢。通过仅在 fid 没有别名 oldfid 时才将 fid 放入clunk_fid错误路径中来修复此问题，从而匹配以下错误路径中的现有防护。当多组件 walk 拆分为多个 p9_client_walk（） 调用且之后的非克隆 walk 失败时，可触发此漏洞。可根据要求提供重现和引用计数警告日志。（CVE-2026-63795）

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

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

  - wifi：iwlwifi： mld：固件重新启动期间停止 TX 当 iwlwifi 固件崩溃时（例如 Intel BE201/Wi-Fi 7 上的 NMI_INTERRUPT_UNKNOWN），iwl_mld_nic_error（） 会将 mld->fw_status.in_hw_restart 设为 true。但是，iwl_mld_tx_from_txq（） 从 mac80211 出列帧并将其推送到传输层之前，不会检查此标记。由于固件已失效，iwl_trans_tx（） 会针对每一帧返回 -EIO，然后立即释放该值。在高吞吐量情况下（例如 Tailscale UDP 流量或活动的 SSH 会话），这会形成一个紧凑的出列-发送-失败释放循环，浪费 CPU 周期并产生快速的 skb 分配改动，从而导致 slab 碎片带来内存压力。RX 路径已具有此防护（iwl_mld_rx_mpdu在 rx.c：1906 in_hw_restart进行检查），TXQ 分配工作线程（iwl_mld_add_txqs_wk在 tx.c：156）中也存在此保护。将相同的防护添加到 iwl_mld_tx_from_txq（），以在固件重新启动期间停止所有 TX。当队列重新分配通过 iwl_mld_add_txq_list（） 触发 iwl_mld_tx_from_txq（） 时，或当新的上层流量调用wake_tx_queue时，mac80211 的 TXQ 中留下的帧会自然耗尽。在 ASUS Zenbook 14 UX3405CA 上测试，内核6.19.5上的 Intel BE201 （Wi-Fi 7） 在 Tailscale 流量下，固件大约每 10-15 分钟崩溃一次。
    (CVE-2026-64175)

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

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

  - Meshtastic 是一个开源网状网络解决方案。在低于 2.7.21.1370b23 的版本中，Meshtastic GitHub 存储库的main_matrix.yml工作流由pull_request_target触发，多个作业会检出攻击者的 fork 代码，并以存储库密码的访问权限和提升的GITHUB_TOKEN权限执行该代码。不存在审批门。来自具有 author_association： NONE 的外部用户的拉取请求会自动触发 CI 工作流。该工作流会直接执行分支检出中的攻击者控制的文件。此问题可能导致 repo 的供应链受损、自托管运行器受损和/或存储库受管。此问题与 GHSA-6mwm-v2vv-pp96 不同，后者解决了通过github.head_ref在相同工作流程的设置作业中造成的命令注入。该补丁正确地移动到环境变量。但是，尚未解决 check、build 和 build-debian-src 作业中更严重的分支检出漏洞。版本 2.7.21.1370b23 包含针对此问题的补丁。
    (CVE-2026-44359)

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

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

  - net/sched：act_mirred：修复导致堆栈溢出的区块转换递归绕过 tcf_mirred_act（） 检查sched_mirred_nest针对 MIRRED_NEST_LIMIT （4） 以防止深度递归。但是，当操作使用块转换 （tcfm_blockid ！= 0） 时，函数在达到计数器增量之前在 tcf_blockcast（） 调用处返回。因此，递归计数器永远不会前进，并且完全绕过限制检查。当两个设备使用 mirred 块广播规则共享一个 TC 出口块时，设备 A 上出口的数据包将通过块广播镜像到设备 B;设备 B 的出口 TC 通过块广播重新进入 tcf_mirred_act（） 并镜像回 A，从而创建一个不受限制的递归循环：tcf_mirred_act -> tcf_blockcast -> tcf_mirred_to_dev -> dev_queue_xmit -> sch_handle_egress -> tcf_classify -> tcf_mirred_act ->（重复）此递归一直持续到内核堆栈溢出。非特权用户可通过 unshare（CLONE_NEWUSER |CLONE_NEWNET）：用户命名空间在新的网络命名空间中授予CAP_NET_ADMIN，这足以创建虚拟设备、附加具有共享区块的 clsact qdiscs，以及安装 mirred blockcast 过滤器。缺陷：任务堆栈保护页面在 ffffc90000b7fff8 发生命中 错误：堆栈保护页面：0000 [#1] SMP KASAN NOPTI CPU：2 UID：1000 PID：169 通信：poc 未受感染 7.0.0-rc7-next-20260410 RIP：0010：xas_find+0x17/0x480 调用跟踪：xa_find+0x17b/0x1d0 tcf_mirred_act+0x640/0x1060 tcf_action_exec+0x400/0x530 basic_classify+0x128/0x1d0 tcf_classify+0xd83/0x1150 tc_run+0x328/0x620
    __dev_queue_xmit+0x797/0x3100 tcf_mirred_to_dev+0x7b1/0xf70 tcf_mirred_act+0x68a/0x1060 [重复 ~30+ 次，直到堆栈溢出] 内核恐慌 - 不同步：中断中的致命异常 通过在调用 tcf_blockcast（） 之前递增 sched_mirred_nest，并在返回时递减，以镜像非区块广播路径来修复此问题。这可确保后续递归条目看到更新的计数器，并受到MIRRED_NEST_LIMIT的正确限制。（CVE-2026-63981）

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

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

  - 隧道：在 iptunnel_pmtud_build_icmp[v6]（） 中的 skb_cow（） 之后加载网络标头 Sashiko 发现 iptunnel_pmtud_build_icmp（） 和 iptunnel_pmtud_build_icmpv6（） 在可重新分配 skb->head 的 skb_cow（） 调用之前缓存 ip_hdr（） 和 ipv6_hdr（）。通过在 skb_cow（） 调用后初始化本地变量修复可能的 UAF。删除不需要的 skb_reset_network_header（） 调用。
    (CVE-2026-63994)

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

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

  - usb：gadget：f_fs：针对请求完成序列化 DMABUF 取消 ffs_epfile_dmabuf_io_complete（） 会在已完成的请求上调用 usb_ep_free_request（），但留下 priv->req（ffs_dmabuf_transfer（） 在提交时设置的反向指针）指向已释放的内存。关闭路径上较新的FUNCTIONFS_DMABUF_DETACH ioctl 或 ffs_epfile_release（） 在 ffs-> 下仍看到非空 priv->eps_lock：if （priv->ep & priv->req） usb_ep_dequeue（priv->ep， priv->req）;因此在释放的usb_request上调用 usb_ep_dequeue（）。在dummy_hcd出列路径仅遍历实时队列和指针比较，因此释放的指针读取时不发生错误，并且 KASAN 要求在 FunctionFS 调用站点进行显式检查以显示释放后使用。在支持 SG 的树内 UDC 上，出列路径会立即取消引用提供的请求：* chipidea 的 ep_dequeue（） 在获取自己的锁之前container_of（req， struct ci_hw_req， req） 并读取 hwreq->req.status。* cdnsp 的 cdnsp_gadget_ep_dequeue（） 首先读取 request->status。在完成中通过 cmpxchg（） 清除 priv->req 的较窄选项未解决争用：
    完成在不eps_lock的情况下运行，因此保留eps_lock的取消路径仍可观察 priv->req 非 NULL，争用并发完成（清除和释放），并将释放的指针传递到 usb_ep_dequeue（）。
    需要一个稍长的补丁，以将释放移至清理工作。与最近的 usbip-vudc 定时器补丁相同类别的生命周期争用 [1]。通过将 usb_ep_free_request（） 从完成移至 ffs_dmabuf_cleanup（），由 ffs->io_completion_wq 上的 ffs_dmabuf_signal_done（） 计划的现有工作处理程序）从回调方向变异 priv->req 的唯一位置。eps_lock 在释放之前清除 eps_lock 下的 priv->req，并且仅在 priv->req 仍命名请求时清除（同一附件上的后续 ffs_dmabuf_transfer（） 可能已将新请求排队）。这使现有 dummy_hcd sync-deque 保持不变：UDC 仍然会在不保留eps_lock的情况下调用完成回调（dummy_hcd在调用回调之前终止自己的锁），并且回调现在完全不进行f_fs锁定。针对取消路径的序列化发生在清理中，清理从工作队列运行，条目时不保留f_fs锁。priv ref 计数保护包含的ffs_dmabuf_priv：ffs_dmabuf_transfer（） 通过 ffs_dmabuf_get（） 获取引用，cleanup 通过 ffs_dmabuf_put（） 将其丢弃，因此即使在取消路径 list_del + ffs_dmabuf_put 之后，priv 也会保持活动状态以进行清除。ffs_dmabuf_transfer（） 错误路径不再释放usb_req inline： fence->req 和 fence->ep 是在 usb_ep_queue（） 之前设置的），因此无论队列是否成功，ffs_dmabuf_cleanup（）（由错误路径 ffs_dmabuf_signal_done（） 计划）都拥有释放。在 KASAN 下，在针对 dummy_hcd 的分离路径和关闭路径上重现，在两个 FunctionFS 取消站点使用可观测性挂钩（kasan_check_byte（priv->req） 紧接在 usb_ep_dequeue 之前），以显示过时指针访问;挂钩不是此修补程序的一部分。捕获的 splats 中的 KASAN 分配器/释放堆栈识别相同的请求：dummy_alloc_request中的 alloc、dummy_timer 中的释放、从 ffs_epfile_release（关闭）和 FUNCTIONFS_DMABUF_DETACH ioctl（分离）访问的错误。应用修补程序后，两个路径在同一个挂钩下静默。从 FunctionFS 设备节点访问该缺陷，在实际部署中，该节点由特权小工具后台程序（adbd、UMS、复合小工具服务等）拥有;无法从非特权用户空间或电缆上的 USB 主机访问它。FunctionFS 挂载默认为 GLOBAL_ROOT_UID，但文件系统支持向非根小工具后台程序委派 uid=、gid= 和 fmode=，因此在实际部署中，攻击者可能是权限较低的服务，而非根服务。（CVE-2026-63894）

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

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

  - hwmon：（pmbus/adm1266） 在 ADM1266_PDIO_NR adm1266_gpio_get_multiple（） 处的 get_multiple 中的 CAP PDIO 扫描使用 for_each_set_bit_from（gpio_nr， mask， ADM1266_GPIO_NR + ADM1266_PDIO_STATUS） { ... } 迭代调用程序提供的掩码的 PDIO 部分，其中 ADM1266_PDIO_STATUS 是 PMBus 命令代码（0xE9，即 233），而不是 PDIO 引脚的数量。预期上限为 ADM1266_GPIO_NR + ADM1266_PDIO_NR = 25。gpiolib 将大小为 gc.ngpio 的掩码（此芯片上 = 25 位），因此迭代最多可find_next_bit（） 242 个，读取多达 217 个额外位（少数无符号长字：64 位上有 4 个，32 位上有 7 个）调用程序堆栈中掩码末尾后的任何内容。然后，该范围内的任何附带集位都会驱动写入调用程序提供的位数组末尾之后的set_bit（gpio_nr， bits）调用，两者皆为越界。用 ADM1266_PDIO_NR 替换常量，以便扫描在最后一个真正的 PDIO 位处停止。（CVE-2026-64084）

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

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

  - serial：zs： 转换为使用平台设备 防止在初始化第一个串行端口时发生崩溃： 控制台：切换到 mono 帧缓冲器设备 160x64 fb0： tc0 上的 PMAG-AA 帧缓冲器设备 DECstation Z85C30 串口驱动程序版本 0.10 CPU 0 无法处理虚拟地址 0000002c， epc == 803ab00c， ra == 803aafe0 上的内核分页请求 哎呀[#1]： CPU：0 PID：1 通信：swapper 未受感染 6.4.0-rc3-00031-g84a9582fd203-dirty #57 $ 0 ： 00000000 10012c00 803aaeb0 00000000 $ 4 ： 80e12f60 80e12f50 80e12f58 81000030 $ 8 ： 00000000 805ff37c 000000000 33433538 $12 ： 65732030 00000006 80c2915d 6c616972 $16 ： 80 e12f00 807b7630 000000000 000000000 $20 ： 00000004 00000348 000001a0 807623b8 $24 ： 00000018 00000000 $28 ： 80c24000 80c25d60 8078b148 803aafe0 Hi ： 000000000 Lo ： 00000000 EPC ： 803ab00c serial_base_ctrl_add+0x78/0xf4 RA ： 803aafe0 serial_base_ctrl_add+0x4c/0xf4 状态：10012c03 内核 EXL IE 原因：00000008 （ExcCode 02） BadVA：0000002c PrId：00000440 （R4400SC） 模块链接于： 进程交换器 （pid： 1， threadinfo=（ptrval）， task=（ptrval）， tls=00000000） 堆栈：80760000 00000cc0 00400044 00400040 803aa02c 80d61ab8 00000000 807b7630 8 0760000 807623b8 807b7628 803aa644 80386998 00000000 80e17780 80220f68 80e17780 80d61ab8 80c17d80 80e17780 80e17780 8063c798 80e17780 80383fa0 00000010 80e17780 00000000 80386998 807a000000000000 00400040 8038f848 807623b8 80d61ab8 00000004 80e17780 00000000 803a68e4 80c25e2c 803bb884 ... 调用跟踪： [<803ab00c>] serial_base_ctrl_add+0x78/0xf4 [<803aa644>] serial_core_register_port+0x174/0x69c [<8077e9ac>] zs_init+0xc8/0xfc [<800404d4>] do_one_initcall+0x40/0x2ac [<8076cecc>] kernel_init_freeable+0x1e4/0x270 [<80605bec>] kernel_init+0x20/0x108 [<800431e8>] ret_from_kernel_thread+0x14/0x1c 代码： 2442aeb0 ae120024 ae0200d0 <8c67002c> 50e00001 8c670000 3c06806e 3c05806e afb30010 ---[ end trace 0000000000000000 ]---（在有问题的提交处报告） -- 取消引用源自 null 的指针指向端口父设备的指针。由于没有设备支持旧版探测，并且它不再是发现设备的首选方式，因此请将驱动程序切换为使用平台设备并将其用作端口的父设备。相应地更新资源处理，并且仅请求在插槽内使用的实际地址跨度，通用平台设备代码已经请求其资源。使用 platform_driver_probe（） 不仅因为 SCC 设备是用焊料固定的并且不容易拆卸，而且最重要的是因为相关的 TTY 的主要设备编号与 dz 驱动程序使用的相同，并且第一个声明它的驱动程序将阻止另一个驱动程序使用它。给定系统中将存在一个 DZ 设备或某些 SCC 设备，但绝不会同时存在两个设备，因此我们希望第一个驱动程序声明的主要设备号才能实际成功绑定到其设备，而 platform_driver_probe（） 是实现这一点的一种方式。切换到平台设备的一个不幸后果是，我们现在在启动程序中很久以后才将控制台从 bootconsole 移交。固件控制台处理程序看起来足够好，但可以工作到这么晚，尤其是在启用中断的情况下。由于现在只剩下一种方法可到达 zs_reset（），因此在不再需要时删除端口初始化标记，并且无条件完成通道重置。
    (CVE-2026-63876)

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

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

  - igc：修复 igc_fpe_xmit_smd_frame（） 中潜在的 skb 泄漏 当 igc_fpe_init_tx_descriptor（） 失败时，没有人处理分配的 skb，从而导致泄漏它。[1] 失败时使用 dev_kfree_skb_any（）。使用以下命令在适配器上 I226 进行测试，同时在 igc_fpe_init_tx_descriptor（） 中注入错误以触发错误路径。 # ethtool --set-mm $DEV verify-enabled on tx-enabled on PMAC [1] 未引用的对象0xffff888113c6cdc0（大小 224）： ...回溯 （CRC be3d3fda）：
    kmem_cache_alloc_node_noprof+0x3b1/0x410 __alloc_skb+0xde/0x830 igc_fpe_xmit_smd_frame.isra.0+0xad/0x1b0 igc_fpe_send_mpacket+0x37/0x90 ethtool_mmsv_verify_timer+0x15e/0x300 （CVE-2026-64110）

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

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

  - drm/amdgpu/jpeg：为 JPEG v5.0.0 环设置no_user_fence JPEG 环不支持 64 位用户屏蔽写入，拒绝带有用户屏蔽的 CS 提交。（从提交 0f43893d3cd478fa57836697525b338817c9c23d 中精选出的内容）（CVE-2026-63842）

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

ID	名称	严重性
328248	Linux Distros 未修补的漏洞：CVE-2026-64161	medium
328247	Linux Distros 未修补的漏洞：CVE-2026-64096	high
328246	Linux Distros 未修补的漏洞：CVE-2026-64086	high
328245	Linux Distros 未修补的漏洞：CVE-2026-64169	medium
328244	Linux Distros 未修补的漏洞：CVE-2026-64047	critical
328243	Linux Distros 未修补的漏洞：CVE-2026-63900	medium
328242	Linux Distros 未修补的漏洞：CVE-2026-63952	high
328241	Linux Distros 未修补的漏洞：CVE-2026-63956	medium
328240	Linux Distros 未修补的漏洞：CVE-2026-64113	critical
328239	Linux Distros 未修补的漏洞：CVE-2026-64124	high
328238	Linux Distros 未修补的漏洞：CVE-2026-64131	medium
328237	Linux Distros 未修补的漏洞：CVE-2026-64153	high
328236	Linux Distros 未修补的漏洞：CVE-2026-63996	high
328235	Linux Distros 未修补的漏洞：CVE-2026-63987	high
328234	Linux Distros 未修补的漏洞：CVE-2026-64152	high
328233	Linux Distros 未修补的漏洞：CVE-2026-63973	medium
328232	Linux Distros 未修补的漏洞：CVE-2026-63091	high
328231	Linux Distros 未修补的漏洞：CVE-2026-64069	critical
328230	Linux Distros 未修补的漏洞：CVE-2026-64042	high
328229	Linux Distros 未修补的漏洞：CVE-2026-64010	high
328228	Linux Distros 未修补的漏洞：CVE-2026-63907	medium
328227	Linux Distros 未修补的漏洞：CVE-2026-64046	critical
328226	Linux Distros 未修补的漏洞：CVE-2026-63908	medium
328225	Linux Distros 未修补的漏洞：CVE-2026-64185	medium
328224	Linux Distros 未修补的漏洞：CVE-2026-63978	critical
328223	Linux Distros 未修补的漏洞：CVE-2026-63909	high
328222	Linux Distros 未修补的漏洞：CVE-2026-63951	high
328221	Linux Distros 未修补的漏洞：CVE-2026-63850	high
328220	Linux Distros 未修补的漏洞：CVE-2026-64164	medium
328219	Linux Distros 未修补的漏洞：CVE-2026-63995	high
328218	Linux Distros 未修补的漏洞：CVE-2026-63980	high
328217	Linux Distros 未修补的漏洞：CVE-2026-63926	high
328216	Linux Distros 未修补的漏洞：CVE-2026-64155	high
328215	Linux Distros 未修补的漏洞：CVE-2026-63863	high
328214	Linux Distros 未修补的漏洞：CVE-2026-63884	high
328213	Linux Distros 未修补的漏洞：CVE-2026-64037	critical
328212	Linux Distros 未修补的漏洞：CVE-2026-63939	critical
328211	Linux Distros 未修补的漏洞：CVE-2026-63969	medium
328210	Linux Distros 未修补的漏洞：CVE-2026-63945	high
328209	Linux Distros 未修补的漏洞：CVE-2026-53389	high
328208	Linux Distros 未修补的漏洞：CVE-2026-63795	critical
328207	Linux Distros 未修补的漏洞：CVE-2026-64175	high
328206	Linux Distros 未修补的漏洞：CVE-2026-44359	critical
328205	Linux Distros 未修补的漏洞：CVE-2026-63981	medium
328204	Linux Distros 未修补的漏洞：CVE-2026-63994	critical
328203	Linux Distros 未修补的漏洞：CVE-2026-63894	high
328202	Linux Distros 未修补的漏洞：CVE-2026-64084	high
328201	Linux Distros 未修补的漏洞：CVE-2026-63876	medium
328200	Linux Distros 未修补的漏洞：CVE-2026-64110	medium
328199	Linux Distros 未修补的漏洞：CVE-2026-63842	high

检测

Nessus 的 Misc. 系列

medium

high

high

medium

critical

medium

high

medium

critical

high

medium

high

high

high

high

medium

high

critical

high

high

medium

critical

medium

medium

critical

high

high

high

medium

high

high

high

high

high

high

critical

critical

medium

high

high

critical

high

critical

medium

critical

high

high

medium

medium

high