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

  - md：暂停前唤醒 raid456 reshape 等待程序 在 raid456 reshape 期间，reshape 位置上的直接 IO 可在 raid5_make_request（） 中休眠以等待 reshape 进度，同时仍保留active_io引用。如果用户空间随后冻结 reshape 并写入 md/suspend_lo 或 md/suspend_hi，则 mddev_suspend（） 会终止active_io并等待所有正在传输的 IO 耗尽。这可能会死锁：IO 需要 reshape 进度才能继续，但 reshape 线程已冻结，因此 active_io 引用永远不会丢失，暂停也不会完成。raid5_prepare_suspend（） 已为 dm-raid 唤醒wait_for_reshape。当 reshape 已经中断时，对正常 md 暂停执行相同的操作，因此等待 raid456 IO 可中止、终止其引用并让暂停完成。mdadm 测试 tests/25raid456-reshape-deadlock 重现了挂起情况。
    (CVE-2026-53123)

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

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

  - accel/ethosu：修复命令流解析器中的 IFM 区域索引越界，NPU_SET_IFM_REGION提取具有参数 & 0x7f 的区域索引，给出的最大值为 127。但是 region_size[] ，结构ethosu_validated_cmdstream_info中 和 output_region[] 的大小都为 NPU_BASEP_REGION_MAX （8），给出了有效的索引 [0..7]。同一交换机中的所有其他区域分配都使用 param & 0x7： NPU_SET_OFM_REGION：
    st.ofm.region = param & 0x7;NPU_SET_IFM2_REGION：st.ifm2.region = param & 0x7;NPU_SET_WEIGHT_REGION：
    st.weight[0].region = param & 0x7;NPU_SET_SCALE_REGION：st.scale[0].region = param & 0x7;IFM 上的0x7f掩码不一致，似乎是拼写错误。feat_matrix_length（） 和 calc_sizes（） 将区域索引直接用作 kzalloc'd info struct 的数组下标：info->region_size[fm->region] = max（...）;提供参数> 7 的NPU_SET_IFM_REGION的用户空间调用方造成写入超过 127*8 = region_size[]1016 字节的开头，从而损坏相邻内核堆数据。通过应用所有其他区域分配所使用的相同 &; 0x7 掩码进行修复。（CVE-2026-53172）

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

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

  - 如果 NSD 配置为区域的辅助服务器，则该区域的主服务器可通过包含 DNS 消息的 AXFR 造成 NSD 崩溃，其中含有特别构建的 SVCB RR 的 rdata 大小为 65512，这为一个用于分配 RR 封装所需空间的 （uint16_t） 变量（因为总大小> 65535）， 造成堆溢出。攻击者可执行多达 65509 字节的受控（RCE 类）头写入 （CVE-2026-12244）

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

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

  - 对目录区域中存在的 SOA 记录的不完整验证可能导致崩溃。（CVE-2026-42388）

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

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

  - Bluetooth：修复 hci_alloc_dev（） 错误路径中的内存泄漏 Bluetooth HCI 中的早期失败 UART 配置泄漏 SRCU percpu 内存。如果在 hci_register_dev（） 完成之前设备初始化失败，则永远不会设置 HCI_UNREGISTER 标记。因此，当设备引用计数达到零时，bt_host_release（） 会将此标记评估为 false，并回退到直接 kfree（hdev）。由于绕过了 hci_release_dev（），所以 hci_alloc_dev（） 中早期初始化的 SRCU 结构永远不会被清理，从而导致 percpu 内存泄漏。通过在释放设备之前显式调用 bt_host_release（） 的回退（未注册）分支中的 cleanup_srcu_struct（），修复泄漏。（CVE-2026-53252）

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

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

  - ALSA：seq：dummy：修复 UMP 事件堆栈越界读取 虚拟排序器端口通过将传入的 struct snd_seq_event复制到堆栈临时、重写源和目标并将临时分发到订阅者来转发事件。该旧事件存储比结构snd_seq_ump_event小。当 UMP 事件到达虚拟客户端时，副本会保留 UMP 标记集，但仅提供旧大小的堆栈存储。然后，订阅者传送路径使用 snd_seq_event_packet_size（） 并从该堆栈对象复制 UMP 大小的数据包，读取超过临时堆栈的末尾。使用现有 union __snd_seq_event 存储并复制针对传入事件报告的数据包大小，然后再重写通用路由字段。这样可以为 UMP 事件保留完整的 UMP 数据包，同时保持旧事件处理不变。
    (CVE-2026-53241)

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

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

  - net：psp：需要 dev-set 和 key-rotate 的管理员权限 dev-set 和 key-rotate netlink 操作修改共享设备状态（分别为 PSP 版本配置和加密密钥材料），但不需要CAP_NET_ADMIN。唯一的访问控制为 psp_dev_check_access（），它仅验证 netns 成员身份。（CVE-2026-52978）

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

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

  - tee：shm：修复 register_shm_helper（） 中的 shm 泄漏 register_shm_helper（） 在调用 iov_iter_npages（） 之前分配 shm。如果 iov_iter_npages（） 返回 0，函数会跳至 err_ctx_put 并泄露 shm。可通过具有长度为 0 的 struct tee_ioctl_shm_register_data TEE_IOC_SHM_REGISTER触发此问题。请跳转到err_free_shm。（CVE-2026-53210）

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

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

  - iommu/dma：不尝试在 swiotlb iommu_dma_iova_link_swiotlb（） 处理在三个部分（头部、中间部和尾部）中未对齐的映射时iommu_map 0 长度区域。如果中间为空，因为没有对齐的页面，它将向下调用大小为 0 的 iommu_map（），iommupt 实现将因非法而失败。然后，它尝试执行错误展开并从错误的位置开始，从而损坏映射，因此最终销毁会触发WARN_ON。检查长度为 0 并避免映射，使用偏移而不是 0 作为取消链接的起点。这通常是通过使用某些类型的 Thunderbolt NVMe 驱动器触发未对齐内存的强制 SWIOTLB 来触发的。NVMe 似乎会针对来自遇到此情况的 smartctl 的传递命令传入奇怪对齐的缓冲区。（CVE-2026-53164）

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

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

  - Debian Linux - qemu - 无 Ubuntu Linux - [未知描述] （CVE-2026-8343）

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

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

  - net：将 pskb_may_pull（） 添加到 skb_gro_receive_list（） skb_gro_receive_list（） 调用 skb_pull（skb， skb_gro_offset（skb）），而不必首先通过 pskb_may_pull（） 确保数据处于线性区域中。当 skb 通过 napi_gro_frags（） 到达时，skb_headlen可以是 0（页面片段中的所有数据），而 skb_gro_offset 则不是零（在 IP+TCP 标头解析之后）。然后 skb_pull（） 会递减 skb->len skb_gro_offset，但 skb->data_len 保持不变，命中 __skb_pull（） 中的 BUG_ON（skb->len < skb->data_len）。UDP fraglist GRO 路径在 udp_offload.c：749 处已包含此防护。将其添加到 skb_gro_receive_list（） 本身可为所有调用程序（TCP、UDP 和任何未来的协议）提供集中保护，并确保在调用 skb_pull（） 之前满足其先决条件。pskb_may_pull（） 失败时，设置 NAPI_GRO_CB（skb）->flush = 1，这样 skb 就不会作为新的 GRO 头保留，而是通过符合 UDP 处理的普通接收路径进行传送。（CVE-2026-53235）

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

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

  - ksmbd：修复双重SMB2_CANCEL上延迟的file_lock释放后使用 延迟的字节范围锁定（阻止的 SMB2_LOCK）通过 setup_async_work（） 在 conn->async_requests 上注册异步工作，其中 cancel_fn = smb2_remove_blocked_lock 且指向结构file_lock cancel_argv[0]。当请求被取消时，工作线程使用 locks_free_lock（） 释放file_lock并采用已取消的提前退出，该退出会转到输出并且永远不会到达 release_async_work（） -- 唯一从连接>async_requests取消工作链接并清除 cancel_fn/cancel_argv 的站点。因此，在async_requests上，工作与指向已释放file_lock的实时cancel_fn保持可匹配，直到连接破坏最终运行 release_async_work（）。smb2_cancel（） 在没有状态防护的情况下无条件触发 cancel_fn，因此到达该窗口的相同 AsyncId 的第二个SMB2_CANCEL将在释放的 file_lock上重新运行 smb2_remove_blocked_lock（） -- slab 释放后使用： 缺陷： KASAN： __locks_delete_block 中的 slab-after-free
    __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 第二次SMB2_CANCEL触发 cancel_fn handle_ksmbd_work 分配者 ...： locks_alloc_lock <- smb2_lock 释放者 ...： locks_free_lock <- smb2_lock（已取消的分支）...大小为 192 的缓存file_lock_cache由经身份验证的 SMB 客户端在干线上使用 KASAN 重现。跳过状态已KSMBD_WORK_CANCELLED的工作，因此无法再次触发其取消回调。（CVE-2026-53198）

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

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

  - macvlan：修复 macvlan_get_size（） 未为 IFLA_MACVLAN_BC_CUTOFF macvlan_get_size（） 预留空间不考虑IFLA_MACVLAN_BC_CUTOFF，但 macvlan_fill_info（） 在 port->bc_cutoff ！= 1 时有条件将其包括在内。当 netlink skb 空间不足时，这会导致 nla_put_s32（） 因 -EMSGSIZE 而失败，从而触发 rtnetlink 中的WARN_ON并阻止转储接口。可通过以下方式重现该缺陷：ip 链接添加 macvlan0 链接 eth0 类型 macvlan 模式桥接 ip 链接设置 macvlan0 类型 macvlan bc_cutoff 0 ip -d 链接显示 macvlan0 # 因 -EMSGSIZE 失败 提交 954d1fa1ac93 中添加了bc_cutoff功能（macvlan：为广播中断添加 netlink 属性），这在 macvlan_fill_info（） 中添加了 nla_put_s32（） 调用，但缺少在 macvlan_get_size（） 中添加相应的 nla_total_size（4）。后续提交 55cef78c244d（macvlan：为 IFLA_MACVLAN_BC_CUTOFF 添加忘记的nla_policy）修复了缺少的 nla_policy 条目，但仍未修复大小计算。（CVE-2026-53013）

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

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

  - ksmbd：修复 durable v2 open ksmbd_lookup_fd_cguid（） 中 ClientGUID 不匹配的持久 fd 泄漏 返回ksmbd_file，其 refcount 通过 ksmbd_fp_get（） 递增。DURABLE_REQ_V2情况下的 parse_durable_handle_context（） 会在 ClientGUID-match 分支的每一个路径上正确释放此引用，方法是调用 ksmbd_put_durable_fd（） 或将所有权转移至 dh_info->fp 以便成功重新连接。但是，当全局文件表中存在具有相同 CreateGuid 但不同 ClientGUID 的条目时，代码只会回到 new-open 路径，而不丢弃从 ksmbd_lookup_fd_cguid（） 获取的引用。根据 MS-SMB2 部分 3.3.5.9.10 （处理SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2创建上下文），服务器必须找到 Open，其 Open.CreateGuid 与请求的 CreateGuid 匹配，并且其 Open.ClientGuid 与接收请求的连接的 ClientGuid 匹配。如果未找到此类打开，服务器必须继续进行正常的打开执行阶段。因此，ClientGUID 不匹配的 CreateGuid 命中就是找不到 Open 的情况：
    继续新的打开是正确的，但绝不能泄漏纯粹作为查找的副作用而获得的引用。重复请求命中此不匹配的 pin 条目global_ft，阻止
    __ksmbd_close_fd（） 从未为相应文件运行，并击败持久清理程序，从而导致长时间的资源泄漏。释放不匹配路径中的引用并清除 dh_info->fp，以便后续逻辑不会将不匹配的查找结果误认为重新连接目标。（CVE-2026-52996）

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

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

  - net/mlx5e：xsk：修复 xmit 失败时的 DMA XDP_TX xdp_frame泄漏 在 mlx5e_xmit_xdp_buff（） 的 XSK 分支中，当 sq->xmit_xdp_frame（） 返回 false（如 XDPSQ 已满）时，该函数在不取消映射 DMA 地址或释放 xdp_convert_zc_to_xdp_frame（） 分配的xdp_frame的情况下返回。xdpi_fifo推送仅在成功时发生，因此完成路径无法恢复这些条目。CONFIG_DMA_API_DEBUG=y 时，驱动程序 unbind 上的泄露浮出水面：DMA-API：pci 0000：08：00.0：从设备释放时，设备驱动程序具有待定的 DMA 分配 [count=1116] 其中一个泄漏的条目详细信息：[device address=0x000000010ffd7028] [size=1534 bytes] [映射为 DMA_TO_DEVICE] [映射为 phy] 警告：
    kernel/dma/debug.c：881 在 dma_debug_device_change+0x127/0x180 ... DMA-API：映射到：
    debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] 添加缺失的取消映射 + xdp_return_frame，以匹配 mlx5e_xdp_xmit（） 中已完成的清理。has_frags在此分支较早阶段遭到拒绝，因此不需要每个 frag 取消映射。
    (CVE-2026-53229)

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

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

  - mm/huge_memory：对设备隐私 PMD 条目提交 65edfda6f3f2 使用正确的标记（mm/rmap：扩展 rmap 和迁移支持 device-private 条目） 更新了 set_pmd_migration_entry（） 以在软叶情况下使用 pmdp_huge_get_and_clear（），但未对函数本身进行进一步调整。
    因此，此函数继续不正确地使用 pmd_write（）、pmd_soft_dirty（） 和 pmd_uffd_wp（） 来确定安装的迁移条目应分别标记为可写入、softdirty 或 uffd-wp。虽然所有内容都不正确，但其中最大的问题是 pmd_write（），因为这可导致 rmap 状态损坏。在 x86-64 上，_PAGE_SWP_SOFT_DIRTY别名为 _PAGE_RW。因此，假设已启用 softleaf 上的 pmd_write（） 将返回条目中编码的 softdirty 状态CONFIG_MEM_SOFT_DIRTY。
    运行 hmm.hmm_device_private.anon_write_child selftest 时发现此情况：1. 然后，测试在某个范围内发生错误，然后将其迁移，从而建立设备专用 THP 范围。2. 然后，父项将其迁移到设备专用可写 PMD 条目，其作品集完全是具有 entire_mapcount=1 的 softdirty 集（意外更正写入状态）的 AnonExclusive。3. 父分支和 PMD 条目设置为设备专用只读条目，entire_mapcount=2，仍设置 softdirty。4. [缺陷] 子写入到该范围然后迁移到 RAM - 意图安装不可写入的迁移条目 - 但由于误解释 softdirty 位，将父和子 PMD 映射替换为可写入条目。5. 在 remove_migration_pmd（） 中，如果 ！softleaf_is_migration_read（entry） 我们在为父子调用 folio_add_anon_rmap_pmd（） 时设置RMAP_EXCLUSIVE标志，因此是 AnonExclusive。6. [SPLAT] 子集迁移了 entire_mapcount=1 的对开本，entire_mapcount=2 的父集，我们最终得到了 entire_mapcount=2 的 AnonExclusive 对开本！断言在 __folio_add_anon_rmap（） 中触发：
    VM_WARN_ON_FOLIO（folio_test_large（folio） &; folio_entire_mapcount（folio） > 1 &; PageAnonExclusive（cur_page）， folio） 此修补程序通过正确引用 set_pmd_migration_entry（） 中 writable、softdirty 和 uffd-wp 的 softleaf 条目字段来修复此问题。它还仅在条目存在时才更新 A/D 标记，因为这些标记对软叶条目没有意义。此修补程序还翻转了 set_pmd_migration_entry（） 中的 if （！present） { ... } else { ... } 逻辑，使其更易于理解，并添加了一些注释以使事情更清楚。我能够将其一分为二以提交 775465fd26a3（lib/test_hmm：添加区域设备私有 THP 测试基础架构），它首先暴露此缺陷，因为正是允许test_hmm生成测试的提交。但是，提交 65edfda6f3f2（mm/rmap：扩展 rmap 并迁移支持设备私人条目）才是实际启用此行为的提交。
    (CVE-2026-53155)

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

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

  - drm/virtio：修复 virtio_gpu_dma_fence_wait（） 中出错时dma_fence refcount 泄漏 dma_fence_unwrap_for_each（） 在内部调用 dma_fence_unwrap_first（），其执行 cursor->chain = dma_fence_get（head），并获取额外的引用。正常循环完成时，dma_fence_unwrap_next（） 通过 dma_fence_chain_walk（） -> dma_fence_put（） 释放此循环。当 virtio_gpu_do_fence_wait（） 失败且函数从循环内部提早返回时，永远不会释放游标>链引用。这是整个内核中唯一在dma_fence_unwrap_for_each内部进行提早返回的调用程序。提前返回前添加 dma_fence_put（itr.chain）。（CVE-2026-53190）

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

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

  - padata：将 CPU 离线回调置于 ONLINE 部分以允许失败 syzbot 报告以下警告：
    CPU1 的 DEAD 回调错误 警告：kernel/cpu.c：1463 at _cpu_down+0x759/0x1020 kernel/cpu.c：1463， CPU#0：在提交 4ae12d8bd9a8（合并 git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux 的“kbuild-fixes-7.0-2”标签“kbuild-fixes-7.0-2”）时的 syz.0.1960/14614，tglx 将其跟踪到 padata_cpu_dead（），因为它是唯一返回错误的子CPUHP_TEARDOWN_CPU回调。CPUHP_TEARDOWN_CPU之前，热插拔状态不允许失败，因此将 CPU 离线回调移至可能失败的 ONLINE 部分。（CVE-2026-53314）

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

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

  - gpio：mvebu：修复暂停/恢复中的空指针取消引用 在暂停/恢复期间为所有 GPIO 组调用 mvebu_pwm_suspend（） 和 mvebu_pwm_resume（），但并非所有 bank 都具有 PWM 功能。不含 PWM 的 GPIO bank 将 mvchip->mvpwm 设置为 NULL。尝试访问 mvpwm->blink_select 时，调用 mvpwm == NULL 的 mvebu_pwm_suspend（） 可造成空指针取消引用。写入 [00000020] 时无法处理虚拟地址 00000020 处的内核空指针取消引用 *pgd=00000000 内部错误：哎呀：815 [#1] PREEMPT ARM 模块链接于： CPU：0 UID：0 PID：406 comm：sh 未受感染 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 硬件名称：Marvell Armada 370/XP（设备树） PC 处于 regmap_mmio_read+0x38/0x54 LR 处于 regmap_mmio_read+0x38/0x54 PC： [<c05fd2ac>] lr： [<c05fd2ac>] psr：
    200f0013 SP：f0c11d10 ip：00000000 FP：c100d2f0 r10： c14fb854 r9：00000000 r8：00000000 r7：c1799c00 r6：00000020 r5：00000020 r4：c179c7c0 r3：f0a231a0 r2：00000020 r1：00000020 r0：00000000 标记：
    模式 SVC_32 上 FIQ 上的 nzCv IRQ ISA ARM 段 无 控件：10c5387d 表：135ec059 DAC：00000051 调用跟踪：从 _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read regmap_mmio_read
    _regmap_read+0x60/0x154 _regmap_read 从 regmap_read+0x3c/0x60 regmap_read 从 mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend 从 dpm_run_callback+0x54/0x180 dpm_run_callback 从 device_suspend+0x124/0x630 device_suspend 从 dpm_suspend+0x124/0x270 dpm_suspend 从 dpm_suspend_start+0x64/0x6c dpm_suspend_start 从 suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter 从 pm_suspend+0x2fc/0x308 pm_suspend 从 state_store+从 kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter 0x6c/0xc8 state_store 从 vfs_write+0x270/0x468 vfs_write 从 ksys_write+0x70/0xf0 ksys_write 从 ret_fast_syscall+0x0/0x54 添加 NULL 检查 调用 PWM 暂停/恢复函数之前对 mvchip->mvpwm 添加空检查。（CVE-2026-53237）

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

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

  - xfrm：iptfs：修复 iptfs_destroy_state（） iptfs_destroy_state（） 调用 hrtimer_cancel（） 中的 ABBA 死锁，同时保持定时器回调也获取的旋转锁，从而导致 SMP 系统上的 ABBA 死锁。对于输出定时器 （iptfs_timer）： - iptfs_destroy_state（） 保持 x->lock，调用 hrtimer_cancel（） - iptfs_delay_timer（） 回调采用 x->lock 对于终止定时器 （drop_timer）： - iptfs_destroy_state（） 保持 drop_lock，调用 hrtimer_cancel（） - iptfs_drop_timer（） 回调采用 drop_lock 两个定时器都使用 HRTIMER_MODE_REL_SOFT，因此其回调在 softirq 环境中运行。当针对当前正在另一个 CPU 上执行的软定时器调用 hrtimer_cancel（） 时，hrtimer_cancel_wait_running（） 会在softirq_expiry_lock旋转 -- 由运行回调的 softirq 持有的相同锁定。如果回调在等待 hrtimer_cancel（） 的调用者持有的旋转锁时被阻断，则会形成循环依赖关系： CPU 0：保留 lock_A -> 等待 softirq_expiry_lock CPU 1：保留 softirq_expiry_lock -> 等待 lock_A 在获取相应的锁之前调用 hrtimer_cancel（） 进行修复。hrtimer_cancel（） 无需保持任何锁定即可安全调用，并将等待任何正在进行的回调完成。对于输出定时器，之后仍会获取锁定以耗尽数据包队列。对于丢失定时器，锁定/解锁对将完全删除，因为它仅存在于定时器回调序列化时，而 hrtimer_cancel（） 已经保证了这一点。由源代码审核发现。（CVE-2026-53197）

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

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

  - ublk：在每次提取时重置每个 IO 已取消的标记 如果 ublk 服务器开始恢复设备但在对所有 IO 发出获取命令之前停止运行，则成功发出的提取命令的取消可能无法完成。这是因为每个 IO 已取消标记可保持设置状态，即使在提交该 IO 的提取之后也可保持设置状态 - 只有在提取了队列的所有 IO 之后，队列中所有 IO 的每个 IO 已取消标记才会一起重置。因此，如果在 ublk 服务器终止时获取队列的 IO 的非空正确子集，则该子集中的 IO 将永远不会被成功取消，因为它们已取消的标记仍保持设置状态，这阻止ublk_cancel_cmd实际调用命令上的 io_uring_cmd_done，尽管这些命令已完成。通过在获取每个 IO 时立即重置 per-IO 取消标记而非等待队列的所有 IO（这可能永远不会发生）来修复此问题。（CVE-2026-53124）

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

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

  - vsock/virtio：修复潜在的不受限制的 skb 队列 virtio_transport_inc_rx_pkt（） 检查 vvs->rx_bytes + vvs->buf_alloc >len。virtio_transport_recv_enqueue（） 跳过具有VIRTIO_VSOCK_SEQ_EOM的数据包的合并。如果馈送 len == 0 和 VIRTIO_VSOCK_SEQ_EOM 的数据包，由于 vvs->rx_bytes 保持在 0，因此可能会有大量数据包排队。通过估算 skb 元数据大小修复此问题：（队列中的 skb 数量） * SKB_TRUESIZE（0） （CVE-2026-53132）

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

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

  - audit：修复 CAPSET 记录中由于复制粘贴错误而导致的 CAPSET 记录中不正确的可继承功能__audit_log_capset（） 将有效功能集记录到可继承字段中。因此，每个 CAPSET 审计记录都使用 cap_effective 而不是 cap_inheritable 值报告cap_pi（进程可继承）。这会静默地损坏用于合规性和取证分析的审计数据：如果攻击者修改可继承功能以准备出现权限升级，则会在审计跟踪中屏蔽更改。自 2008 年首次引入 CAPSET 审计记录以来，该缺陷一直存在。
    (CVE-2026-53287)

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

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

  - memcg：在 refill_stock 中使用轮循策略受害者选择 Harry Yoo 报告，在 nmi 上下文中调用 get_random_u32_below（） 并不安全，而且 nmi 上下文中可发生 memcg 电荷耗尽。更具体地说，get_random_u32_below（） 既不可重入也不对 NMI 安全：它通过batched_entropy_u32状态上的 local_lock_irqsave（） 获取每个 cpu 的local_lock。在 ChaCha 批处理状态的 CPU 更新中抵达并递归到随机子系统的 NMI 将会损坏该状态。memcg_stock local_trylock可防止 percpu 库存本身的重新输入，但无法保护不相关的子系统的 per-cpu 锁定。
    将随机选择替换为存储在 memcg_stock_pcp 中并由local_trylock已保护 cached[] 和 nr_pages[]. 无需原子、随机调用、无需额外锁定。（CVE-2026-53162）

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

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

  - netfilter：重新验证桥接端口 ebt_redirect_tg（） 取消引用 br_port_get_rcu（） 返回但未进行 NULL 检查，从而在原始挂钩调用和 NFQUEUE 重新注入之间删除桥接端口时导致内核错误。但是，仅仅进行 NULL 检查是不够的。正如 sashiko review 所指出的，用户空间不仅会从桥接删除端口，还可以将设备放置到其他虚拟设备中，例如 macvlan。如果发生这种情况，我们必须丢弃数据包，无法将其重新注入桥接路径。切换到 _upper API，我们不需要桥接端口结构。此外，此补丁保持另一个缺陷不变：nfnetlink_log和nfnetlink_queue都过于激进地使用CONFIG_BRIDGE_NETFILTER，从而在桥接系列中排队时阻止某些日志记录功能：
    可在旧CONFIG_BRIDGE_NETFILTER cruft 关闭时启用NETFILTER_FAMILY_BRIDGE。修复标签是共同的祖先，但一直被破坏。（CVE-2026-53220）

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

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

  - accel/ethosu：拒绝长度未初始化的 DMA 命令 cmd_state_init（） 使用 memset（0xff） 初始化命令状态，将 dma->len 保留在 U64_MAX，以发出缺少设置的信号。唯一的二传手是NPU_SET_DMA0_LEN;如果用户空间省略该命令并发出NPU_OP_DMA_START，则 dma->len 仍然U64_MAX。
    在 dma_length（） 中，向 U64_MAX 添加的正步幅换行为较小的值。size0 == 1 时，check_mul_overflow（） 不会触发，并且 dma_length（） 返回 0 而不是 U64_MAX。调用方的U64_MAX检查随后通过， region_size[] 保持 0，并且绕过 ethosu_job.c 中的边界检查，从而允许硬件以过时的物理地址执行 DMA。通过在任何算术运算之前检查 dma_length（） 开头的 U64_MAX 进行修复，这与整个驱动程序用来检测未初始化字段的 sentinel 值一致。（CVE-2026-53170）

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

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

  - bpf：修复通过 freplace 滥用的kprobe_write_ctx 允许 uprobe 程序修改结构pt_regs。
    由于 uprobe 的实际程序类型为 KPROBE，因此当 kprobe 附加到内核函数时，可滥用它来通过 kprobe+freplace 修改结构pt_regs。例如，SEC（？kprobe） int kprobe（struct pt_regs *regs） { return 0; }SEC（？freplace） int freplace_kprobe（struct pt_regs *regs） {regs->di = 0; return 0; } freplace_kprobe prog 将附加到 kprobe prog。kprobe prog 将附加到内核函数。在没有此修补程序的情况下，当内核函数运行时，通过freplace_kprobe prog 的第一个参数将始终设置为 0。若要通过 kprobe+freplace 修复 kprobe_write_ctx=true 的滥用问题，禁止在具有不同kprobe_write_ctx值的 kprobe 程序上附加 freplace 程序。（CVE-2026-53095）

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

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

  - thunderbolt：拒绝验证器中的零长度属性条目 tb_property_entry_valid（） 接受 DIRECTORY、DATA 和 TEXT 类型长度 == 0 的条目。零长度的 TEXT 条目通过验证，但在 null 终止逻辑中造成下溢： property->value.text[property->length * 4 - 1] = '\0';
    当 property->length 为 0 时，相对于分配，这会写入偏移量 -1。在验证器早期拒绝零长度条目，因为其在 XDomain 属性协议中没有有效的表示形式。
    (CVE-2026-53150)

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

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

  - wifi：修复拆分 6 GHz 扫描失败时的泄漏 如果 cfg80211_scan（） 失败，将泄漏 rdev->int_scan_req。请注意，它应该在 ___cfg80211_scan_done（） 时释放，但这种情况不会发生，因为 rdev->scan_req 在该时也是 NULL，从而导致从释放函数提早返回。未引用的对象0xffff8881161d0800（大小 512）：comm wpa_supplicant、pid 379、jiffies 4294749765 hex 转储（前 32 字节）：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 f0 81 13 16 81 88 ff ff ................回溯 （CRC c867fdb6）：kmemleak_alloc+0x89/0x90
    __kmalloc_noprof+0x2fd/0x410 cfg80211_scan+0x133/0x730 nl80211_trigger_scan+0xc69/0x1cc0 genl_family_rcv_msg_doit+0x204/0x2f0 genl_rcv_msg+0x431/0x6b0 netlink_rcv_skb+0x143/0x3f0 genl_rcv+0x27/0x40 netlink_unicast+0x4f6/0x820 netlink_sendmsg+0x797/0xce0 __sock_sendmsg+0xc4/0x160
    ____sys_sendmsg+0x5e4/0x890 ___sys_sendmsg+0xf8/0x180 __sys_sendmsg+0x136/0x1e0
    Linux 验证中心 （linuxtesting.org） 发现的 __x64_sys_sendmsg+0x76/0xc0 x64_sys_call+0x13f0/0x17d0。（CVE-2026-53258）

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

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

  - VFS：修复 nfsd4_create_file（） 中可能的解锁失败 atomic_create在 fs/namei.c 中 fs/namei.c 中的 （） 在返回错误时放弃对目录项的引用。此行为已导入 dentry_create（） 中，因此如果从 atomic_create（） 返回错误则会丢弃引用，但如果 vfs_create（） 返回错误（在不支持 ->atomic_create 的情况下），则不会丢弃引用。调用程序 nfsd4_create_file（） - 通过检查 path->dentry（） 来意识到这一点，该检查将是对 dentry 的计数引用或者错误指针。但是，使用 start_creating（）/end_creating（） 的更改（在 dentry_create（） 更改着陆前不久到地，尽管很可能是在同一时间开发的）意味着 nfsd4_create_file（） *需要*一个有效的 dentry 以便它可以解锁父项。最终结果是，如果 NFSD 导出使用 ->atomic_create 的文件系统，并且如果对 ->atomic_create 的调用返回错误，则 nfsd4_create_file（） 会将错误指针传递给 end_creating（），并且父项将不会被解锁。
    通过更改 dentry_create（） 来修复此问题，确保 path->dentry 始终是有效的 dentry，而不是错误指针。实际错误已以不同方式返回。请注意，如果 ->atomic_create（） 返回不同的 dentry（这在实践中可能是不可能的），我们可以保证（因为它仅由 d_spliace_alias（） 提供）它将具有相同的d_parent，因此当传递给 end_creating（） 时将具有相同的效果。（CVE-2026-53244）

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

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

  - mptcp：允许子流 rcv wnd 缩小 在 MPTCP 连接中，TCP 标头中的“窗口”字段引用 MPTCP 级rcv_nxt，其右边缘不应向后移动。此类限制在 DSS 选项生成时实施。同时，TCP 堆栈独立确保 TCP 级 rcv wnd 右侧的边缘不会向后移动。当传入数据在 TCP 级别被确认且在 MPTCP 序列空间中为 OoO（或落在 backlog）时，这反过来会导致 MPTCP rcv 窗口的人为膨胀。因此，即使发送方行为不当，传入流量也可能会超过接收方 rcvbuf 大小。防止强制允许 TCP 子流缩小 TCP 级 rcv wnd 而不管当前 netns 设置如何的情况。（CVE-2026-53183）

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

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

  - usb：typec：修复错误指针取消引用 系统会检查变量 tps->partner 是否有错误指针，如果是，它会发送一条错误消息但不会返回，然后立即取消引用以下几行：tps->partner = typec_register_partner（tps->port， &desc）;if （IS_ERR（tps->partner）） dev_warn（tps->dev， %s： failed to register partnet\n、__func__）;if （desc.identity） {typec_partner_set_identity（tps->partner）; cd321x->cur_partner_identity = st.partner_identity; }添加提前返回并修复错误消息中的拼写错误。由 Smatch 检测： drivers/usb/typec/tipd/core.c：827 cd321x_update_work（） 错误：“tps->partner”取消引用可能的 ERR_PTR（） （CVE-2026-53028）

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

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

  - drm/bridge：cadence：cdns-mhdp8546-core：在 atomic_enable（） 中及早设置 mhdp 连接器 万一在 atomic_enable 的 cdns_mhdp_link_up（） 或 cdns_mhdp_reg_read（） 中出现错误，我们将转到 cdns_mhdp_modeset_retry_fn（） 并在尝试访问互斥体时命中空指针。我们需要在此之前设置连接器。与带有旗帜的传统案例不同！DRM_BRIDGE_ATTACH_NO_CONNECTOR，我们没有在 bridge_attach（） 中初始化连接器，因此在设备结构中添加 mhdp->connector_ptr以处理 DRM_BRIDGE_ATTACH_NO_CONNECTOR 和 ！DRM_BRIDGE_ATTACH_NO_CONNECTOR，请尽早在 atomic_enable（） 中进行设置，以避免恢复路径（例如设置了 DRM_BRIDGE_ATTACH_NO_CONNECTOR 标记的 modeset_retry_fn（））中可能的空指针取消引用。（CVE-2026-53058）

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

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

  - ipvs：在编辑 ip_vs_edit_service（） 时提早清除 svc 计划程序 ptr，而取消绑定旧的计划程序会在计划程序模块发起 RCU 回调后清除 svc->scheduler ptr。这可造成数据包在 svc->sched_data 已于 RCU 宽限期后释放时使用旧的计划程序。通过在 ip_vs_unbind_scheduler（） done_service 方法计划任何 RCU 回调之前提前清除 ptr 来修复此问题。此外，如果新的计划程序在替换旧计划程序时无法初始化，请尝试在返回错误代码的同时还原旧计划程序。（CVE-2026-53270）

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

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

  - bpf：修复开放代码 task_vma 迭代器中的 mm 生命周期 开放代码 task_vma 迭代器无锁读取 task->mm 并获取 mmap_read_trylock（），但从不调用 mmget（）。如果任务并发退出，则可释放mm_struct，因其未SLAB_TYPESAFE_BY_RCU，进而导致释放后使用。通过 alloc_lock 上的 trylock 安全读取 task->mm，并获取 mm 引用。在 _destroy（） 和错误路径中通过 bpf_iter_mmput_async（） 丢弃引用。bpf_iter_mmput_async（） 是围绕 mmput_async（） 的本地封装程序，具有回退到 ！CONFIG_MMU 上的 mmput（）。预先拒绝禁用 irqs 的上下文（包括 NMI）。_next（） 和 _destroy（） （mmap_read_unlock、bpf_iter_mmput_async） 使用的操作采用禁用了 IRQ 的旋转锁（pool->lock、pi_lock）。从 NMI 或从保留锁定后触发的跟踪点运行可能会死锁。使用 alloc_lock 上的 trylock 代替阻断 task_lock（） （get_task_mm），以避免在 softirq BPF 程序迭代已经在相同 CPU 上保留其alloc_lock的任务时死锁。（CVE-2026-53085）

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

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

  - fwctl：修复类 init 排序以避免设备删除时发生空指针取消引用 CXL 在 drivers/Makefile 中的 fwctl 之前链接。两者都使用“module_init，因此”cxl_pci_driver_init（）“首先运行。当“cxl_pci_probe（）”先调用“fwctl_register（）”，然后调用“device_add（）”时，由于 fwctl_init（） 尚未运行而尚未注册fwctl_class，从而导致“class_to_subsys（）”返回空值并跳过knode_class初始化。删除设备时，“class_to_subsys（）”返回非空值，而“device_del（）”在未初始化的 knode 上调用“klist_del（）”，从而触发空指针取消引用。（CVE-2026-53042）

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

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

  - ipv4：限制IPOPT_SSRR和IPOPT_LSRR选项 此修补程序将 Loose Source and Record Route （LSRR） 和 Strict Source and Record Route （SSRR） IP 选项设置为具有CAP_NET_RAW能力的用户进行限制。
    这可以防止非特权应用程序强制数据包通过攻击者控制的节点进行路由，从而泄漏 TCP ISN 以及其他协议信息。尽管 LSRR 和 SSRR 通常在许多网络环境中受到过滤，但它们仍可能在某些网络路径上受到支持和转发。RFC 7126（关于过滤包含 IPv4 选项的 IPv4 数据包的建议）建议在 和 4.4中4.3删除这些选项。（CVE-2026-53249）

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

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

  - netfilter：synproxy：添加互斥体以保护挂钩引用计数 当用户添加第一个 iptables 目标或 nftables 表达式时，作为 synproxy 基础架构注册 netfilter 挂钩，如果并发执行，它们可相互争用。引入互斥体以序列化 refcount 控制阻止来自两个前端的访问。尽管每个命名空间互斥体可能更有效，但目标/表达式（如 SYNPROXY）不需要它。（CVE-2026-53269）

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

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

  - RDMA/core：验证传入 fops 以进行 ib_get_ucaps（） Sashiko 指出仅依赖 devt 并不安全，因为 char/block 别名，因此如果用户找到具有相同dev_t的区块设备，则可伪装成 ucap cdev fd。测试 f_ops 以仅接受正版 cdev。（CVE-2026-53188）

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

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

  - ovl：成功 ovl_cache_get（） 之后保持 err 零 ovl_iterate_merged（） 在检查 IS_ERR（cache） 之前将 err 中的 PTR_ERR（cache） 存储在错误中。成功时，err 会保留截断的缓存指针，并可作为虚假的非零错误返回。syzbot 重现程序通过 overlay-on-overlay readdir： getdents64 iterate_dir（（外部叠加文件） ovl_iterate_merged（） ovl_cache_get（） ovl_dir_read_merged（） ovl_dir_read（） iterate_dir（内部叠加文件） ovl_iterate_merged（） 仅计算错误路径上的PTR_ERR（缓存）。
    (CVE-2026-53174)

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

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

  - net/sched：act_api：为操作生命周期使用延迟释放的 RCU 当 NEWTFILTER 和 DELFILTER 并发运行时，可通过相关操作创建争用。我们用 CPU0 运行 NEWTFILTER 且 CPU1 运行 DELFILTER 来说明： 0： mutex_lock（） <-- 保持 idr 锁定 0： rcu_read_lock（） 0： p = idr_find（idr， index） <-- 操作 p 有效（RCU 保护 IDR） 0： mutex_unlock（） <-- 释放 idr 锁定 1： refcount_dec_and_mutex_lock（） <-- refcnt 1->0， 互斥锁保持 1： idr_remove（idr， index） <-- 从 IDR 1 删除操作：mutex_unlock（） < -- 互斥体已释放，允许我们删除操作 1：
    tcf_action_cleanup（p）;kfree（p） <-- 立即 Kfrees p，无延迟 0：
    refcount_inc_not_zero（&p->tcfa_refcnt） < -- 哎哟，UAF p 指向已释放的内存 此修补程序修复了 NEWTFILTER 和 DELFILTER 之间的争用条件，方法是将结构rcu_head添加到延迟中使用的tc_action并在删除路径中引入 call_rcu（） 以延迟最终的 kfree（）。注意：这是提交 d7fb60b9cafb 的恢复（net_sched：去掉 tcfa_rcu），也是直接使用 kfree_rcu（） 的现代化/简化操作。让我们来说明新还原的代码路径： 0： rcu_read_lock（） 1：
    refcount_dec_and_mutex_lock（） <-- refcnt 1->0，互斥体保持 1：idr_remove（idr， index） 1：mutex_unlock（） 1：
    call_rcu（&p->tcfa_rcu， tcf_action_rcu_free） < -- 宽限期 0 后延迟 kfree： p = idr_find（idr， index） 0： refcount_inc_not_zero（&p->tcfa_refcnt） <-- 失败，refcnt already 0 1： rcu_read_unlock（） < -- 释放，以便在宽限期后可以运行释放 CPU1 调用 idr_remove（） 后，无法再通过 IDR 访问对象。CPU0 的后续 idr_find（） 将返回 NULL，即使它仍然保留着一个过时指针，立即的 kfree（） 现在也会被推迟到 RCU 宽限期之后，因此不会发生 UAF。
    (CVE-2026-53264)

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

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

  - 恢复 drm/xe：如果暂停期间队列处于空闲状态，则跳过 exec 队列计划切换 这会恢复提交 8533051ce92015e9cc6f75e0d52119b9d91610b6。idle-skip 优化绕过 GuC 挂起，因此 GPU 可能不会执行为无效的 userptr VMA 刷新 TLB 条目的上下文切换。在 LR/preempt-fence VM 模式中，userptr 无效测试期间，这可能会造成错过 TLB 无效以及发生页面错误。
    在暂停时还原无条件的计划切换，以便始终执行上下文切换 TLB 刷新。
    此优化将通过不会跳过 LR/preempt-fence VM 模式中的暂停的补丁重新引入。
    （从提交 6a1e7934d9a6cf46aecae00a99c2603d1295e170 中精选出的内容）（CVE-2026-53201）

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

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

  - drm/amd/display：限制 HDMI HDCP2 rx_id_list读取到缓冲区大小 [原因和方式] 在通过 HDMI 进行 HDCP 2.x 中继器认证期间，驱动程序会读取接收器的 RxStatus 寄存器并提取 10 位消息大小字段（最大值 1023）。此值用作 ReceiverID 列表的读取长度，而不会限制到目标缓冲区的大小 rx_id_list[177]。恶意 HDMI 中继器可公告大于缓冲区大小的消息，从而导致 I2C 读取期间的越界写入。将 mod_hdcp_read_rx_id_list（） 中的读取长度限制为rx_id_list缓冲区的大小，与 DP 分支中已经使用的方法相匹配。（从提交 229212219e4247d9486f8ba41ef087358490be09 中精选出的内容）（CVE-2026-53137）

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

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

  - gpio：rockchip：修复删除时的通用 IRQ 芯片泄漏 驱动程序在探测过程中使用 irq_alloc_domain_generic_chips（） 分配域通用芯片。但是，在删除/拆卸驱动程序时，删除 IRQ 域时不会自动释放通用芯片，因为域标记不包含IRQ_DOMAIN_FLAG_DESTROY_GC。这会同时造成域通用芯片结构和相关的通用芯片泄露。此外，通用芯片仍保留在全局gc_list中，随后可能会在删除 GPIO 库之后被通用 IRQ 芯片挂起、恢复或关闭回调访问，从而可能导致释放后使用和内核崩溃。修复了在删除 rockchip_gpio_remove（） 中的 IRQ 域之前通过显式调用 irq_domain_remove_generic_chips（） 造成的资源泄漏。
    (CVE-2026-53226)

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

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

  - ipv6：sit：GSO 卸载后重新加载内部 IPv6 标头 ipip6_tunnel_xmit（） 在函数进入处缓存内部 IPv6 标头指针，并在 iptunnel_handle_offloads（） 之后继续使用。对于 GSO skbs，iptunnel_handle_offloads（） 调用 skb_header_unclone（）。当 skb 标头被克隆时，skb_header_unclone（） 可以调用 pskb_expand_head（），这可能会移动 skb 头。pskb_expand_head（） 合约要求在调用后重新加载 skb 标头的指针。如果未采用后面的 skb_realloc_headroom（） 分支，SIT 将使用过时的 iph6 指针读取内部跳数限制和 DS 字段。这可在释放旧头的剩余克隆后从释放的 skb 头读取。在卸载帮助程序成功之后以及从内部 IPv6 标头进行后续读取之前重新加载 iph6。skb_realloc_headroom（） 之后保留现有的重新加载，因为该分支也可以替换 skb。（CVE-2026-53228）

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

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

  - wifi：mt76：mt7996：修复 mt7996_mac_dump_work（） 中的释放后使用缺陷 当 mt7996 pci 芯片分离时，mt7996_crash_data在 mt7996_coredump_unregister（） 中释放。但是，工作项dump_work可能仍在运行或待定，从而导致在 mt7996_mac_dump_work（） 中再次取消引用已释放crash_data时出现 UAF 缺陷。争用条件可能在如下方式发生：CPU 0（删除路径）|CPU 1（工作队列）mt7996_pci_remove（） |mt7996_sys_recovery_set（） mt7996_unregister_device（） |mt7996_reset（） mt7996_coredump_unregister（） |queue_work（） vfree（dev->coredump.crash_data） |mt7996_mac_dump_work（） |crash_data-> // UAF 通过确保在取消分配crash_data前正确取消dump_work来修复此问题。在 mt7996_unregister_device（） 中添加 cancel_work_sync（） 以与任何待定或正在执行的转储工作同步。（CVE-2026-53097）

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

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

  - netfilter: 在使用 eth_hdr() `ip6t_eui64`, `xt_mac`, `bitmap:ip,mac`, `hash:ip,mac`, 和 `hash:mac` ipset 类型之前，需要要求以太网 MAC 头；以及 `nf_log_syslog` 在假设 sk_buff 与以太网设备相关联或仅检查 `skb_mac_header(skb)` 处的 `ETH_HLEN` 字节位于 `skb->head` 和 `skb->data` 之间后访问 `eth_hdr(skb)`。确保在访问 `eth_hdr(skb)` 之前，首先验证这些路径中的 skb 是否与一个以太网设备关联，MAC 头是否已设置，并且它至少跨越了一个完整的以太网头。（ CVE-2026-53131 ）

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

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

  - drm/xe：修复 xe_exec_queue_create_ioctl（） 中的错误清理 xe_exec_queue_create_ioctl（） 中存在两个错误处理问题： 1. 当 xe_hw_engine_group_add_exec_queue（） 失败时，错误路径会跳至跳过 xe_exec_queue_kill（） put_exec_queue。如果 VM 处于抢占隔离模式，则 xe_vm_add_compute_exec_queue（） 已将队列添加到 VM 的 compute exec 队列列表。跳过终止会将队列留在该列表中，从而导致队列释放后出现悬摆指针。2. 当 xe_hw_engine_group_add_exec_queue（） 成功后 xa_alloc（） 失败时，错误路径不会调用 xe_hw_engine_group_del_exec_queue（） 从 hw 引擎群组列表中删除队列。队列随后会在仍链接至 hw 引擎群组时释放，进而造成释放后使用。通过以下方式同时修复这两个问题：- 更改 xe_hw_engine_group_add_exec_queue（） 失败路径以跳至kill_exec_queue，以便 xe_exec_queue_kill（） 从 VM 的计算列表中正确删除队列。- 在为 xa_alloc（） 失败路径kill_exec_queue前添加del_hw_engine_group标签，以在继续进行其余清理之前从 hw 引擎群组中删除队列。（从提交 37c831f401746a45d510b312b0ed7a77b1e06ec8 中精选出的内容）（CVE-2026-52976）

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

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

  - netfilter：conntrack_irc：修复可能的越界读取 如果匹配命令字符串后解析失败，我们应退出而不是尝试匹配其他命令。鉴于 TLS 的流行，我怀疑它在 2026 年有任何相关性，此帮助程序应该弃用。（CVE-2026-53268）

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

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

  - mailbox： mailbox-test：不释放重用的通道 如果 RX 通道具有不同的 MMIO，则该通道可以别名设置为 TX 通道。此特殊情况需要在释放通道时处理，否则将发生双重释放。（CVE-2026-53294）

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

ID	名称	严重性
323501	Linux Distros 未修补的漏洞：CVE-2026-53123	medium
323500	Linux Distros 未修补的漏洞：CVE-2026-53172	high
323499	Linux Distros 未修补的漏洞：CVE-2026-12244	high
323498	Linux Distros 未修补的漏洞：CVE-2026-42388	medium
323497	Linux Distros 未修补的漏洞：CVE-2026-53252	medium
323496	Linux Distros 未修补的漏洞：CVE-2026-53241	medium
323495	Linux Distros 未修补的漏洞：CVE-2026-52978	medium
323494	Linux Distros 未修补的漏洞：CVE-2026-53210	medium
323493	Linux Distros 未修补的漏洞：CVE-2026-53164	medium
323492	Linux Distros 未修补的漏洞：CVE-2026-8343	medium
323491	Linux Distros 未修补的漏洞：CVE-2026-53235	high
323490	Linux Distros 未修补的漏洞：CVE-2026-53198	high
323489	Linux Distros 未修补的漏洞：CVE-2026-53013	medium
323488	Linux Distros 未修补的漏洞：CVE-2026-52996	medium
323486	Linux Distros 未修补的漏洞：CVE-2026-53229	high
323485	Linux Distros 未修补的漏洞：CVE-2026-53155	medium
323484	Linux Distros 未修补的漏洞：CVE-2026-53190	medium
323483	Linux Distros 未修补的漏洞：CVE-2026-53314	medium
323482	Linux Distros 未修补的漏洞：CVE-2026-53237	medium
323481	Linux Distros 未修补的漏洞：CVE-2026-53197	medium
323480	Linux Distros 未修补的漏洞：CVE-2026-53124	medium
323479	Linux Distros 未修补的漏洞：CVE-2026-53132	high
323478	Linux Distros 未修补的漏洞：CVE-2026-53287	medium
323477	Linux Distros 未修补的漏洞：CVE-2026-53162	high
323476	Linux Distros 未修补的漏洞：CVE-2026-53220	medium
323475	Linux Distros 未修补的漏洞：CVE-2026-53170	high
323474	Linux Distros 未修补的漏洞：CVE-2026-53095	medium
323473	Linux Distros 未修补的漏洞：CVE-2026-53150	medium
323472	Linux Distros 未修补的漏洞：CVE-2026-53258	medium
323471	Linux Distros 未修补的漏洞：CVE-2026-53244	high
323470	Linux Distros 未修补的漏洞：CVE-2026-53183	high
323469	Linux Distros 未修补的漏洞：CVE-2026-53028	medium
323468	Linux Distros 未修补的漏洞：CVE-2026-53058	medium
323467	Linux Distros 未修补的漏洞：CVE-2026-53270	high
323466	Linux Distros 未修补的漏洞：CVE-2026-53085	medium
323465	Linux Distros 未修补的漏洞：CVE-2026-53042	medium
323464	Linux Distros 未修补的漏洞：CVE-2026-53249	medium
323463	Linux Distros 未修补的漏洞：CVE-2026-53269	medium
323462	Linux Distros 未修补的漏洞：CVE-2026-53188	high
323461	Linux Distros 未修补的漏洞：CVE-2026-53174	high
323460	Linux Distros 未修补的漏洞：CVE-2026-53264	high
323459	Linux Distros 未修补的漏洞：CVE-2026-53201	high
323458	Linux Distros 未修补的漏洞：CVE-2026-53137	high
323457	Linux Distros 未修补的漏洞：CVE-2026-53226	medium
323456	Linux Distros 未修补的漏洞：CVE-2026-53228	critical
323455	Linux Distros 未修补的漏洞：CVE-2026-53097	high
323454	Linux Distros 未修补的漏洞：CVE-2026-53131	critical
323453	Linux Distros 未修补的漏洞：CVE-2026-52976	high
323452	Linux Distros 未修补的漏洞：CVE-2026-53268	high
323451	Linux Distros 未修补的漏洞：CVE-2026-53294	high

检测

Nessus 的 Misc. 系列

medium

high

high

medium

medium

medium

medium

medium

medium

medium

high

high

medium

medium

high

medium

medium

medium

medium

medium

medium

high

medium

high

medium

high

medium

medium

medium

high

high

medium

medium

high

medium

medium

medium

medium

high

high

high

high

high

medium

critical

high

critical

high

high

high