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

  - net：bridge：arp/nd 代理：修复读取邻居 ha 目前会直接读取邻居 ha 地址，但如果正在更新邻居，可导致撕裂/部分读取。请使用 neigh_ha_snapshot 获取地址的稳定快照。（CVE-2026-90106）

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

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

  - ip6mr：不在 ip6mr_cache_report（） 中克隆 dst IPv6 输入将非引用计数 （NOREF） dst 附加到 RCU 下的 skbs。当入口组播数据包缺少 MFC 查找时，ip6mr_cache_unresolved（） 会将 skb 放置到未解析的队列中，从而转义接收端 RCU 宽限期。如果删除并释放了底层路由，并且之后使用错误的父接口解析了 MFC 队列，则 ip6_mr_forward（） 将调用 ip6mr_cache_report（...， MRT6MSG_WRONGMIF），这将在释放的 dst 条目上执行 dst_clone（skb_dst（pkt）），从而触发 slab 释放后使用。排入队列到 mroute6_sk（原始套接字）和 netlink 通知的报告数据包不需要附加的 dst 条目。通过以下方式修复此问题：1. 删除 ip6mr_cache_report（） 中的 dst_clone（） 并确保报告 skb 不包含 dst。2. 在 ip6mr_cache_unresolved（） 中排队未解析的 skb 之前丢弃 skb_dst，与组播转发通过 ip6_route_output（） 重新解析传出路由的事实相匹配。（CVE-2026-90111）

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

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

  - RDMA/mlx5：修复 debugfs cc_params堆栈越界读取 get_param（） 将拥塞参数读取为 u32，但将其具有签名的 %d 格式化为 11 字节堆栈缓冲区。设置了位 31 的值（例如 0x80000000）显示为 -2147483648\n ，其全长为 12。snprintf（） 仅存储 11 个字节，却返回 12，因此 simple_read_from_buffer（） 将 12 字节视为有效字节，并读取超出 lbuf[] 的一个字节。为最宽的无符号小数设置缓冲区大小，使用 %u 格式以匹配 u32，并使用 scnprintf（），以便传递给 simple_read_from_buffer（） 的长度反映实际存储的字节。（CVE-2026-90416）

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

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

  - fs/resctrl：修复删除域时工作线程中的 UAF mbm_handle_overflow（） 和 cqm_handle_limbo（） 工作线程会读取事件计数器，并在此期间可能休眠。它们通过 struct rdt_l3_mon_domain 中嵌入的 delayed_work 进行计划。架构在 cpus_write_lock（） 下分配这些域并将其从其中释放出来，工作线程获取 cpus_read_lock（） 以保持域跨其访问活动。当工作线程被阻断等待 cpus_read_lock（） 而热插拔核心保留 cpus_write_lock（） 时，可能会发生释放后使用：架构释放包含工作线程work_struct的rdt_l3_mon_domain。当工作线程取消阻断时，它对嵌入的工作指针执行的 container_of（） 会取消引用已释放的内存。从工作线程中删除 cpus_read_lock（），而是在架构释放域之前同步耗尽待定和正在进行的工作。
    由于架构在从 RCU 列表取消链接且宽限期过后，将 cpus_write_lock（） 下的域离线，因此无法安排新的工作。取消只需要等待现有工作结束。在 cancel_delayed_work_sync（） 附近的 CPU 脱机期间丢弃rdtgroup_mutex，以便在 mutex 上等待的工作线程在将工作重新固定到其他 CPU 之前完成。当 CPU 脱机时，架构可能以任何顺序迭代资源。例如，MBA 控制域可能在相应的 L3 监控域之前或之后脱机。确保无论架构以何种顺序使域脱机，resctrl fs 都会取消工作线程。（CVE-2026-93099）

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

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

  - wifi：ath11k：修复 ath11k_service_ready_ext_event（） 中的泄漏 目前，在 ath11k_service_ready_ext_event（） 处理期间，可在 TLV 解析期间分配 svc_rdy_ext.mac_phy_caps。
    这是在成功路径上释放的临时分配，而不是在错误路径上释放。如果解析成功到足以分配mac_phy_caps，然后在更高的 TLV 上失败，则分配会泄露。因此释放错误路径上的分配。仅测试编译文件。(CVE-2026-90361)

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

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

  - iomap：在 iomap 回调失败时发布 folio 批次 对不相关修补程序的 sashiko 审查指出，在一些错误情况下，用于 iomap 零范围的 folio 批处理机制无法释放批次。如果调用 ->iomap_end（） 或 ->iomap_begin（） 失败，则直接返回路径将绕过批量清理。当前不存在 ->iomap_end（） 情况，因为没有机制的用户可从此路径返回错误。理论上可发生 ->iomap_begin（） 情况，因为 XFS 可调用填充帮助程序，并在此后的多个时间点出错。这会稍微使事情复杂化，因为 XFS 不会将iomap_flags传输至错误路径中的 iomap 数据结构。要处理这两个问题，首先确保在任一 fs 回调的错误路径中调用清除帮助程序。其次，更新帮助程序以无条件清除标记，只要已填充批次就将其释放。这更清楚地描述了标记用于控制 I/O 路径的目的，而不一定是 fbatch 的状态，因此也围绕此添加了注释。（CVE-2026-90384）

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

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

  - ksmbd：绑定 smb_check_perm_dacl（） ACE 遍历 DACL 大小 smb_check_perm_dacl（） 验证 DACL 是否适合 NT 安全描述符，但随后按剩余的 NTSD 长度 （acl_size） 而不是 DACL 声明的大小 （pdacl_size） 限制其两个 ACE 遍历。当 pdacl->size 小于尾部 NTSD 缓冲区时，声明的 DACL 边界之后的字节数仍在存储的安全描述符内
    - 在访问检查期间作为 ACE 进行解析。构建的 DACL 可将授予访问权限的 ACE 置于 pdacl->size 之外，当前代码会在SMB2_CREATE访问验证期间接受它，而 parse_dacl（） 和 smb_inherit_dacl（） 会在pdacl_size处停止。按pdacl_size绑定两个 ACE 遍历，以匹配服务器中其他位置使用的 DACL 边界语义。验证： - 语义 KUnit 线程显示边界后 ACE 在修复前被选中并在修复后被拒绝 （EACCES） - Linux 主控 （7.2-rc6）、x86_64 （CVE-2026-90153）

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

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

  - amt：不支持 cross-netns 设置。当较低设备取消注册时，amt_device_event（） 会尝试取消注册其较高 AMT 设备，但它有两个问题。1. amt_lookup_upper_dev（） 仅在下层设备的 netns 中查找上层设备 2.amt_device_event（） 仅取消注册单个上层设备 如果在另一个网络中的较低设备上创建 AMT 设备，则删除较低设备将触发下面的 splat 并卡住，直到删除所有上层设备。[0] 考虑到 1.以及以下几点： * amt_link_setup（） 将 dev->netns_immutable 设置为 true * 在快速路径中未调用 skb_scrub_packet（） * iproute2 二进制未能通过 link-netns 找到 cross-netns 低层设备： # ip -n ns1 link add amt0 link-netns ns2 type amt dev veth1 找不到设备 veth1，而是未正确支持它并为每个 netns 的 netdev unreg 做准备， 禁止 cross-netns 设置。请注意，问题 2.需要单独的补丁。[0]： WARNING： net/core/dev.c：12518 at unregister_netdevice_many_notify+0x1cce/0x2250， CPU#48： ip/2031 模块链接于： CPU： 48 UID： 0 PID：
    2031 通信：ip 未受感染 7.2.0-rc5+ #27 PREEMPT（完整） 硬件名称：QEMU Standard PC （i440FX + PIIX，1996），BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP：0010：unregister_netdevice_many_notify （net/core/dev.c：12518） 代码：89 EF E8 D5 52 AE FE E9 D0 F4 FF FF 48 8D 3D F9 3B 9C 02 48 C7 C6 C0 0B 63 84 BA AB 1F 00 00 67 48 0F B9 3A E9 65 FF FF 90 <0f> 0b 90 eb 81 48 8d 3d f6 3b 9c 02 48 c7 c6 c0 0b 63 84 ba e2 1f RSP： 0018：ffffc90004abf160 EFLAGS： 00010212 RAX： ffff888104d38260 RBX： ffff88800b0911b8 RCX：
    dffffc0000000000 RDX： 00000000000000000 RSI： 0000000000000008 RDI： ffffffff85b9f880 RBP： ffffc90004abf2d0 ： ffffffff85b9f887 R09： 1ffffffff0b73f10 R10： dffffc0000000000 R11： ffffffbffff0b73f11R12：R08
    ffff88800b091d08 R13： ffff88800b091178 R14： dffffc0000000000 R15： ffff88800b091000 FS：
    00007f555b86c600（0000） GS：ffff8881942a0000（0000） knlGS：0000000000000000 CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 CR2：0000562107d489c0 CR3：0000000109a40002 CR4：0000000000372ef0 调用跟踪： <TASK> rtnl_dellink （net/core/rtnetlink.） c：3632 net/core/rtnetlink.c：3674） rtnetlink_rcv_msg （net/core/rtnetlink.c：7112） netlink_rcv_skb （net/netlink/af_netlink.c：2556） netlink_unicast （net/netlink/af_netlink.c：1319） netlink_sendmsg （net/netlink/af_netlink.c：1900） ____sys_sendmsg （net/socket.c：775） __sys_sendmsg （net/socket.c：2738） do_syscall_64 （arch/x86/entry/syscall_64.c：63）entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） ...unregister_netdevice：等待 veth0 释放。使用计数 = 7 ref_tracker：netdev@ffff88800d7496d8有 3/3 的用户
    __netdev_adjacent_dev_insert （./include/linux/netdevice.h：4525 ./include/linux/netdevice.h：4554 net/core/dev.c：8791） __netdev_upper_dev_link （net/core/dev.c：8879 net/core/dev.c：8963） netdev_upper_dev_link （net/core/dev.c：9009） amt_newlink （drivers/net/amt.c：3321） （CVE-2026-90232）

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

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

  - crypto：rk3288 - HASH 空闲超时时 ahash 请求失败 rk_hash_run（） 在最终 DMA 传输后等待 RK_CRYPTO_HASH_STS 变为空闲，但忽略轮询结果。如果哈希引擎从未空闲，驱动程序仍会读取摘要寄存器并使用之前的成功值完成请求。存储轮询结果并在读取摘要寄存器之前完成包含超时错误的请求。（CVE-2026-93156）

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

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

  - NFSv4.2：修复 LAYOUTSTATS 发送缓冲区耗尽encode_layoutstats_maxsz预算 XDR_QUADLEN（PNFS_LAYOUTSTATS_MAXSIZE），即布局驱动程序写入的 layoutupdate4 正文的 256 字节。flexfiles 记录可以超过该值。ff_layout_encode_ff_layoutupdate（） 在每个数据服务器上发出一个 netaddr4、一个 nfs_fh4、两个ff_io_latency4、一个 nfstime4 和一个 bool。文件句柄长度为 NFS_MAXFHSIZE 字节的数据服务器已占其中的 132 个字节，两个字节ff_io_latency4各为 64 字节，即 nfstime4 和 bool，再加 144 字节，因此正文会在完全编码 netaddr4 之前传递 256 字节。encode_layoutstats（） 还将 deviceID4 和 layoutupdate4 lou_type字写入，宏未考虑这两个字。文件句柄和地址均由服务器通过 LAYOUTGET 和 GETDEVICEINFO 选择，因此它可以驱动编码器通过发送缓冲区的末尾。
    一旦发生这种情况，xdr_reserve_space（） 会返回 NULL，并且两个 ff_layout_encode_io_latency（） 调用会在保留 dss_info->mirror->lock 的情况下运行，因此此处的 NULL 返回会使锁定永久保留。将PNFS_LAYOUTSTATS_MAXSIZE提高到 384，以便记录适合预留。（CVE-2026-90103）

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

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

  - cxl/mbox：中断空负载上的毒害列表循环 返回 count == 0 并在每次迭代时设置 CXL_POISON_FLAG_MORE 的设备永远不会nr_records前进，因此 max_errors 防护永远不会跳闸，并且在保留 poison.mutex 时 do/while 永远循环。这会挂起 sysfs 触发的扫描线程并封锁设备上所有后续的毒害操作。现有 防止未清理
    _FLAG_MORE防护的目的是限制行为不正确的设备，但不涵盖 count == 0 的情况。停止空负载上的循环，以便故障或恶意设备无法插入毒害扫描。
    (CVE-2026-93097)

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

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

  - PCI/sysfs：向旧 I/O 和内存处理程序添加锁定检查 当前，旧 I/O 和内存 sysfs 处理程序不会检查 security_locked_down（LOCKDOWN_PCI_ACCESS），从而导致 legacy_io 和 legacy_mem 文件在内核锁定时处于无保护状态。提交 eb627e17727e（PCI：锁定内核时锁定 BAR 访问）已新增对 pci_write_config（）、pci_mmap_resource（） 和 pci_write_resource_io（） 的检查，以防止用户空间对可用于修改内核代码但未涵盖旧版处理程序的支援 DMA 的硬件编程。因此，在内核锁定时，root 仍可写入任意 I/O 端口，并映射旧版 I/O 和内存空间，这与锁定预期删除的功能相同。对 pci_write_legacy_io（）、pci_mmap_legacy_mem（） 和 pci_mmap_legacy_io（） 添加相同的检查。这些通用处理程序涵盖定义HAVE_PCI_LEGACY的两种架构（例如 Alpha 和 PowerPC）。[bhelgaas：添加链接]（CVE-2026-90315）

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

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

  - iommu/tegra241-cmdqv：仅在完全初始化 LVCMDQ 后发布 tegra241_vintf_init_lvcmdq（） 将新分配的 vcmdq 指针存储到 vintf->lvcmdqs[] 数组，然后 tegra241_vcmdq_alloc_smmu_cmdq（） 构建 vcmdq->cmdq。错误 ISR 取消引用该 cmdq，因此在此窗口中触发锁存 LVCMDQ 错误（例如，在 kexec 中继承的错误）会使 tegra241_vintf0_handle_error（） 将仍为零的arm_smmu_cmdq传递到 __arm_smmu_cmdq_skip_err（），从而取消引用空队列寄存器指针。舍弃 tegra241_vintf_init_lvcmdq（） 的存储，并在分配结束时发布 vcmdq，并使用与 ISR 中的 smp_load_acquire（） 配对的 smp_store_release（），以便查看完全构建的 LVCMDQ 或 NULL。用户拥有的 LVCMDQ 分配会相应移动，一旦 tegra241_vcmdq_hw_init_user（） 成功，就会使用普通存储发布 vcmdq，因为用户 VINTF 的 lvcmdqs[] 没有无锁读取器 -- 错误 ISR 仅遍历 VINTF0 数组。（CVE-2026-90430）

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

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

  - iommu/vt-d：去除别名时使用正确的 SID 刷新上下文缓存 每个设备的每个 DMA 别名都会调用一次 domain_context_clear_one（） 和 device_pasid_table_teardown（）。每个函数都使用 pci_for_each_dma_alias（） 回调提供的总线/devfn 对定位上下文条目，然后调用 intel_context_flush_no_pasid（），后者从 info->bus 和 info->devfn（即始终为设备本身的请求者 ID）构造设备选择性上下文缓存无效。因此，对于除设备自身 RID 以外的每个别名，刚在内存中清除的上下文条目在上下文缓存中永远不会失效。硬件可能会继续使用该过时的缓存条目。在可扩展模式拆卸路径中，intel_pasid_free_table（） 随后可以释放仍然被该过时条目引用的 PASID 目录，从而允许 IOMMU 遍历已释放的内存。通过将被拆散的条目的源 ID 传递到 intel_context_flush_no_pasid（） 而不是从 @info 派生它来修复此问题。（CVE-2026-90240）

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

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

  - remoteproc：修复通过 rsc_table_for_each_entry（） 中的带符号偏移的 OOB 读取 table->offset[i] 是来自固件的 u32，但存储在带签名的 int 中。构建的偏移（如 0xFFFFFFF0）变为 -16，使 hdr 在表缓冲区之前放置 16 字节。后续的 avail 检查被绕过，因为负 int 在表达式 table_sz - offset - sizeof（*hdr） 中被提升为大size_t，从而产生大型正 avail 并让越界 hdr->type 读取继续进行而未被检测到。将偏移量存储为 u32，并在任何指针算法之前通过无符号比较对其进行验证。（CVE-2026-90314）

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

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

  - wifi：mt76：修复对 mt76_switch_vif_chanctx（） 中具有不同频段的通道上下文的处理 在短时间范围内在不同无线电上执行通道切换时，可针对每个结构ieee80211_vif_chanctx_switch携带具有不同频段的通道上下文。重构 mt76_switch_vif_chanctx（） 以正确处理这种情况。（CVE-2026-90381）

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

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

  - i3c：master：修复主控制器设备取消引用 master->this 的 master->this sysfs 属性回调的释放后使用。但是，master->this 会在释放主设备本身之前在 i3c_master_detach_free_devs（） 中释放。因此，sysfs 访问可取消引用已释放的 master->此指针，从而导致释放后使用。将 master->this 保持活动状态，直至 i3c_masterdev_release（），后者在主设备及其 sysfs 状态被拆散后调用。请勿将 master->this 释放为正常设备分离路径的一部分。在 i3c_master_set_info（） 的错误路径上，将 master->this 和 bus.cur_master 重置为空，然后再释放分配的设备。（CVE-2026-93200）

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

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

  - bpf、cgroup：修复__cgroup_bpf_attach失败后的无效存储访问 替换 cgroup bpf 程序后，可能会出现无效的存储访问问题。在以下情况下会发生这种情况：1. 具有存储空间的 Prog1 在多连接模式下连接到 cgroup。2. 在多连接模式下使用 BPF_F_REPLACE 将 prog1 替换为 prog2，但在中途失败（例如在 bpf_trampoline_link_cgroup_shim 或 update_effective_progs 中）。3. 新的 prog3 以多连接模式附加到 cgroup。原因是
    __cgroup_bpf_attach在附件完成之前就使用新存储来覆盖 PL->storage。附件中途失败时，清除路径会调用 bpf_cgroup_storages_free（new_storage） 以释放新分配的存储，但无法将 pl->storage 还原回old_storage。因此，仍然活动的 prog1 保留了无效或悬摆的存储指针，从而导致在执行 prog1 并调用 prog1 时bpf_get_local_storage无效的内存访问。此外，不会还原原始的 pl->flags 和 cgrp->bpf.flags[atype]。修复此问题，方法是在更新前保存 old_pl_flags、old_storage 和 old_flags，并在出错时将它们全部正确还原到清理路径中。（CVE-2026-90313）

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

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

  - dax：在 dax_holder_notify_failure（） 中读取holder_ops一次 dax_holder_notify_failure（） 在无 READ_ONCE（） 的情况下读取 dax_dev->holder_ops 两次 -- 这两次用于 NULL 检查，一次用于间接 notify_failure（） 调用。并发 fs_put_dax（） 可清除两次读取之间的holder_ops，因此检查可在调用取消引用 NULL 时观察到非空指针。（kill_dax（） 也会清除 holder_ops，但仅限于 synchronize_srcu（） 之后），因此它不能与 dax_read_lock（） 内部的阅读器争用;fs_put_dax（） 不进行此类同步。使用 READ_ONCE（） 将holder_ops提取到本地一次，以便空检查和间接调用观察到相同的值。（CVE-2026-93073）

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

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

  - platform/x86：lg-laptop：修复 LED 资源处理 事件通知回调可能访问 kbd_backlight，即使它未成功向 LED 子系统注册。acpi_remove（） 内部也会发生同样的情况，其中 LED 设备会无条件取消注册。通过跟踪 kbd_backlight LED 设备的可用性并使用 devm_led_classdev_register（） 让 devres 在删除期间负责取消 LED 设备的注册，从而修复此问题。为此，LED 设备的父设备将更改为本机平台设备。（CVE-2026-93128）

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

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

  - firmware：arm_scmi：在回调之前发布通道状态传输设置可以在设置例程返回之前启用回调。mailbox_chan_setup（） 通过 mbox_request_channel（） 注册邮箱客户端，邮箱控制器启动路径可在发布 SCMI 邮箱通道状态之前启用中断传递。同样，smc_chan_setup（） 在 SMC 传输使其 cinfo 指针可见之前请求可选的 A2P 完成 IRQ。如果在这些窗口中触发挂起或虚假回调，传输 RX 回调可能会取消引用空传输 cinfo 指针。仅发布 transport-private 指针也不足够：在 scmi_chan_setup（） 分配 cinfo->handle 之前，早期回调可进入 SCMI 核心。核心从 RX 路径中的 cinfo->handle 派生scmi_info，因此即使传输私有 cinfo 有效，空句柄仍可能出错。在调用传输设置回调之前分配 cinfo->handle。在请求邮箱通道或 IRQ 之前发布邮箱和 SMC 传输专用通道状态，并在设置失败时再次清除之前发布的指针。此外，在发生故障时展开邮箱设置 devres 资源，这样核心忽略的可选 RX 设置错误不会留下过时的传输状态。（CVE-2026-93093）

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

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

  - wifi：mt76：mt7915：避免 mt7915_mcu_get_sta_nss 中的 nss 下溢 如果对等机的 VHT/HE MCS 映射没有受支持的空间流（所有字段0x3），则循环将退出并返回 nss == 0，函数返回 （u8）-1 （255），然后将其写入固件sta_rec_bf波束成形字段。将结果限制为 0。
    (CVE-2026-90372)

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

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

  - arm64：process：修复上下文切换 MTE 仅存储标记检查SCTLR_EL1。当用户选择加入 MTE 存储专用标签检查模式时，会设置 TCSO0。但是，它不是SCTLR_USER_MASK的一部分，这意味着在上下文切换时我们永远不会清除SCTLR_EL1。TCSO0，因此我们会将该设置泄漏到另一个任务中。通过将 SCTLR_EL1_TCSO0_MASK 包括到 SCTLR_USER_MASK （CVE-2026-90094） 中来修复此问题

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

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

  - blk-cgroup：修复策略激活和 blkg 销毁之间的争用 在区块设备上切换 IO 计划程序时，blkcg_activate_policy（） 会为附加到队列的所有 blkg 分配 blkg_policy_data （pd）。
    但是，blkcg_activate_policy（） 可能与并发 blkcg 删除争用，从而导致释放后使用和内存泄漏问题。在下列争用中发生释放后使用：T1 （blkcg_activate_policy）： - 成功为 blkg1 分配 pd （loop0->queue， blkcgA） - 无法为 blkg2 分配 pd （loop0->queue， blkcgB） - 进入 enomem 回滚路径以释放 blkg1 资源 T2 （blkcg 删除）： - blkcgA 会同时删除 - blkg1 会通过 blkg_free_workfn（） 释放 - blkg1->pd 会释放 T1（续）： - 回滚路径在释放 pd 后访问 blkg1->pd->online - 触发释放后使用 此外，blkg_free_workfn（） 会在从 q->blkg_list 中删除 blkg 前释放 pd。这可让 blkcg_activate_policy（） 为正在销毁的 blkg 分配新的 pd，而最终释放 blkg 时无法访问新分配的 pd。通过扩展 blkcg_mutex 范围以序列化 blkcg_activate_policy（） 回滚和 blkg 销毁来修复这些争用，确保 pd 生命周期与 blkg 列表可见性同步。（CVE-2026-90326）

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

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

  - octeontx2-af：修复重复 rvu_mbox_init（） 的 cn20k 邮箱生命周期 rvu_mbox_init在探测期间为 AF-PF 邮箱单独调用，在启用了 SR-IOV 时为 AF-VF 邮箱分别调用 （）。每个调用都用于分配一个新的 ng_rvu 对象，若在第二次调用中覆盖指针，就会泄漏第一个分配。在两个路径中共享一个ng_rvu暴露了多个拆卸缺陷：错误路径释放了所有 cn20k 邮箱 DMA 和 kfree（）d ng_rvu即使只应展开失败的 init 类型，而在 AF-VF init 失败之后仍然使用活的 AF-PF 邮箱内存。mutex_init（） 也会在 AF-VF 路径上重新运行，而 AF-PF 邮箱处理程序仍然可以保留 rvu->mbox_lock。探测和 SR-IOV 失败路径也不会发布 cn20k 邮箱 DMA，因为清理只在 rvu_remove（） 中发生。使用 devm_kzalloc（） 分配一次 ng_rvu，初始化同一区块中的 mbox_lock，仅展开失败的 init 类型的邮箱内存，以及从探测和 pci_enable_sriov（） 错误路径释放 cn20k 邮箱 DMA。（CVE-2026-90079）

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

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

  - bpf：需要 BPF cpumask 以便 bpf_cpumask_populate（） bpf_cpumask_populate（） 通过 bitmap_copy（） 写入其目标，但目标键入为 struct cpumask *。这允许校验器接受只读 kfuncs（如 scx_bpf_get_online_cpumask（））返回的借用 cpumask 指针作为可写入目的地。使目标成为结构bpf_cpumask *，以便 populate 遵循与其他可变 cpumask kfunc 相同的所有权规则。查询 kfuncs 继续接受 const struct cpumask * 输入。
    (CVE-2026-93112)

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

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

  - crypto：sa2ul - 如果上下文池创建失败则停止探测 sa_ul_probe（） 会调用 sa_init_mem（） 以创建用于安全上下文缓冲区的 DMA 池，但忽略其返回值。如果池创建失败，即使以后的请求设置取决于该池，探测仍会继续进行 DMA 设置、算法注册和子填充。当 sa_init_mem（） 失败时停止探测，并将该失败路由到 PM 清理路径，而不尝试破坏未创建的 DMA 池。（CVE-2026-93158）

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

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

  - crypto：atmel-sha204a - 修复 I2C 传输失败时的堆信息泄漏 非阻塞 RNG 路径分配 work_data 结构以跟踪正在传输的异步 I2C 请求的状态。此指针存储于 rng->priv 中，稍后一旦事务完成，读取路径将消耗此指针。如果底层 I2C 传输失败，则会以非零状态调用完成回调。在这种情况下，分配的work_data无法用于生成 RNG 输出，且不得保持与 hwrng 状态关联。
    以前，失败路径仅记录警告，但未清除指针状态，这可导致后续的读取尝试观察到过时状态并将其解释为有效的完成数据。通过释放待定work_data修复此问题。I2C 事务报告错误。这可确保失败的请求不会留下在后续读取时可被解释为有效 RNG 数据的残余状态。清除 rng->priv 在后续非阻塞读取调用中完成。（CVE-2026-93159）

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

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

  - nfc：llcp：在 getsockopt nfc_llcp_getsockopt（） 的套接字锁定下读取 llcp_sock->local，在 lock_sock（sk） 之前读取 llcp_sock->local，然后取消引用锁定区域内的缓存指针。
    llcp_sock_bind（） 分配并清除同一套接字锁定下的 llcp_sock->local，丢弃其错误路径上的最后一个引用。与正在运行的 bind（） 竞用的 getsockopt（） 可观察指针、阻断 lock_sock（），然后在 bind（） 展开后取消引用释放的nfc_llcp_local。将llcp_sock>本地读取和 NULL 检查移到 lock_sock（sk） 区域内，这样 bind（） 就不能改变或释放加载和使用之间的指针。（CVE-2026-90225）

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

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

  - fs/ntfs3：拒绝 mi_enum_attr（） 中的超出范围 evcn 在 mi_enum_attr（） 中，非驻留属性的开始/结束 VCN 验证为：if （svcn > evcn + 1） goto out;U64_MAX evcn 时，evcn + 1 表达式将封装为 0，且任意 svcn 均通过检查。对于接近U64_MAX（但不等于）的 evcn 值，右侧仍然是无意义的接近封装上限，因此 svcn == 0 且 evcn 接近 U64_MAX 的畸形磁盘属性可通过 mi_enum_attr（） 而不被拒绝传递。VCN（虚拟群集号）是群集索引，因此任何有效的 evcn 都由卷的总群集计数限制，ntfs3 将其保存在 sbi->used.bitmap.nbits（运行 mi_enum_attr（） 的任何调用程序之前在 ntfs_init_from_boot（） 中设置）中。拒绝超出此范围的 evcn 值。但是，空的非驻留属性（未分配群集）使用 svcn == 0 和 evcn == -1 （U64_MAX） 合法编码，例如通过 attr->nres.evcn = cpu_to_le64（（u64）vcn - 1）（vcn == 0）。该哨兵必须持续传递，因此从范围检查中排除 evcn == U64_MAX。evcn + 1 测试>现有 svcn 仍然容忍 sentinel（0 > 0 为假）并继续要求 svcn == 0，而范围检查会拒绝所有其他超出范围的 evcn，并因此同时消除 evcn + 1 回绕。svcn 不需要自己的边界：一旦 evcn < nbits，svcn > evcn + 1 意味着 svcn <= nbits。[almaz.alexandrovich@paragon-software.com：修复了 evcn 检查]（CVE-2026-90199）

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

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

  - ocfs2：在 inode 区块验证期间验证内联 xattrs 修补程序系列 ocfs2：验证 xattr 条目边界，v7。本系列会在读取并验证 xattr 元数据时验证 OCFS2 xattr 条目名称/值边界，然后 getxattr（） 或 listxattr（） 可从损坏的元数据遍历超出范围的条目数组或偏移。此修补程序（共 2 个）：ocfs2_validate_inode_block（） 会在 OCFS2 用户遍历 dinode 中的元数据之前对其进行验证，但内联 xattr 元数据仍仅在特定于操作的消费者中检查。现有 ibody 查找帮助程序可验证内联标头放置和条目计数，但 inode 块验证不会拒绝条目名称/值边界。添加平面 xattr 条目验证器，并从 inode 区块验证中调用它以进行内联 xattrs。将操作路径保留在现有的标头/计数查找检查上;现在，在读取时验证 inode 块时会运行完整条目边界检查。在 ocfs2_xattr_ibody_get（） 或 listxattr（） 经过内联存储之前，拒绝损坏的内联 xattr 元数据。验证重现了此内核报告：缺陷：KASAN：任务 python3/529 在地址 ffff8881242a2000 处的 ocfs2_xattr_find_entry+0x5a/0x170 中的释放后使用 读取大小为 2 调用跟踪：dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_find_entry+0x5a/0x170 ocfs2_xattr_get_nolock+0x20a/0x820 ocfs2_xattr_get+0x10c/0x1e0 __vfs_getxattr+0xe2/0x130 vfs_getxattr+0x185/0x1b0 （CVE-2026-90321）

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

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

  - net：bridge：拒绝 VLAN 隧道范围降序 一对降序的 VLAN 和隧道 ID 可通过隧道范围跨度检查。VLAN 减法产生的负 int，与 u32 隧道 ID 减法相比，该 int 转换为无符号。因此，它可以等于封装的隧道 ID 增量。然后，范围循环不会执行任何迭代。由于批处理通知处理添加了 post-loop 错误检查，这会使 err 未初始化并使请求的返回值不可预测。比较跨度之前拒绝 VLAN 范围降序。有效的升序和单一条目范围保持不变，而畸形降序范围则一致返回 -EINVAL。此问题由静态分析检查程序发现，并经手动源审查确认。（CVE-2026-90114）

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

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

  - media：qcom：iris：处理核心 deinit 中的运行时 PM 恢复失败 检查 iris_core_deinit（） 中 pm_runtime_resume_and_get（） 的返回值。如果运行时 PM 恢复失败，请跳过硬件电源关闭操作，但仍会执行软件拆卸和状态转换。另外跳过相应的 pm_runtime_put_sync（） 调用以避免不平衡的运行时 PM 引用。（CVE-2026-90406）

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

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

  - IB/isert：拒绝声明的数据多于已接收数据的 PDU isert_recv_done（） 将每个接收到的 PDU 交给操作码处理程序，而不查看 wc->byte_len，即 HCA 实际放置在接收描述符中的字节数。然后，处理程序会从固定大小描述符中复制出固定大小描述符之外的字节数 - 发起程序在 BHS 中声明的数据段长度（ntoh24（hdr->dlength），通过派生的 unsol_data_len / imm_data_len）： isert_handle_iscsi_dataout（）：sg_copy_from_buffer（sg_start， sg_nents， isert_get_data（rx_desc）， unsol_data_len）;isert_handle_scsi_cmd（）：
    sg_copy_from_buffer（cmd->se_cmd.t_data_sg， sg_nents， isert_get_data（rx_desc）， imm_data_len）;由于从不根据 wc->byte_len 检查声明的长度，发起程序可声明大于其实际发送的字节（且大于描述符）的数据段并造成接收缓冲区的越界读取。没有任何 isert 上游可以关闭这扇门：- __iscsit_check_dataout_hdr（） 根据 conn_ops->MaxXmitDataSegmentLength （MXDSL） 设置入站负载边界 - 一个传输参数，此处用于入站检查。- iscsi_set_connection_parameters（） 设置 ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength;iscsi_check_acceptor_state（） 中的 min（）-clamp 列表中不存在 TARGETRECVDATASEGMENTLENGTH，因此发起程序声明的值是逐字采用的（类型范围 512..16777215）。发起者有效地提高了自己的上限。- isert 永远不会将协商值限制到其自己的固定接收描述符（ISER_RX_SIZE，9216 字节），因此目标核心的边界和描述符大小无关。imm_data_len == data_len 路径不仅仅是过度读取：它通过 sg_set_buf（） 将接收描述符别名并将其作为 SCSI WRITE 的数据源传递到后端，因此过度声明的长度会导致通过后端将描述符的堆内容写入后备存储。后端是过大的散点主义者的受害者，而不是原因;未证实未读回写入字节。触发器：登录完成后（完整功能阶段），声明了大型 TargetRecvDataSegmentLength 和允许未经请求/即时数据的 FirstBurstLength 的发起程序会发送声明的数据段长度超过已接收长度的 PDU。With KASAN：BUG：KASAN：在 sg_copy_buffer+0x150/0x1c0 中的 slab-out-of-bound 通过任务 kworker/1：0H/25 在地址 ffff888109720800 读取中存在大小为 4096 工作队列：ib-comp-wq ib_cq_poll_work 调用跟踪：
    sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 解析为 isert_handle_iscsi_dataout（） （ib_isert.c：1160），通过 isert_rx_opcode（） 内联。在 PDU 到达任何处理程序之前，根据 isert_recv_done（） 中的帧验证 wc->byte_len，如果连接较短则恢复连接。由于该测试在不减去标头长度的情况下进行比较，所以它也会拒绝比 iSER 和 iSCSI 标头短的 PDU，否则可能会从过时的描述符内容中解析出这些标头。登录处理程序拒绝短于 ISER_HEADERS_LEN 的 PDU（提交 29e7b925ae6d （IB/isert： 拒绝短于 ISER_HEADERS_LEN）的登录 PDU），但也不会限制声明的长度;此问题将在下一个修补程序中修复。数据处理程序完全没有长度检查。isert 从固定偏移量读取数据段：
    isert_get_data（） 返回 iSER 标头和ISER_HEADERS_LEN，不对 AHS 进行任何调整。因此，处理程序接触的字节恰好是 [ISER_HEADERS_LEN， ISER_HEADERS_LEN + dlength），并且将该总和与 wc->byte_len 进行比较会精确地限制读取的区域。AHS 术语只会使测试更严格，而不会限制任何更远的内容 ---truncated--- （CVE-2026-90414）

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

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

  - fs/ntfs3：修复 MFT 群集验证中的整数溢出 在 ntfs_init_from_boot（） 中，通过以下命令根据卷大小验证引导扇区的 MFT 群集编号：if （mlcn * sct_per_clst >= sectors || mlcn2 * sct_per_clst >= sectors） goto out;mlcn 和 mlcn2 是直接从引导扇区读取的 u64 字段。
    sct_per_clst以上以 4096（true_sectors_per_clst（） 加上其下方的 is_power_of_2（） 检查）为边界，但乘法以 u64 完成，并在 mlcn（或 mlcn2）足够大时进行换行 -- 例如，接近 2^62 的 mlcn 与 sct_per_clst == 4 封装为 0，这与低于任何非零“扇区”进行比较， 因此绕过检查并接受畸形记录。接受的 mlcn 然后在 sbi->mft.lbo = mlcn << cluster_bits;实际上，生成的读取在区块层失败（sb_bread（） 通过 grow_buffers（） 的 check_mul_overflow（） 保护返回 NULL），因此今天这表现为在奇怪位置的挂载失败，而不是更危险的事情，但验证步骤仍然是错误的，调用者没有理由依赖区块层来捕获一开始就不应该被接受的值。使用 check_mul_overflow（） 计算两个扇区位置，如果任一乘法封装，则挂载失败;这会保留现有语义 （mlcn * sct_per_clst >= sectors），而不是切换至除法 （mlcn >= sectors / sct_per_clst），进而会在“sectors”不是sct_per_clst倍数的边缘情况下加强检查。check_*_overflow（） 样式是 ntfs3 已用于 fs/ntfs3/run.c 中类似磁盘算法的样式。（CVE-2026-90200）

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

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

  - net：sched：修复 gred、bfifo 中的 32 位 backlog 封装，当当前 backlog 加上数据包长度符合队列限制时，插头排队 gred_enqueue（）、bfifo_enqueue（） 和 plug_enqueue（） 允许数据包：
    sch->qstats.backlog + qdisc_pkt_len（skb） <= sch->limit（gred 默认 VQ） gred_backlog+qdisc_pkt_len（skb） <= q->limit（gred 已配置 VQ） sch->qstats.backlog + qdisc_pkt_len（skb） <= sch->limit （bfifo） sch->qstats.backlog + skb->len <= q->limit（插拔） sch->qstats.backlog 和 q->backlog 为 u32，qdisc_pkt_len（）/skb->len 为无符号 int， 因此，所有总和都以 32 位计算并以 2^32 封装。一旦真正的 backlog 超过 4 GiB，封装的总和就会变小，并且准入会不断成功，因此队列无限增长，并且内核可以被驱动到 OOM。将金额提升至 u64，以便在实际积压超过限制时停止录取。该限制为 u32，因此绑定队列保持在 2^32 以下，并且存储的 u32 backlog 永远不会封装。该缺陷只能以根用户身份重现（尽管设置很荒谬）：附加限制接近 4 GiB 的 gred（或 bfifo/plug）qdisc，保持默认 VQ 未配置（对于 gred），并驱动 >4 GiB 的排队流量（例如，通过大小表/stab 来膨胀qdisc_pkt_len，或持续高速率流量）。u32 backlog+len sum 在 2^32 处封装，准入会不断成功，并且队列会无限增长到 OOM。（CVE-2026-90109）

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

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

  - fs/resctrl：防止 rdtgroup_kn_put（） 中的释放后使用 结构 rdtgroup 通过 rdtgroup：：waitcount 进行引用计数。需要结构在休眠期间保持有效（在等待获取rdtgroup_mutex时）的调用方使用 rdtgroup_kn_get（） 进行引用，然后使用 rdtgroup_kn_put（） 将其释放。
    释放路径旨在作为回退释放器：如果计数降至零且该群组已被标记为 RDT_DELETED，则 rdtgroup_kn_put（） 将释放该结构。resctrl 目录删除或 resctrl fs 卸载产生的批量拆卸路径 free_all_child_rdtgrp（） 和 rmdir_all_sub（） 充当主要释放器：它们保留rdtgroup_mutex并释放等待计数为零的每个 rdtgroup，否则它们设置RDT_DELETED并将释放留给最后一个等待程序。这两个自由人比赛。
    rdtgroup_kn_put（） 在 rdtgroup_mutex 之外使用 atomic_dec_and_test（） 提交 waitcount == 0，然后读取 rdtgroup：：flags。在这两个操作之间，free_all_child_rdtgrp（） 或 rmdir_all_sub（）（持有互斥体）的并行调用者可以通过 atomic_read（） 观察 waitcount == 0，调用 rdtgroup_remove（） 和 kfree（） 结构。随后在 rdtgroup_kn_put（） 中读取 rdtgroup：：flags 会变成释放后使用，如果释放的内存刚好满足 RDT_DELETED 标记检查，则结构甚至会被释放两次。将裸的 atomic_dec_and_test（） 替换为 atomic_dec_and_mutex_lock（），以便在计数全局可见之前rdtgroup_mutex到零的递减。然后，rdtgroup：：flags 的检查在由大量释放器持有的同一互斥体下运行，从而使这两个路径互斥。计数未达到零的常见情况保持无锁状态。延迟 kernfs_unbreak_active_protection（），直至卸除互斥体之后，因为 kernfs 主动保护在功能上封装rdtgroup_mutex。删除资源组，在恢复 kernfs 保护后，资源组进而终止其 kernfs 引用。[ bp： 将提交消息拆分为更小、更易于解析的段落。
    ] （CVE-2026-93100）

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

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

  - wifi：rtlwifi：pci：修复 rtl_pci_probe（） 中的错误路径 在 rtl_pci_probe（） 的最后一个错误路径中，由于错误的转至标签，将跳过清除函数。此外，必须还原对 rtl_init_rfkill（）、ieee80211_register_hw（）、rtl_debug_add_one（） 的成功调用。通过更新标签并将相关清除函数添加到最后一个错误路径修复此问题。（CVE-2026-90403）

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

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

  - power：supply：isp1704_charger：取消删除时的工作 USB 通知程序和初始 VBUS 检测可计划 isp->work。remove 路径会取消注册通知程序和电源，但不会等待排队或正在运行的工作，便会中断电源状态。取消注册通知程序后取消工作。在取消注册电源之前执行此操作。此问题由静态分析工具发现。
    (CVE-2026-90395)

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

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

  - RDMA/erdma：保留 AE 和 CM 处理 AE QP 致命事件的 QP 引用，以及 iWARP CM 路径从 dev->qp_xa 加载 QP，然后在 xarray 锁定之外使用或引用它们。erdma_destroy_qp（） 可以在此类查找正在传输时丢弃 destroy-path 引用并释放 QP 资源。添加 erdma_qp_get_by_qpn（） 以通过 kref_get_unless_zero（） 获取 xarray 锁定下的 kref。在终止 destroy-path 引用之前，从 xarray 中移除 QP，以便在现有用户遭到销毁时，不会再有新的查找获取它。（CVE-2026-90308）

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

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

  - speakup：keyhelp：通过将每个函数名称的第一个字节用作索引，通过“（start & 31） - 1”将每个函数名称的第一个字节用作索引，保护letter_offsets可能的超出范围索引 help_init（） 版本 letter_offsets[] 。如果名称开头为 [az] 的 sysfs（根）从 sysfs（根）替代function_names，索引将下溢或超过数组，导致越界写入。可以使用根帐户中的以下命令替代函数名称：
    modprobe speakup_soft echo 0 _bad > /sys/accessibility/speakup/i18n/function_names # 然后在 /dev/tty 上按 Insert+2 此补丁检查 help_init（） 中的第一个字母，如果不在 [az] 范围内，函数会将错误返回给调用程序。最终，此错误会传播到 drivers/accessibility/speakup/main.c：2217，从而导致哔哔声。（CVE-2026-93053）

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

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

  - ALSA：ice1712：通过自动清理修复探测错误时的卡泄漏 snd_ice1712_probe（） 在 snd_card_new（） 之后执行多个初始化步骤，但在不释放 ALSA 卡的情况下直接在后续步骤失败时返回，进而导致探测失败时的资源泄漏。通过 __free（snd_card_unref） 将 snd_devm_card_new（） 与基于范围的清理结合使用，并在成功注册后清除卡片指针以使其保持活动状态。（CVE-2026-90119）

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

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

  - dmaengine：zynqmp_dma：修复运行时 PM 与设备删除之间的争用 zynqmp_dma_remove（） 中，只有在检查状态并执行手动暂停后，运行时 PM 才会被禁用。这可能与删除/取消绑定 （rmmod） 路径中的运行时 PM 争用。首先禁用运行时 PM，然后仅在设备尚未暂停时暂停。阻止任何进一步的运行时 PM 转换。（CVE-2026-93169）

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

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

  - bus：mhi：ep：修复 MHI 设备创建错误路径中的设备引用计数泄漏 mhi_ep_create_device） 在分配传输设备后为 UL 通道采用一个设备引用，为 DL 通道采用另一个设备引用。通常，在删除设备之前，mhi_ep_destroy_device（） 会释放这些引用。如果 dev_set_name（） 或 device_add（） 失败，错误路径当前仅丢弃一个引用。其余的通道引用会阻止设备被释放并保留与从未注册过的设备关联的通道。通过丢弃 DL 通道引用、UL 通道引用和 device_initialize（） 初始引用的通用展开路径来路由这两个故障。
    (CVE-2026-93136)

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

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

  - nvmet-rdma：修复队列拆卸时的响应资源泄漏 当 I/O 正在运行时删除具有 rdma 传输的 nvme 目标时，可以发布响应，但在连接中断之前，无法提供响应的发送完成。因此，永远不会为响应调用 nvmet_rdma_send_done（） 和 nvmet_rdma_release_rsp（），而这会泄露分配的 RDMA 读/写环境和请求 SGL。
    通过运行具有 rdma 传输和 siw 驱动程序的 blktests nvme/061 可重现这些泄露。内核 kmemleak 功能会将其报告如下：未引用的对象0xffff88812bc490c0（大小 32）：comm kworker/2：1H、pid 409、jiffies 4307744490回溯 （crc 89afd339）：__kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30未引用对象0xffff88814bd05e80（大小 64）： comm kworker/3：1H，pid 148，jiffies 4295195428回溯 （CRC E35510CB）：
    __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 为避免内存泄漏， 拆散队列 QP 时回收正在传输响应的内存。调用 nvmet_rdma_free_rsp_resources（） 以释放此类响应的 RDMA 读取/写入上下文和请求 SGL。（CVE-2026-93151）

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

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

  - null_blk：使用锁定序列化 configfs 属性存储 NULLB_DEVICE_ATTR _store不采用任何锁定：
    apply_fn属性（submit_queues、poll_queues）在 apply_fn 返回后在其锁定之外再次写入 dev->NAME;APPLY=NULL 属性完全无锁。configfs 仅对每个打开文件的存储进行序列化，因此并发存储处于单独的 FDS 争用状态。对于apply_fn属性，一旦一个存储的apply_fn重新配置了硬件，第二个（丢失的）存储之后仍可覆盖 dev->NAME。这会使 dev->submit_queues 与实时队列计数不同步，随后由 null_map_queues（） 中的 WARN_ON_ONCE（） 捕获。对于 ！apply_fn 属性，power_store（） 的 null_add_dev（） 将验证并构建处于锁定状态的设备，但之后仅设置 CONFIGURED。存储在此窗口期间滑入可更改字段设置中途，例如，可在zone_nr_conv被限制之后将其推至nr_zones上方，从而导致越界 dev->zones[] 访问。锁定 apply_fn 调用、CONFIGURED 测试和字段写入周围的宏，并将其移出 nullb_apply_submit_queues（）/ nullb_apply_poll_queues（），以便两次覆盖两次路径。这会使用power_store的设置以及彼此序列化存储。（CVE-2026-90185）

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

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

  - Bluetooth：MSFT：根据响应长度验证evt_prefix_len read_supported_features（） 仅检查响应是否涵盖 struct msft_rp_read_supported_features的固定部分，即 11 个字节： if （skb->len < sizeof（*rp）） { bt_dev_err（hdev， MSFT supported features length mismatch）; goto failed; } evt_prefix[] 是灵活数组成员，而 rp->evt_prefix_len 是直接从该响应中提取的未经验证的 u8，因此 msft->evt_prefix = kmemdup（rp->evt_prefix， rp->evt_prefix_len， GFP_KERNEL）;从可能未携带任何字节的回复中复制最多 255 个字节。复制的是控制器从未发送过的数据，然后会用来匹配 msft_vendor_evt（） 中的传入供应商事件。这不是越界访问。skb 数据分配始终至少有 SKB_DATA_ALIGN（sizeof（struct skb_shared_info）） 字节超出负载，该字节大于 255 字节上限，因此读取停留在分配范围内，KASAN 不会进行报告。它仍然是对主机从未提供的字节的读取，长度完全由控制器控制。拒绝对其声明的前缀而言太短的响应。通过 KASAN 内核上的 /dev/vhci 上的仿真控制器进行验证，使用 vhci 以 btintel、btqca、btmtk 和 btrtl 无条件的方式公告 MSFT 操作码。恰好有 11 字节的回复（宣告 evt_prefix_len = 255）到达 kmemdup 并复制 255 字节（skb->len=11 evt_prefix_len=255，转储复制的缓冲区）;由于回复在固定部分结束，因此所有 255 个都来自响应末尾之后。不会生成如上所述分配松弛所预期的 KASAN 报告。使用此修补程序会拒绝响应，原因是 MSFT 事件前缀长度不匹配，而且 msft->evt_prefix 不会设置。（CVE-2026-90251）

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

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

  - wifi：mt76：mt792x：修复 SDIO TX 路径中的内存泄漏 当 tx_prepare_skb（） 在 SDIO TX 路径中返回错误时，skb 未释放，从而导致内存泄漏。丢弃零长度帧（例如 WNM NULL 帧）时可能会发生此情况，从而防止潜在的硬件 TX 挂起。当 tx_prepare_skb（） 失败时，通过使用 ieee80211_tx_status_ext（） 正确释放 skb，修复此问题。（CVE-2026-90378）

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

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

  - net/sched：act_ife：仅在以太网帧上操作act_ife封装/解封装原始以太网标头并使用 skb->dev->hard_header_len作为该标头的长度。这仅适用于以太网设备：在 hard_header_len 与实际拉取的 L2 标头不匹配的设备上（PPP 报告PPP_HDRLEN而入口时未剥离任何内容），入口 skb_push）/skb_pull（） 会使用错误的长度，并且可能在余量紧张时命中skb_under_panic。IFE 在设计上仅使用以太网 - 它构建外部 ethhdr，重写 h_source/h_dest/h_proto，并在解码时调用 eth_type_trans（） - 因此，与其尝试使偏移适用于任意链路类型，不如直接丢弃不带有以太网标头的数据包。仅检查 skb->dev->type 是不够的。我们必须迎合一种极端情况，即 mirred 可以将 skb 从非以太网设备重定向到以太网设备，然后 skb->dev 只字未提 skb 实际具有的帧：从 ppp0 重定向的 skb 到达目标的入口挂钩时具有 mac_len 0，完全没有以太网标头。因此，在入口时也需要ETH_HLEN mac_len。未维护出口mac_len，因此只有设备类型;那里的虚假重定向会产生畸形帧，而不是越界推送，并且在有或没有 IFE 的情况下都将是畸形。这种极端情况不在理论上 - 如果没有此修补程序，从 ppp0 重定向到在其入口挂钩中具有 ife 编码操作的 veth 会发生错误： skbuff： skb_under_panic： len：98 put：14 head：ffff88800e410000 data：ffff88800e40fff5 tail：0x57 end：0x640 dev：veth3 kernel BUG at net/core/skbuff.c：214！调用跟踪：
    skb_push （net/core/skbuff.c：224 net/core/skbuff.c：2657） tcf_ife_act （net/sched/act_ife.c：829 net/sched/act_ife.c：874） tc_run （net/core/dev.c：4463） netif_receive_skb （net/core/dev.c：6463 net/core/dev.c：6522） tcf_mirred_to_dev （net/sched/act_mirred.c：248 net/sched/act_mirred.c：328） tcf_mirred_act （net/sched/act_mirred.c：489） tc_run （net/core/dev.c：4463） process_backlog （net/core/dev.c：6728） 与保证以太网帧，使用 ETH_HLEN 而不是 hard_header_len。
    (CVE-2026-90083)

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

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

  - wifi：mt76：mt7996：在取消引用 phys[] band_idx 来自 2 位描述符字段 （0-3） 并直接用于索引 dev->mt76.phys[]（大小 __MT_MAX_BAND == 3）并取消引用结果之前验证 RX band_idx。损坏或保留的描述符值在具有较少带的部件上可能索引越界或命中 NULL phy。拒绝无效的带索引，镜像 mt7996_rx_get_wcid（）。（CVE-2026-90374）

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

ID	名称	严重性
347749	Linux Distros 未修补的漏洞：CVE-2026-90106	high
347748	Linux Distros 未修补的漏洞：CVE-2026-90111	high
347747	Linux Distros 未修补的漏洞：CVE-2026-90416	high
347746	Linux Distros 未修补的漏洞：CVE-2026-93099	medium
347745	Linux Distros 未修补的漏洞：CVE-2026-90361	medium
347744	Linux Distros 未修补的漏洞：CVE-2026-90384	medium
347743	Linux Distros 未修补的漏洞：CVE-2026-90153	high
347742	Linux Distros 未修补的漏洞：CVE-2026-90232	medium
347741	Linux Distros 未修补的漏洞：CVE-2026-93156	medium
347740	Linux Distros 未修补的漏洞：CVE-2026-90103	high
347739	Linux Distros 未修补的漏洞：CVE-2026-93097	medium
347738	Linux Distros 未修补的漏洞：CVE-2026-90315	high
347737	Linux Distros 未修补的漏洞：CVE-2026-90430	medium
347736	Linux Distros 未修补的漏洞：CVE-2026-90240	high
347735	Linux Distros 未修补的漏洞：CVE-2026-90314	medium
347734	Linux Distros 未修补的漏洞：CVE-2026-90381	high
347733	Linux Distros 未修补的漏洞：CVE-2026-93200	high
347732	Linux Distros 未修补的漏洞：CVE-2026-90313	high
347731	Linux Distros 未修补的漏洞：CVE-2026-93073	medium
347730	Linux Distros 未修补的漏洞：CVE-2026-93128	high
347729	Linux Distros 未修补的漏洞：CVE-2026-93093	medium
347728	Linux Distros 未修补的漏洞：CVE-2026-90372	high
347727	Linux Distros 未修补的漏洞：CVE-2026-90094	medium
347726	Linux Distros 未修补的漏洞：CVE-2026-90326	high
347725	Linux Distros 未修补的漏洞：CVE-2026-90079	medium
347724	Linux Distros 未修补的漏洞：CVE-2026-93112	high
347723	Linux Distros 未修补的漏洞：CVE-2026-93158	medium
347722	Linux Distros 未修补的漏洞：CVE-2026-93159	low
347721	Linux Distros 未修补的漏洞：CVE-2026-90225	high
347720	Linux Distros 未修补的漏洞：CVE-2026-90199	high
347719	Linux Distros 未修补的漏洞：CVE-2026-90321	high
347718	Linux Distros 未修补的漏洞：CVE-2026-90114	medium
347717	Linux Distros 未修补的漏洞：CVE-2026-90406	medium
347716	Linux Distros 未修补的漏洞：CVE-2026-90414	critical
347715	Linux Distros 未修补的漏洞：CVE-2026-90200	high
347714	Linux Distros 未修补的漏洞：CVE-2026-90109	medium
347713	Linux Distros 未修补的漏洞：CVE-2026-93100	medium
347712	Linux Distros 未修补的漏洞：CVE-2026-90403	high
347711	Linux Distros 未修补的漏洞：CVE-2026-90395	medium
347710	Linux Distros 未修补的漏洞：CVE-2026-90308	high
347709	Linux Distros 未修补的漏洞：CVE-2026-93053	high
347708	Linux Distros 未修补的漏洞：CVE-2026-90119	medium
347707	Linux Distros 未修补的漏洞：CVE-2026-93169	medium
347706	Linux Distros 未修补的漏洞：CVE-2026-93136	high
347705	Linux Distros 未修补的漏洞：CVE-2026-93151	high
347704	Linux Distros 未修补的漏洞：CVE-2026-90185	medium
347703	Linux Distros 未修补的漏洞：CVE-2026-90251	medium
347702	Linux Distros 未修补的漏洞：CVE-2026-90378	medium
347701	Linux Distros 未修补的漏洞：CVE-2026-90083	high
347700	Linux Distros 未修补的漏洞：CVE-2026-90374	medium

检测

Nessus 的 Misc. 系列

high

high

high

medium

medium

medium

high

medium

medium

high

medium

high

medium

high

medium

high

high

high

medium

high

medium

high

medium

high

medium

high

medium

low

high

high

high

medium

medium

critical

high

medium

medium

high

medium

high

high

medium

medium

high

high

medium

medium

medium

high

medium