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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：VFS: fix possible failure to unlock in nfsd4_create_file() atomic_create() in fs/namei.c drops the reference to the dentry when it returns an error. This behaviour was imported into dentry_create() so that it will drop the reference if an error is returned from atomic_create(), though not if vfs_create() returns an error (in the case where
    ->atomic_create is not supported). The caller - nfsd4_create_file() - is made aware of this by checking path->dentry, which will either be a counted reference to a dentry, or an error pointer. However the change to use start_creating()/end_creating() (which landed shortly before the dentry_create() change landed, though was likely developed around the same time) means that nfsd4_create_file() *needs* a valid dentry so that it can unlock the parent. The net result is that if NFSD exports a filesystem which uses
    ->atomic_create, and if a call to ->atomic_create returns an error, then nfsd4_create_file() will pass an error pointer to end_creating() and the parent will not be unlocked. Fix this by changing dentry_create() to make sure path->dentry is always a valid dentry, never an error-pointer. The actual error is already returned a different way. Note that if ->atomic_create() returns a different dentry (which may not be possible in practice) we are guaranteed (because it is only ever provided by d_spliace_alias()) that it will have the same d_parent and so it will have the same effect when passed to 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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：usb: typec: Fix error pointer dereference The variable tps->partner is checked for an error pointer and then if it is, it sends an error message but does not return and then immediately dereferenced a few lines below: 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; } Add early return and fix spelling mistake in error message. Detected by Smatch: drivers/usb/typec/tipd/core.c:827 cd321x_update_work() error: 'tps->partner' dereferencing possible 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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：ovl: keep err zero after successful ovl_cache_get() ovl_iterate_merged() stores PTR_ERR(cache) in err before checking IS_ERR(cache). On success err holds the truncated cache pointer and can be returned as a bogus non-zero error. The syzbot reproducer reaches this through overlay-on-overlay readdir: getdents64 iterate_dir(outer overlay file) ovl_iterate_merged() ovl_cache_get() ovl_dir_read_merged() ovl_dir_read() iterate_dir(inner overlay file) ovl_iterate_merged() Only compute PTR_ERR(cache) on the error path. (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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：Revert drm/xe: Skip exec queue schedule toggle if queue is idle during suspend This reverts commit 8533051ce92015e9cc6f75e0d52119b9d91610b6. The idle-skip optimization bypasses GuC suspend, so the GPU may not perform the context switch that flushes TLB entries for invalidated userptr VMAs. In LR/preempt-fence VM mode, this can lead to missed TLB invalidation and page faults during userptr invalidation tests.
    Restore unconditional schedule toggling on suspend so the context-switch TLB flush is always performed.
    This optimization will be reintroduced with a fix that does not skip suspend in LR/preempt-fence VM mode.
    (cherry picked from commit 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 依赖供应商报告的程序包是否存在进行判断。

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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：iommu: Fix WARN_ON in
    __iommu_group_set_domain_nofail() due to reset In __iommu_group_set_domain_internal(), concurrent domain attachments are rejected when any device in the group is recovering. This is necessary to fence concurrent attachments to a multi-device group where devices might share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in __iommu_group_set_domain_nofail(). Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should not be rejected, as the domain would be freed anyway in these nofail paths while group->domain is still pointing to it. So pci_dev_reset_iommu_done() could trigger a UAF when re-attaching group->domain. Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through the group->recovery_cnt fence, so as to update the group->domain pointer. Instead add a gdev->blocked check in the device iteration loop, to prevent any concurrent per-device detachment. (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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：ptp: ocp: fix resource freeing order Commit a60fc3294a37 (ptp: rework ptp_clock_unregister() to disable events) added a call to ptp_disable_all_events() which changes the configuration of pins if they support EXTTS events. In ptp_ocp_detach() pins resources are freed before ptp_clock_unregister() and it leads to use-after-free during driver removal. Fix it by changing the order of free/unregister calls. To avoid irq handler running on the other core while ptp device unregistering, call synchronize_irq() after HW is configured to stop producing irqs and no irqs are in-flight. (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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：um: Fix potential race condition in TLB sync During the TLB sync, we need to traverse and modify the page table, so we should hold the page table lock. Since full SMP support for threads within the same process is still missing, let's disable the split page table lock for simplicity. (CVE-2026-53020)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: phy: don't try to setup PHY-driven SFP cages when using genphy We don't have support for PHY-driver SFP cages with the genphy code. On top of that, it was found by sashiko that running sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY probing runs under RTNL, which isn't the case for non-genphy drivers. This problem was reproduced, and does lead to a deadlock on RTNL. Before the blamed commit, the phy_sfp_probe() call was made by individual PHY drivers, so there was no way to get to the SFP probing path when using genphy.
    Let's therefore only run phy_sfp_probe when not using genphy. (CVE-2026-53231)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/gem: Try to fix change_handle ioctl, attempt 4 [airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far: 5e28b7b94408 (drm: Set old handle to NULL before prime swap in change_handle) tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong: - There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 (drm/gem: fix race between change_handle and handle_delete) tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong. - dc366607c41c (drm: Replace old pointer to new idr) tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix. We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now.
    Very clearly that's not the case. Here's my attempt to sort this out: - Rename the local variable to new_handle, the old aliasing with args->handle is just too dangerously confusing. - Merge the gem obj lookup with the two-stage idr_replace so that we avoid getting ourselves confused there. - This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gem_close on the new_handle could steal that. Fix that with the same two-stage approach create_tail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia. - Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idr_replace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit. - While at it, also replace the 7 space indent with 1 tab. And finally, because I flat out don't trust my abilities here at all anymore: - Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus. v2: Sashiko noticed that I didn't handle the error path for idr_replace correctly, it must be checked with IS_ERR_OR_NULL like in gem_handle_delete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky. Also add the Fixes: line for the original ioctl, I forgot that too. (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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：fs/ntfs3: prevent uninitialized lcn caused by zero len syzbot reported a uninit-value in ntfs_iomap_begin [1]. Since runs was not touched yet, run_lookup_entry() immediately fails and returns false, which makes the value of *len 0. Simultaneously, the new value and err value are also 0, causing the logic in attr_data_get_block_locked() to jump directly to ok, ultimately resulting in *lcn being triggered before it is set [1]. In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward to before updating lcn to avoid this [1]. [1] BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110 Local variable lcn created at:
    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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：drm/xe/dma-buf: fix UAF with retry loop Retry doesn't work here, since bo will be freed on error, leading to UAF. However, now that we do the alloc & init before the attach, we can now combine this as one unit and have the init do the alloc for us.
    This should make the retry safe. Reported by Sashiko. v2: Fix up the error unwind (CI) (cherry picked from commit 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 依赖供应商报告的程序包是否存在进行判断。

ID	名称	严重性
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
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

检测

Nessus 的 Misc. 系列

medium

high

high

medium

medium

high

medium

medium

medium

medium

high

high

high

high

high

medium

critical

high

critical

high

high

high

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