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

  - USB：serial：io_ti：修复 build_i2c_fw_hdr（） 中的堆溢出 build_i2c_fw_hdr（） 分配固定大小的缓冲区（16*1024 - 512） + sizeof（struct ti_i2c_firmware_rec） 字节，然后将 le16_to_cpu（img_header->Length） 字节复制到其中，但未验证 Length 是否适合固件记录标头后的可用空间。img_header->Length 是固件文件的__le16，最高可达 65535。check_fw_sanity（） 验证总固件大小，但未专门验证 img_header->Length。
    通过拒绝 img_header->Length 超出可用目标空间的图像修复。（CVE-2026-53195）

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

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

  - iommu：修复由于重置 In 导致的 __iommu_group_set_domain_nofail（） 中的WARN_ON
    __iommu_group_set_domain_internal（），当组中的任何设备正在恢复时，并发域附件将被拒绝。这是将并发附件屏蔽到多设备组的必要条件，因为 PCI DMA 别名 quirk 导致设备可能共享相同的 RID，但WARN_ON会触发
    __iommu_group_set_domain_nofail（）。不应拒绝分离/拆卸路径中的其他 IOMMU_SET_DOMAIN_MUST_SUCCEED 调用程序，例如 __iommu_group_set_core_domain 和 __iommu_release_dma_ownership，因为当 group->domain 仍指向域时，域无论如何都会在这些 nofail 路径中释放。因此，pci_dev_reset_iommu_done（） 可在重新附加 group->domain 时触发 UAF。遵从 IOMMU_SET_DOMAIN_MUST_SUCCEED 标记，允许调用程序通过群组>recovery_cnt围栏，从而更新群组>域指针。而是在设备迭代循环中添加 gdev->blocked 检查，以防止任何并发的每设备分离。（CVE-2026-52952）

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

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

  - netfilter：nft_fib：修复通过 OIFNAME 寄存器发生的过时堆栈泄漏 对于NFT_FIB_RESULT_OIFNAME目标寄存器声明为 len = IFNAMSIZ（四个 32 位寄存器），但在 lookup-fail、RTN_LOCAL 和 oif-mismatch 路径上 nft_fib{4,6}_eval（） 仅通过 *dest = 0 写入一个寄存器。其余三个寄存器保留为 nft_do_chain（） 结构nft_regs中堆栈上的任何内容，加载寄存器范围的下游表达式可将未初始化的内核堆栈泄露给用户空间。
    NFTA_FIB_F_PRESENT存在性检查具有相同的形状：它仅对NFT_FIB_RESULT_OIF有意义，但任何结果类型都会接受它，而 eval 通过 nft_reg_store8（） 存储单个字节，从而使声明的 span 的其余部分过时。同时修复这两个问题：- 将 eval 中的裸 *dest = 0 替换为 nft_fib_store_result（），这样会为 OIFNAME strscpy_pad（） 整个 IFNAMSIZ（并且已在另一个早期返回路径中使用），以及 - 将NFTA_FIB_F_PRESENT限制为NFT_FIB_RESULT_OIF，并将其目标声明为单个 u8，这样标记的范围与 eval 写入的一个字节相匹配。（CVE-2026-53134）

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

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

  - net：bcmgenet：修复泄漏的free_bds 回收 tx 队列时，我们快进写入指针以丢弃任何传输中的数据。这些丢弃的帧不会加回空闲 bd 池。我们还需要告知 netdev 我们将丢弃所述数据。（CVE-2026-53087）

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

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

  - ima_fs：为不受支持的哈希算法正确创建 securityfs 文件 ima_tpm_chip->allocated_banks[i].crypto_id 会在 TPM 算法不受支持时初始化为HASH_ALGO__LAST。但是，有些地方依赖算法是有效的，因为它是由 访问的 hash_algo_name[]。在 hash_algo_name 中 6.12.40 观察到以下读取越界：
    ================================================================== 缺陷：KASAN：在 create_securityfs_measurement_lists+0x396/0x440 中的全局越界 在地址 ffffffff83e18138 读取的大小为 8 按任务 swapper/0/1 CPU：4 UID：0 PID：1 通信：swapper/0 未受感染 6.12.40 #3 调用跟踪： <TASK> dump_stack_lvl+0x61/0x90 print_report+0xc4/0x580 ？ kasan_addr_to_slab+0x26/0x80 ？ create_securityfs_measurement_lists+0x396/0x440 kasan_report+0xc2/0x100 ？ create_securityfs_measurement_lists+0x396/0x440create_securityfs_measurement_lists+0x396/0x440 ima_fs_init+0xa3/0x300 ima_init+0x7d/0xd0 init_ima+0x28/0x100 do_one_initcall+0xa6/0x3e0 kernel_init_freeable+0x455/0x740 kernel_init+0x24/0x1d0 ret_from_fork+0x38/0x80 ret_from_fork_asm+0x11/0x20 </TASK> 有缺陷的地址属于变量： hash_algo_name+0xb8/0x420 有缺陷地址周围的内存状态： ffffffff83e18000： 00 01 f9 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 ffffffff83e18080： 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff83 e18100： 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9 ^ ffffffff83e18180： f9 f9 f9 f9 00 00 00 00 00 00 04 f9 f9 f9 f9 ffffffff83e18200： 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 ================================================================== TPM 芯片似乎支持 sha3_256，但尚未tpm_algorithms：TPM TPM0：具有不受支持的 bank 算法的 TPM 0x0027 这就是 TPM_ALG_SHA3_256 == 0x0027来自受信任平台模块 2.0 库第 2 部分：结构，第 51 页 [1]。另请参阅相关的 U-Boot 算法更新 [2]。因此，通过使用
    如果 crypto 算法未初始化，则_tpm_alg_<ID> postfix。测试机器上的外观如下（修补程序移植到 v6.12 版本）：# ls -1 /sys/kernel/security/ima/ ascii_runtime_measurements ascii_runtime_measurements_tpm_alg_27 ascii_runtime_measurements_sha1 ascii_runtime_measurements_sha256 binary_runtime_measurements binary_runtime_measurements_tpm_alg_27 binary_runtime_measurements_sha1 binary_runtime_measurements_sha256策略runtime_measurements_count违规 [1]：
    https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf [2]： https://lists.denx.de/pipermail/u-boot/2024-July/558835.html(CVE-2026-53038）

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

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

  - drm/v3d：修复间接 CSD 将工作组归零时的 vaddr 泄漏 v3d_rewrite_csd_job_wg_counts_from_indirect（） 映射间接缓冲区和工作组缓冲区，并预期在返回前将其释放。当从缓冲区读取的任何工作组计数为零时，该函数会提早退出并跳过清除，从而泄漏两个 BO 的 vaddr 映射。跳转到清理路径而非直接返回，因此映射一律丢失。（CVE-2026-53140）

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

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

  - net/sched：sch_dualpi2：dualpi2_change（） 中的 C 队列和 L 队列都耗尽 修复 dualpi2_change（） 以在 dualpi2 qdisc 的配置变更后正确执行更新后的限制和 memlimit 值。
    安装此修补程序之前，dualpi2_change（） 在减少积压或内存使用时，始终尝试通过根 qdisc（C 队列）将数据包出列，并且无条件假设将返回有效的 skb。当流量分类导致数据包在 L 队列中排队而 C 队列为空时，这会导致限制或内存限制强制执行期间发生空 skb 取消引用。如果 C 队列路径为非空，可先从 C 队列路径中出队修复此问题。一旦 C 队列为空，数据包将直接从 L 队列出列。针对两个队列检查来自 qdisc_dequeue_internal（） 的返回值。从 L 队列出队时，父 qdisc、qlen 和 backlog 计数器会明确更新，以保持总体 qdisc 统计数据的一致性。（CVE-2026-52997）

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

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

  - ptp：ocp：修复资源释放顺序 提交 a60fc3294a37（ptp：重做 ptp_clock_unregister（） 以禁用事件） 添加对 ptp_disable_all_events（） 的调用，用于更改引脚配置（如果它们支持 EXTTS 事件）。在 ptp_ocp_detach（） 引脚中，资源在 ptp_clock_unregister（） 之前释放，这会导致删除驱动程序期间的释放后使用。通过更改释放/取消注册调用的顺序修复此问题。若要避免 ptp 设备取消注册时其他核心上运行 irq 处理程序，请在 HW 配置为停止产生 irq，且没有 irq 正在传输后，调用 synchronize_irq（）。（CVE-2026-53222）

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

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

  - netlabel：验证未标记的地址和掩码属性长度 netlbl_unlabel_addrinfo_get（） 使用地址属性长度来确定属性数据是否可读取为 IPv4 或 IPv6 地址，但未独立验证相应的掩码属性长度。因此，构建的通用 Netlink 请求可提供含有较短掩码属性的有效 IPv4/IPv6 地址属性，其稍后会作为完整 struct in_addr或 struct in6_addr 读取。默认情况下，NLA_BINARY策略长度为最大长度，因此请将 NLA_POLICY_EXACT_LEN（） 用于未标记的 IPv4/IPv6 地址和掩码属性。
    这样会在策略验证期间拒绝短属性，还会通过策略自检暴露确切的长度要求。（CVE-2026-53238）

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

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

  - ice：修复 ice_reset_all_vfs（） 中的空指针取消引用 ice_reset_all_vfs（） 忽略 ice_vf_rebuild_vsi（） 的返回值。当 VSI 重建失败时（例如通过 nvmupdate64e 进行 NVM 固件更新期间），ice_vsi_rebuild（） 会破坏其错误路径上的 VSI，将txq_map和rxq_map保留为空。后续对 ice_vf_post_vsi_rebuild（） 的无条件调用会导致访问 vsi->txq_map[0] 时 ice_ena_vf_q_mappings（） 中出现空指针取消引用。ice_reset_vf（） 中的 single-VF 重置路径已通过检查 ice_vf_reconfig_vsi（） 的返回值并在失败时跳过 ice_vf_post_vsi_rebuild（））来正确处理此情况。将相同的模式应用于 ice_reset_all_vfs（）：检查 ice_vf_rebuild_vsi（） 的返回值并在失败时跳过 ice_vf_post_vsi_rebuild（） 和 ice_eswitch_attach_vf（）。
    VF 处于安全禁用状态（ICE_VF_STATE_INIT未设置，VFGEN_RSTAT未设置为 VFACTIVE），可通过由 VF 的 PCI 重置（sysfs 重置或驱动程序重新绑定）触发的 VFLR 恢复。请注意，此修补程序无法防止 VF VSI 重建在 NVM 更新期间失败，根本原因是处理 EMP 重置时固件处于过渡状态，这可造成 Admin 队列命令（ice_add_vsi、ice_cfg_vsi_lan）失败。此修补程序仅阻止在重建失败时造成内核崩溃的后续空指针取消引用。crash> bt PID：50795 TASK：
    ff34c9ee708dc680 CPU：1 个命令：kworker/u512：5 [ff72159bcfe5bb50] ffffffffaa8850ee #1 的machine_kexec [ff72159bcfe5bba8] fffffffaaa15fba #2 的__crash_kexec [ff72159bcfe5bc68] ffffffffaaa16540 #3 的crash_kexec [ff72159bcfe5bc70] ffffffffaa837eda #4 的oops_end [ff72159bcfe5bc90] fffffffffaa893997 #5 的page_fault_oops [ff72159bcfe5bce8] ffffffffab528595 #6 exc_page_fault #0[ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2 [异常 RIP： ice_ena_vf_q_mappings+0x79] RIP： ffffffffc0a85b29 RSP： ff72159bcfe5bdc8 RFLAGS： 00010206 RAX： 00000000000f0000 RBX： ff34c9efc9c00000 RCX： 000000000000000 RDX： 00000000000000000 RSI： 0000000000000010 RDI： ff34c9efc9c00000 RBP： ff34c9efc27d4828 R8：
    0000000000000093 R9： 0000000000000040 R10： ff34c9efc27d4828 R11： 0000000000000040 R12： 0000000000100000 R13： 0000000000000010 R14： R15： ORIG_RAX： ffffffffffff CS： 0010 SS： 0018 #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice] #8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice] #9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice] #10 [ff72159bcfe5be88] process_one_work at fffffffffaa93dca4 #11 [ff72159bcfe5bec8] 在 fffffffffaa93e9de #12 worker_thread [ff72159bcfe5bf18] kthread 在 ffffffffaa946663 #13 [ff72159bcfe5bf50] 在 fffffffffaa8086b9 ret_from_fork 尝试取消引用 RDX 中 ice_sriov.c：294 的空指针时发生错误，这会加载 vsi->txq_map（ice_vsi 中的偏移0x4b8）。错误 VSI 是分配的 slab 对象，但在失败的 ice_vsi_rebuild（） 后未完全初始化：崩溃>结构ice_vsi 0xff34c9efc27d4828 netdev = 0x0、rx_rings = 0x0、tx_rings = 0x0、q_vectors = 0x0、txq_map = 0x0、rxq_map = 0x0、alloc_txq = 0x10、num_txq = 0x10、alloc_rxq = 0x10、num_rxq = 0x10、 nvmupdate64e 进程正在执行 NVM 固件更新：
    crash> bt 0xff34c9edd1a30000 PID： 49858 TASK： ff34c9edd1a30000 CPU： 1 COMMAND： nvmupdate64e #0 [ff72159bcd617618] 在 ffffffffab5333f8 #4 __schedule [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice] #5 [ff72159bcd6177a8] 在 ffffffffc0a35b47 ice_sq_send_cmd_retry [ice] #6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice] #7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice] #8 ---truncated--- （CVE-2026-53289）

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

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

  - um：修复 TLB 同步中潜在的争用条件在 TLB 同步过程中，我们需要遍历和修改页表，因此应保持页表锁定。由于仍然缺少对同一进程内线程的完整 SMP 支持，所以为简单起见，我们还是禁用拆分页表锁定。（CVE-2026-53020）

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

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

  - net：phy：使用 genphy 时，不尝试设置 PHY 驱动的 SFP 保护架。我们不支持使用 genphy 代码的 PHY 驱动程序 SFP 保护架。最重要的是，sashiko 发现运行 sfp_bus_add_upstream（） 以解决 genphy 死锁，至于 genphy，PHY 探测在 RTNL 下运行，而非 genphy 驱动程序则并非如此。再现了此问题，并且确实导致了 RTNL 上的死锁。在受到指责的提交之前，phy_sfp_probe（） 调用是由单个 PHY 驱动程序发出的，因此在使用 genphy 时无法进入 SFP 探测路径。因此，我们仅在不使用 genphy 时运行phy_sfp_probe。
    (CVE-2026-53231)

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

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

  - drm/gem：尝试修复 change_handle ioctl，尝试 4 [airlied：刚刚添加了一些关于如何重新启用的评论] 在列表中，因为猫已经出袋子了，我们显然不够好，无法私下解决这个问题。
    到目前为止的故事：5e28b7b94408（drm：在 change_handle 中的 prime 交换前将旧句柄设置为空）尝试修复 gem_close 和 gem_change_handle ioctl 之间的争用条件，但做错了一些事情：- 与本地变量句柄（实际上是新句柄）之间存在混淆，因此两阶段技巧实际上应用于错误的 idr 槽。7164d78559b0 （drm/gem：修复 change_handle 和 handle_delete 之间的争用）尝试通过添加另一个代码块来修复该问题，但忘记添加错误处理。这意味着我们现在有两条路，都有点错误。- dc366607c41c （drm：将旧指针替换为新 idr）尝试应用另一个补丁，但不一致，同样是因为句柄混淆 - 如果我们对新句柄采取两阶段方法，这将是正确的补丁（有点，有点，一团糟）。只不过这不是原始修复的意图。我们也没有为原始 ioctl 合并 igt，这是一个很大的禁忌。此问题曾尝试解决原始缺陷补丁中的不在列表中的问题，而 amd QA 人员声称该缺陷现已修复。很明显，事实并非如此。这是我试图解决这个问题的尝试：- 将本地变量重命名为 new_handle，使用 args->handle 的旧别名太危险了，令人困惑。- 将 gem obj 查找与两阶段idr_replace合并，以避免在那里混淆。- 这意味着我们不再有剩余的临时引用，只有从 idr 继承的引用。new_handle上的并发gem_close可窃取这一点。使用与create_tail使用的相同的两阶段方法修复该问题。正如评论中记录的那样，这有点矫枉过正，但我也不相信我正确理解这一切的能力，所以使用我们从其他 ioctl 中建立的模式来获得最大的偏执狂。- 调整错误路径。我已尝试使错误和成功路径通用，因为它们是相同的，只是删除了哪个句柄以及我们调用 idr_replace 再次（重新）安装对象。但这让事情读起来更混乱，所以我把它保留在更冗长的版本中，不幸的是，这稍微隐藏了整个代码流中的对称性。- 同时，将 7 个空格缩进替换为 1 个制表符。最后，因为我完全不再相信我在这里的能力：- 禁用 ioctl，直到我们得到 igt 情况，并在列表中解决其他所有内容并获得完全共识。v2：Sashiko 注意到我没有正确处理 idr_replace 的错误路径，必须像 gem_handle_delete 中一样用IS_ERR_OR_NULL进行检查。所以，是的，绝对应该只使用 1:1 现有的路径，因为这是无穷无尽的棘手。还为原始 ioctl 添加了 Fixes： 行，我也忘记了。（CVE-2026-53145）

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

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

  - 攻击者可能可以通过发送包含无效 DATA 帧的 DoH3 GET 查询来延迟对 DoH3 查询的处理。（CVE-2026-40208）

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

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

  - xfrm：policy：修复 xfrm_policy_bysel_ctx（） 中不准确的 bin 上的释放后使用 通过在仍按住 bin 的同时删除 bin 之前对其进行修剪修复争用xfrm_policy_lock。直接使用 __xfrm_policy_inexact_prune_bin（），因为已持有锁。封装程序 xfrm_policy_inexact_prune_bin（） 变为未使用并被删除。
    争用： CPU0 （XFRM_MSG_DELPOLICY） CPU1 （XFRM_MSG_NEWSPDINFO） ========================== ========================== xfrm_policy_bysel_ctx（）： spin_lock_bh（xfrm_policy_lock） bin = xfrm_policy_inexact_lookup（） __xfrm_policy_unlink（pol） spin_unlock_bh（xfrm_policy_lock） xfrm_policy_kill（ret） // 宽窗口，未保留锁定 xfrm_hash_rebuild（）： spin_lock_bh（xfrm_policy_lock）
    __xfrm_policy_inexact_flush（）： kfree_rcu（bin） // 已释放 bin spin_unlock_bh（xfrm_policy_lock） xfrm_policy_inexact_prune_bin（bin） // UAF：已释放 bin （CVE-2026-53239）

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

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

  - fs/ntfs3：防止零长度造成的未初始化 LCN syzbot 报告了 ntfs_iomap_begin 中的一个 uninit-value [1]。由于尚未触及 runs，run_lookup_entry（） 会立即失败并返回 false，进而使 *len 的值为 0。同时，新值和 err 值也是 0，导致 attr_data_get_block_locked（） 中的逻辑直接跳转到 ok，最终导致 *lcn 在设置前被触发 [1]。在 ntfs_iomap_begin（） 中，clen 中的 0 值检查前移到更新 lcn 之前，以避免此情况 [1]。[1] 缺陷：KMSAN：ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c：825 中的 uninit-value ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c：825 iomap_iter+0x9b7/0x1540 fs/iomap/iter.c：110 创建位置的本地变量 lcn 创建位置：ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c：786 （CVE-2026-53029）

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

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

  - mailbox：mailbox-test：出现探测错误时释放通道，释放之前获取的通道。
    这不仅可以防止泄漏，还可以防止 UAF 情况，因为客户端结构仍然会被删除，因为它是通过 devm 分配的。（CVE-2026-53296）

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

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

  - bpf：修复标量 regs 的 map_kptr_match_type 中的空取消引用 提交 ab6c637ad027（bpf：修复本地 kptr 的 bpf_kptr_xchg（） 问题）重构的 map_kptr_match_type（） 以在检查 base_type（） 之前在 btf_is_kernel（） 上分支）。存储在 kptr 插槽中的标量寄存器没有 btf，因此 btf_is_kernel（reg->btf） 调用取消引用 NULL。在任何 reg->btf 访问之前移动 base_type（） ！= PTR_TO_BTF_ID 防护。（CVE-2026-53032）

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

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

  - clk：spacemit：ccu_mix：修复 ccu_mix_trigger_fc（） 中的反向条件 修复跳过频率变更触发器的反向情况，该情况会在 cpufreq 扩展期间造成内核错误。（CVE-2026-53019）

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

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

  - drm/xe/dma-buf：修复具有重试循环的 UAF 重试在此处不起作用，因为出错时将释放 bo，从而导致 UAF。但是，现在我们在附加之前进行了 alloc 和 init，我们现在可以将其合并为一个单元，并让 init 为我们进行分配。这应该可以保证重试安全。此问题由 Sashiko 报告。v2：修复错误展开 （CI）（从提交 479669418253e0f27f8cf5db01a731352ea592e7 中精选出的内容）（CVE-2026-52950）

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

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

  - IB/isert：拒绝短于 ISER_HEADERS_LEN 的登录 PDU 在 drivers/infiniband/ulp/isert/ib_isert.c 中，isert_login_recv_done（） 将登录请求负载长度计算为 wc->byte_len减去无下界的ISER_HEADERS_LEN，并且login_req_len为已签名 int。远程 iSER 发起程序可发布登录发送工作请求，其中包含少于 ISER_HEADERS_LEN (76) 的字节数，因此减法会下溢，login_req_len 会变为负数。然后 isert_rx_login_req() 将该负长度读回有符号的 int，采用 min(rx_buflen, MAX_KEY_VALUE_PAIRS)，且由于 min() 是有符号的，所以它保留了负值；然后，该值作为 memcpy() 长度传递，并符号扩展至数 GB 的 size_t。复制到 8192 字节的 login->req_buf 的运行大幅越界且存在错误，会导致目标节点崩溃。登录阶段先于进行 iSCSI 身份验证，因此无需任何凭据即可访问此路径。拒绝任何在减法前短于 ISER_HEADERS_LEN 的登录 PDU，以反映工作完成失败时的现有提前返回，从而使 login_req_len 永远不会变为负数。上边界是安全的：已发布的登录缓冲区不能提供超过 ISER_RX_PAYLOAD_SIZE 的大小，因此差异保持在 MAX_KEY_VALUE_PAIRS 或以下，并且现有 min() 限制了上边界；只需添加缺少的下边界即可。
    (CVE-2026-53176)

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

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

  - ALSA： timer：关闭时强制关闭定时器实例 通过 snd_timer_free（） 释放snd_timer对象且仍待定 snd_timer_instance 对象已分配给定时器对象时，它会尝试取消链接所有实例并仅为每个 ti->timer 设置 NULL，然后立即释放资源。但是，问题在于，当存在与链接到此定时器的主实例相关联的从属定时器实例时：也就是说，尽管主实例未链接，这些从属实例仍然指向已释放的定时器对象，这可能导致释放后使用。尤其当涉及新的用户空间驱动的定时器 （CONFIG_SND_UTIMER） 时，可轻易触发此错误，因为它可通过简单的文件打开/关闭创建并删除定时器对象，而其他应用程序可能继续访问该定时器。此修补程序试图弥补上述问题：现在不再只是断开链接，而是对每个待定的定时器实例强制调用 snd_timer_close[_locked]（），以便也正确分离所有已分配的从属定时器实例。由于创建该实例的驱动程序稍后可能会调用 snd_timer_close（），因此也会在开头添加SNDRV_TIMER_IFLG_DEAD检查。（CVE-2026-53193）

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

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

  - Bluetooth：MGMT：在类型检查之前验证广告 TLV tlv_data_is_valid（） 从 data[i] 读取每个广告数据字段长度，然后检查受管理 EIR 类型的 data[i + 1]，然后检查当前字段是否仍适合提供的缓冲区内。因此，长度字节为缓冲区最后一个字节的畸形字段可使解析器读取超出公告数据的一个字节。当畸形的 MGMT_OP_ADD_ADVERTISING 请求到达该路径时，KASAN 报告以下内容：缺陷：KASAN：大小为 1 的 tlv_data_is_valid（） 读取中的 vmalloc-out-of-bound 调用跟踪：tlv_data_is_valid（） add_advertising（） hci_mgmt_cmd（） hci_sock_sendmsg（） 在任何 type-octet 检查之前移动现有的 element-length 检查，以便在解析器查看 data[i + 1] 之前，证明每个非空元素都包含其类型字节。
    (CVE-2026-53255)

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

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

  - mm/memory-failure：修复 get_huge_page_for_hwpoison 中的 hugetlb_lock AA 死锁 当与并发取消映射 thread#0 thread#1 争用时，同一 hugetlb 页面上的两个并行 madvise（MADV_HWPOISON） 调用可在 hugetlb_lock 上触发递归旋转锁自死锁（AA 死锁）： -------- -------- madvise（folio， MADV_HWPOISON） -> 成功毒化作品集 madvise（folio， MADV_HWPOISON） unmap（folio） try_memory_failure_hugetlb get_huge_page_for_hwpoison spin_lock_irq（&hugetlb_lock） <- held
    __get_huge_page_for_hwpoison hugetlb_update_hwpoison（） -> MF_HUGETLB_FOLIO_PRE_POISONED goto out：
    folio_put（） refcount：1 -> 0 free_huge_folio（） spin_lock_irqsave（&hugetlb_lock） -> AA 死锁！出局：
    __get_huge_page_for_hwpoison（） 中的路径会在 hugetlb.c 封装程序 get_huge_page_for_hwpoison（） 仍然持有 hugetlb_lock 时，调用 folio_put） 丢弃 GUP 引用。如果并发取消映射已释放页表映射引用，则 folio_put（） 会将 folio refcount 降至零，从而触发尝试重新获取非递归hugetlb_lock的 free_huge_folio（）。通过将 hugetlb_lock 采集从 hugetlb.c 封装程序移动到 get_huge_page_for_hwpoison（） 来修复此问题。将 spin_unlock_irq（） 放在 out： 标签的 folio_put（） 之前，以便作品集始终在锁外释放。[akpm@linux-foundation.org：修复争用，根据 Miaohe 重命名标签]（CVE-2026-53207）

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

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

  - drm/amd/display：将 VBIOS HDMI 重定时器寄存器计数限制为数组大小 [原因和方式] VBIOS 集成信息表（v1_11 和 v2_1）包含 HdmiRegNum 和 Hdmi6GRegNum 字段，其用作将重定时器 I2C 寄存器设置复制到固定大小数组（dp*_ext_hdmi_reg_settings[9] 和 dp*_ext_hdmi_6g_reg_settings[3]）时的循环边界。使用前未验证这些 u8 字段，因此畸形 VBIOS 可指定多达 255 的值，从而导致驱动程序探测期间发生越界堆写入。在复制循环之前，在 get_integrated_info_v11（） 和 get_integrated_info_v2_1（） 中，使用 min_t（） 将每个寄存器计数限制到目标数组大小。（从提交 5a7f0ef90195940c54b0f5bb85b87da55f038c69 中精选出的内容）（CVE-2026-53136）

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

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

  - net：mvpp2：在 XDP 或 skb 使用之前重填 RX 缓冲区 RX 错误路径将当前描述符缓冲区返回硬件 BM 池。这仅当驱动程序仍拥有缓冲区时有效。
    mvpp2_rx_refill（） 可在将当前缓冲区传递到 XDP 或附加到 skb 后发生故障。在这些情况下，mvpp2_run_xdp（） 可能回收、重定向或排队页面以进行XDP_TX，而 skb 释放也会停用数据缓冲区。将此类缓冲区返回至 BM 可让硬件 DMA 进入不再属于 RX ring 的内存。在将当前缓冲区传递到 XDP 或 skb 之前重新填充 BM 池。如果分配失败，请丢弃数据包并将仍拥有的当前缓冲区返回给 BM，从而保留池深度。重填成功后，后续的本地丢弃会停用/释放当前缓冲区，而不是将其返回至 BM。（CVE-2026-53215）

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

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

  - 攻击者可通过 HTTP/3 查询发送构建的 DNS，触发异常，阻止立即释放某些缓冲区。缓冲区会在 QUIC 连接结束时释放，但是在某些设置上，可能会打开足够并发的 DoH3 流来触发内存不足的情况，从而导致拒绝服务。（CVE-2026-40211）

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

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

  - Bluetooth：ISO：修复不释放 iso_conn_big_sync hci_get_route（） 上通过 hci_dev_hold（） 返回引用计数的 hci_dev 指针时的 hdev 引用。该函数会正常退出，或发生错误而从未释放。（CVE-2026-53251）

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

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

  - netfilter：nft_ct：退出 get eval 中的模板 ct 我在查看历史 syzbot 报告 [1] 时注意到了这个问题。像下面的规则足以触发该缺陷：table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } 第一个表达式通过 nft_ct_set_zone_eval（） （nf_ct_tmpl_alloc -> kzalloc，元组都是零，nf_ct_l3num（ct） == 0）。然后，下一个表达式会在同一 skb 上调用 nft_ct_get_eval（），将模板视为真正的 ct，并命中 16 字节 memcpy 路径。当 dreg 处于NFT_REG32_15这会溢出内核堆栈上超过 struct nft_regs;dreg 值较小时，它会静默强制邻近寄存器重写。拒绝 eval 条目和 nft_ct_get_fast_eval（） 中的模板 ct，镜像 nft_ct_set_eval（） 已有的检查。此外，通过 priv->len 而非 nf_ct_l3num（ct） 绑定 NFT_CT_SRC/NFT_CT_DST 中的地址副本：nf_ct_get_tuple（） 在 pkt_to_tuple（） 仅填充与协议相关的前导字节之前将元组归零，因此 tuple->{src，dst}.u3.all 的结尾字节是明确定义的零。priv->len 在规则加载时进行验证，因此复制大小现在由目标寄存器限制，而不是按连接跟踪上不受信任的字段限制。[1]:
    https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c (CVE-2026-53267)

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

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

  - bpf：返回来自task_vma迭代器的 VMA 快照 当帮助程序获取依赖于 mmap_lock 的锁时，将 per-VMA 锁跨 BPF 程序主体保留会产生锁定排序问题： vm_lock -> i_rwsem -> mmap_lock -> vm_lock 通过 memcpy（） 在 _next（） 中的每个 VMA 锁定下对 VMA 进行快照，然后在返回前终止锁定。BPF 程序仅访问快照。校验器仅信任vm_mm和vm_file指针（请参阅 verifier.c 中的 BTF_TYPE_SAFE_TRUSTED_OR_NULL）。vm_file在锁定时使用 get_file（） 进行引用计数，并在下次迭代时或在 _destroy（） 中通过 fput（） 释放。vm_mm已正确，因为 lock_vma_under_rcu（） 验证 vma->vm_mm == mm。memcpy（） 会保持所有其他指针原样，因为校验器将其视为不受信任。（CVE-2026-53084）

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

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

  - 使用 SetMacAddrAction 时可能会发生越界读取，从而可导致通过网络发送未初始化的内存或崩溃。（CVE-2026-40210）

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

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

  - locking/rtmutex：等候程序未排队时跳过 remove_waiter（） syzbot 通过FUTEX_CMP_REQUEUE_PI在 remove_waiter（） 中触发了以下崩溃：KASAN：范围 [0x0000000000000a88-0x0000000000000a8f] 中的 null-ptr-deref class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c：1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0
    __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex（） 在死锁检测后未布防等候程序，从而使 waiter->task 为空，其中 3bfdc63936dd（rtmutex：在 remove_waiter（） 中使用 waiter：：task 而非当前任务）会造成此问题致命。此外，rt_mutex_start_proxy_lock（） 不应在成功获取 rtmutex 时调用 remove_waiter（）。1a1fb985f2e2（futex：正确处理早期死锁返回）将 remove_waiter（） 从 __rt_mutex_start_proxy_lock（） 中（其中“ret”仅为 0 或 < 0）移至封装程序中。加强此检查以考虑 try_to_take_rt_mutex（）。
    (CVE-2026-53163)

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

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

  - 无效区域可能通过 ZONEMD 验证，但实际上不应通过。这仅在使用 ZONEMD 验证配置了 ZoneToCache 时才有意义。（CVE-2026-42390）

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

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

  - net：openvswitch：修复可能的ERR_PTR kfree_skb 在 Fixes 标签中安装修补程序之后，回复 skb 的分配可在锁定ovs_mutex之前或之后进行。但是，错误清理仍遵循经典的反向顺序，假设在锁定前分配回复：它在解锁后释放。如果在锁定互斥体之后发生回复分配并失败，则回复将留下ERR_PTR，并且执行会跳至尝试释放无效指针的相应清理阶段。
    通过在保存指针错误值之后将指针设置为空，来修复此问题。（CVE-2026-53227）

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

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

  - misc：fastrpc：修复工作队列上下文中的fastrpc_user释放后使用 fastrpc_device_release（） 与处理 DSP 响应的工作队列之间存在争用条件。当用户关闭文件描述符时，fastrpc_device_release（） 会释放fastrpc_user结构。同时，正在运行的 DSP 调用可以通过 schedule_work（&ctx->put_work） 完成和 fastrpc_rpmsg_callback（） 计划上下文清除。如果工作队列与 fastrpc_device_release（） 释放用户结构并行或之后运行 fastrpc_context_free（），它将取消引用已释放的fastrpc_user。根据争用时的上下文状态，可命中以下任一访问权限：1.
    fastrpc_buf_free（） 在将物理地址传递到 dma_free_coherent（） 之前，会调用 fastrpc_ipa_to_dma_addr（buf->fl->cctx， ...） 从存储的 IOVA 中剥离 SID 位。2. fastrpc_free_map（） 读取 map->fl->cctx->vmperms[0].vmid 以重建 qcom_scm_assign_mem（） 调用所需的源权限位掩码，该调用将内存从 DSP VM 返回回 HLOS。3. fastrpc_free_map（） 获取 map->fl->lock 以从 fl->maps 列表中安全地删除映射节点。生成的释放后使用表现为：pc：fastrpc_buf_free+0x38/0x80 [fastrpc] lr：fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 向 fastrpc_user 添加基于 kref 的引用计数。
    让每个调用上下文在分配时对用户进行引用，并在上下文释放时将其释放。关闭文件时释放 fastrpc_device_release（） 中的初始引用。将释放待定上下文、映射、mmap 和通道上下文引用的用户结构的拆卸移动到 kref 释放回调 fastrpc_user_free（） 中，以便仅在最后一个引用丢弃时运行，而不管这是在设备关闭时还是在最终的传输上下文完成之后发生。
    (CVE-2026-53161)

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

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

  - tcp：在 reqsk_queue_hash_req（） 中添加 preempt_{disable，enable}_nested（）。syzbot 报告 __inet_csk_reqsk_queue_drop（） 中有一个异常的 reqsk->rsk_refcnt下溢。捕获的 reqsk_put（）在
    仅当从 ehash 中成功删除 reqsk 时才调用 __inet_csk_reqsk_queue_drop（）。此外，reqsk_timer_handler（） 在此之后会调用另一个 reqsk_put（）。这表示 reqsk 缺少用于 ehash 的 refcnt 和定时器本身。由于所有 syzbot 报告都已启用PREEMPT_RT，因此唯一可能的情况是 reqsk_queue_hash_req（） 在 mod_timer（） 之后和 refcount_set（） 之前被抢占，然后在 1s 后触发的计时器会因其侦听器的 close（） 而中止 reqsk。让我们用 preempt_disable_nested（） 和 preempt_enable_nested（） 来包装 mod_timer（） 和 refcount_set（）。请注意，inet_ehash_insert（） 包含正常的 spin_lock（） （PREEMPT_RT 中的互斥），因此必须在 preempt_disable_nested（） 之外调用它，但这没关系。查找路径只是忽略 ehash 中的 0 sk_refcnt条目并尝试创建另一个 reqsk，但这将在 inet_ehash_insert（） 处失败。[0]：refcount_t：下溢；释放后使用。WARNING： lib/refcount.c：28 at refcount_warn_saturate+0xb2/0x110 lib/refcount.c：28， CPU#0：
    ktimers/0/16 链接的模块：CPU：0 UID：0 PID：16 通信：ktimers/0 受感染：G L syzkaller #0 PREEMPT_{RT，（full）} 受感染：[L]=SOFTLOCKUP 硬件名称：Google Google Compute Engine/Google Compute Engine，BIOS Google 04/18/2026 RIP：0010：refcount_warn_saturate+0xb2/0x110 lib/refcount.c：28 代码：e4 7d d1 0a 67 48 0f b9 3a eb 4a e8 38 3d 23 fd 48 8d 3d e1 7d d1 0a 67 48 0f b9 3aEB 37 E8 25 3D 23 fd 48 8d 3d de 7d d1 0a <67> 48 0f b9 3a eb 24 e8 12 3d 23 fd 48 8d 3d db 7d d1 0a 67 48 0f RSP：
    0000：ffffc90000157948 EFLAGS： 00010246 RAX： ffffffff84a1301b RBX： 0000000000000003 RCX： ffff88801ca98000 RDX： 0000000000000100 RSI： 0000000000000000 RDI： ffffffff8f72ae00 RBP： ffffffff99ae3b01 R08：
    ffff88801ca98000 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880425ef568 R13: ffff8880425ef4f8 R14: ffff8880425ef578 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff888126386000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f7b46710e9c CR3： 000000000dbb6000 CR4： 000000000003526f0 调用跟踪： <TASK> __refcount_sub_and_test include/linux/refcount.h：400 [内联] __refcount_dec_and_test include/linux/refcount.h：432 [内联] refcount_dec_and_test include/linux/refcount.h：450 [内联] reqsk_put include/net/request_sock.h：136 [内联] __inet_csk_reqsk_queue_drop+0x3ce/0x440 net/ipv4/inet_connection_sock.c：1007 reqsk_timer_handler+0x651/0xdf0 net/ipv4/inet_connection_sock.c：1137 call_timer_fn+0x192/0x5e0 kernel/time/timer.c：1748 expire_timers kernel/time/timer.c：1799 [内联] __run_timers kernel/time/timer.c：2374 [内联] __run_timer_base+0x6a3/0x9f0 kernel/time/timer.c：2386 run_timer_base kernel/time/timer.c：2395 [内联] run_timer_softirq+0x67/0x170 kernel/time/timer.c：2403 handle_softirqs+0x1de/0x6d0 kernel/softirq.c：622 __do_softirq kernel/softirq.c：656 [内联] run_ktimerd+0x69/0x100 kernel/softirq.c：1151 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c：160 kthread+0x388/0x470 kernel/kthread.c：436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 </TASK> （CVE-2026-53260）

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

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

  - wifi：nl80211：拒绝超大的 EMA RNR 列表 nl80211_parse_rnr_elems（） 将解析的元素计数存储在 u8 支持的 cfg80211_rnr_elems：：cnt 字段中，并使用该计数来调整灵活数组分配的大小。
    当计数达到 255 时拒绝嵌套的 NL80211_ATTR_EMA_RNR_ELEMS 输入，然后再次增加它。
    这会使解析器与其填充的数据结构保持一致，并与 nl80211_parse_mbssid_elems（） 使用的现有边界检查匹配。（CVE-2026-53182）

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

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

  - mm/hugetlb：当 hugetlb 作品集复制路径中出错时恢复预留 mm/hugetlb.c 中的两个站点通过 alloc_hugetlb_folio（） 分配 hugetlb 作品集（消耗 VMA 预留）然后调用 copy_user_large_folio（），这在提交 1cb9dc4b475c 时变成 int-return（mm：hwpoison：支持从 HugePage 写入时复制错误恢复）并且现在可能失败（例如 hwpoisoned 源页面上的 -EHWPOISON）。在失败路径上，folio_put（） 通过 free_huge_folio（） 还原了全局 hugetlb 池计数，但每个 VMA 预留映射条目仍保持标记为已消耗：- hugetlb_mfill_atomic_pte（） 重新提交路径 （UFFDIO_COPY） - 当 hugetlb_try_dup_anon_rmap（） 失败时，copy_hugetlb_page_range（） fork-time CoW 路径（罕见：在 fork 下固定了 hugetlb 匿名作品集） 用户可见的效果： 在UFFDIO_COPY到重新提交复制失败的私有 hugetlb VMA 中，该地址的保留会从 VMA 的保留映射中泄漏。同一地址的后续错误会走无预留路径，在 hugetlb 池压力下，任务会在其先前预留的地址进行 SIGBUS。fork-time CoW 路径在子 VMA 的保留映射中以相同的方式泄漏，不过它需要固定的 hugetlb 匿名页面 + hw中毒源的罕见组合。在两个错误路径的 folio_put（） 前添加缺少的 restore_reserve_on_error（） 调用。（CVE-2026-53154）

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

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

  - misc：fastrpc：修复 rpmsg 回调中的空指针取消引用 当 DSP 在 fastrpc_rpmsg_probe（） 完成初始化之前发送 glink 消息时，在引导的 Hawi 上发现空指针取消引用：
    无法处理虚拟地址上的内核空指针取消引用 0000000000000178 pc：
    _raw_spin_lock_irqsave+0x34/0x8c LR：fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... 调用跟踪：
    _raw_spin_lock_irqsave+0x34/0x8c （P） fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] 错误地址0x178对应于 struct fastrpc_channel_ctx 内的锁定变量，确认当 fastrpc_rpmsg_callback（） 尝试采用旋转锁时 cctx 为空。这里有两个问题。首先，在 spin_lock_init（） 和 idr_init（） 之前调用 dev_set_drvdata（），从而留下一个窗口，回调可检索有效的 cctx 指针，但对未初始化的旋转锁进行操作。第二种情况，一旦驱动程序被绑定，rpmsg 通道就会进入激活状态，因此 fastrpc_rpmsg_callback（） 可在调用 dev_set_drvdata（） 之前触发，从而导致 dev_get_drvdata（） 返回 NULL。将所有 cctx 初始化移到 dev_set_drvdata（） 之前修复了这两个问题，以便在回调可见之前将结构完全初始化，并在 fastrpc_rpmsg_callback（） 中添加空检查作为防范任何剩余窗口。
    (CVE-2026-53158)

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

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

  - staging：rtl8723bs：rtw_mlme：ie_length 减法前添加边界检查 添加防护，确保在减去固定 IE 偏移之前ie_length足够大，从而防止无符号的整数下溢。
    (CVE-2026-53178)

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

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

  - ALSA：PCM：修复链接流上 snd_pcm_drain（） 中的等待队列列表损坏 snd_pcm_drain（） 使用不清除 entry.prev/next 的init_waitqueue_entry，并add_wait_queue并发 UNLINK 后to_check不再在群组中时跳过的条件remove_wait_queue。孤立的等待条目保留在未链接的子流休眠队列中。在下一次耗尽迭代中，add_wait_queue 会在仍链接旧队列时将条目添加到新队列，从而损坏两个列表。后续wake_up取消引用 func 指针处的 NULL（从错译的wait_queue_head_t偏移 0 处的旋转锁映射而来），从而导致内核错误。将 init_waitqueue_entry/add_wait_queue/条件remove_wait_queue替换为 init_wait_entry/prepare_to_wait/ finish_wait。init_wait_entry在每次迭代时通过INIT_LIST_HEAD清除上一个/下一个，并设置在唤醒时自动删除条目的autoremove_wake_function。finish_wait可安全地处理已删除和仍在排队的情况。（CVE-2026-53242）

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

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

  - 发送大量构建的 DNS 查询的攻击者可能会触发插入动态块，该值会造成在 prometheus 端点产生无效输出。然后，prometheus 端点将被抓取工具拒绝，直到动态块到期。（CVE-2026-40011）

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

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

  - iommu/riscv：更新 DDT/PDT 条目后添加 IOTINVAL 添加 riscv_iommu_iodir_iotinval（） 以在更新 DDT 或 PDT 条目后执行所需的 TLB 和上下文缓存无效，如 RISC-V IOMMU 规范（部分 6.3.1 和 6.3.2）。（CVE-2026-53057）

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

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

  - perf/amd/ibs：避免从 IBS NMI 处理程序调用 perf_allow_kernel（） 从 NMI 上下文调用 perf_allow_kernel（） 不安全，可能是致命的。通过在事件初始化时捕获权限，将其存储在 event->hw.flags 中，并使 NMI 处理程序依赖于该缓存标记，而不是直接进行调用。（CVE-2026-53114）

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

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

  - 恶意授权服务器可通过 ZoneToCache 函数发送构建的区域，从而导致缓存毒化。（CVE-2026-33612）

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

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

  - l2tp：pppol2tp：保持对 pppol2tp_ioctl（） 中的会话的引用 pppol2tp_ioctl（） 直接读取 sock->sk->sk_user_data，无需任何锁定或引用计数。如果在 copy_from_user（） 期间诱导了可控制的休眠（例如通过 userfaultfd 页面错误休眠），并行套接字关闭可异步触发 pppol2tp_session_close（）。这样会通过 l2tp_session_del_work 工作队列释放 l2tp_session 结构。恢复后，ioctl 线程会取消引用过时的会话指针，从而导致释放后使用 （UAF）。通过使用条目上的 RCU 安全、refcounted 辅助函数 pppol2tp_sock_to_session（sk），安全地提取会话引用来修复此问题。这样会在休眠期间锁定会话的引用计数。我们将函数构建为通过标准 err 中断退出，从而保证在所有返回路径上干净地调用 l2tp_session_put（） 以删除引用。为了保留现有行为，我们仅针对需要会话及其魔术签名的特定 L2TP 命令验证会话及其魔术签名。这可确保在未连接的套接字上调用的通用/未知 ioctl 仍返回 -ENOIOCTLCMD 并正确回退到通用处理程序（例如在 sock_do_ioctl（） 中）。（CVE-2026-53262）

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

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

  - udp：运行 sockmap 判定之前清除 skb->dev 在 UDP 接收路径上，skb->dev 通过 union { struct net_device 被重新利用为 dev_scratch（由 udp_set_dev_scratch（） 设置的 truesize/state 缓存）
    *dev;无符号长dev_scratch;} 在 sk_buff 中。当 UDP 套接字位于 sockmap 中时，sk_data_ready为 sk_psock_verdict_data_ready（），它会调用 udp_read_skb（） -> recv_actor（） （sk_psock_verdict_recv） 以在 softirq 中运行附加的 SK_SKB 判定程序。如果该程序调用套接字查找帮助程序 （bpf_sk_lookup_tcp/udp， bpf_skc_lookup_tcp），则 bpf_skc_lookup（） 会执行以下操作：if （skb->dev） caller_net = dev_net（skb->dev）;skb->dev 仍保留dev_scratch值（非 NULL 整数），因此 dev_net（） 将其作为结构net_device取消引用 * 且内核会在 softirq 中的非规范地址上发生常规保护错误： 哎呀：一般保护错误，可能针对非规范地址 0x1010000800004a0 CPU：1 UID：0 PID：1406 通信：syz.2.19 未受感染 7.1.0-rc6 #1 PREEMPT（full） RIP：
    0010：bpf_skc_lookup net/core/filter.c：7033 [内联] RIP：0010：bpf_sk_lookup+0x45/0x160 net/core/filter.c：7047 调用跟踪： <IRQ> bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0
    __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 </IRQ> dev_scratch 所考虑的 rmem 电荷由 skb_recv_udp（） 在出列时释放，就在上方，因此当 recv_actor（） 运行时，暂存已失效。清除 skb->dev，以便 bpf_skc_lookup（） 回退到sock_net（skb->sk），后者 skb_set_owner_sk_safe（） 设置就在上面。（CVE-2026-53184）

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

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

  - drm/v3d：具有将工作组清零时跳过 CSD 计算着色器调度对其在 CFG0 中的工作组计数进行编码。CFG2 寄存器。在三个维度中的任何一个维度中以零计数启动调度都是无效的。首先，硬件会将 0 处理为 65536，而用户空间驱动程序最多公开 65535。除此之外，具有零工作组维度的提交应该是无操作的。这些归零的计数可通过间接 CSD 作业到达调度路径，其工作组计数仅在读取间接缓冲区后才为已知，并且在法律上可能为零，但这种情况应该仅导致 no-op。
    使用间接 BO 工作组计数覆盖间接 CSD 作业工作组计数，即使它们为零，并且当任何工作组计数为零时不将作业提交到硬件，因此作业会立即完成，而不是运行着色器。（CVE-2026-53139）

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

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

  - Bluetooth：L2CAP：拒绝通过 MTUsig net/bluetooth/l2cap_core.c 的 BR/EDR 信号数据包：l2cap_sig_channel（） 接受通道 MTU 之前的 BR/EDR 信号数据包，并且在不强制执行信号 MTU （MTUsig） 的情况下调度每个命令。在无线电范围内的蓝牙 BR/EDR 对等机可以在配对前发送大于 MTUsig 且包含许多 L2CAP_ECHO_REQ 命令的固定信道 CID 0x0001 数据包。在实际无线电库存内核运行中，一个包含 168 个零长度ECHO_REQ命令的 681 字节信令数据包使目标在大约 220 毫秒内传输了 168 ECHO_RSP 帧。影响：在无线电范围内的蓝牙 BR/EDR 对等体在配对之前，可能会强制从一个包含打包 ECHO_REQ 命令的 681 字节固定信道信令数据包获取 168 个ECHO_RSP帧。将 Linux 的 BR/EDR 信号 MTU 定义为规范最小 48 字节，并在调度任何命令之前拒绝任何具有一个L2CAP_COMMAND_REJECT_RSP携带L2CAP_REJ_MTU_EXCEEDED的较大信号数据包。MTUExceeded 的蓝牙核心规范措辞规定，拒绝标识符应与数据包中的第一个请求命令匹配，并且仅包含响应的数据包应静默丢弃。Linux 有意偏离该处方：静默丢弃会使对等机不同步，因为远程堆栈永远不会知道其响应已被丢弃，并且找到第一个请求命令需要遍历命令标头经过 MTUsig，即处理来自我们已确定数据包太大而无法处理的数据包的字节。
    因此，我们始终发出一次拒绝，并使用第一个命令标头中的标识符，即单个固定偏移字节读取。不受限制的 BR/EDR 信号解析器和 ECHO_REQ 响应路径都追溯到初始 git 导入;以后引入的提交无法用于 Fixes 标签。（CVE-2026-53208）

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

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

  - soc/tegra：cbb：修复结构查找表中的不正确ARRAY_SIZE 修复结构查找表中不正确的ARRAY_SIZE使用，此问题可在目标超时查找期间造成越界访问。（CVE-2026-53044）

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

ID	名称	严重性
323450	Linux Distros 未修补的漏洞：CVE-2026-53195	high
323449	Linux Distros 未修补的漏洞：CVE-2026-52952	high
323448	Linux Distros 未修补的漏洞：CVE-2026-53134	medium
323447	Linux Distros 未修补的漏洞：CVE-2026-53087	high
323446	Linux Distros 未修补的漏洞：CVE-2026-53038	medium
323445	Linux Distros 未修补的漏洞：CVE-2026-53140	medium
323444	Linux Distros 未修补的漏洞：CVE-2026-52997	medium
323443	Linux Distros 未修补的漏洞：CVE-2026-53222	medium
323442	Linux Distros 未修补的漏洞：CVE-2026-53238	medium
323441	Linux Distros 未修补的漏洞：CVE-2026-53289	medium
323440	Linux Distros 未修补的漏洞：CVE-2026-53020	high
323439	Linux Distros 未修补的漏洞：CVE-2026-53231	medium
323438	Linux Distros 未修补的漏洞：CVE-2026-53145	high
323437	Linux Distros 未修补的漏洞：CVE-2026-40208	low
323436	Linux Distros 未修补的漏洞：CVE-2026-53239	high
323435	Linux Distros 未修补的漏洞：CVE-2026-53029	medium
323434	Linux Distros 未修补的漏洞：CVE-2026-53296	high
323433	Linux Distros 未修补的漏洞：CVE-2026-53032	medium
323432	Linux Distros 未修补的漏洞：CVE-2026-53019	medium
323431	Linux Distros 未修补的漏洞：CVE-2026-52950	high
323430	Linux Distros 未修补的漏洞：CVE-2026-53176	medium
323429	Linux Distros 未修补的漏洞：CVE-2026-53193	high
323428	Linux Distros 未修补的漏洞：CVE-2026-53255	high
323427	Linux Distros 未修补的漏洞：CVE-2026-53207	medium
323426	Linux Distros 未修补的漏洞：CVE-2026-53136	high
323425	Linux Distros 未修补的漏洞：CVE-2026-53215	critical
323424	Linux Distros 未修补的漏洞：CVE-2026-40211	medium
323423	Linux Distros 未修补的漏洞：CVE-2026-53251	medium
323422	Linux Distros 未修补的漏洞：CVE-2026-53267	high
323421	Linux Distros 未修补的漏洞：CVE-2026-53084	medium
323420	Linux Distros 未修补的漏洞：CVE-2026-40210	medium
323419	Linux Distros 未修补的漏洞：CVE-2026-53163	medium
323418	Linux Distros 未修补的漏洞：CVE-2026-42390	medium
323417	Linux Distros 未修补的漏洞：CVE-2026-53227	medium
323416	Linux Distros 未修补的漏洞：CVE-2026-53161	high
323415	Linux Distros 未修补的漏洞：CVE-2026-53260	critical
323414	Linux Distros 未修补的漏洞：CVE-2026-53182	high
323413	Linux Distros 未修补的漏洞：CVE-2026-53154	medium
323412	Linux Distros 未修补的漏洞：CVE-2026-53158	medium
323411	Linux Distros 未修补的漏洞：CVE-2026-53178	high
323410	Linux Distros 未修补的漏洞：CVE-2026-53242	high
323409	Linux Distros 未修补的漏洞：CVE-2026-40011	low
323408	Linux Distros 未修补的漏洞：CVE-2026-53057	high
323407	Linux Distros 未修补的漏洞：CVE-2026-53114	medium
323406	Linux Distros 未修补的漏洞：CVE-2026-33612	high
323405	Linux Distros 未修补的漏洞：CVE-2026-53262	high
323404	Linux Distros 未修补的漏洞：CVE-2026-53184	high
323403	Linux Distros 未修补的漏洞：CVE-2026-53139	medium
323402	Linux Distros 未修补的漏洞：CVE-2026-53208	medium
323401	Linux Distros 未修补的漏洞：CVE-2026-53044	high

检测

Nessus 的 Misc. 系列

high

high

medium

high

medium

medium

medium

medium

medium

medium

high

medium

high

low

high

medium

high

medium

medium

high

medium

high

high

medium

high

critical

medium

medium

high

medium

medium

medium

medium

medium

high

critical

high

medium

medium

high

high

low

high

medium

high

high

high

medium

medium

high