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

  - soc：aspeed：lpc-snoop：修复 snoop_file_read put_fifo_with_discard（） 中的 usercopy 溢出在 kfifo 上同时充当生产者和使用者：它在不与同样通过 kfifo_to_user（） 消耗的 snoop_file_read（） 同步的情况下从 IRQ 处理程序调用 kfifo_skip（）（向外）和 kfifo_put（）（进出）。在 SMP 系统上，此并发访问可留下（输入 - 输出）大于环缓冲区，因此 __kfifo_to_user（） 对 （输入 - 输出） 的限制无效，并且 kfifo_copy_to_user（） 可尝试通过 kmalloc-2k 后备存储的 copy_to_user（）： usercopy： 从 SLUB 对象“kmalloc-2k”（偏移 0，大小 2049）检测到内核内存泄露尝试！mm/usercopy.c！ 的内核缺陷调用跟踪：usercopy_abort
    __check_heap_object __check_object_size kfifo_copy_to_user __kfifo_to_user snoop_file_read vfs_read 通过 IRQ 处理程序（生产者）和文件阅读器（使用者）之间共享的每个通道旋转锁将 kfifo 访问序列化。使用 __guarded_by（&lock） 注释@fifo，并将驱动程序选择纳入上下文分析，以便编译器强制所有 fifo 访问保持锁定。（CVE-2026-74729）

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

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

  - hwmon：（ltc4282） 钳制负电流限制 将负值传递到 ltc4282_write_curr（） 时，将直接将签名的长 val 转换为 u64： drivers/hwmon/ltc4282.c：ltc4282_write_curr（） { /* 需要以毫伏传递 */ u32 in = DIV_ROUND_CLOSEST_ULL（（u64）val * st->rsense， DECA * MICRO）; ... }此转换将负输入转换为大的正值。随后的除法结果使变量中的 u32 溢出，截断为伪随机正值。将其传递到 ltc4282_write_voltage_byte（） 时，它被限制为最大限制而不是零。在转换之前将 val 限制为 0 并限制为支持的最大上限，并在除法之前将结果分配给 64 位临时变量，以避免下溢和也可能的溢出。（CVE-2026-74685）

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

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

  - net/atm：修复 vcc_setsockopt（） 中的 slab-out-bound 读取 vcc_setsockopt（） 包含无效的 optlen 检查：if （__SO_LEVEL_MATCH（optname， level） &; optlen ！= __SO_SIZE（optname）） return -EINVAL;如果
    __SO_LEVEL_MATCH（optname， level） 被评估为错误（例如，如果调用程序传递了不匹配的级别），长度检查 optlen ！= __SO_SIZE（optname） 短路并绕过。然后执行失败到 switch（optname），假定 optval 包含足够空间则调用 copy_from_sockptr（）。此外，即使级别匹配，cgroup BPF setsockopt 过滤器也会在输入后缩小 optlen。由于内核指针上的 copy_from_sockptr（） 使用 memcpy（），因此当 optlen 小于预期结构大小时，这会导致 KASAN slab-of-bound 读取。使用 copy_safe_from_sockptr（） 修复此问题，该会在复制之前无条件验证 optlen 至少为预期大小。还将本地“value”变量类型从“unsigned long”更改为“int”）以便SO_SETCLP匹配其在 64 位系统上的 sizeof（int） ABI 编码。（CVE-2026-74689）

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

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

  - mm/vmalloc：获取大型 vmap 上的 init_mm 锁定以避免 ptdump UAF 修补程序系列 mm：修复由 ptdump 和 vmap 之间的争用造成的 UAF pgtable 释放，v6。内核页表遍历器分为两大类 - 不需要通过 walk_kernel_page_table_range_lockless（） 排除的范围，以及需要通过 walk_kernel_page_table_range（） 或 walk_page_range_debug（） 排除的范围。前一个类别仅供在其完全拥有且不同时写入的范围内运行的 arm64 arch 代码使用。
    后一类由在完全拥有的范围内运行的内核页表遍历器组成（但需要针对并发写入器排除）。用于排除的锁定为 mmap 锁定，对于内核范围而言，这是 init_mm 上的 mmap 锁定。ptdump 是一种特殊情况，既是 walk_page_range_debug（） 的唯一用户，也是它遍历其未拥有范围的唯一情况。这会产生一个问题，因为可在 ptdump 下释放页表。因此，内核中确实存在释放后使用错误，本系列将解决该缺陷。vmap 会尽可能将页表提升为大型叶条目，并在发生这种情况时释放较低的页面表。这样做时不会针对并发 ptdump 遍历保留任何有意义的锁定。因此，当前可能会发生释放后使用。本系列通过让 vmap 大型升级逻辑获取 mmap 读取锁定，同时设置大型页表条目并释放之前的叶页表来解决此问题。ptdump 代码已获取 mmap 写入锁定，因此通过获取 ptdump 遍历器只会观察到大型页表条目或现有页表条目，并且其下没有释放任何内容。提交 fa93b45fd397 时已针对 arm64 应用了此问题的缓解措施（arm64：通过 ptdump 启用 vmalloc-huge），本系列必须谨慎处理此问题。此缓解措施可在 ptdump 正在进行时，通过获取 vmap 页表释放init_mm上的 mmap 读取锁定，来解决此问题。但是，如果只是将该系列中的补丁应用于 arm64 而不恢复更改，则该系列中的补丁将导致死锁。这是因为 vmap 可能在 ptdump 尝试获取写入锁定之前获取读取锁定，然后该写入锁定进入队列，而 rwsem 耗尽规则意味着 arm64 代码中（未确认的）嵌套 mmap 读取锁定也将阻断，这意味着从不释放原始读取锁定，因此会死锁。本系列通过在 vmap 逻辑中 #ifndef CONFIG_ARM64 mmap 读取锁定，然后部分恢复提交 fa93b45fd397（arm64：
    通过 ptdump 启用 vmalloc-huge），保持大型 vmap 支持的启用并通过部分恢复修补程序删除 ifdeffery。本系列中还涉及一些相关问题：* x86 页面属性逻辑（特别是更改页面属性 （CPA））实现了一项功能，可通过将大型范围折叠成大型叶条目。与 ptdump walk 并行执行时，这同样可造成 UAF，因此类似地获取init_mm mmap 锁定以避免此问题。* CPA 逻辑允许并发页表操纵和 CPA 折叠，这意味着前者存在访问后者释放的页表的风险。通过获取整个 CPA 折叠操作中的 mmap init_mm写锁定和页表操纵上的读取锁定来修复此问题。* x86 和 arm64 允许非内核 MM 的遍历（两者都允许 EFI MM 遍历，在 x86 的情况中是任意 MM），因此我们通过锁定 init_mm 以及正在遍历的 mm，确保内核映射保持稳定。修补程序的顺序是针对严格依存关系（特别是必须在 vmap 变更之后执行的 arm64 部分恢复）和逻辑依存关系（非内核 mm 补丁只有在 vmap/CPA 补丁就绪后才有意义）确定的。此修补程序（共 3 个）：目前有一个令人讨厌的 ra ---truncated--- （CVE-2026-74672）

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

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

  - Input：evdev - 修复 evdev_pass_values（） 中的信息泄漏 在 evdev_pass_values（） 中，input_event 结构被分配在内核堆栈上，并且逐字段填充。但是，它永远不会完全初始化。在 struct input_event包含显式或隐式填充（例如 32 位__pad字段 SPARC64）的架构上，这些填充字节保持未初始化状态。当此事件结构随后传递到客户端缓冲区并稍后复制到用户空间时，未初始化的填充字节会泄漏内核堆栈内存，从而可能暴露敏感信息。下列问题存在
    __evdev_queue_syn_dropped和__pass_event。通过在填充整个事件结构的字段之前先使用 memset（） 显式清零整个事件结构来修复此问题。这可确保在数据越过安全边界之前清除所有填充字节。（CVE-2026-74673）

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

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

  - serial：8250_dma：关闭时清除过时的 RX 状态 serial8250_release_dma（） 终止 RX DMA 并释放通道，但保留设置rx_running。如果在 RX 传输处于活动状态时关闭端口，则当 rxchan 为 NULL 时，会保持过时状态，直到在下一次打开时再次请求通道。认可 a7b9ce39fbe4（序列号：8250_dw：确保取消断言 BUSY）添加的 DesignWare BUSY 变通方案在启动期间从 LCR 写入路径调用 serial8250_rx_dma_flush（）。这会在 serial8250_request_dma（） 获取新 RX 通道之前发生。重新打开时，过时的rx_running状态因而使刷新路径传递空通道到 dmaengine_pause（），进而造成内核 Oops。终止 RX DMA 后清除rx_running，与 TX 清理相匹配。此外，如果 DMA 对象或 RX 通道不可用，则返回刷新帮助程序，这样启动和拆卸路径就无法将空通道传递给 DMAengine API。
    (CVE-2026-74654)

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

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

  - KVM：SVM：使用单独的锁序列化对所有者和镜像列表的访问 KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM和KVM_CAP_VM_COPY_ENC_CONTEXT_FROM之间的交互可导致两个单独的问题： - 在 sev_migrate_from（） 中，当目标 KVM 是镜像时，镜像条目会从源的列表移动到所有者的mirror_vms列表， 不持有所有者锁，这与所有者镜像列表的其他写入器不同（sev_vm_copy_enc_context_from（）， sev_vm_destroy（））。并发 COPY 或销毁可与 sev_migrate_from（） 争用并损坏列表。- 在 sev_vm_destroy（） 中，*所有者* 仍然活动，并可同时收到导致 sev->enc_context_owner 更改的KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM。在这种情况下，错误的 VM 会接收 kvm_put_kvm（）。第二个问题需要特别小心，因为所有者可能会在读取和锁定之间完全消失（即使争用窗口小得不可能）。因此，无法在所有者锁定下执行检查而不将 struct kvm 置于 SLAB_TYPESAFE_BY_RCU 之下（这将允许在 RCU 关键部分下kvm_get_kvm_safe（））。只使用全局锁要简单得多，因为关键部分非常小，而且新锁始终是叶锁。（CVE-2026-74607）

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

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

  - 恢复 thermal/drivers/hwmon：稍微清理编码样式 恢复提交 030a48b0f6ce（thermal/drivers/hwmon：稍微清理编码样式），通过从错误路径中删除有效检查，向 thermal_add_hwmon_sysfs（） 错误路径引入释放后使用。（CVE-2026-74604）

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

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

  - Netty （io.netty：netty-handler） 4.2.0.Final 至 4.2.16.Final 版本以及 4.1.136.Final 及之前版本在使用普通（非扩展）X509TrustManager 且基于不安全的信任管理器封装不可用时，禁用 SslProvider.OPENSSL 客户端路径上的 TLS 主机名验证 （Java 25+）。在此配置中，OpenSSL 客户端不会执行主机名验证，从而允许中间人攻击者提供为其他主机名颁发的证书，并且该证书在未经验证的情况下被接受。
    已在 4.2.17.Final 和 4.1.137.Final 中修复。（CVE-2026-62243）

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

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

  - xsk：未请求时间戳时清除元数据指针 用户空间可在处理请求后更改元数据标记。因此，在完成期间重新读取它们可使内核写入提交数据包时未请求的时间戳。除非请求时间戳完成，否则在请求处理期间清除元数据指针。然后，完成处理可使用指针本身，而非重新读取标记。在 mlx5 多数据包 WQE 路径上，按批次评估元数据：
    xsk_tx_metadata_request（） 仅针对启动会话的描述符运行，就像通过共享 WQE 应用一次的校验和卸载一样。仅该描述符的指针会被重置，因此完成处理可以为会话的其他描述符记录时间戳，而不管它们自己的XDP_TXMD_FLAGS_TIMESTAMP位如何。写入停留在元数据区域内;单 WQE、其他零复制和通用路径会重置每个描述符的指针，且不会受到影响。（CVE-2026-74709）

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

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

  - 之前 3.10.0 的 NLTK 在 StreamBackedCorpusView 中包含任意本地文件读取漏洞，可绕过 pathsec。通过直接调用 builtins.open（） 而非 pathsec.open（） 来强制执行。无论 ENFORCE 设置如何，控制 fileid 参数的攻击者都可以读取任意本地文件，包括敏感系统文件和应用程序凭据。（CVE-2026-63312）

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

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

  - 已修复 Linux 内核中的下列漏洞：ALSA: usb: Fix UAF at delayed release of MIDI2 EPs The recent fix for UAF in ump_to_endpoint() caused another UAF because it tries to dereference the UMP endpoint object, but this might be executed at a delayed context where the endpoint has been already released. Add private_free to clear the associated data for avoiding the further dereference for delayed releases. (CVE-2026-74642)

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

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

  - sctp：删除对等机时清除new_transport sctp_process_asconf_param（） 在 asoc->new_transport 中存储新添加的对等机传输。处理 ASCONF 区块中的所有参数后，sctp_sf_do_asconf（） 使用此指针将 HEARTBEAT 发送到新的传输。来自远程 SCTP 对等机的经认证的 ASCONF 可以添加传输，然后在同一区块中使用通配符 DEL-IP 参数再次删除它。通配符删除将保留 ASCONF 到达的传输，但通过 sctp_assoc_del_nonprimary_peers（） 删除新添加的传输。删除操作未清除 asoc->new_transport，而是将其指向已删除的传输。sctp_sf_do_asconf（） 接着会创建一个 HEARTBEAT，其 chunk->transport 指向已删除的传输，但不保留传输引用。
    在本地地址替换期间，src_out_of_asoc_ok 保持此 HEARTBEAT 处于control_chunk_list状态。RCU 释放传输后，成功ASCONF_ACK替换地址将释放排队的 HEARTBEAT，并且 sctp_outq_select_transport（） 读取已释放传输的状态。该问题是在 SCTP 对象的静态审计期间发现的。通过经身份验证的对等机，复制程序在启用 KASAN 的 netdev/main 内核上的 2 次未修补的运行中，有 2 次触发相同的 KASAN 报告： 缺陷：KASAN：在 addr ffff88800b9bd95c 处的 sctp_outq_select_transport 读取中存在大小为 4 的释放后使用，由任务 python3/197 调用跟踪：
    sctp_outq_select_transport+0x549/0x8b0 [sctp] sctp_outq_flush+0x306/0x2c60 [sctp] sctp_transport_immediate_rtx+0xaf/0x260 [sctp] sctp_process_asconf_ack+0xa48/0xf70 [sctp] 按任务 197 分配：sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] 上一次可能相关的工作创建：
    __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp] sctp_process_asconf+0xd9c/0x1090 [sctp] 第一个无效访问是在 net/sctp/outqueue.c：833 的 transport->state 的四字节读取。同一复制器通过此更改完成了完整的认证 ASCONF 和本地地址替换序列，没有 KASAN 报告或 oops。在删除对等机时清除 new_transport，然后才能将其用于创建心跳信息。（CVE-2026-74586）

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

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

  - xsk：要求至少 16 字节的 TX 元数据AF_XDP接受小至 8 字节的 TX 元数据长度，但每个受支持的请求都需要这些标记和至少一个 8 字节请求字段。这类短元数据也会让内核读取超过注册的区域。要求 16 字节而不是 sizeof（struct xsk_tx_metadata），以保持与不使用启动时元数据的应用程序的兼容性。
    (CVE-2026-74710)

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

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

  - ring-buffer：初始化 rb_allocate_cpu_buffer（） 中的阅读器页面顺序 在 rb_allocate_cpu_buffer（） 中，bpage->order 被省略，将其保留为 0。如果 subbufs 大于 PAGE_SIZE 的环形缓冲区释放后，这是一个问题：free_buffer_page（） 依赖此值。使该值与实际分配大小 （buffer：：subbuf_order） 保持一致。（CVE-2026-74602）

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

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

  - net：usb：ax88179_178a：修复 ax88179_tx_fixup（） 中的 skb 泄漏 当接口启用了 NETIF_F_SG 并且 skb_linearize（） 在 ax88179_tx_fixup（） 中失败时，该函数会在不释放 skb 的情况下返回 NULL。
    usbnet_start_xmit（） 将来自 tx_fixup（） 的空返回视为终止（info->flags 未为此驱动程序设置FLAG_MULTI_PACKET），跳至执行“if （skb） dev_kfree_skb_any（skb）”的终止标签。由于 tx_fixup（） 返回 NULL，usbnet_start_xmit（） 中的本地 skb 变量为 NULL，因此原始 skb 永远不会在线性化失败（即在内存压力下）的每个 TX 帧上释放内存泄漏。在返回之前释放 skb，以匹配已用于同一函数中 pskb_expand_head（） 失败路径的错误处理。（CVE-2026-74678）

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

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

  - xfs：处理 xfs_buf_free 中的 NULL b_addr 当 xfs_buf_alloc_backing_mem（） 失败时，会使用 bp->b_addr 调用 xfs_buf_free（），仍然为 NULL。代码会陷入调用 virt_to_folio（NULL） 的 folio_put 路径，从而取消引用无效地址并导致内核崩溃。调用跟踪：xfs_buf_free+0x25f/0x510 xfs_buf_alloc+0xc98/0x19b0 xfs_buf_find_insert+0x55/0x14d0 xfs_buf_get_map+0x122b/0x17c0 xfbtree_init_leaf_block+0x11c/0x4a0 xfbtree_init+0x1bb/0x460 xrep_rmap_setup_scan+0x100/0x1f0 xrep_rmapbt+0x41/0xc0 通过在 bp->b_addr 为 NULL 时跳过 folio_put（） 来修复此问题。（CVE-2026-74728）

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

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

  - bpf：tcp：修复 bpf_iter_tcp_established_batch（） 中的释放后使用 reqsk_queue_hash_req（） 将TCP_NEW_SYN_RECV request_sock发布至 ehash 链、终止存储段锁定，然后仅将 rsk_refcnt 设为 3。__inet_lookup_established（） 等无锁读取器使用 refcount_inc_not_zero（） 处理此问题，但 bpf_iter_tcp_established_batch（） 在保持存储桶锁定时使用普通 sock_hold（），前提是该锁保证 sk_refcnt > 0。该假设不适用于 request_sock： CPU 0 CPU 1 ----- ----- tcp_conn_request（） reqsk_queue_hash_req（） inet_ehash_insert（req） spin_lock（bucket） __sk_nulls_add_node_rcu（req） // rsk_refcnt == 0 spin_unlock（bucket） bpf_iter_tcp_established_batch（） spin_lock（bucket） sock_hold（req） <-- 在 0 spin_unlock（bucket） refcount_set（&req->rsk_refcnt， 3） // 重写饱和值，其表面为：refcount_t：加法为 0;释放后使用。WARNING： lib/refcount.c：25 at refcount_warn_saturate+0x48/0x90， CPU#1 调用跟踪：
    bpf_iter_tcp_established_batch+0x14e/0x170 bpf_iter_tcp_batch+0x53/0x200 bpf_iter_tcp_seq_next+0x27/0x70 bpf_seq_read+0x107/0x410 vfs_read+0xb9/0x380 当发布 CPU 的 refcount_set（） 覆盖计数时，迭代器窃取的引用丢失，导致缺少套接字一个引用。当最后一个合法所有者丢弃其引用时，reqsk 会在仍然可访问时释放，进而导致释放后使用。
    这种情况在几秒钟内以 tcp_syncookies=0 重现，少数线程对本地监听器执行 connect（）/close（），而其他线程则在紧凑的循环中读取 iter/tcp 链接。使用 refcount_inc_not_zero（） 并在失败时跳过套接字。跳过的套接字仍是存储桶的一部分，因此请继续将其计入预期。重新分配的大小与预期不同，当锁定在最后一个 realloc 中保留时，其 refcount 发布的请求 sock 必须已经有空间。跳过的套接字在预期中计数，但从未进行批处理，因此end_sk在实际完成的批处理中可能低于预期。通过遍历是否留下任何套接字来确定完整性。锁定 realloc 之后的 WARN 会进行相同的检查，取代自提交 cdec67a489d4 以来无法在该路径上保留的 end_sk == 预期检查（bpf：
    tcp：确保 iter->batch 始终包含完整的存储桶快照）。如果存储桶中每个匹配的套接字都是 mid-init （refcount 0），则 end_sk 保持 0。前进到下一个存储桶，而不是返回本轮从未填充的批次条目。（CVE-2026-74714）

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

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

  - gpio：pca953x：修复pca953x_irq_bus_sync_unlock regmap 锁定 regmap 配置中禁用锁定，因为此驱动程序使用自己的锁定。这意味着所有对 regmap 函数（读取或写入）的调用都必须保持i2c_lock。函数 pca953x_irq_bus_sync_unlock（） 未执行此操作，因此多个线程可能导致读取/写入不正确的寄存器。之前的修补程序曾部分修复此问题，但仅保护中断掩码寄存器的写入，而非从方向寄存器的读取。
    (CVE-2026-74733)

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

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

  - binfmt_misc：从其他用户命名空间完成挂载时不发出警告 fsopen（） 在 fc->user_ns 中记录调用程序的用户命名空间并返回普通文件描述符。没有任何内容将调用 fsconfig（FSCONFIG_CMD_CREATE） 的任务与创建上下文的任务相关联。fd 在 fork（） 和 exec（） 之间继承，并且可通过 unix 套接字传递。故意允许从其他用户命名空间完成上下文。vfs_cmd_create（） 通过 mount_capable（） 进行创建授权，对FS_USERNS_MOUNT检查 ns_capable（fc->user_ns， CAP_SYS_ADMIN） 并成功执行在 fc->user_ns 的上级中保留CAP_SYS_ADMIN的任务。因此，非特权任务可访问 bm_fill_super（） 中的 WARN_ON（）：在子项中创建用户和挂载命名空间，在其中调用 fsopen（binfmt_misc），将 fscontext fd 发送至父项，让父项问题FSCONFIG_CMD_CREATE。两个命名空间都来自普通 unshare（1），在任何地方都不需要任何功能： WARNING： fs/binfmt_misc.c：938 at bm_fill_super+0xa2/0xc0 [binfmt_misc] CPU： 15 UID： 1000 PID： 3243382 Comm： fswarn 调用跟踪：
    get_tree_keyed+0x7d/0xb0 bm_get_tree+0x34/0x90 [binfmt_misc] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 子项需要挂载命名空间，因为 fsopen（） 本身在 may_mount（） 上进行门控，而 （） 要求在拥有调用方挂载命名空间的用户命名空间中进行CAP_SYS_ADMIN。fsconfig（） 不会重复该检查。它是 WARN_ON（） 而不是 WARN_ON_ONCE（），因此可在循环中提出此条件来污染内核并淹没日志，并导致使用 panic_on_warn 引导的内核发生错误。继续拒绝安装并停止警告。bm_fill_super（） 中的任何内容都依赖于匹配的两个命名空间，它从 sb->s_user_ns 派生所有内容。
    (CVE-2026-74618)

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

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

  - vdpa/mlx5：修复 create_direct_keys（） 中的缓冲区长度，我们已在 CI 中看到以下 KASAN 消息：
    缺陷：KASAN：cmd_exec+0x550/0xca0 中的 slab-out-of-bound [mlx5_core] 任务 qemu-system-s39/82764 在地址0000000176795020处读取大小为 272 [...][<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...]有缺陷的地址位于分配的 4384 字节区域内部的 4128 字节 [0000000176794000,0000000176795120） 因此，实质上我们读取了超出 4384 字节分配的 16 字节。
    create_direct_keys计算输入和输出缓冲区的指针和长度。in 的大小计算包括整个结构大小 （out + in + mtt[]），但传递到 cmd_exec 的指针仅指向“in”字段，而跳过了“out”字段。这会导致 mlx5_copy_to_msg（） 在复制命令数据时读取超出分配的缓冲区 sizeof（out） 字节。正确计算输入大小以匹配指针和分配大小。（CVE-2026-74712）

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

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

  - serial：amba-pl011：释放 IRQ RS485 后取消 RS485 hrtimers 触发器 hrtimers 嵌入在 devm 管理的端口中，可在释放后触发。IRQ 处理程序可以布防定时器，因此请先释放 IRQ，然后取消两个定时器。在不布防定时器的情况下完成 RS485 停止，并取消 remove（） 中未调用关机的 suspend-then-unbind 路径的定时器。此问题由内部静态分析工具发现。（CVE-2026-74652）

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

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

  - tls：rx：在 TLS 1.3 乐观重试之前还原 msg_iter 当映射乐观 TLS 1.3 零复制路径的用户页面时，tls_decrypt_sg（） 推进 msg->msg_iter。如果解密的记录被证明不是未填充的应用程序数据，则 tls_decrypt_sw（） 会重试到内核 skb 中，但会保留迭代器的高级状态。
    随后，来自 skb 的后续副本会在稍后的时间点在调用程序 iovecs 中再次写入解密的字节，而 recvmsg（） 仅报告重试后的长度。TLS 对等机可在接收方启用 TLS_RX_EXPECT_NO_PAD 后触发此漏洞。按乐观映射消耗的字节数恢复迭代器，然后在不进行零复制的情况下重试。添加 selftest，该 selftest 会在发送启用 TLS_RX_EXPECT_NO_PAD 的 TLS 1.3 控制记录，并验证 recvmsg（） 不会覆盖超过返回长度的 iovecs。
    (CVE-2026-74611)

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

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

  - net/smc：修复 smc_listen_out（） 和监听器之间的 TOCTOU 争用 smc_listen_out（） 在无监听器锁定的情况下读取 lsmc->sk.sk_state，然后仅在检查通过后才获取 lock_sock_nested（）。
    这将打开一个窗口，其中 smc_close_active（） 可以将监听器转换为 SMC_CLOSED，调用 smc_close_cleanup_listen（） 以耗尽接受队列，并释放锁定，所有这些都在无锁读取和延迟锁定获取之间进行：smc_listen_work （smc_hs_wq） smc_close_active（）
    ------------------------------- ------------------------- release_sock（child） if （sk_state == SMC_LISTEN） TRUE lock_sock（listener） sk_state = SMC_CLOSED smc_close_cleanup_listen（） release_sock（listener） flush_work（tcp_listen_work） lock_sock_nested（listener） smc_accept_enqueue（listener， child） /* 在死侦听器上排队的子进程 */ smc_close_active（） 仅刷新tcp_listen_work。已调度到用于 CLC 握手smc_hs_wq上的工作项目继续在无人看管的情况下运行。smc_accept_enqueue（） 采用从未释放的子sock_hold（），因此子smc_sock、其 clcsock 和引用全部泄漏。在服务器调用 close（） 的同时打开 TCP 连接的远程对等机可耗尽内核内存。
    将 lock_sock_nested（） 移动到sk_state检查之前，以便测试和排队在监听器锁定下是原子的。（CVE-2026-74692）

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

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

  - ipvs：禁用 calc 阶段后停止估计器 IPVS 估计器 kthread 0 从归零的链和刻度限制开始，直到其初始计算阶段完成。如果网络命名空间拆卸在该阶段清除 ipvs->enable，则 ip_vs_est_calc_phase（） 可以在不安装正限制的情况下返回。然后 kthread 可继续进入其主循环，并以零chain_max、tick_max和est_max_count值耗尽est_temp_list。每个排队都会消耗一个可用的刻度行，但est_count永远不会达到零est_max_count值。在所有行都用完后，行查找返回 IPVS_EST_NTICKS，ip_vs_enqueue_estimator（） 写过刻度和tick_len数组。如果 kthread 正在停止或 IPVS 已禁用，则在计算阶段结束后退出 kthread 0。这可防止在初始化限制失败后耗尽临时估计器。Estimator kthreads 现在可在拆卸或重新加载停止 kd->task 之前自行退出。创建额外任务引用并通过 kthread_stop_put（） 将其释放之后保留，这样 kd->task 一直有效，直到停止路径耗用该引用。（CVE-2026-74670）

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

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

  - NLTK 之前 3.10.0 的版本在 pathsec.py 中默认为 ENFORCE=False，从而导致所有安全验证函数发出警告而非引发异常。攻击者可利用仅在手动启用时才会激活的已禁用安全控件，来绕过路径遍历和 pickle 反序列化保护。（CVE-2026-62388）

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

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

  - tcp：修复跨重用端口迁移的 TFO max_qlen核算 监听器的TCP_FASTOPEN max_qlen不再准确，并允许通过比配置的要多得多的待定 Fast Open 请求。这仅出现在SO_REUSEPORT听器迁移中，其中关闭听器会将其仍在待定的 TFO 子项移交给幸存的子项。FastOpenQ.qlen 在创建子进程时以 tcp_fastopen_create_child（） 收费，在握手完成时在 reqsk_fastopen_remove（） 中取消收费。uncharge 遵循子项指向的请求的rsk_listener项，并且 inet_reqsk_clone（） 已将子项重新指向新监听器拥有的新请求，因此 ++ 和 -- 位于两个不同的套接字上。新监听器的 qlen 漂移为负，其限制不再绑定。在迁移期间对新监听器收费，就像 reqsk_queue_migrated（） 已经对 queue->young 和 queue->qlen 所做的那样。（CVE-2026-74696）

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

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

  - rqspinlock：死锁时保留队列时重置末尾 目前，在检测到死锁的情况下，rqspinlock 禁止破坏等候队列。死锁检查发生频率相对较高（AA 的输入时间，ABBA 的输入时间为 1 毫秒），涉及死锁的锁定场景可能不会涉及等待程序线程。因此，在我们检测到死锁并退出之后，不刷新队列并让其他等待程序尝试获取锁定非常有用。但是，我们需要遵循与之前对waitq_timeout标签相同的逻辑：重置尾巴，如果不能，则适当地向下一个服务员发出信号。发生死锁时，此信号仅将 MCS 节点标记为已解锁，而在超时时，此信号将发出RES_TIMEOUT_VAL信号。因此，差异在于传播的值，它决定了队列是保持活动状态还是被刷新。不进行尾部重置并等待下一个等待程序可导致我们是最后一个等待程序的情况，因此没有下一个等待程序到达，从而导致此路径中的间歇性停止。一旦下一位服务员加入，我们就会被解除阻断。在理论上，当下一个服务员永远不会加入时，我们就有可能无限期地拖延。这只会发生在 ABBA 死锁时，因为进入等待队列会受到 AA 检查保护。导致此情况的精确执行顺序可以是：CPU 0 保持锁定 A。CPU 1 保持锁定 B。CPU 2 尝试锁定 B，成为 B 的待定等待程序。CPU 0 尝试锁定 B。B 已设置锁定+挂起的位，因此 CPU 0 排队。CPU 1 尝试锁定 A。CPU 0 检测到 ABBA 死锁。CPU 0 发生死锁检测后，它将静坐等待队列中的下一个等待程序填充 node->next，这将遇到延迟，直到此类等待程序到达。通过调整 waitq_timeout 标签之前的死锁检查逻辑来修复此问题。合并这两种情况的代码并使用“ret”来区分传播的值是合理的，但这仅作为未来重构任务的练习，以避免此修补程序中出现 diff 噪声。（CVE-2026-74686）

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

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

  - sctp：使 chunk->transport 与其排队的列表保持一致 __sctp_outq_flush_rtx（） 在不更新 chunk->transport： if （chunk->tsn_gap_acked） { list_move_tail（&chunk->transmitted_list， &transport->transmitted）; continue; }然后，该区块位于实时传输的列表中，而区块>传输仍会命名不同的区块。如果从 ASCONF Delete-IP 中删除该传输 - sctp_assoc_rm_peer（） - sctp_transport_free（），RCU 将释放该传输，而该区块只留下一个悬摆指针。sctp_assoc_rm_peer（） 清理对等>传输和 asoc->outqueue.out_chunk_list，但该区块两者都不存在。设置tsn_gap_acked时未跟随指针。在 TSN 上违背的 SACK 会清除该标志，下一个 SACK 会到达 tchunk->transport->flight_size -= sctp_data_size（tchunk）;在释放的运输工具内。KASAN 报告从 sctp_assoc_rm_peer（） 中释放的 sctp_check_transmitted（） 中存在 slab-use-after-free 读取。删除和 SACK 都来自关联对等方。在移动时设置区块>传输。普通的重新发送路径不需要任何东西：只有在 sctp_packet_append_chunk（） 返回 SCTP_XMIT_OK 之后，它才能到达其 list_move_tail（），并且 __sctp_packet_append_chunk（） 到那时已经重振了区块。由 XBOW 发现，由 Baul Lee 分类 <baul.lee@xbow.com> (CVE-2026-74588)

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

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

  - net：prestera：验证固件标头长度 prestera_fw_hdr_parse（） 读取固件标头，然后再检查固件映像是否包含该标头。拒绝比结构prestera_fw_header短的图像，然后再解码 magic 和版本字段。（CVE-2026-74693）

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

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

  - xsk：验证启动时元数据大小 启动时元数据超出 struct xsk_tx_metadata的前 16 个字节。当注册的元数据区域不包含完整字段时，拒绝请求。
    为通用传输路径生成验证标记的快照，并将该快照用于请求和完成处理，从而避免在用户空间同时更改标记时做出不一致的决策。请注意，只有xsk_skb_metadata正确使用这些标记__xsk_buff_get_metadata会忽略它们。Next 提交解决了该问题。（CVE-2026-74708）

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

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

  - misc：fastrpc：在中断的调用上移动 mmap 时，采用 fl->lock 当调用被信号中断时，wait_for_completion_interruptible（） 返回 -ERESTARTSYS，fastrpc_internal_invoke（） 将每个缓冲区从 fl->mmaps 移动到 cctx->invoke_interrupted_mmaps。此 list_del（）/list_add_tail（） walk 运行时不持有 fl->lock，即在 fastrpc_req_mmap（） 和 fastrpc_req_munmap（） 中序列化其他任何地方的 fl->mmaps 的锁。采用 fl->lock 绕过移动，匹配所有其他 fl->mmaps 访问器。（CVE-2026-74646）

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

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

  - ipv6：修复路由信息选项长度验证 rt6_route_rcv（） 根据前缀长度验证路由信息选项 （RFC 4191） 长度，但两项检查都会差一。rinfo->length 是以 8 个八进制数为单位的 ND 选项长度，它*包含*8 字节选项标头，因此包含 N 字节前缀的选项的长度 == 1 + N/8。RFC 4191 部分 2.3 要求前缀长度大于 64 时长度为 3，大于 0 时要求长度 2 或 3。该代码分别接受长度 >= 2 和长度 >= 1。然后，ipv6_addr_prefix（） 会将 prefix_len/8 字节复制到 rinfo->prefix 之外，因此含有 （prefix_len=128， length=2） 或 （prefix_len=64， length=1） 的路由器公告会使内核读取超过选项结尾处最多 8 字节。这些字节以已安装路由的前缀结束，因此对用户空间可见：# RA with a Route Information option （prefix_len=128， length=2） # 后跟源链路层地址选项， 01 01 de ad be ef ca fe $ ip -6 route show 2001：db8：dead：beef：101：dead：beef：café via fe80：：1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^下一个选项，读取越界 当 Route Information 选项是数据包中的最后一个选项时，这 8 个字节则来自 skb 尾部空间。拒绝 RFC 4191 不允许的选项长度。
    (CVE-2026-74598)

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

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

  - xsk：处理请求时验证元数据 零复制路径在获取描述符上下文时验证 TX 元数据，然后在准备硬件请求时再次读取。用户空间可更改这些操作之间的元数据并绕过原始验证。验证 xsk_tx_metadata_request（） 中的元数据，并将生成的标记快照用于每个功能检查。读取请求字段一次，以便所有零复制驱动程序仅处理成功验证后观察到的值。
    (CVE-2026-74707)

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

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

  - net：smc：修复 smc_rx_splice smc_rx_splice（） 在获取涵盖每个 splice 条目生命周期的引用之前将页面传递到 splice_to_pipe（） 中的 splice 条目生命周期不平衡。在 VM 支持的 RMB 路径中，splice_to_pipe（） 可能会通过 smc_rx_spd_release（） 丢弃未排队的条目，而排队的条目则会在之后通过管道缓冲区回调释放。旧的 post-splice 核算还从构建描述符时发生变化的偏移中派生出排队的 VM 页面数量，并且多页 splice 将一个 sock_hold（） 与多个 sock_put（） 调用配对。在 splice_to_pipe（） 之前获取每个候选条目的页面和套接字引用，并从 smc_rx_spd_release（） 中删除从未排队的条目的匹配私有状态、页面引用和套接字引用。这修复了引用计数不平衡，该缺陷可导致页面引用计数下溢并触发释放后使用。（CVE-2026-74631）

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

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

  - staging：rtl8723bs：修复缺失的共享密钥认证质询长度检查 WEP shared-key 认证处理程序使用质询文本元素的攻击者控制的长度，但未依据固定的 128 字节 chg_txt 缓冲区进行检查。在 OnAuthClient（） 中，rtw_get_ie（） 的长度（最长可达 255）用于将 memcpy（） 执行为 128 字节的 pmlmeinfo->chg_txt，因此发送畸形 WLAN_EID_CHALLENGE 元素的恶意 AP 最多可溢出/不足填充chg_txt 127 个字节。在关联之前，在共享密钥身份验证期间，可通过无线方式访问。在发生溢出时，驱动程序可写入越界。在填充不足的情况下，驱动程序可回显过时的缓冲区内存。质询文本被定义为恰好是 128 个八位字节，这已经按照WLAN_AUTH_CHALLENGE_LEN定义提供了;要求元素在使用前正好是该长度。（CVE-2026-74649）

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

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

  - net：usb：ipheth：修复断开连接时的 carrier_work UAF ipheth_sndbulk_callback（） 重新武装任何非零 URB 状态上的载波检查工作：否则 schedule_delayed_work（&dev->carrier_work， 0）;没有任何关系与接口启动，因此可以在 ipheth_close（） 耗尽工作后再次布防工作，并保持布防状态，直到私人区域嵌入它的 netdev 释放为止。在通过正在运行的 TX URB 拔出时，ipheth_disconnect（） 通过 unregister_netdev（） -> ipheth_close（） -> cancel_delayed_work_sync（） 清空工作，然后才调用 ipheth_kill_urbs（）。usb_kill_urb（） 使用 -ENOENT 完成正在运行的 TX URB，因此 ipheth_sndbulk_callback（） 在耗尽后运行并重新布防carrier_work。如果接口仅在 TX URB 正在运行时关闭，并且 ipheth_carrier_check_work（） 每秒重新排队一次，则相同的完成也会重新布防工作。unregister_netdev（） 不会为已经关闭的接口调用 ipheth_close（），因此在以后的拔出时也不会耗尽任何内容。在两种情况下，free_netdev（） 都会在 carrier_work 仍待定时释放 netdev，而 ipheth_carrier_check_work（） 会取消引用已释放的内存。将工作与接口状态绑定，而不是追逐完成：在 ipheth_close（） 中禁用它，在 ipheth_open（） 中启用它，这样只要接口未启动，从 URB 完成 schedule_delayed_work（） 就不会运行。disable_delayed_work_sync（） 也会等待正在运行的实例，因此完全替换它所取代的 cancel_delayed_work_sync（）。工作在 ipheth_probe（） 中开始禁用，因此启用/禁用从第一次打开开始计算平衡。在 linux-next （next-20260731） 的 KASAN 下重现，dummy_hcd 和 raw-gadget 代替设备，驱动上述第二条路径（接口已关闭，因此 unregister_netdev（） 不会调用 ipheth_close（））：15 个未修补的引导中，有 15 个在 __run_timers（） 中报告了释放后使用 slab，由 ipheth_disconnect（） 释放并通过 queue_delayed_work_on（） 从 ipheth_sndbulk_callback（） 重新布防）。仅与此修补程序不同的内核上的相同触发报告了 0（共 15），并且载波检查在打开/关闭周期中仍然起作用。复制器需要一个连接的 USB 设备来停止耗尽大量 OUT，以及一个链接向下和拔出，以 root 身份驱动。这不是权限越界，也未开发任何恶意利用原语。由 0sec （）https://0sec.ai 发现。（CVE-2026-74677）

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

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

  - ipv6：防止 in6_dev_get（） 恢复 inet6_dev in6_dev_get（） 在 RCU 下读取 dev->ip6_ptr，然后无条件增加其 refcount。设备拆卸可清除指针并丢弃这些操作之间的最后一个引用。该增量随后恢复一个 RCU 释放已排入队列的对象，以便调用者可以在释放后使用该对象。使用 refcount_inc_not_zero（） 并在对象已达到零时返回 NULL。RCU 通过尝试的引用采集使内存保持可访问，并且成功的增量会为调用程序固定对象。在完全未安装修补程序的 6f5156d7a31a （v7.2-rc3） 内核上独立运行，将无效引用采集重现为 UID 1000：
    refcount_t：在 0 上加法;释放后使用。ip6_mc_source+0xef4/0x17e0 紧随其后的是 ip6_mc_source（） 中相应的引用下溢。同一未修补修订版提供的跟踪信息还显示 RCU 读取端部分结束后的访问： 缺陷：KASAN：mutex_lock+0x76/0xe0 中释放后使用 任务 poc/1219 在地址 ffff888015b50240 处的大小为 8 的写入 缺陷由 OpenAI Security Research 发现并分类，并由 Trail of Bits 验证。（CVE-2026-74630）

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

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

  - staging：rtl8723bs：验证监视器传输帧长度 rtw_cfg80211_monitor_if_xmit_entry（） 删除 radiotap 标头，然后在 802.11 不检查是否仍有基标头的情况下读取帧 802.11 控制字段。在确认 skb 包含数据路径之前，数据路径还会提取计算的 802.11、QoS 和 SNAP 标头跨度。因此，截断的帧可造成越界读取，或者留下用于以太网地址写入的数据不足。拒绝不包含基本 802.11 标头的帧和不包含其完整计算标头范围的数据帧。（CVE-2026-74648）

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

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

  - mm：修复直接页表回收中错误的刷新地址 zap_pte_range 回收页表时，它会执行：pte_free_tlb（tlb， pmd_pgtable（pmdval）， addr）;这是无条件错误的：如果执行此代码，则 addr *always* 指向表所涵盖范围的末尾之外。addr 参数用于刷新 TLB（实际上是 paging-structure-cache）以删除对待释放表的引用，任何关注该参数的架构都将刷新错误的地址。（但他们仍然会释放正确的页面）。我认为值得思考为什么内核可以工作。如果命中有问题的代码行，我们将首先清除 PMD 条目（第 1954 行，第 zap_empty_pte_table 行），然后我们将在设置了 force_flush （tlb_flush_mmu_tlbonly（tlb）） 时发出待定刷新，然后我们将跳过第 1979 行的重试（呸！），然后我们将执行有问题的 pte_free_tlb 调用。*或者* 我们将在pte_free_tlb前立即清除 PMD 条目（第 1983 行、第 zap_pte_table_if_empty 行）。如果在清除 PMD 条目时有任何待定的刷新（即我们实际上清除了任何最后一级条目），那么刷新确实应该刷新对表的所有引用（Linus 似乎肯定认为它适用于所有架构 [0]）。在清除时我们没有累积的同花顺的条件非常复杂（整个zap_pte_range函数具有荒谬复杂的控制流）。如果遇到坏情况，则最终将在上次刷新范围之后清除 PMD 条目，并且任何 CPU 都可以自由缓存对（空）页表的引用。如果由于普通读取或写入而发生这种情况，则会出现段错误，因此这种情况很少发生。但缓存也可能被推测性地填充。然后我们将刷新错误的地址，然后释放并可能重用该表。在 x86 上，即使刷新错误的地址也会在非 KPTI Intel 系统上起作用，因为 INVLPG 会刷新 *所有* 分页结构缓存，而不只是刷新目标地址的缓存。
    但 INVPCID 不会，如果 INVPCID 可用，flush_tlb_one_user 将使用 INVPCID。然后我们干杯。AMD 系统更容易受到影响：我们设置了 EFER。TCE 位，这会使 INVLPG 仅刷新目标地址。我认为这可以解决此处报告的 ripgrep 中的一个问题：
    https://github.com/BurntSushi/ripgrep/issues/3494 [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u(CVE-2026-74674）

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

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

  - vsock/virtio：避免在拆卸后重新填充 RX 队列 提交 b917507e5ad9（vsock/virtio：在 .remove（） 期间停止工作线程）可使 RX 工作线程在清除rx_run时跳至其公共退出。当缓冲区计数较低时，该退出仍会重新填充 RX 队列，因此跨 virtio_vsock_vqs_del（） 排队的工作可在删除 virtqueue 之后添加缓冲区。缺陷：KASAN：任务 kworker/0:1 Workqueue 大小为 4 的 virtqueue_add_sgs 读取中的 slab-use-after-free： virtio_vsock virtio_transport_rx_work 调用跟踪：
    virtqueue_add_sgs （drivers/virtio/virtio_ring.c：2796） virtio_vsock_rx_fill （net/vmw_vsock/virtio_transport.c：332） virtio_transport_rx_work （net/vmw_vsock/virtio_transport.c：701） process_one_work （kernel/workqueue.c：3314） worker_thread （kernel/workqueue.c：3478） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：158） ret_from_fork_asm （arch/x86/entry/entry_64.S：245） ... 由任务 141 释放：kfree （mm/slub.c：6566） vp_del_vq （drivers/virtio/virtio_pci_common.c：259） vp_del_vqs （drivers/virtio/virtio_pci_common.c：285） virtio_vsock_freeze （net/vmw_vsock/virtio_transport.c：912） virtio_device_freeze （drivers/virtio/virtio.c：658） virtio_pci_freeze （drivers/virtio/virtio_pci_common.c：601） pci_pm_freeze （drivers/pci/pci-driver.c：1098） device_suspend （drivers/base/power/main.c：1968） 内核错误 - 不同步： KASAN：panic_on_warn套...... 清除rx_run时跳至不填充退出，留下正常退出以补充正在运行的队列。（CVE-2026-74613）

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

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

  - 当输入行正好是缓冲区长度时，src/filehandling.c 中 hashcat 的 fgetl（） 函数会在超出调用程序缓冲区一个字节处写入空终止符。攻击者可以通过提供包含刚好 HCBUFSIZ_LARGE 字节行的哈希文件、potfile 或单词表来触发此越界堆写入。
    (CVE-2026-68767)

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

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

  - veth：修复 XDP frag 调整后的 skb 长度核算 veth 通过xdp_buff暴露非线性 skb 片段。如果 XDP 程序调整了片段区域，veth_xdp_rcv_skb（） 会将xdp_frags_size复制回 skb->data_len，但保留包含旧片段贡献的 skb->len。在片段收缩后，这会使 skb_headlen（） 大于实际线性面积。在重现的 UDP 接收路径中
    __skb_datagram_iter（） 将 1024 字节复制到超过实际线性尾部的用户空间，从 struct skb_shared_info开始。复制的字节包含受影响 skb 的 nr_frags、xdp_frags_size 和来自 skb_shinfo（skb）->frags[0] 的内核指针。实际数据包数据被置换相同数量并在结束时被截断。在替换前减去旧data_len，然后再添加新data_len，保持 skb->len 和 skb->data_len 同步。此外，bpf_xdp_pull_data（） 可在保留碎片存在的同时推进data_end。然后 skb 仍然是非线性的，因此旧 __skb_put（skb， off） 会触发 SKB_LINEAR_ASSERT（）。在 bpf_prog_run_generic_xdp（） 之后使用 skb_set_tail_pointer（） 并显式更新 skb->len。与 __skb_put（） 不同，skb_set_tail_pointer（） 不需要线性 skb。带有 MTU 64000 的 veth 对上的 60000 字节 UDP 数据报从其片段区域缩短了 1024 字节。
    修复之前，所有 10 次运行都会产生损坏的负载。修复之后，所有 10 次运行都完全符合预期负载。强制尾室复制者也在碎片仍然存在的情况下练习 bpf_xdp_pull_data（）;
    旧代码会触发 SKB_LINEAR_ASSERT（），而此补丁会传递 10/10 次运行。（CVE-2026-74612）

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

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

  - ima：实例化 file_truncate 和 path_truncate 挂钩 实例化 file_truncate 和 path_truncate LSM 挂钩，以便在请求截断时立即重置操作缓存标记 （IMA_DONE_MASK），以便在下次访问时根据策略重新收集、重新测量、重新审计和重新评估文件。
    (CVE-2026-74592)

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

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

  - ipvs：衍合隧道 ICMP 错误后清除 IPv4 选项 ip_vs_in_icmp（） 将 skb 从外部 ICMP 数据包衍合到引用的原始请求，然后再将其传递到 icmp_send（）。但是，IPCB（skb）->opt 仍描述外部 IPv4 标头。因此，外部标头中的时间戳选项会在衍合后留下指向引用传输标头的偏移量。__ip_options_echo（） 将该过时位置的一个字节视为选项长度，并将其复制到 __icmp_send（） 堆栈上固定大小的选项存储中，造成堆栈越界写入。重置网络标头后清除过时的选项元数据。
    保留其余控制块字段，包括 ICMP 响应路径使用的入口接口。
    (CVE-2026-74669)

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

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

  - Hashcat 在 src/outfile.c 的 outfile_write（） 函数中包含一个基于堆的缓冲区溢出（越界写入）。将输出组合到固定大小的缓冲区（HCBUFSIZ_LARGE ~16 MB）中时，该函数通过 memcpy 顺序附加用户名、分隔符、哈希和明文，而未验证累积长度是否在缓冲区容量内。对 --username --show 包含几乎填满缓冲区的超大用户名的构建哈希文件运行时，组装的总输出将超过缓冲区，从而导致堆缓冲区溢出，从而损坏内存并使进程崩溃。
    (CVE-2026-68768)

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

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

  - net：atlantic：释放环 deinit aq_vec_deinit（） 上的搁浅 TX 缓冲区通过单个 aq_ring_tx_clean（） 调用耗尽 TX 环，这最多释放 AQ_CFG_TX_CLEAN_BUDGET （256） 个描述符并在 hw_head 处停止，一旦 aq_vec_stop（） 停止硬件和 NAPI，该描述符就不再移动。超出预算的已完成描述符以及仍在 [hw_head， sw_tail） 中发布的所有内容在接口出现故障时保留其 skb 或 xdp_frame：然后 aq_vec_ring_free（） 释放缓冲区环，引用将永久丢失。
    如今，这是 TX/XDP_TX 负载下每个接口上的静默内存泄漏。通过将 RX 路径转换为针对 net-next 发布的 page_pool，它变得更加明显：XDP_TX帧在 RX 环的page_pool上携带片段引用，因此单个搁浅帧将池的飞行计数永远保持在零以上。然后，page_pool_destroy（） 从不完成，池及其页面会一同泄漏，并且page_pool_release_retry（） 停止池关闭时每隔 60 秒收到一次警告，每当 ifdown、XDP 分离或环在负载下调整大小时XDP_TX。恢复删除之前的 aq_ring_tx_deinit（） 并再次用于拆卸，有一个扩展：如今 TX 环可以容纳xdp_frames，因此也请释放它们。由于 xdp_return_frame（） 在进程环境中运行，因此会将其与 （） 一起返回。
    (CVE-2026-74623)

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

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

  - ipvs：避免 ip_vs_nat_icmp 中的越界写入 Sashiko 警告，本地攻击者可在数据包通过 IPVS 处理数据包时对其进行修改。有些地方会多次读取 IP ihl 字段，可能会造成越界访问。其中一个地方是ip_vs_nat_icmp我们可以在验证区域之后写作的地方。通过提供密码参数来修复此问题，就像对 IPv6 所做的那样，并使用 ciph->len 作为嵌入式传输标头的偏移量。通过仅读取 ihl 字段来修改某些 IPv4 标头检查。（CVE-2026-74724）

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

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

  - netfilter：nf_flow_table：在 skb_dst_set_noref（） 之前终止现有 skb dst 通过 netfilter 流表卸载挂钩（或 XFRM 卸载路径）传入的 skb 可能已经携带在之前的 RX 或路由步骤中分配的 ref-counted dst_entry。当 skb 已持有引用计数的 dst 时调用 skb_dst_set_noref（） 将覆盖 skb->_skb_refdst，泄漏之前的 dst_entry 引用计数并触发 skb_dst_check_unset（） 中的DEBUG_NET_WARN_ON_ONCE断言： 警告：在 include/linux/skbuff.h：1170 skb_dst_check_unset 警告：在 include/linux/skbuff.h：1234 skb_dst_set_noref 警告： 在 nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c：864 设置非引用流表目标之前，请终止任何带有 skb_dst_drop（skb） 的现有 dst_entry 引用。（CVE-2026-74695）

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

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

  - net/mlx5：fw_tracer，创建错误时返回 NULL 跟踪器创建可能因返回 NULL 或 ERR_PTR而失败。返回值存储时不进行设备上的检查，用户以相同的方式处理 ERR_PTR 和 NULL。这也会造成核心转储逻辑中发生崩溃，进而缺少ERR_PTR检查，并最终取消引用它，如下图所示。将跟踪程序创建切换为仅在失败时返回 NULL，因此调用程序只需要进行一次 NULL 检查。内部错误：错误：0000000096000006 [#1] SMP 模块链接于：
    mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU：1 UID：0 PID：12 通信：kworker/u16：0 未受 6.19.7 #1 感染 PREEMPT（none） 工作队列：mlx5_health0001：01：00.0 mlx5_fw_reporter_err_work [mlx5_core] pstate：a3400009 （NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--） pc：mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] lr： mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core] SP：ffff800081cf3c40 x29：
    ffff800081cf3c90 x28： 0000000000000000 x27： 00000000000000000 x26： ffff000080018828 x25： 00000000000000000 x24： ffff000080304a05 x23： ffff800081cf3d80 x22： ffff0000847e01a0 x21： 00000000000000000 x20：
    ffff0000847e01a0 x19： fffffffffffffffa1 x18： ffff80008310bbf0 x17： ffff800080119650 x16： ffff80008010df54 x15： ffff80008010d4ac x14： ffff800079c202e4 x13： ffff80008002fe60 x12： ffff800080119650 x11：
    ffff80008010df54 x10： ffff80008010d4ac x9 ： ffff800079c203d8 x8： ffff800081cf3c88 x7 ： 0000000000000000 x6 ： 0000000000000000 x5 ： 0000000000000000 x4 ： 0000000000000008 x3 ： 0000000000000030 x2 ：
    0000000000000008 x1：0000000000000000 x0：00000000c5c4000e 调用跟踪：
    mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] （P） mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core] devlink_health_do_dump+0x9c/0x160 devlink_health_report+0x1c0/0x288 mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core] process_one_work+0x15c/0x3d8 worker_thread+0x18c/0x320 kthread+0x148/0x228 ret_from_fork+0x10/0x20 代码： b9400000 5ac00800 7a401800 540003ca （3940a260） ---[ end trace 00000000000000000 ]--- 内核错误 - 不同步： 哎呀： 致命异常 SMP： 停止次要 CPU 内核偏移： 禁用 CPU 功能： 0x000000,00078031,75fce5a1,35fffe67 内存限制： 无 ---[ 结束 内核错误 - 不同步： 哎呀： 致命异常 ]--- （CVE-2026-74717）

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

ID	名称	严重性
338938	Linux Distros 未修补的漏洞：CVE-2026-74729	high
338937	Linux Distros 未修补的漏洞：CVE-2026-74685	medium
338936	Linux Distros 未修补的漏洞：CVE-2026-74689	high
338935	Linux Distros 未修补的漏洞：CVE-2026-74672	high
338934	Linux Distros 未修补的漏洞：CVE-2026-74673	medium
338933	Linux Distros 未修补的漏洞：CVE-2026-74654	medium
338932	Linux Distros 未修补的漏洞：CVE-2026-74607	high
338931	Linux Distros 未修补的漏洞：CVE-2026-74604	high
338930	Linux Distros 未修补的漏洞：CVE-2026-62243	high
338929	Linux Distros 未修补的漏洞：CVE-2026-74709	high
338928	Linux Distros 未修补的漏洞：CVE-2026-63312	high
338927	Linux Distros 未修补的漏洞：CVE-2026-74642	medium
338926	Linux Distros 未修补的漏洞：CVE-2026-74586	critical
338925	Linux Distros 未修补的漏洞：CVE-2026-74710	high
338924	Linux Distros 未修补的漏洞：CVE-2026-74602	high
338923	Linux Distros 未修补的漏洞：CVE-2026-74678	high
338922	Linux Distros 未修补的漏洞：CVE-2026-74728	medium
338921	Linux Distros 未修补的漏洞：CVE-2026-74714	high
338920	Linux Distros 未修补的漏洞：CVE-2026-74733	high
338919	Linux Distros 未修补的漏洞：CVE-2026-74618	medium
338918	Linux Distros 未修补的漏洞：CVE-2026-74712	critical
338917	Linux Distros 未修补的漏洞：CVE-2026-74652	high
338916	Linux Distros 未修补的漏洞：CVE-2026-74611	critical
338915	Linux Distros 未修补的漏洞：CVE-2026-74692	high
338914	Linux Distros 未修补的漏洞：CVE-2026-74670	high
338913	Linux Distros 未修补的漏洞：CVE-2026-62388	high
338912	Linux Distros 未修补的漏洞：CVE-2026-74696	high
338911	Linux Distros 未修补的漏洞：CVE-2026-74686	medium
338910	Linux Distros 未修补的漏洞：CVE-2026-74588	critical
338909	Linux Distros 未修补的漏洞：CVE-2026-74693	high
338908	Linux Distros 未修补的漏洞：CVE-2026-74708	high
338907	Linux Distros 未修补的漏洞：CVE-2026-74646	high
338906	Linux Distros 未修补的漏洞：CVE-2026-74598	high
338905	Linux Distros 未修补的漏洞：CVE-2026-74707	high
338904	Linux Distros 未修补的漏洞：CVE-2026-74631	high
338903	Linux Distros 未修补的漏洞：CVE-2026-74649	high
338902	Linux Distros 未修补的漏洞：CVE-2026-74677	high
338901	Linux Distros 未修补的漏洞：CVE-2026-74630	high
338900	Linux Distros 未修补的漏洞：CVE-2026-74648	high
338899	Linux Distros 未修补的漏洞：CVE-2026-74674	high
338898	Linux Distros 未修补的漏洞：CVE-2026-74613	high
338897	Linux Distros 未修补的漏洞：CVE-2026-68767	medium
338896	Linux Distros 未修补的漏洞：CVE-2026-74612	critical
338895	Linux Distros 未修补的漏洞：CVE-2026-74592	high
338894	Linux Distros 未修补的漏洞：CVE-2026-74669	critical
338893	Linux Distros 未修补的漏洞：CVE-2026-68768	medium
338892	Linux Distros 未修补的漏洞：CVE-2026-74623	medium
338891	Linux Distros 未修补的漏洞：CVE-2026-74724	high
338890	Linux Distros 未修补的漏洞：CVE-2026-74695	high
338889	Linux Distros 未修补的漏洞：CVE-2026-74717	high

检测

Nessus 的 Misc. 系列

high

medium

high

high

medium

medium

high

high

high

high

high

medium

critical

high

high

high

medium

high

high

medium

critical

high

critical

high

high

high

high

medium

critical

high

high

high

high

high

high

high

high

high

high

high

high

medium

critical

high

critical

medium

medium

high

high

high