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

  - btrfs：始终等待有序盘区以避免 OE 争用 [缺陷] Syzbot 报告一个缺陷，同一范围内可能存在冲突的 OE： BTRFS 危急 （device loop4）：insert_ordered_extent：264 中的错误：
    重叠有序盘区，现有 OE file_offset 16384 num_bytes 430080 标记0x1089，新 OE file_offset 16384 num_bytes 430080 标记0x80 （errno=-17 对象 alrea[ 179.162726][ T6897] BTRFS 危急 （device loop4）：insert_ordered_extent：264 中的错误：重叠有序盘区，现有 OE file_offset 16384 num_bytes 430080 标记0x1089，新 OE file_offset 16384 num_bytes 430080 标记0x80（errno=-17 对象已存在）------------[ cut here ]------------ fs/btrfs/ordered-data 处的内核缺陷。C：264！硬件名称：Google Google Compute Engine/Google Compute Engine、BIOS Google 05/09/2026 RIP：
    0010：btrfs_alloc_ordered_extent+0x943/0xad0 调用跟踪： <TASK> cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990
    __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
    ---[ end trace 000000000000000000 ]--- [CAUSE] Since commit ff66fe666233（btrfs：修复针对附加直接写入的错误缓冲 IO 回退），如果直接 IO 完成较短，我们会将 isize 恢复回原始 isize，以便在缓冲的回退期间可遵守附加写入。通常，在缓冲的回写期间，我们依靠 lock_and_cleanup_extent_if_need（） 函数等待任何现有的有序盘区。但只有当start_pos位于 isize 内时，才会发生有序盘区等待。由于我们已在失败的直接 IO 期间恢复 isize，因此不会等待任何有序盘区。这意味着我们可发生争用，其中直接 IO OE 仍在树中、已完成但尚未删除，然后我们要为缓冲写入插入 OE，从而导致上述崩溃。[修复]使 OE 无条件等待，以处理恢复的 isize 情况。由于 lock_and_cleanup_extent_if_need（） 现在可以锁定盘区或返回 -EAGAIN，因此还要删除处理非盘区锁定情况的分支，并对其重命名以删除_if_need后缀。以下微基准测试显示了 btrfs_buffered_write（） 的运行时间差异，执行“xfs_io -f -c pwrite 0 1m”工作负载，所有值都是以纳秒为单位的平均运行时间。函数运行时 |之前 |之后
    -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need（） | 58.2183.0 |btrfs_buffered_write（） | 2115.62973.3 |btrfs_buffered_write（） 的整体运行时间仍然很小（仍然不到 3 微秒），我想说额外的成本仍然是可以接受的。修复此问题的替代方法是在 iomap_end（） 期间等待有序盘区，此时完成 isize 恢复。但该解决方案将破坏 nowait 要求，就像 nowait 直接 IO 结束较短一样，我们必须无条件等待 OE，否则下一个附加缓冲的 IO 仍会遇到同样的问题。所以这里我们必须将等待成本转移到缓冲写入，但至少代码稍微精简一些。（CVE-2026-90264）

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

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

  - vdpa/mlx5：修复错误路径中迭代add_direct_chain错误列表 在 add_direct_chain（） 中，新分配的直接 MR 条目被添加到本地列表“tmp”，仅在成功时才会将其拼接成 mr->head。在错误路径中，清理循环错误地迭代 mr->head 而非 tmp。通过迭代 err_alloc 清理路径中的“tmp”进行修复。（CVE-2026-90128）

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

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

  - NFSv4：修复传递到 nfs4_add_lease（） 中的 nfs4_delete_lease（） 的不正确参数 当 nfs4_add_lease（） 与委派返回争用时，它会调用 nfs4_delete_lease（） 进行清理。以前，它传递了合法地可以为 NULL 的 priv。传递空 priv 最终导致 generic_setlease（） 中的空指针取消引用。（CVE-2026-90148）

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

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

  - ksmbd：释放前分离被阻止的锁定请求 ksmbd 保留用于字节范围锁定簿记的file_lock仍可是 VFS 阻止请求图表的一部分。特别是，VFS 可通过flc_blocked_requests在已经被阻止的请求下链接一个新的等待程序。ksmbd_file引用计数不涵盖该图表。__ksmbd_close_fd（） 和跨请求解锁路径直接释放这些保留的 file_lock 对象。如果仍然附加依存等待程序，locks_release_private（） 命中 BUG_ON（！list_empty（&flc->flc_blocked_requests））。相同的生命周期不匹配可导致释放的ksmbd_lock可通过其 request-local llist 访问。先将file_lock从阻止请求图中分离，然后再将其释放到关闭、跨请求解锁和回滚路径中。locks_delete_block（） 还会唤醒在对象下链接的请求。发布已完成的锁定时删除 llist，以便全局可见的ksmbd_lock不再指向提交工作线程的堆栈。（CVE-2026-90155）

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

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

  - wifi：mt76：mt7996：完全重置时清除 WCID 条目后释放 vif 链接 mt7996_mac_reset_vif_iter（） 会将非默认 vif 链接排入队列以获取kfree_rcu而 dev->wcid[] 仍保留指向嵌入在每个已释放链接中的 WCID 的指针;然后，mt76_reset_device（） 会取消引用这些条目，并对其运行 mt76_wcid_cleanup（）。
    如果其间有宽限期，则清除操作会对释放的内存进行操作。请先运行 mt76_reset_device（），以便在链接仍然有效时清理和清除 wcid 条目。（CVE-2026-90356）

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

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

  - erofs：修复交错的 ztailpacking pclusters 交错式 pcluster 的磁盘大小应按块对齐，而 ztailpacking 交错式 pcluster 应完全无效。目前，mkfs.erofs 不会生成任何启用 ztailpacking 的交错式 pcluster，因此这不会影响任何现有的有效文件系统。然而，特制的图像可包含无效的交错式 ztailpacking pcluster，从而导致从 kmap'd 页面发生越界读取，并将不相关的内核内存复制到用户空间不可见的页面缓存中。（CVE-2026-90161）

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

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

  - ASoC：fsl_audmix：重做探测中的运行时 PM 处理 pm_runtime_enable（） 之后，AUDMIX 区块会关闭电源并保持暂停状态，直到第一个运行时恢复。probe（） 和首次恢复之间发出的寄存器写入（例如从 DAPM 或 ALSA 控制路径）以未通电的硬件为目标，并造成系统挂起。
    通过在 pm_runtime_enable（） 之后立即调用 pm_runtime_resume_and_get（） 来解决此问题，以启动硬件并启用其时钟。之后使用 pm_runtime_put（） 释放引用，以允许运行时 PM 框架在空闲时暂停设备并将 regmap 切换为仅缓存模式。禁用了 CONFIG_PM 或未启用运行时 PM 时，pm_runtime_* 调用是不启动硬件的 stub。通过直接调用 fsl_audmix_runtime_resume（） 明确处理这种情况，以便始终初始化硬件并启用其时钟，从而确保无论 PM 配置如何，寄存器访问都成功。（CVE-2026-93184）

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

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

  - nfc：llcp：将 SNL TLV 解析绑定到 skb 并添加长度检查 nfc_llcp_recv_snl（） 使用从 skb->len 派生的 u16 偏移/长度对遍历 SNL TLV 列表，而不对实际 skb 数据进行边界读取。
    接下来出现三个问题：- 对于短帧 （skb->len < LLCP_HEADER_SIZE），tlv_len下溢。- 在未检查是否还剩两个字节的情况下读取 per-TLV 标头（类型、长度）。- 声明的 TLV 长度可超过缓冲区末尾，长度 == 0 的 SDREQ service_name_len = 长度 - 1 下溢 （size_t），从而在以下 strncmp（） / nfc_llcp_sock_from_sn（） 中驱动越界读取。
    SDRES 案例同样读取 tlv[2]/tlv[3] 而不进行长度检查。附近的 NFC 设备无需身份验证即可访问此权限;LLCP 链接在 NFC-DEP 后自动激活。按指针遍历 TLV 列表，在线性 skb 数据上以 skb_tail_pointer（） 为界，并在使用前验证每个 TLV 声明的长度。为 SDREQ （>= 1） 和 SDRES（恰好 2）添加明确的长度检查。由 0sec 自动化安全研究工具 （）https://0sec.ai 发现。（CVE-2026-90223）

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

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

  - swiotlb：保留动态池的分配虚拟地址 当需要从 atomic 上下文解密的池时，swiotlb_alloc_tlb（） 可从 DMA atomic 池进行分配。通过 CONFIG_DMA_DIRECT_REMAP，原子池由重新映射的虚拟地址提供支持，这些地址与 phys_to_virt（） 返回的直接映射地址不同。swiotlb_init_io_tlb_pool（） 当前会从物理起始地址重建池虚拟地址。对于原子池支持的分配，这会在 pool->vaddr 中存储错误的地址。随后，swiotlb_free_tlb（） 将该地址传递给 dma_free_from_pool（），后者将无法识别区块 将分配路径返回的虚拟地址传递到 swiotlb_init_io_tlb_pool（） 中，并将该地址存储在 pool->vaddr 中。这会使池自由路径使用与分配器相同的虚拟地址。（CVE-2026-90387）

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

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

  - bpf：修复 bpf_tracing_link_release 中的警告 验证器中盲目地“tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX”可损坏 trampoline。1. 附加到tail_call_reachable程序“tr->flags”的 fexit 变为“BPF_TRAMP_F_CALL_ORIG |BPF_TRAMP_F_TAIL_CALL_CTX“。而且，trampoline 将使用 jmp insn 而非调用 insn 戳戳目标 prog 的 nop insn。2. 另一个装有相同tail_call_reachable前进目标的 fexit。“tr->flags”变为“BPF_TRAMP_F_TAIL_CALL_CTX”。3. 关闭第一个 fexit 链接。由于“tr->flags”中无BPF_TRAMP_F_CALL_ORIG，trampoline 将无法使用调用 insn 还原程序的 nop insn。[ 3.410719] WARNING： kernel/bpf/syscall.c：3551 at bpf_tracing_link_release+0x53/0x60， CPU#1： test_progs/98 ...[ 3.428793] bpf_link_free+0x58/0x130 [3.429293] bpf_link_release+0x23/0x30 通过以“|=”和锁定更新“tr->flags”来修复警告。
    (CVE-2026-92485)

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

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

  - xsk：遵循零复制路径中的XDP_TX_METADATA 只要 UMEM 具有元数据空间，即使描述符未设置XDP_TX_METADATA，零复制路径也会读取 TX 元数据。通过元数据帮助程序传递描述符选项，除非设置了选项，否则忽略元数据。这不会修复针对 mlx5 MPWQE 的现有 per-WQE 元数据处理。只有启动会话的描述符才能通过 xsk_tx_metadata_request（） 并配置批处理共享的卸载状态。因此不会验证加入开放会话的描述符上的元数据，也不会配置其请求的卸载。此外，即使未设置 XDP_TXMD_FLAGS_TIMESTAMP，来自此类描述符的非 NULL 元数据指针也会被视为时间戳完成请求，因此其元数据并集可用未请求的时间戳覆盖。修复一个 MPWQE 内的混合元数据状态需要单独的变更。
    (CVE-2026-90086)

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

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

  - bpf：清除 __bpf_get_task_stack 中出错时的 buf 使用 __bpf_get_task_stack 的 bpf_get_task_stack 和 bpf_get_task_stack_sleepable 帮助程序都已将 buf 定义为ARG_PTR_TO_UNINIT_MEM参数，我们应在每个返回路径中初始化 buf。为__bpf_get_task_stack失败路径添加缺失的 buf memset。
    这提供了确定性的缓冲区内容，当缓冲区直接用作映射键时非常有用。（CVE-2026-90300）

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

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

  - drm/amd/display：将 MST HDCP 每个连接器数组的大小调整为 32 AMDGPU_DM_MAX_DISPLAY_INDEX为 31。建议最多 32 个连接器。但它的使用方式就像MAX_DISPLAY_COUNT一样。因此，我们与 DRM 核心相差，它最多支持 32 个连接器。将 AMDGPU_DM_MAX_DISPLAY_INDEX 重命名为 AMDGPU_DM_MAX_DISPLAY_COUNT 以匹配其实际用途，并将大小增大到 32 以匹配最初预期的大小。（CVE-2026-90289）

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

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

  - dm-pcache：验证持久内存 cache_pos_decode（）、cache_key_decode（） 和 cache_replay（） 的 last-kset 分支中的 seg_id 字段，回写工作线程和 GC 工作线程从缓存设备元数据获取缓存段 ID 并将其编入索引 cache->segments[]，而无需根据缓存>n_segs进行检查。
    该元数据仅通过固定的公共种子受到 CRC 保护，因此在表加载 （CAP_SYS_ADMIN） 上提供缓存设备的玩家可控制 id;超出范围值会形成失控的pcache_cache_segment指针，并通过此指针进行取消引用和写入 -- 由磁盘上的数据驱动的越界读写。添加 cache_seg_id_valid（） 并拒绝每个解码站点的超出范围的 ID，从而导致操作失败，并使用 -EIO 而不是编制超出数组的索引。根据初始化段计数 （cache_info.n_segs） 而不是物理设备总数绑定 ID。seg_num 以下的伪造 cache_info.n_segs 否则会留下 segments[cache_info.n_segs..seg_num） 作为数据指针为 NULL 的归零 struct，因此仍会取消引用该窗口中伪造的 ID。更新的修补程序保证 cache_info.n_segs <= seg_num，并且驱动程序创建的缓存将两者相等，因此有效图像不受影响。（CVE-2026-93201）

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

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

  - ntfs：修复 ntfs_decompress（） 中的差一页面溢出 ntfs_decompress（） 中的每个标记范围检查使用 if （cb >= cb_sb_end || dp_addr > dp_sb_end） 中断;因此，dp_addr == dp_sb_end会落入符号副本“*dp_addr++ = *cb++”，在目标页面之外写入一个字节。由于 NTFS_SB_SIZE == PAGE_SIZE目的地是单页，因此字节位于相邻页面中，而 *dest_ofs 在子块末尾之后保留一个（后面的“*dest_ofs &= ~PAGE_MASK”然后产生 1，而不是 0，因此页面永远不会最终完成，后面的子块会继续写过它）。因此，损坏的压缩 $DATA 属性在读取文件时会产生有界运行的越界写入。一旦dp_addr达到 dp_sb_end 就休息;完整的子块仍然会完成，因为其最终副本会dp_addr前进到恰好dp_sb_end。
    (CVE-2026-90118)

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

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

  - wifi：mac80211_hwsim：避免停止队列耗尽中的空 skb mac80211_hwsim_stop（） 丢弃数据>待定中留下的任何帧。循环当前检查 skb_queue_empty（），然后分别出列。该拆分与 TX 状态处理有关争用，可删除队列锁定下的待定帧。如果在空检查后删除最后一个条目，则 skb_dequeue（） 返回 NULL，停止路径会将该 NULL skb 传递到 ieee80211_free_txskb（）。请改用 skb_dequeue（） 作为循环条件。出列结果是停止拥有和释放的对象，清空队列的并发状态完成只会使循环终止。（CVE-2026-93149）

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

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

  - bpf、riscv：修复 arena load_acquire emit_atomic_ld_st（） 返回 1 的可扩展处理，使 build_body（） 跳过子词load_acquire后的 zext。调用程序会执行 ret = ret ？： add_exception_handler（...），这会跳过任何非零 ret 上的 add_exception_handler（），因此缺少可扩展的条目且错误PROBE_ATOMIC load_acquire错误。REG_DONT_CLEAR_MARKER使 rd 因错误而过时，而校验器仍认为负载覆盖了它，因此程序可通过映射泄露它。调用 add_exception_handler（） 之前检查 ret >= 0，并传递 rd 进行LOAD_ACQ，这样错误就会像PROBE_MEM负载一样将 rd 归零。针对 zext 跳过返回未更改的 ret。（CVE-2026-92517）

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

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

  - arm_mpam：禁用驱动程序取消绑定以避免 UAF 当用户取消绑定 MSC 并且该 MSC 是组件唯一剩下的 MSC 时，将释放相应的mpam_component。如果用户随后继续读取 resctrl 文件系统中的 schemata 文件，则将从 resctrl_arch_get_config（） 访问mpam_component，导致释放后使用。由于 MPAM 驱动程序不是模块，因此取消绑定 sysfs 接口是触发删除的唯一方式。无需处理允许某些未使用的 MSC 取消绑定的复杂问题，只需删除 unbind sysfs 接口。（CVE-2026-90270）

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

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

  - phy：qcom：qmp-usb-legacy：修复早期运行时挂起时可能的空取消引用 存在一个小窗口，运行时挂起回调可在 pm_runtime_enable（） 之后和 pm_runtime_forbid（） 之前运行。在这种情况下，会发生崩溃，因为运行时暂停/恢复取消引用 qmp->phy 指针，其尚未初始化：“if （！qmp->phy->init_count） {' 如果用户在 qmp phy 初始化之前通过 sysfs 属性重新启用 runtime-pm，也会发生此情况。与其他 qcom phy 驱动程序类似，引入可用于避免依赖可能未初始化 phy 指针的 qmp->phy_initialized 变量。
    (CVE-2026-90282)

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

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

  - ksmbd：不跳过对单字节范围的锁定检查 check_lock_range（） 使用包含范围。其调用程序将结束偏移作为 start + length - 1 传递，因此 start == end 代表有效的单字节范围，而不是空白范围。因此，start == end 快捷方式会跳过对单字节读取、写入、copychunk 操作和单字节截断范围的强制性字节范围锁定检查。未检查覆盖该字节的冲突锁定，并允许操作继续进行。删除快捷指令。截断大小 == inode->i_size 情况已通过仅在新大小与当前文件大小不同时调用 check_lock_range（） 来处理。（CVE-2026-90176）

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

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

  - drm/amd/display：修复 CRTC 重置函数中的悬摆指针 amdgpu_dm_crtc_reset_state（） 在分配新状态之前释放旧状态。如果 kzalloc（） 失败，该函数返回时不更新状态指针，为已释放的内存留下一个悬摆指针。通过首先分配新状态修复此问题。
    分配失败时，旧状态保持不变，函数会安全返回。由 Linux 验证中心 （linuxtesting.org） 使用 SVACE 发现。[调整围绕当前 amd-staging-drm-next 的移动]（CVE-2026-93175）

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

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

  - ext4：使用 fsdata 跟踪内联数据写入状态并修复争用 不要在 write_end 处理程序中检查实时 inode 状态（ext4_has_inline_data（inode） 和 ext4_test_inode_state（inode， EXT4_STATE_MAY_INLINE_DATA）），而是使用地址空间操作的 fsdata 参数来显式传递 write_begin 准备写入的状态。并发线程（如 ext4_page_mkwrite（））可以将内联数据转换到介于 write_begin 和 write_end 之间的范围。如果发生这种情况，write_end处理程序先前会错过内联write_end路径，并失败至基于范围的write_end逻辑。
    但是，由于从未在 write_begin 中分配区块缓冲区，这将导致空指针取消引用或数据丢失，原因是 folio_buffers（folio） 为 NULL。将 EXT4_WRITE_DATA_INLINE （4） 定义为位标记（位 2），将 fsdata 视为按位标记而不是互斥枚举，以保持写入路径状态独立。通过 fsdata 传达此状态：成功准备内联写入时，1） ext4_write_begin（） 和 ext4_da_write_begin（） 通过按位 OR 设置 *fsdata 中的EXT4_WRITE_DATA_INLINE位。2） 输入时，ext4_write_begin（） 清除 EXT4_WRITE_DATA_INLINE 位以安全地处理 VFS 重试（其中 generic_perform_write（） 在其重试跳跃时绕过 fsdata 初始化）。
    3） write_end处理程序会执行逐位 AND 以检查 EXT4_WRITE_DATA_INLINE 位是否已设置，并相应地调用内联 write_end 帮助程序。此外，在缓冲写入期间，ext4_write_inline_data_end（） 会在准备写入之后获取 xattr 锁定。如果并发页面错误 （ext4_page_mkwrite（）） 在 write_end 处理程序检查状态之后但在 ext4_write_inline_data_end（） 获取 xattr 写锁定之前将内联数据转换为某个范围，则后续检查将通过 BUG_ON（！ext4_has_inline_data（inode）） 触发内核错误。为了保持 git 历史记录有效且可一分为二，请将 ext4_write_inline_data_end（） 中的BUG_ON检查替换为同一提交中的妥善错误处理重试路径。如果在锁定 xattr 后清除了内联数据，我们将安全地释放所有资源（释放 iloc.bh、解锁/放置 folio、停止活动的日志事务句柄）并返回 0（VFS 重试）以让通用写入路径安全地重试操作。（CVE-2026-92500）

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

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

  - libceph：验证标题负载长度 解析 Ceph messenger v2 协议标题时，会从标题前缀解码“payload_len”字段。如果客户端发送带有 0 payload_len 的标题，则内核将设置 0 长度的套接字读取。这违反了状态机中的不变量，在“populate_in_iter（）”中触发警告：------------[ cut here ]------------ !iov_iter_count（&con->v2.in_iter） WARNING： net/ceph/messenger_v2.c：3129 at populate_in_iter net/ceph/messenger_v2.c：3129 [inline]， CPU#1：
    kworker/1:3/5070 WARNING： net/ceph/messenger_v2.c：3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c：3159， CPU#1： kworker/1:3/5070 ... 调用跟踪： <TASK> ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c：1575 process_one_work kernel/workqueue.c：3322 [内联] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c：3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c：3486 kthread+0x388/0x470 kernel/kthread.c：436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 </TASK> 根据 msgr2 协议规范，标题负载应至少包含两个 64 位整数（“server_feat”和“server_req_feat”）。因此，“payload_len”必须至少为 16 个字节。通过在“process_banner_prefix（）”中添加检查以拒绝小于 16 字节的“payload_len”修复此问题。这阻止 0 长度读取并正确地因协议错误中止连接。（CVE-2026-90067）

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

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

  - drm/sun4i：tcon：终止 TCON TOP 设备引用 of_find_device_by_node（） 采用设备引用。在 mux 配置成功后将其终止。（CVE-2026-90298）

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

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

  - iommu/tegra241-cmdqv：修复 init-failure 路径上的 VINTF0 泄漏 tegra241_cmdqv_init_structures（） 通过 kzalloc_obj（） 分配 VINTF0，初始化它，然后预分配其逻辑 VCMDQ。其两个错误路径泄漏。
    当 tegra241_cmdqv_init_vintf（） 失败时，它会在 VINTF0 到达 cmdqv->vintfs[] 数组之前返回，因此探测失败时 devres 展开无法到达它;直接在此处释放它。之后的 VCMDQ 预分配失败反而会使 VINTF0 处于发布状态，因此这次展开会到达 tegra241_cmdqv_remove_vintf（），然后将其从 vintf->hyp_own 中释放。但 tegra241_vintf_hw_init（） 只会在之后从 HW 回读设置该标记，因此仍未初始化的 VINTF0 读取为客户机所有并泄漏，mutex_destroy（） 和 ida_destroy（） 在其从未设置过的字段上运行。从 vintf->idx 决定所有权，而是分配其 id 时分配的索引：idx 0 是内核拥有的 VINTF0，而 idx >= 1 标记客户机 VINTF。因此，tegra241_cmdqv_remove_vintf（） 和 tegra241_vintf_free_lvcmdq（） 中的内核内释放决定现在也以 idx 为关键，并且hyp_own保持纯 HW 回读状态。
    (CVE-2026-90424)

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

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

  - scsi：sd：修复 scsi_alloc_sgtables（） 失败时special_vec内存池泄漏 sd_set_special_bvec（） 为 UNMAP 和 WRITE SAME 命令分配特殊的负载页面。如果之后在 sd_setup_unmap_cmnd（） 或 sd_setup_write_same{10,16}_cmnd（） 中 scsi_alloc_sgtables（） 发生故障，SCSI 中间层不会调用 uninit_command（），因为RQF_DONTPREP尚未设置，从而导致泄漏页面。出错时调用 sd_uninit_command（），释放页面后清除RQF_SPECIAL_PAYLOAD。（CVE-2026-90267）

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

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

  - nilfs2：防止超级根区块中的越界读取 在 nilfs_read_inode_common（） 之前，超级根区块解析超级根 inode 元数据大小受到信任。拒绝其计算的磁盘占用空间超过文件系统区块大小的 super-root inode 大小。这可防止畸形文件系统图像使 nilfs_read_inode_common（） 读取超过超级根块的末尾。[ryusuke：明确提交标题]（CVE-2026-90419）

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

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

  - btrfs：zoned：btree_writepages（） 启动时刷新活动元数据块群组 btree_writepages（） 按逻辑地址升序写入 btree inode 的脏元数据。在分区文件系统上，一次只有一个元数据和一个系统块组可进行写入，且 check_bg_is_active（） （通过 btrfs_check_meta_write_pointer（）） 会在回写从一个块组移动到下一个块组时透视活动块组。如果活动块组位于比另一个也持有脏元数据的块组更高的逻辑地址，则升序遍历首先到达较低的块组，并且要写入它，必须完成活动块组并激活较低的块组。它无法完成仍有未发送 IO 的区块群组，并且在 WB_SYNC_ALL & ！for_sync（提交）回写期间，它故意拒绝等待 fs_info->zoned_meta_io_lock 下的该 IO，因为这可能会死锁。因此，枢纽本身也无法发出提交，因此它放弃：btrfs_check_meta_write_pointer（） 返回 -EAGAIN，btrfs_write_and_wait_transaction（） 将其视为致命并中止事务，从而强制文件系统为只读。这在元数据密集型重定位（例如 fstests btrfs/187）下间歇性发生。在 btree_writepages（） 开头刷新活动元数据和系统区块群组，在其已持有的 fs_info->zoned_meta_io_lock 下，这样它们就没有剩余的未发送 IO，而后面的枢纽可以完成它们并向前推进。（CVE-2026-90261）

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

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

  - samples/ftrace：修复 ftrace-direct-multi-modify 中ERR_PTR上的 kthread_stop（） ftrace_direct_multi_init（） 在不进行 IS_ERR（） 检查的情况下将 kthread_run（） 的返回值分配给 simple_tsk。当 kthread_run（） 失败时，它返回 ERR_PTR（-ENOMEM），但 init 仍返回 0，因此模块加载时包含错误指针的simple_tsk。卸载时，ftrace_direct_multi_exit（） 随后将该ERR_PTR传递给 kthread_stop（），从而导致空指针取消引用。使用 IS_ERR（） 检查 kthread_run（） 的返回值;失败时，取消注册 ftrace 直接调用并传播错误代码。（CVE-2026-90066）

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

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

  - usb：gadget：r8a66597：避免探测错误路径中的ep0_req双重释放 如果 usb_add_gadget_udc（） 失败，r8a66597_probe（） 跳转到 err_add_udc 并释放ep0_req，然后转向 clean_up2，当它为非 NULL 时，ep0_req 将再次释放。从err_add_udc中删除冗余的释放并保持clean_up2清理，这样请求才会被释放一次。使用原型静态分析工具发现问题，并经代码审查确认。（CVE-2026-93141）

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

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

  - misc：bcm-vk：针对 msgq_inited bcm_vk_sync_msgq（） 使用 acquire/release 填充消息队列信息，然后设置msgq_inited。阅读器在访问消息队列及其缓存队列信息之前调用 bcm_vk_drv_access_ok（）。atomic_set（）/atomic_read（） 不会对这些访问进行排序。阅读器可以看到msgq_inited设置，同时仍可以看到过时的队列信息。发布初始化队列时使用释放，检查门时使用获取。将 bcm_vk_blk_drv_access（） 中的清除保持为 atomic_set（）。它关闭门，并且不向阅读器发布队列状态。（CVE-2026-93052）

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

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

  - arm64：ptrace：保持“orig_x0”与 syscall 条目提交 e057b9477232 上的 x0 同步（arm64：syscall：
    确保保存的 x0 与跟踪程序更新保持同步）尝试解决 syscall 条目跟踪的一个长期问题，其中跟踪程序能够操纵第一个 syscall 参数而无需进行 seccomp 或审计检查。遗憾的是，该修复并不完整 [1]，因为它未能在 seccomp ptrace 退出 （SECCOMP_RET_TRACE） 期间更新 x0 的追踪程序与重新评估的 seccomp 过滤器之间的“orig_x0”。不要将挂钩添加到核心 seccomp 代码，而是将同步代码移动到 ptrace GPR 和 syscall 设置代码中，以便无论在 syscall 条目路径上停止什么时候，“orig_x0”都与 x0 保持最新。（CVE-2026-90347）

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

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

  - RDMA/nldev：验证动态计数器属性长度 RDMA_NLDEV_ATTR_STAT_HWCOUNTERS 是嵌套属性，其子项直接通过 nla_get_u32（） 使用。顶级策略仅验证容器，因此不会建立每个子容器的固定形状。要求每个子负载在读取之前正好是一个 u32。（CVE-2026-92523）

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

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

  - net：mana：将 MSI-X 矢量封装到设备 MSI-X 表大小 mana_gd_query_max_resources（） 的>num_msix_usable大小来自 resp.max_msix 和 CPU 计数，但从不来自设备 MSI-X 表。在 1792 vCPU M 系列 VM 上，当表有 1024 个条目时，产生 1793，然后 mana_gd_setup_remaining_irqs（） 遍历指数 1..1792，从msix_map_region（） 映射的区域的末端运行： 缺陷：无法处理地址的页面错误：ff8e347f8b99800c RIP：0010：msix_prepare_msi_desc+0x7a/0x90 RAX：
    0000000000004000 RBX：ff4330cb164ea780 RCX：ff8e347f8b998000 调用跟踪： <TASK>
    __msi_domain_alloc_irqs+0x13a/0x440 msi_domain_alloc_irq_at+0x149/0x1b0 mana_gd_setup+0x351/0x890 mana_gd_probe+0x274/0x390 </TASK> RAX 为索引 1024 * PCI_MSIX_ENTRY_SIZE，超出表一个条目。
    msi_insert_desc（） 会对索引进行范围检查，但仅针对 MSI 域 hwsize（仅与表匹配 MSI 父域上的设备）。使用全局 PCI/MSI 域时，hwsize MSI_XA_DOMAIN_SIZE，因此没有任何内容会限制请求。使用 pci_msix_vec_count（） 封num_msix_usable。（CVE-2026-90082）

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

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

  - nfc：nci：修复解析 nci_core_init_rsp_packet_v1（） 和 nci_core_init_rsp_packet_v2（） 解析 CORE_INIT_RSP 数据包而不验证 skb 是否包含足够的数据CORE_INIT_RSP时对未初始化内存的使用。格式错误的响应（如通过 virtual_ncidev 注入的响应）可在提供不足数据的同时声明大num_supported_rf_interfaces，从而造成读取未初始化的 slab 内存。
    此项稍后用于 nci_init_complete_req（），触发 KMSAN uninit-value 警告。在访问数据包字段之前添加 skb 长度检查：- 验证 skb 状态字段至少有 1 字节。- 在解析之前验证 skb 能否保存固定大小的标头。- 在 v2 中，对解析循环中的每个可变长度rf_interface条目及其扩展参数进行边界检查。- 在 v1 中，验证 skb 是否足够大，可变长度 rf_interfaces 数组和尾部 rsp_2 结构。（CVE-2026-90221）

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

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

  - cxl/features：拒绝小于标头的 Set Features 输出缓冲区 cxlctl_set_feature（） 会根据用户的 fwctl_rpc.out_len 计算其输出缓冲区大小，但从未检查其大小是否足以容纳 fwctl_rpc_cxl_out 标头。当 out_len == 0 时，kvzalloc（） 返回 ZERO_SIZE_PTR，这会通过 ！rpc_out 检查，随后的 rpc_out->size = 0 然后通过毒害指针写入。在分配之前，拒绝其输出缓冲区无法保存响应头的请求。Set Feature 回复不携带有效负载，因此只需要标头。（CVE-2026-93078）

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

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

  - HID：roccat：绑定设备提供的配置文件索引 kone_keep_values_up_to_date（） 和 kone_profile_activated（） 使用设备提供的 8 位配置文件值作为 5 元素 kone->profiles[] 数组的索引，而不进行范围检查。声明 Roccat Kone ID 的恶意 USB 设备可发送带有超出范围值的切换配置文件事件（或探测时的startup_profile读取），并使驱动程序读取越界;结果会通过actual_dpi sysfs 属性泄露。拒绝两个路径中的超出范围索引。这是通过静态分析发现的，并通过以下修补程序中添加的 KUnit 测试证实（KASAN：slab-out-of-bounds）。（CVE-2026-93188）

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

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

  - sched/fair：修复 update_tg_cfs_runnable（） 中的溢出 运行 hackbench 时出现除以零崩溃：[14697.488452] CPU：112 UID：0 PID：124791 Comm：hackbench 未受感染 7.1.0-rc2+ [14697.492627] RIP：0010：propagate_entity_load_avg+0x35f/0x3e0 [14697.506799] <TASK> [14697.507411]
    __dequeue_task+0x2b4/0xc70 [14697.508677] dequeue_task_fair+0x36/0x370 [14697.509047] dequeue_task+0x101/0x2f0 [14697.509426] __schedule+0x1b1/0x1a00 [14697.510868] anon_pipe_read+0x3da/0x450 [14697.511400] vfs_read+0x361/0x390 [14697.512053] __x64_sys_read+0x19/0x30 除以零会在此处发生： if （scale_load_down（gcfs_rq->load.weight）） { load_sum = div_u64（gcfs_rq->avg.load_sum， scale_load_down（gcfs_rq->load.weight））; } gcfs_rq->load.weight 是一个非常大的值，div_u64被截断为低 32 位， 恰好是 0。使用 AI 进行调查，原因是 update_tg_cfs_runnable（） 中的 u32 溢出，使用 tg_tasks（） 时扁平拾音成为受害者：u32 new_sum、divider;...new_sum = se->avg.runnable_avg * 分频器;<-- 繁荣 以下序列显示了这如何触发崩溃： propagate_entity_load_avg（） update_tg_cfs_runnable（） # u32 溢出损坏 runnable_sum __update_load_avg_cfs_rq（） ___update_load_avg（） # 计算不合理的 runnable_avg update_tg_load_avg（） # 传播到 tg->runnable_avg update_cfs_group（） calc_concur_shares（） tg_tasks（） # long-to-int 截断，负的 nr reweight_entity（） # 损坏的 se->load.weight update_load_add（） # 损坏的 cfs_rq->load.weightpropagate_entity_load_avg（） update_tg_cfs_load（） div_u64（） # 通过将new_sum从 u32 加宽到 u64 进行修复（在此修复后很长时间内，无需强制 tg_tasks（） 返回无符号状态）（CVE-2026-93182）

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

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

  - bpf：修复 bpf_find_vma（） 中 mm_struct 的释放后使用 bpf_find_vma（） 读取 task->mm 并调用 mmap_read_trylock（mm） 而不保留 mm 上的引用。在外部任务中，并行 exit_mm（） 可释放无锁读取和 trylock 之间的mm_struct，从而导致释放后使用。mm_struct不SLAB_TYPESAFE_BY_RCU。对于当前任务，task->mm 是稳定的。对于外部任务，将 mm 固定在 task->alloc_lock 下，然后使用 mmput_async（） 将其释放，镜像提交 d8e27d2d22b6（bpf：修复开放代码 task_vma 迭代器中的 mm 生命周期）。使用 spin_trylock（） 而不是 get_task_mm（），这样 BPF 上下文就不会在alloc_lock上阻断。拒绝 irqs-disabled 上下文和 foreign-task 路径上的 ！CONFIG_MMU，因为丢弃 mm 引用在那里不安全。争用：CPU0（BPF 程序） CPU1（退出任务） ============================ ========================== bpf_find_vma（foreign_task）：mm = task->mm exit_mm（）：task->mm = NULL mmput（mm） -> 释放 mm_struct mmap_read_trylock（mm） // mm （CVE-2026-93137） 上的 UAF

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

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

  - dax/fsdev：对 direct_access 中的 kaddr 使用 __va（phys） 针对 __fsdev_dax_direct_access（） 中的 kaddr 返回使用 __va（phys） 而不是 virt_addr + linear_offset。上一个代码向 virt_addr 添加了设备线性字节偏移（即 ranges[0] 的__va），但对于范围之间存在物理间隙的多范围设备，此线性算术会交叉间隙并生成错误的内核虚拟地址。对于任何范围布局，使用 __va（phys） 都是正确的，其中 phys 来自 dax_pgoff_to_phys（） ，因为直接映射独立地转换每个物理地址。这会将 dev_dax->virt_addr 设置为只写，因此删除该字段（建议者为 Dave Jiang）。（CVE-2026-93074）

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

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

  - ublk：如果地址范围（由用户空间 ublk 服务器提供）超出允许的用户地址空间，检查 import_ubuf（） 返回值 import_ubuf（） 可能失败。返回 import_ubuf（） 失败时已复制的 0 字节，而不是将未初始化的 struct iov_iter传递给 ublk_copy_user_pages（）。
    (CVE-2026-90324)

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

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

  - null_blk：将DEFINE_MUTEX用于文件范围互斥体 在 null_init（） 中，mutex_init（&lock） 目前发生在 configfs_register_subsystem（） 之后，这会将 nullb 子系统暴露给用户空间。在初始化互斥体之前，进入 /sys/kernel/config/nullb/ 的争用 mkdir（） 可达到 null_find_dev_by_name（） -> mutex_lock（&lock），触发警告： [ 123.137788] DEBUG_LOCKS_WARN_ON（lock->magic ！= lock） [ 123.137796] 警告：kernel/locking/mutex.c：159 at mutex_lock+0x171/0x1c0， CPU#13： mkdir/1301 [ 123.140090] 链接的模块：null_blk（+） nft_fib_inet nft_fib_ipv4 ......[ 123.154926] 调用跟踪： [ 123.155172] [123.155419<TASK>] ？ __pfx_mutex_lock+0x10/0x10 [ 123.156181] ？ __pfx__raw_spin_lock+0x10/0x10 [ 123.156571] nullb_group_make_group+0x20/0x100 [null_blk] [ 123.157011] configfs_mkdir+0x47b/0xc70 [ 123.157337] ？
    __pfx_configfs_mkdir+0x10/0x10 [ 123.157719] ？ may_create_dentry+0x242/0x2e0 [ 123.158061] vfs_mkdir+0x2a9/0x6c0 [ 123.158352] filename_mkdirat+0x3dc/0x500 [ 123.158710] ？
    __pfx_filename_mkdirat+0x10/0x10 [ 123.159070] ？ strncpy_from_user+0x3a/0x1d0 [ 123.159413]
    __x64_sys_mkdir+0x6b/0x90 [ 123.159760] do_syscall_64+0xea/0x600 将运行时 mutex_init（&lock） 替换为静态 DEFINE_MUTEX（lock） 声明以修复此问题。（CVE-2026-90190）

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

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

  - 时间/命名空间：验证 proc_timens_set_offset（） 中的纳秒字段 该函数验证tv_sec是否在 [-KTIME_SEC_MAX， KTIME_SEC_MAX] 范围内，但在将其用于 timespec64_add（） 之前从未验证tv_nsec是否在有效范围 [0， NSEC_PER_SEC-1] 范围内。timespec64_add（） 预期两个 timespec64 结构都有标准化值，tv_nsec在 [0， 999999999] 范围内。如果 off->val.tv_nsec 包含无效值（负值或 >= NSEC_PER_SEC），则可导致不正确的计算或发生意外行为。执行加法之前，添加验证以确保tv_nsec在有效范围内。（CVE-2026-93146）

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

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

  - bpf：修复 bpf_get_btf_vmlinux bpf_get_btf_vmlinux（） 中的 vmlinux BTF 准备争用 延迟解析bpf_verifier_lock下的 vmlinux BTF，但通过普通存储发布结果并通过普通无锁加载重新检查。没有对发布指针的存储排序 btf_parse_vmlinux（） 内部初始化 struct btf 的存储：在弱排序的 arch 中，原则上，首次并行调用者可先于显示已解析的内容之前观察到指针。由于 mutex_unlock（） 仅与以后采集的相同锁定同步，因此此类阅读器没有帮助。因此，请使用 smp_store_release（） 发布指针并使用 smp_load_acquire（） 在快速路径上读取该指针。需要获取语义，而不是依赖关系排序的 READ_ONCE（）：
    btf_parse_vmlinux（） 还会填充返回对象外部的全局变量（例如 bpf_ctx_convert.t）。地址依赖关系只会对通过指针执行的访问进行排序，不覆盖其他全局。
    (CVE-2026-93138)

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

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

  - thermal：intel：int3400：在探测失败时清理 ODVP evaluate_odvp（） 会在注册热区和后续探测资源之前创建每个 ODVP sysfs 文件。当前展开路径仅从较晚的 sysfs 失败路径调用 cleanup_odvp（），因此 evaluate_odvp（） 之后但在该标签之前的失败（包括 thermal_tripless_zone_device_register（） 失败）会留下 ODVP 文件和存储。将 ODVP 清除移动到通用 ART/TRT 展开路径，以便 evaluate_odvp（） 之后的每次失败都释放 ODVP 状态。还要清除 cleanup_odvp（） 中缓存的 ODVP 指针，因为 evaluate_odvp（） 在探测继续时已经可以针对部分设置失败调用它。（CVE-2026-92504）

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

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

  - bpf、xdp：将卸载检查移动到 dev_xdp_install（） bpf_xdp_link_update（） 会直接调用 dev_xdp_install（） 并跳过 dev_xdp_attach（），因此 dev_xdp_attach（） 中的检查不会运行。用户可以与普通程序建立 XDP 链接，然后使用 BPF_LINK_UPDATE 交换已卸载或设备绑定的程序，这样会将其置于软件路径上。dev_xdp_install（） 是所有三个路径经过的唯一一个位置：ip 链接设置 xdp 和BPF_LINK_CREATE通过 dev_xdp_attach（） 到达它，BPF_LINK_UPDATE 直接调用它。因此将程序检查（卸载、绑定至另一设备、通用模式下设备绑定、本机与通用、DEVMAP 和 CPUMAP）移动到该处，并在 dev_xdp_attach（） 中仅保留 netlink-flag 检查 （XDP_FLAGS_UPDATE_IF_NOEXIST）。
    (CVE-2026-90146)

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

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

  - firmware：arm_scmi：拒绝超出范围的 DT 协议 ID 消息头中携带的 SCMI 协议 ID 受到MSG_PROTOCOL_ID_MASK的限制。DT 解析路径发现超出该范围的协议 ID，但仅记录错误，然后继续处理无效值。这可使畸形 32 位 DT reg 值到达采用 u8 协议 ID 的帮助程序，在其中可将其截断和/或视为其他协议。对于通道设置，对生成的 SCMI 协议身份别名化时，也可以将两个不同的超出范围的值用作不同的 IDR 密钥。在设置通道或创建协议设备之前，跳过其 reg 值不符合 SCMI 协议 ID 字段的 DT 协议节点。（CVE-2026-93085）

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

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

  - ublk：执行uring_cmd前验证 auto buf reg 通过 UBLK_F_AUTO_BUF_REG，无效的 sqe->addr 可在 ublk_fill_io_cmd（） 设置UBLK_IO_FLAG_ACTIVE后失败。当标签保持活动状态时，uring_cmd完成，这可能导致拆卸挂起。从缓冲区应用中拆分验证，这样检查就不会产生副作用，然后获取uring_cmd并存储已验证的缓冲区。在 FETCH 中应用相同的顺序，以便在 __ublk_fetch（） 状态检查之前不写入 io->buf。（CVE-2026-90323）

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

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

  - net/sched：cls_api：修复因插入争用丢失而导致所采用原型的拆卸。在 tc_new_tfilter（） 中，create 分支会在调用 tcf_chain_tp_insert_unique（） 之前将 tp_created = 1 设置为 1。当调用方输掉争用时（另一个请求首先在同一链/prio 上插入了一个原型），insert_unique（） 会破坏调用方自己的tp_new，并返回获胜者的原型和额外的引用。tp_created从未被清除，因此失败者的错误路径将获胜者的实时原型视为自己的原型，并在其上调用 tcf_chain_tp_delete_empty（），静默地取消获胜请求已通过RTM_NEWTFILTER公布的活动分类器的链接。在单个三态变量中跟踪插入步骤的结果，以便每个错误路径都能正确响应：- TP_NOT_CREATED：未创建原型;追寻老路。- TP_CREATED：proto 插入成功;与之前相同的代码路径。- TP_NOT_OWNED：新 - 输掉了插入争用;tp 是另一个请求的原型（tp_new 的 destroy 已发布的链 ref）两个 errout 反应都是从 state 派生的单个表达式。此补丁的动机是 Sashiko 对修补程序的自动审查（net/sched：cls_api：破坏锁定的分类器时始终获取rtnl_lock）[1][2]。审查确定了请求丢失 tcf_chain_tp_insert_unique（） 争用时所采用的原型拆卸的静默取消链接行为。[1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com （CVE-2026-90248）

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

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

  - net/sched：fq_pie：钳制默认量子以避免有符号溢出 fq_pie_init（） 在无钳制的情况下设置 q->quantum = psched_mtu（qdisc_dev（sch））。具有极大 MTU 的设备（例如接受 MTU 2147483634 的 max_mtu == 0 的虚拟）使 psched_mtu（） 返回0x80000000，这导致已签名的 flow->deficit 溢出到 fq_pie_qdisc_dequeue（） 中INT_MIN，从而造成无限循环和软锁定。模拟已经绑定到 [1， 1 << 20] 的 fq_pie_policy;将默认值限制为 [256， 1 << 20]。256 与 fq_codel 的底线相匹配，对于 DRR 量子来说是一个合理的最低值。重现缺陷的条件：MTU（加上 hard_header_len）将 psched_mtu（） 封装到符号位中的设备（例如，max_mtu == 0 接受 MTU 2147483634的虚拟设备）。需要用户命名空间中的CAP_NET_ADMIN。（CVE-2026-90074）

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

ID	名称	严重性
347831	Linux Distros 未修补的漏洞：CVE-2026-90264	medium
347830	Linux Distros 未修补的漏洞：CVE-2026-90128	medium
347829	Linux Distros 未修补的漏洞：CVE-2026-90148	medium
347828	Linux Distros 未修补的漏洞：CVE-2026-90155	medium
347827	Linux Distros 未修补的漏洞：CVE-2026-90356	high
347826	Linux Distros 未修补的漏洞：CVE-2026-90161	high
347825	Linux Distros 未修补的漏洞：CVE-2026-93184	medium
347824	Linux Distros 未修补的漏洞：CVE-2026-90223	high
347823	Linux Distros 未修补的漏洞：CVE-2026-90387	high
347822	Linux Distros 未修补的漏洞：CVE-2026-92485	high
347821	Linux Distros 未修补的漏洞：CVE-2026-90086	medium
347820	Linux Distros 未修补的漏洞：CVE-2026-90300	high
347819	Linux Distros 未修补的漏洞：CVE-2026-90289	high
347818	Linux Distros 未修补的漏洞：CVE-2026-93201	high
347817	Linux Distros 未修补的漏洞：CVE-2026-90118	high
347816	Linux Distros 未修补的漏洞：CVE-2026-93149	medium
347815	Linux Distros 未修补的漏洞：CVE-2026-92517	medium
347814	Linux Distros 未修补的漏洞：CVE-2026-90270	medium
347813	Linux Distros 未修补的漏洞：CVE-2026-90282	medium
347812	Linux Distros 未修补的漏洞：CVE-2026-90176	high
347811	Linux Distros 未修补的漏洞：CVE-2026-93175	high
347810	Linux Distros 未修补的漏洞：CVE-2026-92500	high
347809	Linux Distros 未修补的漏洞：CVE-2026-90067	high
347808	Linux Distros 未修补的漏洞：CVE-2026-90298	medium
347807	Linux Distros 未修补的漏洞：CVE-2026-90424	high
347806	Linux Distros 未修补的漏洞：CVE-2026-90267	medium
347804	Linux Distros 未修补的漏洞：CVE-2026-90419	high
347803	Linux Distros 未修补的漏洞：CVE-2026-90261	medium
347802	Linux Distros 未修补的漏洞：CVE-2026-90066	medium
347801	Linux Distros 未修补的漏洞：CVE-2026-93141	high
347800	Linux Distros 未修补的漏洞：CVE-2026-93052	medium
347799	Linux Distros 未修补的漏洞：CVE-2026-90347	high
347798	Linux Distros 未修补的漏洞：CVE-2026-92523	medium
347797	Linux Distros 未修补的漏洞：CVE-2026-90082	high
347796	Linux Distros 未修补的漏洞：CVE-2026-90221	medium
347795	Linux Distros 未修补的漏洞：CVE-2026-93078	medium
347794	Linux Distros 未修补的漏洞：CVE-2026-93188	high
347793	Linux Distros 未修补的漏洞：CVE-2026-93182	medium
347792	Linux Distros 未修补的漏洞：CVE-2026-93137	high
347791	Linux Distros 未修补的漏洞：CVE-2026-93074	high
347790	Linux Distros 未修补的漏洞：CVE-2026-90324	high
347789	Linux Distros 未修补的漏洞：CVE-2026-90190	medium
347788	Linux Distros 未修补的漏洞：CVE-2026-93146	medium
347787	Linux Distros 未修补的漏洞：CVE-2026-93138	high
347786	Linux Distros 未修补的漏洞：CVE-2026-92504	high
347785	Linux Distros 未修补的漏洞：CVE-2026-90146	high
347784	Linux Distros 未修补的漏洞：CVE-2026-93085	medium
347783	Linux Distros 未修补的漏洞：CVE-2026-90323	high
347782	Linux Distros 未修补的漏洞：CVE-2026-90248	medium
347781	Linux Distros 未修补的漏洞：CVE-2026-90074	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

medium

high

high

medium

high

high

high

medium

high

high

high

high

medium

medium

medium

medium

high

high

high

high

medium

high

medium

high

medium

medium

high

medium

high

medium

high

medium

medium

high

medium

high

high

high

medium

medium

high

high

high

medium

high

medium

medium