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

  - iommu/tegra241-cmdqv：在拆除 VINTF 之前释放错误 IRQ tegra241_cmdqv_remove（） 首先拆除每个 VINTF，然后调用 free_irq（）。去除 VINTF 会释放 vintf0 并清除 cmdqv->vintfs[0]。该窗口中的错误导致 tegra241_cmdqv_isr（） 读取过时插槽并将其传递给 tegra241_vintf0_handle_error（），这将取消引用空指针或已释放的指针。拆除 VINTF 之前释放 IRQ。free_irq（） 会等待正在运行的处理程序完成并阻止新的处理程序，因此任何 ISR 都无法在 VINTF 被拆散时观察到它。注意：用户拥有的 VINTF （viommu） 可比此拆卸更耐用，此操作可取消映射 cmdqv->base 并释放 cmdqv->vintfs，因此稍后的 viommu 关闭可触及已释放的内存。这里既未引入也未修复此问题：物理 IOMMU 不是可插拔设备，因此 iommufd 在设计上不包含 viommu 后面的引用，并且当 viommu 仍然运行时不会进行此拆卸。（CVE-2026-90426）

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

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

  - wifi：mt76：mt7996：绑定的 TLV 漫游mt7996_mcu_get_chip_config tlv->len 推进响应 TLV 循环但没有最小值，因此包含零长度 TLV 的理论固件响应可永久旋转，从而在设备探测过程中挂起 CPU。同样会在未进行边界检查的情况下读取 u32 负载。
    拒绝短的固定字段，在长度低于标头或溢出 skb 的 TLV 上停止。
    (CVE-2026-90370)

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

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

  - bus：mhi：host：修复 EDL sysfs 失败时的控制器清除 mhi_register_controller（） 在创建可选的 trigger_edl sysfs 文件之前添加控制器设备。如果 sysfs_create_file（） 失败，错误路径只会丢弃设备引用并使设备保持注册状态。因此，请在 put_device（） 之前调用错误路径中的 device_del（）。（CVE-2026-90402）

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

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

  - wifi：mt76：mt7996：为 CSA 中止倒计时 TLV 预留空间 CSA 倒计时处于活动状态时，mt7996_mcu_beacon_cntdwn（） 会发出两个bss_bcn_cntdwn_tlv条目（CSA 倒计时和 CCA 中止密件抄送），但MT7996_BEACON_UPDATE_SIZE仅保留一个条目。启用 MBSSID 和接近最大信标模板的情况下，额外的 8 个字节可将卸载命令推过 MT7996_MAX_BSS_OFFLOAD_SIZE 并触发 skb_over_panic（）。为两个倒计时 TLV 预留空间。 （CVE-2026-90366）

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

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

  - drm/panthor：通过 kbo 范围重叠检查添加 vm_bind 区域 创建 VM 时，调用程序必须指定为映射内核 BO 预留的地址空间的范围。这意味着vm_bind暴露于 UM 的 BO 的映射不应与该区域相交，但目前我们不会对此进行检查。起初，我考虑通过其 reserve_{offset， range} 参数将这些值提供给 drm_gpuvm_init（），但事实证明，它适用于未通过通常的 drm_gpuvm 拆分/合并电路管理的 VM 地址跨度，因此在 VM 创建时存储用户 VA 范围的末尾并在 vm_bind ioctl 路径中快速检查是最简单的解决方法。新的检查还确保vm_bind范围不会溢出 64 位无符号整数的大小。这已经在 drm_gpuvm_sm_map -> drm_gpuvm_range_valid 内的调用堆栈下方完成，但最好在调用 GPUVM 函数之前在驱动程序中尽早失败，这样我们就不会浪费时间分配vm_bind上下文资源。（CVE-2026-90409）

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

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

  - xfrm：修复 xfrm_dev_direct_output（） 中的 skb 双重释放 来自 local_out（） 的非 1 返回值表示 skb 已被消耗或其所有权已转移。然而，xfrm_dev_direct_output（） 仍然会释放此路径上的 skb，从而在 netfilter 丢弃数据包时造成双重释放并使任何其他所有者失效。直接返回 local_out（） 结果，与 xfrm_output_resume（） 中的所有权处理匹配。（CVE-2026-92489）

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

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

  - xsk：修复 __xsk_rcv（） 中的空指针取消引用 在 __xsk_rcv（） 多缓冲区路径中，循环中调用 xsk_buff_alloc（） 时不检查其返回值。xsk_buff_can_alloc（） 仅计算填充队列条目而不验证其地址，因此在 xsk_buff_alloc（） 拒绝所有剩余条目并返回 NULL 时可成功。错误：一般保护错误，可能针对非规范地址0xdffffc0000000000 KASAN：范围 [0x0000000000000000-0x0000000000000007] 中的 null-ptr-deref RIP：0010：__xsk_rcv+0x426/0xc20 （net/xdp/xsk.c：350） 调用跟踪：xsk_generic_rcv+0x26d/0x5f0 xdp_do_generic_redirect+0x3c5/0xcf0 do_xdp_generic+0x92f/0xe70 __netif_receive_skb_core.constprop.0+0xf7e/0x2b30 通过两阶段事务修复此问题。首先分配并暂变数据包所需的所有缓冲区，如果有任何分配失败，则使用 xsk_buff_free（） 回收所有暂存的缓冲区。只有在此阶段成功后，才能在无错误循环中复制数据、保留 RX 描述符并释放缓冲区。（CVE-2026-90115）

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

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

  - wifi：mt76：修复RXDMAD_C缓冲区回收争用 RXDMAD_C缓冲区来自 RRO 数据队列的页面池，这些页面池绑定到不同的 NAPI，因此此处使用的直接页面池回收可争用拥有的 NAPI;采用非直接路径，与已对 WED RX 队列相同的操作。（CVE-2026-90371）

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

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

  - RDMA/core：等待 RCU 回调，然后卸载 ib_core put_gid_ndev（） 已与 call_rcu（） 一起排队，并在 ib_core 中实现。停止工作队列不会耗尽已排入队列的回调，因此 RCU 可在卸载模块代码后调用它。synchronize_rcu（） 不等待回调。在所有生产者都停止后等待他们。（CVE-2026-93110）

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

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

  - isofs：释放 zisofs 块指针缓冲区头 zisofs_fill_pages（） 读取压缩的块指针表。错误路径释放当前buffer_head，循环在前进时也会释放旧buffer_head。但是，成功路径会保留引用的最后一个buffer_head。在返回成功之前将其释放。（CVE-2026-90434）

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

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

  - bpf：拒绝通过不受信任的 BTF 指针进行的写入 check_ptr_to_btf_access（） 可让程序类型 btf_struct_access 回调在默认 BTF 访问路径拒绝非读取访问之前验证写入。
    这会绕过由 bpf_rdonly_cast（） 等帮助程序创建的不受信任的 BTF 指针的只读策略。在回调分支之前，通过通用入口点的 PTR_UNTRUSTED BTF 指针拒绝非读取访问，以处理所有情况。（CVE-2026-93144）

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

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

  - blk-iolatency：释放策略数据时清除延迟状态 io.latency 可限制没有自身延迟目标的群组。当同级缺少其目标时，check_scale_change（） 会缩减其对等方，并且达到队列深度的对等方会在每次进一步缩减时都会调用其 blkcg_use_delay（），即使 min_lat_nsec == 0。iolatency_pd_offline（） 通过 iolatency_set_min_lat_nsec（） 重置目标，这仅清除非零到零转换时的延迟，因此它永远不会清除此类对等机。然后释放策略数据会使 blkg->use_delay set 和 blkcg->congestion_count 提升，并且没有任何可以终止策略数据的内容。然后，只要 cgroup 存在，blk_cgroup_congested（） 就会为该 cgroup 及其子级中的每个任务返回 true：page_cache_sync_ra（） 将预读切入到单个页面，page_cache_async_ra（） 完全跳过该页面，而 __folio_throttle_swaprate（） 会获取swap_avail_lock并计划匿名 Folio 分配的节流。清除 iolatency_pd_free（） 中的延迟。届时，bio 持有的 blkg 引用已耗尽，或队列因策略停用而被冻结，因此 check_scale_change（） 无法重新布防它。免费回调也可查看从未附加到 blkg 的策略数据，因此会进行 pd->blkg 检查。（CVE-2026-90183）

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

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

  - IB/isert：在会话注册之后发布全功能接收缓冲区 isert_put_login_tx（） 在 __transport_register_session（） 运行之前发布全功能接收缓冲区，因此不等待最终登录响应的发起程序仍可对se_tpg为 NULL 的se_session执行 SCSI 命令 - 此错误与之前的修补程序相同， 在 target_submit+0xbe。从之前的修补程序已用于发送该响应的 isert_get_rx_pdu（） 中发布它们，并在发送前将其发布：接收队列在发起程序被告知其可以使用它时已填满。在那里分配保留了现有属性，即一旦最终登录响应在线上，内存分配失败就不会发生。最终登录请求和 isert_post_recvm（） 之间的接收队列已经是空的;
    这在 1200 次登录中从 92 US 的中位数移动到 172 US 的中位数。只有在被告知之前发送的发起程序才能访问该窗口，并且在 IB 和 RoCE 上，其发送会在该窗口重试，直到缓冲区出现 - isert_rdma_accept（） 要求 rnr_retry_count = 7。iWARP 没有 RNR 流控制，因此同一个发送会改为终止连接。在 rxe 上测量，每次运行 400 次登录周期，使用不等待的启动程序：检测的版本在 10 次运行中发布缓冲区之前未对 isert_recv_done（） 进行任何条目计数，其中该发起程序在 10 次未修补的运行中错误了 8 次，并且仅使用上一个修补程序时 10 次中有 5 次错误。未测试：iWARP、通过 iSER 的发现会话和真实的 HCA。
    (CVE-2026-90293)

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

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

  - RDMA/core：修复 ib_destroy_cq_user（） 中潜在的释放后使用 通过 netlink 路径访问 CQ 时，所述 CQ 的唯一同步机制为 rdma_restrack_get（）。目前，rdma_restrack_del（） 是在 ib_destroy_cq_user（） 的末尾调用的，为时已晚，因为此时与 CQ 关联的供应商特定资源可能已经释放。这可能会留下一个短暂的窗口，其中 CQ 仍可通过重新跟踪访问，从而导致潜在的释放后使用。通过将 rdma_restrack_begin_del（） 调用移动到 ib_destroy_cq_user（） 的开头来修复此问题，确保在释放 CQ 内部资源之前从 restrack 中删除 CQ。这可保证没有新用户持有对正在销毁的 CQ 的引用。此外，此更改保留了创建和销毁例程之间的预期反向顺序：在成功创建结束时添加资源以进行重新跟踪，因此在销毁流期间应首先从重新跟踪中删除资源，从而保持生命周期管理的一致性和可预测性。（CVE-2026-92511）

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

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

  - smb/server：修复 ksmbd_ipc_tree_connect_request（） 中的 null-ptr-deref 请参阅以程：
    ksmbd_tree_conn_connect ksmbd_share_config_get share->name = kstrdup（） // 失败 if （！test_share_config_flag（share， KSMBD_SHARE_FLAG_PIPE）） // false // 不检查“share->name” ksmbd_ipc_tree_connect_request strlen（share->name） // null-ptr-deref （CVE-2026-90166）

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

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

  - net/smc：在 REQ_ADD_LINK 到 ADD_LINK 转换中覆盖之前释放隐藏的 qentry 当 smc_llc_event_handler（） 在 ADD_LINK 请求到达时将本地 LLC 流从 SMC_LLC_FLOW_REQ_ADD_LINK 转换到 SMC_LLC_FLOW_ADD_LINK 时，它会无条件调用 smc_llc_flow_qentry_set（）： if （lgr->llc_flow_lcl.type == SMC_LLC_FLOW_REQ_ADD_LINK） { lgr->llc_flow_lcl.type = SMC_LLC_FLOW_ADD_LINK; smc_llc_flow_qentry_set（&lgr->llc_flow_lcl， qentry）;... }在SMC_LLC_FLOW_REQ_ADD_LINK flow->type 时到达的CONFIRM_LINK或ADD_LINK_CONT通过 SMC_LLC_CONFIRM_LINK/SMC_LLC_ADD_LINK_CONT 处理程序（存储在任何非 NONE 流类型的 flow->qentry 中）隐藏到 flow->qentry 中。后续ADD_LINK到达时，REQ_ADD_LINK分支会使用新指针覆盖 flow->qentry，而不会首先释放隐藏的分配，从而泄漏一个 kmalloc 对象。隐藏条目没有使用者：smc_llc_wait（） 仅从尚未计划的 llc_add_link_work 调用，而流类型仍为REQ_ADD_LINK。此时没有服务员睡在llc_msg_waiter上。在覆盖之前无条件释放任何隐藏的 qentry 是安全的。在 REQ_ADD_LINK 分支中调用 smc_llc_flow_qentry_del（），然后再调用 smc_llc_flow_qentry_set（）。smc_llc_flow_qentry_del（） 在释放前已检查 flow->qentry，因此未隐藏任何条目的正常路径为非 op。（CVE-2026-90108）

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

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

  - platform/x86：dell-wmi-base：修复模块加载失败时的资源泄漏 当模块加载失败时，我们需要正确清理 SMBIOS 请求和隐私驱动程序。（CVE-2026-93130）

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

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

  - wifi： iwlwifi： mei： 在读取 SAP 消息之前检查其长度 在读取消息之前验证 SAP 消息大小是否不大于本地缓冲区，以避免缓冲区溢出。（CVE-2026-93063）

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

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

  - bpf：比较状态修剪期间的迭代器类型迭代器堆栈槽可以是MEM_RCU或PTR_UNTRUSTED。
    这些状态不得相等，否则校验器可能会修剪不安全的路径。比较STACK_ITER插槽的指针类型。（CVE-2026-90217）

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

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

  - dmaengine：xilinx_dma：修复 AXIDMA 和 MCDMA 中断处理程序中的通道空闲状态管理 修复 AXIDMA 和 MCDMA irq 处理程序中的争用条件，其中通道可能被错误地标记为空闲，并在仍在处理描述符时尝试虚假传输。在以下情况下会发生此问题：1. 多个描述符已排入队列且处于活动状态。2. 在完成某些描述符之后触发中断。3.
    xilinx_dma_complete_descriptor（） 将完成的描述符移动到done_list。4. 通道被标记为空闲并调用 start_transfer（），即使 active_list 仍然包含未处理的描述符。5. 这会导致过早传输尝试以及潜在的描述符损坏或错过完成。仅当活动列表实际为空时才将通道标记为空闲并开始新的传输，从而确保妥善管理通道状态并避免虚假传输尝试。（CVE-2026-93170）

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

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

  - vdpa_sim：修复工作线程创建失败后的清理 vdpasim_create（） 在 kthread_run_worker（） 失败时将 vdpasim-->worker 保留为ERR_PTR。错误路径随后会丢弃设备引用，从而释放部分初始化的仿真器。vdpasim_free（） 会无条件地将工作线程指针传递至 kthread_destroy_worker（），因此取消引用ERR_PTR并可触发一般保护错误。存储工作线程错误，清除指针，并且仅在成功初始化时才清理工作线程。
    此外，通过保护 virtqueue 和 IOTLB 清理使发布路径容忍部分初始化的对象，因为可通过其他初始化失败访问相同的版本路径。我自己发现了这个错误，尽管该补丁是在 AI 协助下编写的。（CVE-2026-90130）

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

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

  - bpf：在加载 check_atomic_load（） 调用 check_load_mem（） 之前先检查加载获取 src ptr 类型，然后再调用 atomic_ptr_type_ok（）。对于提取到其自己的源寄存器 （dst_reg == src_reg） 的加载获取，check_load_mem（） 会以加载值的类型覆盖src_reg的类型，因此后续的 atomic_ptr_type_ok（） 不再看到源指针并且无法拒绝不允许的类型（ctx、pkt、flow_keys、sock）。由于 bpf_convert_ctx_accesses（） 不会重写原子负载，底层内核对象的原始访问权将保留在原地。目标类型取自 ctx 访问本身，因此，例如，对 struct __sk_buff 的 sk 字段进行加载获取会将寄存器键入为 PTR_TO_SOCK_COMMON_OR_NULL，而 type_is_sk_pointer（） 也不匹配，而实际上它保留了未转换的 struct sk_buff字节。一旦通过 NULL 检查，这是一种类型混淆，而不仅仅是泄漏内核数据。在加载之前，使用 check_reg_arg（） 验证src_reg并使用 atomic_ptr_type_ok（） 检查源指针类型，以镜像 check_atomic_rmw（） 再次加载。超出范围的寄存器编号早前已被 check_and_resolve_insns（） 拒绝（提交 503d21ef8eac（bpf：尽早进行寄存器范围验证）），唯一的豁免 is_stack_arg_ldx（） 需要BPF_LDX |BPF_MEM |BPF_DW，因此永远不会匹配BPF_ATOMIC insn。因此，atomic_ptr_type_ok（） 不能取消引用寄存器状态越界，即，以下补丁提交解决的越界读取不会再次出现（也通过 selftest 证实）。（CVE-2026-90312）

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

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

  - RDMA/rxe：编制 wqe->dma.sge[ 索引前验证 num_sge/cur_sge] 对于用户 QP，qp->sq.queue 是应用程序直接写入的环，因此 rxe_post_send（） 采用 is_user 分支，仅计划send_task而不验证 WQE。rxe_requester（） 通过 req_next_wqe（） 就地消耗它并调用 copy_data（），从而使用攻击者控制的 num_sge/cur_sge 编制索引 &wqe->dma.sge[cur_sge]。只有内核路径边界num_sge （validate_send_wr（））;从不检查用户 WQE，因此本地非特权用户可发布包含超出范围cur_sge或超大num_sge的 WQE，并强制在 copy_data（） 中越界读取 per-WQE sge 数组（vmalloc OOB 读取，本地 DoS）。使用前将 num_sge绑定到 rxe_requester（） 中的 qp->sq.max_sge，get_srq_wqe（） 已经保护 SRQ 条目的方式，并且仅当 WQE 携带负载时绑定cur_sge （dma.resid）：copy_data（） 在接触 dma->sge[] 之前提早返回零长度副本，因此零负载 WQE（max_sge == 0 QP 可发布的唯一类型）保持有效。在KASAN下转载;copy_data（） 中的 vmalloc-out-of-bounds 已消失。（CVE-2026-92525）

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

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

  - net/sched：sfq：钳制 quantum 以避免已签名溢出软锁定 sfq_init（） 设置 q->quantum = psched_mtu（qdisc_dev（sch））（无符号）。具有极大 MTU 的设备（例如接受 MTU 2147483634 的 max_mtu == 0 的虚拟）会使 psched_mtu（） 返回0x80000000，因此 slot->allot = INT_MIN 和 INT_MIN + INT_MIN 永远在 INT_MIN 和 0 之间切换，在 qdisc 锁定下旋转 sfq_dequeue（）。将量子限制为 [256， 1 << 20]，以便重填循环终止。下限还涵盖 q->quantum == 0（psched_mtu（） 返回 0），它以相同的方式旋转 sfq_dequeue（）。sfq_change（） 已经拒绝负量子，因此仅暴露 init 路径。重现缺陷的条件：MTU（加上 hard_header_len）将 psched_mtu（） 封装到符号位中的设备（例如，max_mtu == 0 接受 MTU 2147483634的虚拟设备）。
    需要用户命名空间中的CAP_NET_ADMIN。（CVE-2026-90072）

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

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

  - Bluetooth：L2CAP：修复争用 l2cap_sock_cleanup_listen（） 与 put_chan 对于未拥有 sk->sk_socket 的 L2CAP 套接字，读取 l2cap_pi（sk）->chan 可能与并发 l2cap_sock_kill（） -> l2cap_sock_put_chan（） 争用。这会排除同步proto_ops回调，但在 l2cap_sock_cleanup_listen（） 中的访问具有不安全的无锁读取。[任务 1][任务 2 （hdev->工作队列）] l2cap_sock_release（parent） l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock（sk） l2cap_sock_teardown_cb bt_accept_unlink bt_sk（sk）->parent = NULL release_sock（sk） ----------------> lock_sock（sk） parent = /* NULL */ lock_sock（sk） <--------------------- release_sock（sk） sock_set_flag（sk， SOCK_ZAPPED） l2cap_sock_close_cb l2cap_sock_kill（sk） l2cap_sock_put_chan chan = READ l2cap_pi（sk）->chan l2cap_pi（sk）->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan（chan） kref_get_unless_zero（&chan->ref） 任务 1 可能会发现 NULL，进而造成 null-ptr-deref。
    通过在 l2cap_sock_kill（） 中执行 lock_sock（） 以与 l2cap_sock_cleanup_listen（） 同步来修复争用。
    此处不需要 hold_unless_zero（），如果其为非 NULL，则 l2cap_pi（sk）->chan 拥有引用。详尽说明代码注释与锁定。（CVE-2026-90091）

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

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 依赖供应商报告的程序包是否存在进行判断。

ID	名称	严重性
347774	Linux Distros 未修补的漏洞：CVE-2026-90426	medium
347773	Linux Distros 未修补的漏洞：CVE-2026-90370	medium
347772	Linux Distros 未修补的漏洞：CVE-2026-90402	high
347771	Linux Distros 未修补的漏洞：CVE-2026-90366	medium
347770	Linux Distros 未修补的漏洞：CVE-2026-90409	high
347769	Linux Distros 未修补的漏洞：CVE-2026-92489	critical
347768	Linux Distros 未修补的漏洞：CVE-2026-90115	medium
347767	Linux Distros 未修补的漏洞：CVE-2026-90371	high
347766	Linux Distros 未修补的漏洞：CVE-2026-93110	high
347765	Linux Distros 未修补的漏洞：CVE-2026-90434	medium
347764	Linux Distros 未修补的漏洞：CVE-2026-93144	high
347763	Linux Distros 未修补的漏洞：CVE-2026-90183	medium
347762	Linux Distros 未修补的漏洞：CVE-2026-90293	high
347761	Linux Distros 未修补的漏洞：CVE-2026-92511	high
347760	Linux Distros 未修补的漏洞：CVE-2026-90166	medium
347759	Linux Distros 未修补的漏洞：CVE-2026-90108	high
347758	Linux Distros 未修补的漏洞：CVE-2026-93130	medium
347757	Linux Distros 未修补的漏洞：CVE-2026-93063	high
347756	Linux Distros 未修补的漏洞：CVE-2026-90217	high
347755	Linux Distros 未修补的漏洞：CVE-2026-93170	high
347754	Linux Distros 未修补的漏洞：CVE-2026-90130	medium
347753	Linux Distros 未修补的漏洞：CVE-2026-90312	high
347752	Linux Distros 未修补的漏洞：CVE-2026-92525	high
347751	Linux Distros 未修补的漏洞：CVE-2026-90072	medium
347750	Linux Distros 未修补的漏洞：CVE-2026-90091	high
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

检测

Nessus 的 Misc. 系列

medium

medium

high

medium

high

critical

medium

high

high

medium

high

medium

high

high

medium

high

medium

high

high

high

medium

high

high

medium

high

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