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

  - apparmor：在no_new_privs测试前检查标签版本 aa_change_profile（） 在no_new_privs子集检查前使用 fn_label_build_in_scope（） 构建替代标签。构建帮助程序可能失败并返回 NULL 或 ERR_PTR，但在现有 IS_ERR_OR_NULL（） 检查之前，结果已传递给 aa_label_is_unconfined_subset（）。在构建之后立即重复使用现有的目标标签构建失败处理。这可保留当前的审核处理，同时防止子集帮助程序取消引用无效标签。（CVE-2026-72460）

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

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

  - 已修复 Linux 内核中的下列漏洞：kernfs: fix xattr race condition with multiple superblocks Multiple superblocks with different namespaces can share the same kernfs_node when kernfs_test_super() finds a matching root but different namespace. This means multiple inodes from different superblocks can reference the same kernfs_node->iattr->xattrs structure. The VFS layer only holds per-inode locks during xattr operations, which is insufficient to serialize concurrent xattr modifications on the shared kernfs_node. This can lead to race conditions in simple_xattr_set() where the lookup->replace/remove sequence is not atomic with respect to operations from other superblocks. Fix this by protecting xattr operations with the existing hashed kernfs_locks->open_file_mutex[] array, which is already used to protect per-node open file data. The hashed mutex array provides scalable per-node serialization (scaled by CPU count, up to 1024 locks on 32+ CPU systems) with zero memory overhead.
    Changes: - Rename open_file_mutex[] to node_mutex[] to reflect dual purpose - Add kernfs_node_lock_ptr() and kernfs_node_lock() helpers - Protect simple_xattr_set() calls in kernfs_xattr_set() and kernfs_vfs_user_xattr_set() with the hashed mutex - Update file.c to use new helpers via compatibility wrappers - Update documentation to explain the extended lock usage (CVE-2026-74343)

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

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

  - wifi：mt76：mt7996：修复 mt7996_tx_prepare_skb（） 中可能的标记泄漏 如果mt7996_tx_prepare_skb例程中link_conf或link_sta查找失败，mt7996 驱动程序将泄漏已分配的 tx 标记。修复出错时释放标记的问题。（CVE-2026-74323）

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

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

  - ipvs：重置 ip_vs_conn_new 提交 9a05475cebdd 中的完整 ip_vs_seq struct（ipvs：避免 ip_vs_conn_new 中的kmem_cache_zalloc） 更改了 ip_vs_conn_new（） 以通过 kmem_cache_alloc（） 分配ip_vs_conn对象。然后，该函数显式初始化许多字段，但仅重置两个结构ip_vs_seq成员中的 in_seq.delta 和 out_seq.delta。这会使 init_seq 和 previous_delta 处于未初始化状态。这通常无害，但相应的 IP_VS_CONN_F_IN_SEQ 或 IP_VS_CONN_F_OUT_SEQ 标记已清除。但是，对于从同步消息获知的连接，ip_vs_proc_conn（） 会保留IP_VS_CONN_F_BACKUP_MASK的这些标记，并在消息忽略IPVS_OPT_SEQ_DATA时传递 opt=NULL。在这种情况下，可以在设置 SEQ 标记的情况下对新连接进行哈希处理，但 in_seq/out_seq 的其余部分仍包含过时的 slab 数据。之后 IPVS 应用程序帮助程序处理此类连接的数据包时，vs_fix_seq（） 和 vs_fix_ack_seq（） 会使用 previous_delta 和 init_seq 重写 TCP 序号。因此，畸形 sync 消息会使转发的数据包在其 TCP seq/ack 编号中携带过时的 slab 字节，还可损坏转发的 TCP 流。在发布连接之前，完全重置两个 struct ip_vs_seq 成员。这与现有的重置结构ip_vs_seq注释相匹配，并使序列调整门保持不活动状态，除非以后安装有效的序列数据。（CVE-2026-72020）

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

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

  - fs/ntfs3：向 indx_find_buffer 添加深度限制以防止堆栈溢出 indx_find_buffer（） 递归降序 B+ 树索引，没有深度限制。具有循环索引节点引用的构建 NTFS 图像会造成无限循环，从而溢出内核堆栈并造成系统错误。可以通过挂载恶意 NTFS 文件系统（例如通过桌面自动挂载从 USB 驱动器中），并删除其索引条目触发 indx_delete_entry（） 中的重新平衡回退路径的文件来实现此目的。添加深度参数，并在达到 fnd->nodes 数组边界时使用 -EINVAL 退出，进而符合 indx_find（） 中的 fnd_push（） 已强制实施的限制。相关函数 indx_find（） 之前已针对类似的无限循环问题（提交 1732053c8a6b）进行了修补，但是缺少 indx_find_buffer（）。（CVE-2026-72194）

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

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

  - wifi：cfg80211：当父 EHT 多链路元素具有与未传输的 BSSID 索引相匹配的 MLD ID 时，在 MLD ID 读取 cfg80211_gen_new_ie（） 从父帧复制 ML 探测响应元素之前验证 EHT MLE。代码仅在调用 ieee80211_mle_get_mld_id（） 之前检查扩展元素是否具有多个字节。该帮助程序假设 BASIC MLE 具有足够多的通用信息和文档，调用者必须首先使用 ieee80211_mle_type_ok（）。攻击链：恶意 AP 在 MBSSID 信标中发送短 EHT MLE。cfg80211_inform_bss_frame_data（） 存储复制的 IE 缓冲区。
    cfg80211_parse_mbssid_data（） 构建未传输的 BSS IE。cfg80211_gen_new_ie（） 会在父帧中查看 EHT MLE。然后，ieee80211_mle_get_mld_id（） 读取超过 IE 边界。读取 MLD ID 之前验证 MLE 类型和大小。这符合 MLE 帮助程序所需的协定，并在访问任何内部 MLE 字段之前拒绝短元素。（CVE-2026-68472）

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

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

  - sctp：验证嵌入地址参数长度 sctp_verify_asconf（） 和 sctp_verify_param（） 仅针对固定的最小大小 sizeof（struct sctp_addip_param） + sizeof（struct sctp_paramhdr） 验证 ADD_IP、DEL_IP 和 SET_PRIMARY 参数。这可确保外部参数足够大，可包含嵌入式地址参数标头，但不会验证嵌入式地址参数声明的长度是否符合外部参数的边界。随后，sctp_process_param（） 和 sctp_process_asconf_param（） 提取嵌入式地址参数并将其传递给 af->from_addr_param（），后者使用地址参数长度解析可变长度地址负载。因此，损坏的对等机可公告超过包含参数中剩余字节的嵌入式地址参数长度。处理嵌入式地址参数之前，验证 addr_param->p.length 是否不超过 sctp_addip_param 标头后的可用空间。嵌入地址长度超出包含参数边界时，拒绝格式畸形参数。这可防止在解析 INIT 或 ASCONF 处理路径中所携带的畸形参数时的越界读取。（CVE-2026-74287）

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

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

  - 已修复 Linux 内核中的下列漏洞：xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.
    (CVE-2026-72137)

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

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

  - rxrpc：修复 ACKALL 数据包处理 rxrpc_input_ackall（） 接受 ACKALL 数据包时未检查调用的状态是否可以合法地拥有未完成的传输缓冲区。因此，伪造的 ACKALL 可在任何回复数据包排队之前以 RXRPC_CALL_SERVER_RECV_REQUEST 联系到新的服务调用。在该状态下，call->tx_top 为零，call->tx_queue为 NULL，因此 rxrpc_rotate_tx_window（） 将取消引用 NULL txqueue 并触发空指针取消引用。通过以下方法修复 ACKALL 数据包的处理：（1） 添加两种新的调用状态：RXRPC_CALL_CLIENT_PRE_SEND，表示客户端调用已连接，但尚未传输任何内容;和 RXRPC_CALL_CLIENT_AWAIT_ACK，这表示所有内容都已至少传输一次，但我们现在正在等待 Tx 缓冲区中剩余的内容经过 ACK'd（可能仍会发生重新传输）。RXRPC_CALL_CLIENT_PRE_SEND状态在为呼叫分配通道时设置，并在传输第一个数据包时转换为RXRPC_CALL_CLIENT_SEND_REQUEST状态。然后缩小RXRPC_CALL_CLIENT_AWAIT_REPLY范围以指示所有 Tx 数据包都已经过 ACK，我们现在正在等待收到回复。（2） 根据 Wyatt Feng 的原始修补程序 [1]，ACKALL 处理程序随后会检查调用状态是否为 Tx 缓冲区中可能存在 ACK 内容的状态，但现在这包括AWAIT_ACK而非AWAIT_REPLY。如果以错误的状态接收 ACKALL 数据包，则会忽略此数据包。请注意，与 Wyatt Feng 的修补程序不同，不再需要检查 Tx 缓冲区是否存在，因为状态集现在涵盖了此缓冲区。（3） 使 ACKALL 处理程序使用 call->tx_transmitted 而不是 call->tx_top，因为前者明确是传输的最高数据包序列号，而后者的定义更宽松。感谢 Jeffrey Altman 描述 ACKALL 数据包[1] 的历史记录。（CVE-2026-74430）

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

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

  - bpf：修复BPF_PROG_QUERY越界写入和 cgroup 向后兼容BPF_PROG_QUERY无条件地将“query.revision”字段写回用户空间。如果用户空间传递较小的“bpf_attr”结构（例如 40 字节，这是添加“query.revision”之前的布局），内核将执行越界写入。通过将用户提供的属性大小“uattr_size”下传播到 cgroup 查询处理程序，并在提供的缓冲区大小不足时有条件跳过将修订字段写入用户空间，来修复此问题。bpf_mprog_query 中的 query.revision 在结构上与 cgroup 案例相同：无条件编写的后期尾字段。但向后兼容的危险并不相同。最小历史大小测试是针对每个命令进行的，并且bpf_mprog_query仅服务于在 struct 中随修订而生的附加类型： - tcx_prog_query -> BPF_TCX_INGRESS/EGRESS - netkit_prog_query -> BPF_NETKIT_PRIMARY/PEER tcx、netkit、修订字段和bpf_mprog_query本身都位于同一个 v6.6 合并窗口中（053c8e1f235d 添加了 mprog 查询 API + 修订;e420bed02507 中的 tcx， 35dfaad7188c 中的 netkit）。从来没有一个 tcx/netkit BPF_PROG_QUERY用户空间不知道修订。因此，对于这些命令，最小合法结构已经覆盖偏移 56-64，这里无法破解任何旧的二进制文件。与 cgroup 对比：BPF_PROG_QUERY 2017 年发布的 cgroup 连接类型;几年后附加修订回写 （120933984460）。该路径具有真实的修订前调用者群体。（CVE-2026-74371）

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

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

  - i2c：imx：修复 SMBus 块读取为 0 （IRQ） 时锁定的总线 SMBus 3.1 6.5.7 允许块读取字节计数为 0，但中断驱动的块读取状态机将其作为 -EPROTO 拒绝。更糟糕的是，它返回时没有 NACK+STOP：下一个接收周期已经开始，因此目标继续保持 SDA，总线保持卡住，直到此 i2c 控制器重新启动。接受 count=0：NACK 正在传输的虚拟字节 （TXAK） 并将 msg->len 设置为 2，i2c_imx_isr_read_continue（） 通过其正常的最后一个字节路径发出 STOP。虚拟字节被丢弃;block-read 调用方仅消耗 buf[0..count-1]。读取 I2DR 同样已经布防了错误路径计数> I2C_SMBUS_BLOCK_MAX下一个字节，因此在使用 -EPROTO 中止之前 NACK 它 （TXAK）;
    否则，失败换乘的 STOP 无法完成，并且公交车保持滞留状态。原子路径较早回归 （v3.16） 并单独修复;此修补程序仅涵盖 v6.13 状态机返工。
    (CVE-2026-72141)

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA.
    So do the simpler thing for now and just reject everything that isn't memory. (CVE-2026-72277)

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

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

  - accel/amdxdna：修复 VMA 访问争用 aie2_populate_range（） 和 amdxdna_umap_release（） 访问可能已经释放的已保存 VMA 指针，从而导致潜在的释放后使用。从这些函数中删除 VMA 访问以避免争用。（CVE-2026-72331）

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

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

  - ieee802154：admin-gate 旧版 LLSEC 转储操作 在 net/ieee802154/netlink.c 中，旧版 IEEE802154_NL 系列 ops 表使用不设置 .flags 的 IEEE802154_DUMP（） 构建 LLSEC 转储条目（LLSEC_LIST_KEY、LLSEC_LIST_DEV、LLSEC_LIST_DEVKEY、LLSEC_LIST_SECLEVEL），因此通用 netlink 未设置任何 .flags 来运行它们。
    现代 nl802154 系列管理员通过 NL802154_CMD_GET_SEC_KEY 和好友使用 .flags = GENL_ADMIN_PERM 进行等效读取。任何可打开 AF_NETLINK/NETLINK_GENERIC 的本地 uid 都可解析 MAC 系列， 802.15.4 并在安装了 LLSEC 密钥的任何 wpan netdev 上转储LLSEC_LIST_KEY;转储处理程序将原始 16 字节 AES-128 密钥字节（IEEE802154_ATTR_LLSEC_KEY_BYTES，从 struct ieee802154_llsec_key.key 逐字复制）写入回复。恢复 AES 密钥会损害 802.15.4 LLSEC 链接的机密性和真实性，因为 LLSEC 使用 CCM* 并且同一密钥对帧进行身份验证和加密。影响：任何无功能的本地 uid 都可通过在旧版 IEEE802154_NL generic-netlink 系列上发出LLSEC_LIST_KEY转储，从任何具有管理员安装 LLSEC 密钥的 wpan netdev 上的内核密钥表读取原始 16 字节 AES-128 LLSEC 密钥。引入镜像 IEEE802154_DUMP（） 但设置 .flags = GENL_ADMIN_PERM 的 IEEE802154_DUMP_PRIV（），并将其用于四个 LLSEC 转储条目。LIST_PHY 和 LIST_IFACE保留 IEEE802154_DUMP（），因为现代 nl802154 系列按照设计将其等同项暴露给非特权读取器（NL802154_CMD_GET_WPAN_PHY和NL802154_CMD_GET_INTERFACE进位可由非特权用户批注检索）。（CVE-2026-72049）

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

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

  - fhandle：拒绝 capable_wrt_mount（） 中分离的挂载 最近的 fhandle RCU 补丁将挂载命名空间功能检查移至 capable_wrt_mount（） 中，因此非空mnt_namespace在 ns_capable（） 取消引用中幸存。由于 may_decode_fh（） 先检查了 is_mounted（），因此帮助程序仍假设后面的 READ_ONCE（mount->mnt_ns） 一定为非 NULL。这种假设并不稳定。从 open_tree（...， OPEN_TREE_CLONE） 分离的挂载可在 fput 时溶解，而 open_by_handle_at（） 处于这些检查之间，并且 umount_tree（） 可清除挂载>mnt_ns。如果帮助程序发现 NULL，它会取消引用mnt_ns>user_ns并发生错误。RCU 读取发现分离的挂载时返回假。这使放宽的权限路径保持保守：不再附加到命名空间的挂载不能授权 open_by_handle_at（） 访问。（CVE-2026-72034）

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

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

  - wifi：wcn36xx：修复PRINT_REG_INFO指示中从固件计数读取的 OOB 由固件控制的 rsp->count 字段用作循环边界，无需根据消息长度进行验证而编制灵活 rsp->regs[] 数组索引。一个超过实际数据的计数会造成从堆分配的消息缓冲区进行越界读取。添加计数是否适合接收到的消息的检查。
    (CVE-2026-74340)

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

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

  - net：wwan：iosm：MUX 下行链路解码器 mux_dl_adb_decode（） 中的绑定设备偏移使用取自调制解调器的偏移和长度遍历汇总数据报表链。first_table_index、next_table_index、table_length、datagram_index 和 datagram_length 都是设备提供的 le 值。仅检查first_table_index，且仅检查非零。解码器随后形成 adth = block + adth_index，并读取表标头和与接收到的 skb 无边界的数据报条目。报告超过下行链路缓冲区的索引或长度的调制解调器导致解码器读取越界。缓冲区是IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE的，而 skb->len 最多是缓冲区，因此 skb->len 是真正的限制，但未针对其检查带偏移中的其中任何一个限制。表链后面也没有进行任何转发进度检查。循环从 adth->next_table_index 获取下一个表，仅当该表达到零时才停止。调制解调器可以暂存两个相互指向的表，因此循环永不结束。它在 softirq 中运行，并在每次传递时克隆 skb。使用前根据 skb->len 验证每个设备偏移和长度。块标头必须适合。每个表标头，在输入时和每次next_table_index之后，都必须位于 skb 中。数据报表必须适合。每个数据报索引和长度都必须位于 skb 内。标头填充不得超过数据报长度，因此接收长度不会封装。要求每个next_table_index向前移动，这样链就不能循环。此漏洞在 KASAN 下重现为 iosm net 设备启动后正常下行链路接收上的 slab 越界读取。（CVE-2026-72029）

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

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

  - iommufd：从 dmabuf 分离后破坏页面内容 Sashiko 指出这已出现故障，通过 dmabuf 无效回调，互斥体仍可在使用中。在完全分离 dmabuf 之前，不破坏任何页面内容。（CVE-2026-74328）

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

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

  - 已修复 Linux 内核中的下列漏洞：rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.
    (CVE-2026-74433)

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

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

  - Glances 是一款开源系统跨平台监控工具。从 4.5.2 直到 4.5.6，
    glances/actions.py 中的 _sanitize_mustache_dict（） 跳过嵌套的列表和字典字符串（例如进程 cmdline 值），从而允许管道字符在 chevron.render（） 中留存，并由 secure_popen（） 通过管理员配置的操作模板执行。此问题已在 4.5.6中修复。（CVE-2026-62982）

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

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

  - vhost/vdpa：验证 mmap 和错误路径中的 virtqueue 索引 vhost_vdpa_mmap（） 和 vhost_vdpa_fault（） 使用 vma->vm_pgoff 作为 get_vq_notification（） 的 virtqueue 索引，但它们不验证索引是否小于 v->nvqs。ioctl 路径已同时执行边界检查和 array_index_nospec（），但 mmap/fault 路径仅检查索引是否适合 u16。这会允许超出范围的队列索引访问驱动程序特定的 get_vq_notification（） 回调。通过提取统一的 vhost_vdpa_get_vq_notification（） 帮助程序来修复此问题，该帮助程序会针对 v->nvqs 验证队列索引并在调用驱动程序回调之前应用 array_index_nospec（）。mmap 和错误路径都使用此帮助程序，并且边界检查被整合到一个位置。从源检查来看，最合理的影响是回调路径中的越界访问，这可能导致无效的 PFN 重新映射和崩溃/DoS。（CVE-2026-74312）

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

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

  - netfilter：nft_meta_bridge：修复NFT_META_BRI_IIFPVID堆栈泄漏 这需要测试非零 retval。
    (CVE-2026-72433)

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

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

  - powerpc/uaccess：修正 mask_user_address（） 中的CONFIG_PPC_E500检查 mask_user_address（） 错误地检查 CONFIG_E500 而不是 CONFIG_PPC_E500，从而导致硬件上 E500 不使用 mask_user_address_isel（）。修复检查以使用正确的名称。（CVE-2026-68473）

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

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

  - ASoC：SOF：拓扑：在解析之前验证供应商数组大小 sof_parse_token_sets（） 在迭代拓扑私有数据时读取 array->size。循环条件仅检查是否仍有一些数据，因此具有截断尾部供应商数组的畸形拓扑可使解析器在提供完整的供应商数组标头之前读取 size 字段。读取 array->size 之前，验证剩余专用数据是否包含完整的 snd_soc_tplg_vendor_array 标头。声明的数组大小检查也需要保持签名状态。asize 是整数，但 sizeof（*array） 的类型为 size_t，因此比较它们会直接将负的 asize 值提升为无符号并让它们通过检查，如下面的稳定审查线程参考中所述。验证声明的数组大小时，将 sizeof（*array） 转换为 int。在解析器调度到特定于元组的代码之前，这会拒绝负大小、零大小和其他太小的大小。
    (CVE-2026-72300)

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into normal checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the normal controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a late flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.
    (CVE-2026-72287)

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

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

  - net/sched：sch_codel：在还原 qlen 之前，请勿在扫视期间调用 qdisc_tree_reduce_backlog 每当 codel 在扫视期间丢弃数据包时，它都会调用 qdisc_tree_reduce_backlog。出现一个问题，因为它在重新增加 qlen 之前调用了 qdisc_tree_reduce_backlog。如果 qlen 降至零，但 peek 返回 skb，则即使 codel 队列中仍有 1 个数据包，仍将执行父项的 qlen_notify 回调，因此将错误地停用父项类，从而在 qfq 将 codel 作为子项时导致失控内存访问等问题： [ 36.339843][ T370] 哎呀：一般保护错误，可能针对非规范地址0xfbd59c0000000024： 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN：范围内可能是失控内存访问 [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU：2 UID：0 PID：370 通信：tc 未受感染 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT（full） [ 36.341113][ T370] 硬件名称：Bochs Bochs， BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP：0010：qfq_deactivate_agg （include/linux/list.h：1029（鉴别器 2） include/linux/list.h：1043（鉴别器 2） net/sched/sch_qfq.c：1369（鉴别器 2）net/sched/sch_qfq.c：1395 （discriminator 2）） sch_qfq [ 36.342221][ T370] RSP：0018：ffff8881100ef370 EFLAGS：
    00010216 [ 36.342422][ T370] RAX：0000000000000000 RBX：ffff8881058a9568 RCX：dffffc00000000000 [36.342664][ T370] RDX：1ffff11021064dc3 RSI：ffff888108326e00 RDI：dffffc00000000000 [ 36.342905][ T370] RBP：ffff8881058a8280 R08：dead0000000000122 R09：1bd5a000000000024 [ 36.343140][ T370] R10：
    ffffbfff2940329 R11： ffffbfff2940329 R12： 0000000000000000000 [ 36.343383][ T370] R13： dead0000000000100 R14： ffff8881058a9580 R15： ffff8881058a9578 [ 36.343631][ T370] FS： 00007fc04b0ca780（0000） GS：ffff888184fef000（0000） knlGS：000000000000000000 [ 36.343911][ T370] CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 [ 36.344116][ T370] CR2： 0000557c02c02000 CR3： 0000000010e0ba000 CR4： 00000000000750ef0 [36.344359][ T370] PKRU： 55555554 [ 36.344481][ T370] 调用跟踪： ...[ 36.345054][ T370] qfq_reset_qdisc （net/sched/sch_qfq.c：357 net/sched/sch_qfq.c：1487） sch_qfq [ 36.345222][ T370] qdisc_reset （net/sched/sch_generic.c：1057） [ 36.345503][ T370] __qdisc_destroy （net/sched/sch_generic.c：1096） [36.345677][ T370] qdisc_graft （net/sched/sch_api.c：1062 net/sched/sch_api.c：1053 net/sched/sch_api.c：1159） [ 36.346335][ T370] tc_get_qdisc （net/sched/sch_api.c：1528 net/sched/sch_api.c：1556） 通过仅在 qlen 之后调用 peek 中的 qdisc_tree_reduce_backlog 来修复此问题已恢复。（CVE-2026-74267）

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

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

  - batman-adv：仅在 skb realloc 之后才访问 skb->data unicast_ttvn batadv_get_vid（） 调用的 pskb_may_pull（） 可重新分配 skb 后面的缓冲区。需要重新分配指向旧缓冲区的变量以避免释放后使用。对以太网标头正确地完成了此操作，但对unicast_packet指针未实现此操作。（CVE-2026-72234）

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

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

  - netfilter：nf_conncount：防止终止及早确认 ct 提交的 connlimit 权限 69894e5b4c5e（netfilter：
    nft_connlimit：如果跳过添加，则更新计数）引入了一个回归，其中，将 connlimit 用于软限制方案时，有效连接的数据包会被丢弃。当新连接重复使用当前处于TIME_WAIT状态的套接字时，会发生此问题。在此方案中，连接跟踪条目的评估为已确认。以前，__nf_conncount_add（） 假设如果连接已确认且并非源自回路接口，则应跳过添加并返回
    -EEXIST。跳过添加将触发垃圾回收运行，从而清理TIME_WAIT连接。
    活动连接计数结果会降为 0，xt_connlimit不当处理，进而导致错误拒绝完全有效的新连接。通过将接口检查替换为与协议无关的状态检查来修复此问题。我们现在跳过树插入，仅当连接IPS_ASSURED时才保留无锁垃圾回收优化。这允许对早期确认的设置数据包（如重用的 TIME_WAIT 套接字或本地生成的 SYN-ACK）进行正确评估和计数，而不会发生错误丢弃。保留转至check_connections路径以确保正确去重这些设置数据包。这已在本地配置的 slowhttptest 和 HTTP 服务器中进行了测试，以确保不会破坏本地或外部连接的软限制情况。此外，它还通过了 OVS 区域限制进行测试。（CVE-2026-72418）

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

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

  - net：sungem：修复当 register_netdev（） 失败时探测错误清理 gem_init_one（） 调用 gem_remove_one（）。
    gem_remove_one（） 注销并释放 net_device 拥有的资源，包括 DMA 区块、MMIO 映射、PCI 区域以及 net_device 本身。然后，gem_init_one（） 会回到自己的清理标签，并再次释放相同的资源。将 register_netdev（） 错误路径保留在 gem_init_one（） 中：清除 drvdata，以便 PM/remove 路径不看到注册过半的设备，删除探测期间添加的 NAPI 实例，并让现有清理标签释放一次资源。探测错误路径的本地静态分析检查器发现此问题。在发送此补丁之前，已对报告的路径进行了手动检查。使用 CONFIG_SUNGEM=y 进行编译测试。由于没有可用的 sungem 硬件，因此未执行运行时测试。（CVE-2026-72406）

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

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

  - RDMA/mlx5：修复 ODP 填充失败 mlx5r_umr_update_xlt（） 分配和 DMA 通过 mlx5r_umr_create_xlt（） 映射 XLT 缓冲区时的 UMR XLT 清理。通过 mlx5r_umr_unmap_free_xlt（） 由通用清理路径释放缓冲区。mlx5_odp_populate_xlt（） 变得容易出错后，其错误路径会直接返回并跳过该清理。这会泄露 XLT DMA 映射和缓冲区。如果使用了紧急 XLT 页面，它也会使xlt_emergency_page_mutex保持锁定状态。中断循环，以便执行通过现有清理路径。（CVE-2026-74396）

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

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

  - ipvs：确保 ICMP 错误中的内部标头位于余量内 Sashiko 指出，在使用 pskb_pull（） 剥离外部标头后，我们应确保 ipv4_update_pmtu（）、icmp_send（） 和 IP_VS_DBG（） 等函数的 skb 余量中存在来自隧道的 ICMP 错误中的内部 IP 标头。此外，还添加了针对内部标头长度的更多检查。（CVE-2026-72319）

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

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

  - afs：修复 Fix afs_insert_volume_into_cell（） 上设置的卷AFS_VOLUME_RM_TREE以对替换的卷（而不是新卷）设置AFS_VOLUME_RM_TREE，因为它现在已从单元格的卷树中删除。这将导致从树上删除旧卷两次，而新卷永远不会删除。（CVE-2026-72371）

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

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

  - netfilter：xt_u32：拒绝无效的位移计数 u32_match_it（） 对 32 位值执行规则提供的位移操作数。畸形 u32 规则可提供 32 次或以上的位移计数，从而在数据包评估期间触发未定义的位移越界。验证 u32_mt_checkentry（） 中的 XT_U32_LEFTSH 和 XT_U32_RIGHTSH 操作数，并在畸形规则到达数据包路径之前将其拒绝。（CVE-2026-72350）

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

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

  - smb：客户端：修复传递 ioctl 边界检查中的溢出 smb2_ioctl_query_info（） 在将 PASSTHRU_FSCTL 响应负载复制到用户空间之前对其进行验证。负载偏移和长度均来自 32 位字段。边界检查目前直接添加 OutputOffset 和 qi.input_buffer_length，因此在将结果与响应缓冲区长度进行比较之前，可以在 32 位算术中进行加法封装。恶意服务器可使用较大的 OutputOffset 和较小的 OutputCount 使封装的总和通过边界检查。后面的 copy_to_user（） 然后从响应缓冲区外的 io_rsp + OutputOffset 中读取。将 size_add（） 用于偏移加长度检查，这样溢出就被视为越界。
    (CVE-2026-72310)

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

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

  - 已修复 Linux 内核中的下列漏洞：netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage. (CVE-2026-72249)

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

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

  - iio：adc：xilinx-ams：修复事件处理中的越界通道查找 当找不到匹配的scan_index时，ams_event_to_channel（） 可能会返回超过 dev->channels 末尾的指针。这可导致 ams_handle_event（） 中的无效内存访问。在 ams_event_to_channel（） 中添加边界检查，在找不到通道时返回 NULL。同时保护调用程序以安全处理此情况。（CVE-2026-72480）

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

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

  - net：ip6_vti：需要设备 netns 中的CAP_NET_ADMIN，以便 changelink vti6_changelink（） 最多在两个 netn 上操作，即 dev_net（dev） 和隧道链接 netns t->net。当设备创建或移动到运行请求的 netns 以外的 netns 中时，它们会有所不同。rtnl changelink 路径仅针对 dev_net（dev） 检查CAP_NET_ADMIN，因此拥有该处特权但不在 t->net 中的调用方可重写 t->net 中的隧道。在解析任何属性之前，在其顶部的 rtnl_dev_link_net_capable（） 上对 vti6_changelink（） 进行门禁。（CVE-2026-72055）

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

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

  - apparmor：aa_label_alloc在分配失败时使用 aa_label_free aa_label_alloc（） 会在分配或采用标签代理之前分配 secid。如果后续代理步骤失败，错误路径仅释放标签内存，从而泄露所有由 aa_label_init（） 初始化的资源。在故障路径上使用 aa_label_free（），以便在释放后备存储器之前，部分初始化的标签释放其 secid 和其他标签资源。（CVE-2026-72459）

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

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

  - SUNRPC：在 TLS connect_worker上固定上rpc_clnt TLS 连接路径存在释放后使用：
    没有什么能将上rpc_clnt固定在延迟的connect_worker上。xs_connect（） 将 task->tk_client 作为原始指针存储在 sock_xprt：：clnt 中，并将工作线程排队;对于以 TLS 保护的传输，该工作线程为 xs_tcp_tls_setup_socket（），它会从保存的指针（cl_timeout、cl_program、cl_prog、cl_vers、cl_cred cl_stats）中读取多个字段，以构造内部握手rpc_clnt的参数。xprt 不引用rpc_clnt;rpc_clnt引用 XPRT。xs_destroy（） 会取消connect_worker，但它仅在 xprt 的 refcount 降至零时运行，这在 rpc_clnt 释放其在 rpc_free_client_work（） 中的cl_xprt引用之前不会发生。当 TLS 握手严重失败时（例如，客户端证书与服务器不匹配的 mTLS 挂载），连接任务将通过 -EACCES 唤醒并退出，挂载调用程序调用 rpc_shutdown_client（），并在排队的connect_worker触发前释放上rpc_clnt。据 Michael Nemanov 报告，xs_tcp_tls_setup_socket（） 然后取消引用释放的 clnt，从而产生refcount_t下溢。通过新的 rpc_hold_client（） 帮助程序对 xs_connect（） 中用于 TLS 传输的上rpc_clnt进行引用，并使用 rpc_release_client（） 将其放入connect_worker的退出路径中。、xprt_lock_connect（） / xprt_unlock_connect（） 配对已经将 xs_connect（） 与 xs_tcp_tls_setup_socket（） 序列化，因此获取和释放是一对一平衡的。非 TLS 连接工作线程 （xs_tcp_setup_socket） 从不读取 sock_xprt：：clnt，因此请不考虑该路径并避免 clnt-holds-xprt-holds-clnt 本应阻止 xprt 销毁的循环。（CVE-2026-72317）

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

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

  - 已修复 Linux 内核中的下列漏洞：s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption.
    Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes. (CVE-2026-72412)

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: s390: Fix unlikely race in try_get_locked_pte() Fix an unlikely race in try_get_locked_pte(), which could have happened if puds or pmds get unmapped between the p?dp_get() and p?d_offset() functions. (CVE-2026-72291)

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

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

  - ocfs2：拒绝短于群集的 FITRIM 范围 ocfs2_trim_mainbm（） 修剪群集单位的全局位图，但其过短的范围验证仅检查 sb->s_blocksize。在群集大小大于区块大小的文件系统上，接受至少为一个区块但小于一个群集的 FITRIM 范围，然后下移至 len == 0。较晚的开始 + len - 1 和 len -= ...然后算术下溢并可驱动修剪超出请求的范围。拒绝短于 s_clustersize 的范围。这为甚至不能丢弃一个分配单元的请求保留了现有的 -EINVAL 行为，并将零集群修剪排除在组遍历之外。（CVE-2026-74349）

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

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

  - configfs：修复 ->s_children 的无锁遍历 锁定父目录可防止条目被其他线程删除，但 *不能* 保护光标被 lseek（） 移动 - 或就此而言被释放。（CVE-2026-74330）

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

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

  - binder：缓存 secctx 大小，然后再发布将其归零 binder_transaction（） 用 sg_buf_end_offset 界定分散-收集缓冲区区域并减去对齐的 LSM 上下文大小，因为 secctx 写入该区域的末尾。减法显示为 lsmctx.len，但该行运行时已清除该字段：security_secid_to_secctx（secid， &lsmctx） /* lsmctx.len set */ lsmctx_aligned_size = ALIGN（lsmctx.len， sizeof（u64）） extra_buffers_size += lsmctx_aligned_size ...
    security_release_secctx（&lsmctx） /* memset 零长度 */ ...sg_buf_end_offset = sg_buf_offset + extra_buffers_size - ALIGN（lsmctx.len， sizeof（u64）） /* ALIGN（0,8） */ security_release_secctx（） does memset（cp， 0， sizeof（*cp）），因此 lsmctx.len 回读为 0，减法没有任何贡献，使得sg_buf_end_offset因每笔交易对 txn_security_ctx 节点的对齐 secctx 大小而太大。
    然后，每个 BINDER_TYPE_PTR 对象派生 buf_left = sg_buf_end_offset - sg_buf_offset 作为其副本的唯一上限，因此膨胀的末端偏移量使副本运行到已经持有 secctx 的字节中。因此，必须在释放前缓存对齐后的大小，而不是从现已清除的字段重新读取。通过在首次计算时将其缓存在函数范围内的lsmctx_aligned_size并减去lsmctx_aligned_size而不是在释放之后重新读取 lsmctx.len 来修复。将相同的值重复用于之前的buf_offset计算。（CVE-2026-68458）

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

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

  - mtd：rawnand：lpc32xx_slc：完成超时时 DMA 传输失败 lpc32xx_xmit_dma（） 等待 DMA 完成回调但忽略 wait_for_completion_timeout（）。超时 DMA 传输因此会取消映射，并成功报告为 NAND 读取/写入路径。当完成等待到期时返回 -ETIMEDOUT。在取消映射 scatterlist 之前终止 DMA 通道，以便超时传输在返回错误后无法继续访问缓冲区。（CVE-2026-68466）

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

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

  - rxrpc：修复 rxrpc_recvmsg（） 中潜在的无限循环 修复 rxrpc_recvmsg（） 中的等待 还需检查 oob 队列。（CVE-2026-74431）

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

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

  - netfilter：nf_conntrack_reasm：IPv6 磁盘碎片整理后的保护mac_header调整 nf_ct_frag6_reasm（） 将数据包头向前滑动以丢弃 IPv6 片段标头，然后无条件推进 skb->mac_header：skb->mac_header += sizeof（struct frag_hdr）;在 NF_INET_LOCAL_OUT defrag 路径上，skb 尚未有链路层标头，因此 skb->mac_header 仍为未设置的 sentinel （u16）~0U。添加 sizeof（struct frag_hdr） 会将其封装为较小的值 （0xffff + 8 == 7），之后 skb_mac_header_was_set（） 会错误地报告存在 MAC 标头，且 skb_mac_header（） 指向余量。自引入以来，重组器就已经进行了这种无条件的添加;mac_header 是裸指针时无害，但一旦mac_header成为 u16 偏移量，其未设置状态是 skb_mac_header_was_set（） 测试的 ~0U 哨兵，它就出错了。同级 net/ipv6/reassembly.c 执行相同的重定位并保护调整;镜像这里的守卫。（CVE-2026-72250）

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

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

  - tpm：tpm2-sessions：在不安装完成回调的情况下，在 drivers/char/tpm/tpm2-sessions.c 调用 crypto_kpp_generate_public_key（） 和 crypto_kpp_compute_shared_secret（） 中等待 tpm_buf_append_salt tpm_buf_append_salt（） 中的异步 KPP 完成，丢弃两个返回值，并立即通过 kpp_request_free（） 释放kpp_request。当解析的 ecdh-nist-p256 KPP 后端为异步时 （atmel-ecc， HPRE， keembay-ocs），任一操作都返回 -EINPROGRESS，且延迟完成工作线程将取消引用已释放的请求。路径在每次熵轮询时通过 tpm_get_random -> tpm2_get_random -> tpm2_start_auth_session -> tpm_buf_append_salt 从hwrng_fillfn内核线程自动触发，无需任何 userland 操作。安装 crypto_req_done 作为完成回调，在 crypto_wait_req（） 中封装两个 KPP 操作，并将错误传播给调用程序。对于同步后端来说，等待是无操作的。（CVE-2026-72151）

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

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

  - websocket-driver 是具有可插拔 I/O 的 WebSocket 协议处理程序。在之前 0.8.2版本的 WebSocket：:D river.server（） 未捕获 URI：：InvalidURIError 的情况下，将畸形主机标头传递到 lib/websocket/http/request.rb 中的 URI.parse，从而允许远程客户端在应用程序未捕获来自 parse（） 的错误时造成 TCP 支持的 WebSocket 服务器崩溃。此问题已在 0.8.2 版本中修复。
    (CVE-2026-61666)

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

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

  - 已修复 Linux 内核中的下列漏洞：gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo):
    header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows:
    coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing. (CVE-2026-72046)

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

ID	名称	严重性
337421	Linux Distros 未修补的漏洞：CVE-2026-72460	high
337420	Linux Distros 未修补的漏洞：CVE-2026-74343	high
337419	Linux Distros 未修补的漏洞：CVE-2026-74323	high
337418	Linux Distros 未修补的漏洞：CVE-2026-72020	critical
337417	Linux Distros 未修补的漏洞：CVE-2026-72194	critical
337416	Linux Distros 未修补的漏洞：CVE-2026-68472	high
337415	Linux Distros 未修补的漏洞：CVE-2026-74287	critical
337414	Linux Distros 未修补的漏洞：CVE-2026-72137	critical
337413	Linux Distros 未修补的漏洞：CVE-2026-74430	high
337412	Linux Distros 未修补的漏洞：CVE-2026-74371	high
337411	Linux Distros 未修补的漏洞：CVE-2026-72141	high
337409	Linux Distros 未修补的漏洞：CVE-2026-72277	critical
337408	Linux Distros 未修补的漏洞：CVE-2026-72331	high
337407	Linux Distros 未修补的漏洞：CVE-2026-72049	high
337406	Linux Distros 未修补的漏洞：CVE-2026-72034	high
337405	Linux Distros 未修补的漏洞：CVE-2026-74340	high
337404	Linux Distros 未修补的漏洞：CVE-2026-72029	high
337403	Linux Distros 未修补的漏洞：CVE-2026-74328	high
337402	Linux Distros 未修补的漏洞：CVE-2026-74433	critical
337401	Linux Distros 未修补的漏洞：CVE-2026-62982	high
337400	Linux Distros 未修补的漏洞：CVE-2026-74312	high
337399	Linux Distros 未修补的漏洞：CVE-2026-72433	high
337398	Linux Distros 未修补的漏洞：CVE-2026-68473	high
337397	Linux Distros 未修补的漏洞：CVE-2026-72300	medium
337396	Linux Distros 未修补的漏洞：CVE-2026-72287	high
337395	Linux Distros 未修补的漏洞：CVE-2026-74267	critical
337394	Linux Distros 未修补的漏洞：CVE-2026-72234	critical
337393	Linux Distros 未修补的漏洞：CVE-2026-72418	high
337392	Linux Distros 未修补的漏洞：CVE-2026-72406	high
337391	Linux Distros 未修补的漏洞：CVE-2026-74396	high
337390	Linux Distros 未修补的漏洞：CVE-2026-72319	critical
337389	Linux Distros 未修补的漏洞：CVE-2026-72371	high
337388	Linux Distros 未修补的漏洞：CVE-2026-72350	high
337387	Linux Distros 未修补的漏洞：CVE-2026-72310	high
337386	Linux Distros 未修补的漏洞：CVE-2026-72249	critical
337385	Linux Distros 未修补的漏洞：CVE-2026-72480	high
337384	Linux Distros 未修补的漏洞：CVE-2026-72055	high
337383	Linux Distros 未修补的漏洞：CVE-2026-72459	high
337382	Linux Distros 未修补的漏洞：CVE-2026-72317	critical
337381	Linux Distros 未修补的漏洞：CVE-2026-72412	critical
337380	Linux Distros 未修补的漏洞：CVE-2026-72291	critical
337379	Linux Distros 未修补的漏洞：CVE-2026-74349	high
337378	Linux Distros 未修补的漏洞：CVE-2026-74330	high
337377	Linux Distros 未修补的漏洞：CVE-2026-68458	high
337376	Linux Distros 未修补的漏洞：CVE-2026-68466	high
337375	Linux Distros 未修补的漏洞：CVE-2026-74431	high
337374	Linux Distros 未修补的漏洞：CVE-2026-72250	high
337373	Linux Distros 未修补的漏洞：CVE-2026-72151	high
337372	Linux Distros 未修补的漏洞：CVE-2026-61666	high
337371	Linux Distros 未修补的漏洞：CVE-2026-72046	critical

检测

Nessus 的 Misc. 系列

high

high

high

critical

critical

high

critical

critical

high

high

high

critical

high

high

high

high

high

high

critical

high

high

high

high

medium

high

critical

critical

high

high

high

critical

high

high

high

critical

high

high

high

critical

critical

critical

high

high

high

high

high

high

high

high

critical