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

  - tracing：使 show_event_filters/触发器文件采用跟踪数组引用 新添加的文件show_event_filters和显示跟踪数组内设置的所有筛选器或触发器的文件和show_event_triggers不会引用其显示的跟踪数组。无需引用，可在任务读取这些文件之一时通过 rmdir 释放trace_array。这些文件会迭代一个实例 （trace_array） 内的所有事件，读取该实例的数据时，不会阻止其释放。这会导致释放后使用崩溃。通过 trace_array_get（） 将这两个文件的打开获取trace_array引用，以防止在打开文件时释放trace_array。（CVE-2026-90014）

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

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

  - perf/x86/intel：修复 LBR 堆栈中的内核地址泄漏 在 Arch LBR 获得 CPL 过滤支持之前，仅限用户的分支堆栈仍可包含内核地址。因此，即使请求了 PERF_SAMPLE_BRANCH_USER，内核分支记录也可能暴露在用户空间中。例如，在 Intel Tiger Lake 上，以下命令仍可报告来自地址的具有内核空间的 SYSRET/ERET 条目：$ ./perf record -e cycles：p -o - --branch-filter any，save_type，u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' 总时间： 0.000 [秒] 0.219000 usecs/op 4,566,210 操作/秒 [ perf 记录： 唤醒 1 次写入数据 ] [ perf 记录：
    捕获并写入 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-///6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- 问题在于 intel_pmu_lbr_filter（） 未充分验证抽样条目的权限级别。它会根据分支类型和收件人地址过滤某些不匹配项，但不会拒绝其发件人地址违反所请求分支权限过滤器的条目。通过扩展软件过滤以针对br_sel同时验证发件人和收件人地址来修复此问题。任何包含内核地址的 LBR 条目都不能与请求的用户过滤器相匹配，因此会遭到终止。这可防止内核地址出现在仅限用户的分支堆栈中。（CVE-2026-89984）

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

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

  - media：v4l2-ctrls：验证 HEVC EXT SPS RPS 计数 HEVC SPS 控件携带解码器驱动程序用于遍历匹配的 EXT SPS 动态数组的短期和长期 RPS 计数。拒绝超过 64 个短期集和 32 个长期参考的 HEVC 限制的 SPS 值，以便驱动程序以后无法在超出这些控件进行索引。同时拒绝其负或正图片计数超过 16 个条目数组，或者其 delta-POC 计数组合超过 HEVC DPB 最大值的 EXT SPS ST RPS 条目。
    (CVE-2026-89873)

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

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

  - KVM： nVMX：对嵌套失败的 VM-Enter 进行服务本地 TLB 刷新 KVM 在完全嵌套的 VM-Exit（通过 __nested_vmx_vmexit（））时进行服务，但嵌套 VM-Enter 失败时（例如由于 nested_vmx_enter_non_root_mode（）） 中的 VMCS 检查失败）则不会刷新。然而，即使嵌套 VM-Enter 未成功，KVM 仍有可能需要执行的排队 TLB 刷新。例如，如果为 L2 禁用 VPID（通过 nested_vmx_transition_tlb_flush（），或如 SDM 所说的通过 MSR 加载列表：如果以架构上需要 TLB 刷新的方式加载任何 MSR，则 TLB 将更新，以便在 VM 进入后，逻辑处理器将不使用在转换之前缓存的任何转换。SDM 不清楚何时应该进行 TLB 刷新，以及失败的 VM 条目是否刷新 TLB，因此在此情况下始终进行 TLB 刷新更安全。更具体地说，KVM 还会更新上一个用于 nested_vmx_transition_tlb_flush（） 中 L2 的 VPID L1（即 last_vpid），即使 VM 进入最终失败也是如此。使用当前代码，如果 L1 更改 L2 的 VPID，然后执行一个失败的 VM 输入，然后执行一个成功的 VM 输入，则 KVM 可能错过 TLB 刷新，因为失败的 VM 输入会更新last_vpid但实际上不会刷新 TLB。针对失败的 VM 条目提供本地 TLB 刷新服务可确保在更新 last_vpid时始终刷新 TLB。（CVE-2026-89930）

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

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

  - media：v4l2-fwnode：修复 v4l2_fwnode_parse_link 中的 fwnode 泄漏 在 v4l2_fwnode_parse_link（） 中，使用 fwnode_graph_get_remote_endpoint（） 获取远程端点 fwnode 引用。此引用在错误路径中正确释放，但在成功路径中泄漏。返回 0 之前添加了缺失的 fwnode_handle_put（） 以防止引用泄漏。[Sakari Ailus：稍微修复主题前缀和编码样式。]（CVE-2026-89872）

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

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

  - drm/amdkfd：在 MES 队列逐出/暂停后添加 TLB 刷新。与自动执行此操作的 HWS 不同，MES （Micro Engine Scheduler） 在取消映射队列后不会执行重磅 TLB 无效化。
    这会造成争用条件，其中正在传输的 DMA 描述符可以访问未映射的内存，从而导致 SVM 页面迁移期间发生页面错误和 GPU 队列挂起。此问题表现为启用 XNACK 模式 1 时，gfx1151 （Strix Point） 上的 KFDSVMRangeTest.MultiThreadMigrationTest 失败，GPU 计算队列挂起并提交了数据包但从未消耗。在两个位置删除 MES 队列后添加 kfd_flush_tlb（） 调用：- evict_process_queues_cpsch（）：在逐出期间删除所有队列之后 - suspend_queues（）：在 debug/criu 队列暂停之后（使用 mem_fence 屏障） 这样可以确保在释放或迁移内存之前刷新来自未映射队列的所有正在传输的内存。（从提交 f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77 中精选出的内容）（CVE-2026-89811）

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

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

  - iio：buffer：将 IIO dma 隔离锁定生命周期绑定到隔离 “iio_dma_fence”实现当前使用嵌入在“iio_dmabuf_priv”中的锁定。但“iio_dma_fence”的寿命可能超过“iio_dmabuf_priv”，这可导致释放后使用。通过将锁定的生存期嵌入到同一结构中，将锁定的生存期与围栏的生存期联系起来。我们不能只保留对来自“iio_dma_fence”的“iio_dmabuf_priv”的引用，因为“iio_buffer_dmabuf_release（）”可能会休眠，而不允许隔离释放回调进入休眠状态。
    请注意，“dma_fence”框架现在具有内部锁定，在“dma_fence_init（）”中将“lock”传递“NULL”时使用，但为了允许向后移植此修补程序，请使用外部锁定。
    (CVE-2026-89940)

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

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

  - f2fs：只有 redirty 固定 redirty_blocks redirty_blocks（） 中的 folios 会用 read_cache_folio（） 固定作品集，然后使用 filemap_lock_folio（） 再次遍历相同的范围以对其进行 redirty 并丢弃它占用的引用。提交 5951fee46bef（f2fs：在 redirty_blocks（） 中使用作品集）将第二个传递更改为 do/while 循环。如果 read_cache_folio（） 在固定任何内容之前失败，page_idx 不会前进，但清除循环仍会运行一次。如果 readahead 已在页面缓存中填充了失败的作品集，则该额外迭代会找到它，并且 folio_put_refs（folio， 2） 丢弃一个引用过多。之后的drop_caches或回收可以报告 BUG： Bad page state。仅重塑已成功固定的范围。
    (CVE-2026-89841)

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

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

  - usb：typec：hd3ss3220：跟踪每个使用者的 VBUS 启用状态 regulator_is_enabled（） 报告聚合调节器状态，而不是此使用者是否持有启用引用。如果另一个使用者先启用 VBUS，驱动程序可跳过自己的 regulator_enable（） 调用，稍后尝试丢弃从未获取的引用，从而触发不平衡稳压器禁用警告。跟踪本地成功的启用和禁用调用。操作失败时保持状态不变，以便在此使用者保持平衡引用时由后续角色或 ID 通知重试该操作。（CVE-2026-90028）

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

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

  - drm/nouveau/uvmm：展开 OP_UNMAP_SPARSE 时清除脏标记 成功的OP_UNMAP_SPARSE用 nouveau_uvma_region_dirty（） 将其区域标记为脏区域，并将拆卸推迟到 nouveau_uvmm_bind_job_cleanup（） 中;它不会从 UVMM->region_mt中删除该区域。如果作业中较新的 op 失败，展开路径永远不会清除 reg->dirty（设置在一个位置，未在任何地方清除）并设置 op->reg = NULL，因此清除会跳过拆卸。该区域被保留在具有脏集的树中，并且从未发出完成信号。之后超过该范围的绑定随后会在 uvmm 的生命周期内永久失败 -- -ENOENT 或来自脏检查的 -EINVAL，或是 bind_validate_region（） 中无法终止的 wait_for_completion（）。
    展开恢复稀疏取消映射时清除 reg->dirty，将区域还原到找到它的状态。（CVE-2026-89800）

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

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

  - media：cx23885：拆卸前取消 NetUP CI 工作 netup_ci_exit（） 可在netup_ci_state的工作项 netup_read_ci_status（） 可能仍处于待定状态或在系统工作队列中运行时释放该。工作线程使用 container_of（） 获取状态并取消引用它，因此它的寿命不得超过该状态。netup_ci_init（） 会将初始状态读取放入队列，CI GPIO 中断随后会将来自 netup_ci_slot_status（） 的相同工作排队。删除期间，cx23885_finidev（） 会在 CI 设备取消注册前调用 free_irq（）。free_irq（） 阻止进一步的 IRQ 处理程序运行，但不会耗尽之前排入队列的工作，因此工作线程可以在 netup_ci_exit（） 释放状态之后运行。在调用 dvb_ca_en50221_release（） 和 kfree（） 之前先调用 cancel_work_sync（）。此问题由内部静态分析工具发现。
    (CVE-2026-89893)

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

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

  - LoongArch：BPF：将 arena 寄存器插槽移至 TCC 上下文下方 当前，堆栈布局将可选的 arena 寄存器插槽置于末尾调用计数器上下文之上。动态启用arena_vm_start时，它会移动堆栈帧内tcc_ptr插槽的相对偏移量，导致硬编码跟踪宏不匹配，从而可能导致内存未对齐或损坏。要解决此问题，请将 arena 寄存器保存和还原序列移动到 build_prologue（） 和 epilogue 中的尾部调用计数器上下文插槽下方。更新 __build_epilogue（） 以插入适当的偏移量递减，以安全跳过不需要的tcc_ptr读取区块，同时与最底部重新定位的 arena 插槽准确对齐。通过此修补程序，tcc_ptr插槽始终位于基本被调用方保存的寄存器的正下方的固定距离处，与竞技场功能是否开启无关。（CVE-2026-89905）

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

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

  - media：em28xx：修复断开连接时 dev_next->devlist 的释放后使用 探测 has_dual_ts=1 的设备并采用is_audio_only路径时，dev 和 dev->dev_next 都通过 em28xx_init_extension（） 添加到全局em28xx_devlist。但是，在断开连接期间，em28xx_close_extension（dev） 仅调用 list_del（&dev->devlist），而使 dev->dev_next->devlist 仍然在全局列表中链接。随后通过 kref_put（） 释放 dev_next 时，其 devlist 条目将变为em28xx_devlist中的悬摆指针。下一个调用 em28xx_init_extension（） 的设备探测在 list_add_tail 检测到已释放的节点时，会触发列表损坏缺陷。此缺陷是由提交 a368ecde8a50（USB：核心：通过清除描述符中的保留位修复重复端点缺陷）暴露的，该缺陷会在端点解析期间清除 bEndpointAddress 中的保留位。这会导致模糊端点地址（如 0xf3）被规范化为 0x83，em28xx 将其解释为供应商音频端点，从而启用此类描述符以前无法访问的 is_audio_only + has_dual_ts 代码路径。通过在释放设备之前从 em28xx_close_extension（） 中的全局列表中删除 dev->dev_next->devlist 来修复此问题。（CVE-2026-89891）

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

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

  - nvme-tcp：检查 C2HData PDU 的数据方向 nvme_tcp_handle_c2h_data（） 按命令 id 找到请求并检查其是否具有负载，但不检查命令是否要求读取数据。因此，使用 C2HData 应答写入命令的控制器会到达 nvme_tcp_recv_data（），其中
    _copy_to_iter（） 命中 WARN_ON_ONCE（i->data_source） 并返回 0。接收路径将其转换为 -EFAULT 并重置控制器。不会复制任何数据，因此这不是内存损坏。控制器收到的是一个可随意发出的内核警告，这在通过 panic_on_warn引导的主机上是致命的。发送路径已经知道方向 - 它在构建命令时会查阅 rq_data_dir（） - nvme_tcp_handle_r2t（） 检查其命名请求的长度和偏移。C2HData 路径完全不检查方向。拒绝命令不是读取的 C2HData PDU。拒绝它会导致命令失败并重置控制器，就像此函数中的相邻检查一样;消失的是警告。[ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING： lib/iov_iter.c：193 at
    _copy_to_iter+0x289/0x1330， CPU#0： kworker/0：1H/71 [ 6.888137] CPU： 0 UID： 0 PID： 71 comm： kworker/0：1H 未受感染 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT（lazy） [ 6.891165] 工作队列： nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP： 0010：_copy_to_iter+0x289/0x1330 [ 6.903739] 调用跟踪： [ 6.904085] 6.909254<TASK> [ ] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0[ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] </TASK> [ 6.927226]
    ---[ 结束跟踪 00000000000000000 ]--- [ 6.927878] nvme nvme0：队列 1 复制请求0x71数据失败 [6.928709] nvme nvme0：接收失败：-14 （CVE-2026-89973）

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

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

  - usb：gadget：midi2：修复 f_midi2_free_ep_reqs 中的空指针取消引用 当尝试清理从未初始化的端点时，f_midi2_free_ep_reqs（） 中出现空指针取消引用。通过 configfs 配置 MIDI 2.0 小工具并将区块方向设置为 SNDRV_UMP_DIR_INPUT 时，小工具绑定阶段 （f_midi2_bind（）） 期间会明确跳过 midi1_ep_out 端点的初始化。因此，usb_ep->card 字段仍然为 NULL。随后，当主机设置替代设置时，f_midi2_set_alt（） 通过调用 f_midi2_stop_eps（） 无条件停止 IN 和 OUT 端点，而 （） 又会为两个端点调用 f_midi2_free_ep_reqs（）。为未初始化的midi1_ep_out调用 f_midi2_free_ep_reqs（） 时，它会尝试取消引用 usb_ep->card 以确定要释放的请求数量，从而导致崩溃。在 f_midi2_free_ep_reqs（） 中使用 usb_ep->num_reqs 而非 usb_ep->card->info.num_reqs 来修复此问题。usb_ep->num_reqs 在 f_midi2_init_ep（） 期间设置正确，如果端点从未初始化，则保持为 0，从而安全地避免循环。为保持一致性，请对 f_midi2_alloc_ep_reqs（） 应用相同的更改。错误：一般保护错误，可能针对非规范地址 0xdffffc00000000ee：0000 [#1] SMP KASAN NOPTI KASAN：
    范围内的 null-ptr-deref [0x0000000000000770-0x0000000000000777] ... RIP：0010：f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c：1166 [内联] RIP：0010：f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c：1246 ... 调用跟踪： <TASK> f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c：1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c：1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c：1877 （CVE-2026-90024）

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

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

  - 恶意构造的邮件标头可导致将多个字段解析为一个字段，或可能违反内存安全。已在 Thunderbird 156、Thunderbird 140.16和 Thunderbird 153.3中修复此漏洞。（CVE-2026-92238）

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

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

  - media：cec： extron-da-hd-4k-plus：添加健全性检查，添加检查以防止溢出 msg.msg[]，以防传入数据畸形。（CVE-2026-89898）

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

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

  - usb：gadget：f_midi：初始化 f_midi_alloc（） 中的工作f_midi_alloc将 free_ref 初始化为 1，并且仅当通过 f_midi_register_card（） 注册声卡时才能增加。仅在实际执行INIT_WORK的 f_midi_bind（） 中调用 f_midi_register_card（）。如果从未运行 f_midi_bind（），则工作不会初始化，且 f_midi_free 中的 if 条件变为真，这会导致稍后在
    __flush_work为 work->func = 0。通过将 INIT_WORK 从 f_midi_bind（） 移至 f_midi_alloc（） 来修复此问题。
    (CVE-2026-90021)

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

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

  - ALSA：pcm：修复非原子操作和触发启动之间的争用 我们保护原子 PCM 操作之间并发状态转换的争用，但非原子操作（hw_params、hw_free 和准备）与原子操作之间的检查并不完美;在 hw_params &; co 开始时会检查冲突的 PCM 状态，但在非原子 PCM 操作期间仍可发出原子 PCM 操作。此类场景的一个示例是，线程 A 为已准备好的流重新发布 PREPARE 或 HW_PARAMS，而另一个线程 B 在准备操作的中间触发 PCM 启动。虽然这通常不会导致很严重的问题，但如 syzkaller 所报告，它可能会造成一些不一致（例如 ODEBUG 警告）。有各种原子 PCM 操作，基本上唯一的问题是 PCM 启动，因为它从 PREPARED 状态运行。其他触发命令（停止等）用于运行或其他特殊状态，因此它们被过滤为先决条件。此修补程序用于防止非原子操作期间的 PCM 触发启动，从而解决上述问题。幸运的是，hw_params、hw_free和准备操作调用 snd_pcm_buffer_access_lock（），这可用于检查 PCM 触发器的并发操作 -- 它将运行时>buffer_accessing设置为负数（如果可能），因此 PCM 触发器只需要检查运行时>buffer_accessing值;如果为负数，则表示并发的非原子型 PCM 操作正在运行。（CVE-2026-89979）

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

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

  - mm/page_alloc：不在 UP 修补程序系列的 NMI 中spin_trylock（） mm/page_alloc：修复 RT/UP 上的 free_pages_nolock（）。Sashiko 在查看其他系列时发现的预先存在的缺陷：
    https://lore.kernel.org/all/20260703-alloc-trylock-v5-0-c87b714e19d3@google.com/ 我没有重现这些错误，我怀疑没有现实世界的用户受到它们的影响。此修补程序（共 2 个）：如 can_spin_trylock（） 中所述，在此环境中使用此修补程序不安全。提交 620b46ed6ae17 （mm/page_alloc：
    从 UP 的 NMI 中的 alloc_frozen_pages_nolock（） 提早返回 NULL）在 alloc 端修复了此问题，但错过了空闲端。影响：如果非 SMP 版本上存在使用 NMI 中的这些功能（可能为跟踪）的 BPF 程序，这可能造成内核崩溃，并且本地攻击者可能利用此漏洞来升级权限。（CVE-2026-90046）

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

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

  - media：rtl2832_sdr：start_streaming（） 失败时释放 URB 和流缓冲区 rtl2832_sdr_start_streaming（） 依次调用 rtl2832_sdr_alloc_stream_bufs（）、rtl2832_sdr_alloc_urbs（） 和 rtl2832_sdr_submit_urbs（），共享一个仅解锁互斥体并返回的 err： 标签。当 alloc_urbs（） 成功但 submit_urbs（） 失败时，或者当 alloc_stream_bufs（） 成功后 alloc_urbs（） 自行返回 -ENOMEM，则 URB 和/或一致的 DMA 流缓冲区保持分配状态，同时流向 vb2 报告失败。下一个VIDIOC_STREAMON上有两个潜在缺陷：
    1） rtl2832_sdr_alloc_stream_bufs（） 无条件将 dev->buf_num 重置为 0 并覆盖 dev->buf_list[]/dev->dma_addr[]，从而永久泄漏由上一个尝试分配的一致的 DMA 内存。 2） rtl2832_sdr_alloc_urbs（） 始终不会重置 dev->urbs_initialized，而只会递增它。第二次成功传递后，urbs_initialized可超过 MAX_BULK_BUFS，因此后续的 rtl2832_sdr_free_urbs（） 会从 urbs_initialized - 1 向下移动到 0，并读取 dev->urb_list[] 末尾，将垃圾指针传递给 usb_free_urb（）。镜像 stop_streaming（） 已执行的拆卸：在错误路径上，在解锁前调用 rtl2832_sdr_free_urbs（） 和 rtl2832_sdr_free_stream_bufs（）。这两个帮助程序都是幂等的（free_urbs kill 和 zero urbs_initialized;free_stream_bufs在 URB_BUF 上进行门控并清除buf_num计数器），因此部分失败路径和无分配路径保持安全。通过自动检查 INV-003 系列发现的问题，网址为 https://sashiko.dev/(CVE-2026-89880）

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

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

  - media：cx231xx：拒绝 VBI 队列繁忙时的几何变更 vidioc_s_fmt_vid_cap（） 和 vidioc_s_std（） 变更设备范围的 dev->width / dev->norm，但只在 *video* 队列 （dev->vidq） 繁忙时拒绝变更。VBI 队列 （dev->vbiq） 共享相同的几何：cx231xx_init_vbi_isoc（） 从 dev->norm 锁存 dma_q->lines_per_field，VBI videobuf2 平面的大小从 vbi_queue_setup（） 和 vbi_buf_prepare（） 中的 dev->width / dev->norm 调整大小，然后 cx231xx_do_vbi_copy（） 在每次 URB 完成时重新计算 *live* dev->width 的目标偏移和锁存lines_per_field：
    偏移 = lines_completed * （dev->width << 1） + ...;if （dma_q->current_field == 2） 偏移 += dev->width * 2 * dma_q->lines_per_field;memcpy（plane + offset， p_buffer， lencopy）;由于 VBI 节点与视频节点共享video_ioctl_ops，因此应用程序可以调整小型 VBI 平面（具有小宽度的 REQBUFS/QBUF 或符合 NTSC 标准）的大小，然后在 VBI 流运行时通过视频节点扩大 dev->width（或将 dev->norm 切换为 PAL）——允许进行更改，因为仅检查 dev->vidq），并让设备提供字段 2 VBI 负载。cx231xx_do_vbi_copy（） 现在计算较大几何和 memcpy（） 超出已分配的较小平面的末端的偏移，即堆越界写入，其偏移由攻击者选择，其内容来自设备。cx231xx_copy_vbi_line（） 中的 per-field guard 无济于事：它会根据锁存的 lines_per_field（而不是平面的实际容量）限制副本，并且 vb2 不会对已准备的缓冲区重新运行 buf_prepare（）。当 VBI 队列繁忙时，拒绝格式/标准更改，这样不能在分配的 VBI 缓冲区下更改几何图形。（CVE-2026-89894）

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

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

  - iio：pressure：dps310：修复 ACPI 探测时的空指针取消引用 通过其 ACPI HID （IFX3100） 枚举设备时，i2c_client_get_device_id（） 返回 NULL：ACPI 派生的客户端名称不匹配驱动程序的 i2c_device_id 表。 然后，dps310_probe（） 会在探测期间取消引用 iio->name = id->name 中的空指针，并造成内核崩溃。IIO 设备名称始终为 dps310，因此请直接进行设置并丢弃现在未使用的设备 id 查找。（CVE-2026-89933）

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

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

  - usb：gadget：修复 usb_put_function_instance（） 中的空指针取消引用 usb_put_function_instance（） 尝试在 fi struct 中取消引用 fd 从而在 uvc_alloc_inst（） 错误路径中获取 mod。但是，在 uvc_alloc_inst（） 中分配 fi 后，直到 try_get_usb_function_instance（） 中稍后才会分配 fd，从而保证在错误路径中为空。通过为 fi->fd 添加用于返回 fd 是否为空的空值检查来修复此问题。
    (CVE-2026-90019)

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

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

  - samples/damon/mtier：处理 damon_stop（） 失败 damon_sample_mtier_stop（） 假设其 damon_stop（） 调用始终成功停止两个 DAMON 上下文。因此，它在 damon_stop（） 调用后释放两个 DAMON 上下文。但是，如果给定上下文已停止，damon_stop（） 会失败并返回错误，同时让尚未停止的 DAMON 上下文继续运行。由于 kdamond_fn（） 中的内存分配失败，可能会发生这种非预期的早期 DAMON 上下文停止。由于 damon_sample_mtier_stop（） 只是释放所有具有链接至上下文的 damon_target 和 damon_region 对象的所有 DAMON 上下文，因此未停止的 DAMON 上下文 （kdamond） 的执行最终会使用已释放的内存（释放后使用）。通过根据每个上下文分隔要调用的 damon_stop（） 修复此问题。请注意，DAMON_SYSFS 还允许多种 DAMON 上下文执行。但是，它会逐一调用每个上下文的 damon_stop（）。因此，此问题仅存在于 mtier 中。从长远来看，最好重构 damon_stop（） 以始终确保停止所有上下文，而不管中间是否失败。
    不过，请使用当前方式进行此修复，以保持简单且易于向后移植。我稍后会进行重构。此问题由 Sashiko 发现 [1]。（CVE-2026-90006）

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

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

  - KVM：arm64：正确地将 TLBI 范围上限设为存档限制 TLB 按范围无效化有一个相当强大的方法，可以用少量位对相当大的范围进行编码。此范围可以基于任意 VA，这意味着如果管理程序足够天真，将范围添加到基础中，客户机很容易生成溢出... 确保将范围限制为由确定 VA 范围的地址位指定的限制。对于 IPA 无效，此问题会进一步修正，以忽略上限范围。（CVE-2026-89911）

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

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

  - scsi：qla2xxx：在重置处理程序中序列化闪存版本读取 未重置 sysfs 重置操作 （0x20261） 的更新缓存版本会调用 get_flash_version（），其可在不保留 ha->optrom_mutex 的情况下读取硬件闪存寄存器。VPD 更新路径在 optrom_mutex 下序列化同一个调用，因此该重置路径可将其闪存寄存器访问与并行 VPD 或 optrom 闪存操作交错，并破坏读取。在 get_flash_version（） 调用中保持 ha->optrom_mutex 以匹配 VPD 更新路径。
    (CVE-2026-89855)

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

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

  - drm/amdgpu：重置时强制完成 KIQ 环隔离 与 MES 计划程序环一样，KIQ 环设置为 no_scheduler = true 并使用轮询隔离，因此 amdgpu_device_pre_asic_reset（） 中的强制完成循环会跳过它。其 hw 隔离值存在于 wb （GTT） 内存中，在 MODE1 重置后仍留存，而 fence_drv.sync_seq 会继续前进，因此在重置之后，第一个 KIQ 提交可对从不回写的 seq 进行永久轮询。强制完成 KIQ 环围栏，使其 hw 围栏重新对齐为sync_seq。（CVE-2026-89813）

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

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

  - scsi：qla2xxx：保持 qla24xx_report_id_acquisition（） 中的 vport 引用 在格式 1 路径中，当保持 vport_slock 时虚拟端口位于 ha->vp_list，但在使用 vp 之前终止锁定：
    调用 qla_update_host_map（） 并在 vp 上设置 VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED。该窗口未进行任何引用，因此并发 qla24xx_deallocate_vp_id（） 可终止和释放 vport，从而导致释放后使用。找到匹配的 vp 时，在 vport_slock 下获取 vport 引用 （vref_count），并在最后一次使用 vp 后将其丢弃。qla24xx_deallocate_vp_id（） 会等待 vref_count 达到零，然后断开并释放 vport，因此指针会保持有效。这与其他 ha->vp_list 遍历已使用的参考习语相匹配。（CVE-2026-89861）

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

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

  - NFSD：防止客户端在close_lru期间发生释放后使用 最终 CLOSE 之后留在 nn->close_lru 上的nfs4_openowner将上一个关闭的 stateid 保持在oo_last_closed_stid中，仅保留指向其nfs4_client的原始指针。自助洗衣店收获超时条目、终止 nn->client_lock，并调用 nfs4_put_stid（），后者通过 cl_lock 取消引用客户端。没有任何内容将客户端固定到该窗口之间，因此并发 force_expire_client（） 可以释放客户端，而 nfs4_put_stid（） 读取已释放的内存。__destroy_client（） 进入相同的争用，在没有cl_lock的情况下走 clp->cl_openowners。在丢弃客户端client_lock之前用 cl_rpc_users 固定客户端，并跳过已到期的客户端。然后，__destroy_client（） 通过 release_last_closed_stateid（） 清理其自己的close_lru条目，因此 teardown 不再与 laundromat 争用。
    (CVE-2026-90037)

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

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

  - fs/ntfs3：修复 ni_create_attr_list（） 中的 slab-of-bound 写入 ni_create_attr_list（） 分配一个固定的 al_aligned（record_size） （== record_size） 字节的缓冲区，然后遍历主 MFT 记录的每个属性，对每个属性写入一个ATTR_LIST_ENTRY，然后通过 le_size（name_len） 前进光标，而不检查缓冲区的末尾;总大小仅在循环后计算。最小大小的驻留属性在磁盘上占用 SIZEOF_RESIDENT （0x18 = 24） 字节，但未命名的属性会在列表中扩展到 le_size（0） （0x20 = 32） 字节。由于记录中的属性数量不限制（mi_enum_attr（） 接受任意多个相同类型、无名称的最小大小属性），因此打包此类属性的构建记录会生成大于 record_size 的列表并溢出堆缓冲区。可从构建的、循环挂载的 NTFS 图像实现此目的：打开文件并添加属性（例如通过 setxattr）可驱动 ntfs_set_ea（） -> ni_insert_resident（） -> ni_insert_attr（） -> ni_ins_attr_ext（） -> ni_create_attr_list（）。缺陷：KASAN：任务 setfattr/345 在地址 ffff000008984c00 处的大小为 4 的写入 ni_create_attr_list+0xc48/0x1058 中的 slab-out-bound ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0
    __arm64_sys_setxattr+0xa4/0x124 按任务 345 分配：ni_create_attr_list+0x188/0x1058 有缺陷的地址属于大小为 1024 的缓存 kmalloc-1k（写入地点为 object+1024）。根据实际属性调整缓冲区的大小，而非假设单一record_size总是足够的。（CVE-2026-90048）

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

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

  - s390/vfio-ap：修复取消引用 matrix_mdev->kvm 而不检查 NULL ap_driver结构有两个字段，分别是指向回调的函数指针：* .on_config_changed：在 AP 总线扫描函数开头调用，以通知设备驱动主机 AP 配置已变更，且关联的 AP 设备将相应添加或删除。这使实现者有机会在添加或删除相关设备之前评估配置更改并对其做出响应。* .on_scan_complete：在 AP 总线扫描功能结束时调用，通知设备驱动程序主机 AP 配置已更改，AP 设备已相应添加或删除。这使实现者有机会在添加或删除相关设备后响应更改。
    这两个回调分别通过 vfio_ap_on_cfg_changed 和 vfio_ap_on_scan_complete 函数在 vfio_ap 设备驱动程序中实现。在这两个回调函数的调用堆栈中，采用 matrix_mdev->kvm->lock 互斥体时未检查 matrix_mdev->kvm 是否为空。如果从未设置过 matrix_mdev->kvm，则尝试获取锁定将触发空指针取消引用。此修补程序在采用 matrix_mdev->kvm->lock 互斥体之前添加了对 matrix_mdev->kvm == NULL 的检查。请注意，在 vfio_ap_mdev_hot_plug_config 函数中取得的 matrix_mdev->kvm->lock 互斥体会连同访问matrix_mdev字段所需的 matrix_dev->mdevs_lock 一起移动到调用函数。在采用 kvm->lock 互斥体之前更改对此处的 matrix_mdev->kvm 检查没什么意义，因此此修补程序中已经完成了该操作。请务必注意以下几点：1. matrix_dev->guests_lock在两个回调函数的开头获取。这可确保matrix_mdev不会通过 vfio_ap_mdev_remove 函数删除，因为在删除对象之前也需要matrix_dev_guests_lock;因此，matrix_mdev将在回调函数的持续时间内可用。2. 必须采用matrix_dev>mdevs_lock互斥体才能访问matrix_mdev结构 3 中的字段。必须在 matrix_dev->mdevs_lock 之前采用 matrix_mdev->kvm->lock 互斥体，以防止 lockdep 崩溃。4：通过 vfio_ap_mdev_update_guest_apcb 函数将客户机的 AP 配置插入其 SIE 状态描述时，必须保持 kvm->lock。
    5.vfio_ap_mdev_update_guest_apcb在对客户机的AP配置进行热插拔之前，会检查matrix_mdev->kvm，验证其为非空。（CVE-2026-89958）

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

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

  - s390/vfio-ap：修复访问 ap_matrix_mdev 对象列表所需的缺少锁定 为了遍历或添加/删除 matrix_dev >mdev_list中的 ap_matrix_mdev 对象，必须保留 matrix_dev >guests_lock 互斥体。有两个函数可以在不保留互斥体的情况下访问列表： vfio_ap_mdev_probe 函数~~~~~~~~~~~~~~~~~~~~~~~~~~~ vfio_ap_mdev_probe 函数使用matrix_dev>mdevs_lock互斥体来保护向matrix_dev>mdev_list添加新创建的 ap_matrix_mdev 对象。此互斥体不保护列表访问;其目的是防止对 ap_matrix_mdev 对象中包含的字段进行并发访问。如果同时创建或删除另一个 mdev，则此漏洞可导致内核内存损坏或释放后使用。向 matrix_dev->mdev_list 添加 ap_matrix_mdev 对象现在由 matrix_dev->guests_lock 保护，这是防止并发 mdev_list访问的正确方法。还删除了以下两行代码，因为matrix_mdev是通过使用 kzalloc 的宏vfio_alloc_device分配，所以在调用 vfio_register_emulated_iommu_dev 之前分配 struct 时，req_trigger和 cfg_chg_trigger 已初始化为零。此时段将不会在设备暴露给用户空间后，这些触发器被设置为 NULL。matrix_mdev->req_trigger = NULL;
    matrix_mdev->cfg_chg_trigger = NULL;vfio_ap_mdev_for_queue 函数~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 支持显示 /sys/bus/ap/devices 中设备状态属性的 status_show 函数调用 vfio_ap_mdev_for_queue 函数，该函数迭代 matrix_dev->mdev_list 以查找表示要显示状态的队列设备的对象。为了遍历此列表，必须保留matrix_dev>guests_lock互斥体。为了解决这个问题，在status_show函数中采用matrix_dev>mdevs_lock互斥体之前，先获取guests_lock互斥体。它被带到那里而不是 vfio_ap_mdev_for_queue 函数 - 在需要它的地方 - 因为它必须在mdevs_lock互斥体之前取，以便遵守正确的锁定顺序并防止 lockdep splat;还因为需要mdevs_lock来访问该函数中matrix_mdev对象内的字段。请参阅 Linux 内核树中的 vfio-ap-locking.rst。（CVE-2026-89956）

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

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

  - bpf：在 bpf_get_stackid 中禁用优先权 get_perf_callchain 调用需要禁用优先权，并且只要访问其返回的跟踪条目缓冲区，我们就需要将其禁用。请注意，已在禁用优先权的情况下执行 bpf_get_stackid_pe 函数。（CVE-2026-89799）

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

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

  - KVM：arm64：vgic-v3：在 vgic_v3_save_pending_tables vgic_v3_save_pending_tables（） 中使用 xa_for_each（） 迭代 dist->lpi_xa 中获取 LPI 引用，并在循环正文中取消引用返回的 struct vgic_irq，而不保留 LPI 上的引用。xarray 迭代器在查找当前条目时仅提供临时 RCU 覆盖。这对于此循环正文来说是不够的，因为它会在迭代完成之前读取结构vgic_irq中的字段并执行客户机内存访问。并发路径可触发此争用：irqfd 缓存注入路径 （vgic_its_inject_cached_translation） 通过 vgic_its_check_cache（） 获取暂时性 LPI 引用，而不保留 kvm->lock、vcpu->mutex、config_lock 或 its_lock。如果访客 ITS DISCARD 随后将缓存和 ITE 引用放置在its_lock下，则暂时性注入引用可能会成为最后一个引用。当 vgic_put_irq（） 将其删除时，LPI 将从lpi_xa中删除并通过 kfree_rcu（） 释放。同时，vgic_v3_save_pending_tables（） 可能仍保留着从 xarray 迭代器获取的过时指针，并在 RCU 宽限期结束后对其取消引用。通过采用稳定引用的 vgic_get_irq（） 重新提取每个迭代的 LPI，然后在所有路径中使用 vgic_put_irq（） 将其丢弃，从而修复此问题。这与 vgic ITS 代码中其他 lpi_xa 迭代器已经使用的模式相匹配。
    (CVE-2026-89913)

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

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

  - drm/amdgpu：钳制分区外环的隔离索引 adev->isolation[] 每个分区都有一个插槽，但未分配给环的环保持AMDGPU_XCP_NO_PARTITION，即 ~0，因此无法用该环编制数组索引。SDMA 提交在隔离强制和 VM 刷新路径上都遇到此问题，并且跳闸 UBSAN。以更干净的着色器路径的方式回退到第一个插槽，并在环类型检查使其相关之前停止获取地址。（CVE-2026-89814）

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

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

  - 遇到引用 14 个或更多 SVCB/HTTPS ServiceMode 记录的 SVCB/HTTPS AliasMode 记录的 BIND 解析器可能无法正确解除内部资源分配。如果这种情况反复发生，资源耗尽最终将阻止解析器执行新的递归查找。此问题影响 BIND 9 版本9.18.09.18.50到 、 到 9.20.09.20.27、 9.21.09.21.25到 9.18.11-S1 到 9.18.50-S1，以及 9.20.9-S1 到 9.20.27-S1。（CVE-2026-81563）

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

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

  - drm/nouveau/dmem：修复大型作品集的 DMA 取消映射大小不匹配的问题 设备私有 THP 迁移使用 page_size（） 映射迁移缓冲区，并以 dma_info-> 大小记录该长度。对于复合对开本page_size（） 顺序PAGE_SIZE <<，但两个拆卸站点仍将文字PAGE_SIZE传递给 dma_unmap_page（）：- 成功路径上的 nouveau_dmem_migrate_to_ram（），以及复制错误路径上的 - nouveau_dmem_migrate_copy_one（）。对于订单> 0 个作品集，此取消映射的次数少于映射的次数，从而泄漏 IOMMU/IOVA 映射的其余部分。nouveau_dmem_migrate_chunk（） 和 nouveau_dmem_evict_chunk（） 中的其他取消映射站点已使用保存的大小;也在这里使用它。
    (CVE-2026-89804)

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

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

  - drm/panel-edp：修复探查失败时的 i2c 适配器泄漏 确保在探测失败（如探测延迟）和驱动程序取消绑定时，以及如果设备树冗余地使用“ddc-i2c-bus”属性指向 aux ddc 总线，则丢弃 i2c 适配器引用。CVE-2026-89824

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

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

  - spi：修复部分映射失败时的 DMA 映射所有权 如果 TX 映射成功后 RX 映射失败，
    __spi_map_msg（） 取消映射 TX，但保留tx_sg_mapped设置。如果 TX 映射在后续传输中失败，则为较早传输创建的映射将保持活动状态。在两种情况下，cur_{tx，rx}_dma_dev都尚未更新，因为它们仅在映射了每个传输之后才会被分配。因此，后续 spi_unmap_msg（） 可能再次取消 TX 映射映射或使用空或过时设备释放较早的映射。使用空设备可触发 oops。空 SG 表不会防止空取消引用，因为 dma_unmap_sg_attrs（） 会在检查条目计数之前访问设备。在映射开始之前发布两个映射设备，并通过 __spi_unmap_msg（） 展开所有故障。这会清除映射标记，并通过创建映射的设备释放每个映射一次。当传输不需要映射时，在循环之前发布设备也会刷新它们。此情况下未设置映射标记，因此当前用户不会将指针用作映射所有者。（CVE-2026-90012）

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

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

  - accel/ethosu：修复作业完成围栏清理 ethosu_ioctl_submit_job（） 在验证缓冲区句柄之前分配done_fence。分配后发生错误，调用 ethosu_job_err_cleanup（） 释放作业但泄漏未初始化的隔离。计划程序依赖关系错误也会让 ethosu_job_run（） 先于 dma_fence_init（） 返回。然后正常清除会将已归零的 refcount 传递至 dma_fence_put（）。释放通用清理路径中的done_fence并使用 dma_fence_was_initialized（） 将初始化的隔离与原始分配区分开来。[robh：还修复了 goto]（CVE-2026-89976）

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

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

  - nvme-fc：修复 nvme_add_ctrl（） 失败时结构选项的双重释放 nvmf_create_ctrl（） 拥有结构选项并在 ->create_ctrl（） 返回错误时释放这些选项，因此传输不得在其自己的错误路径中释放这些选项。nvme-fc 通过测试 nvme_fc_ctrl_free（） 中的 ctrl->ctrl.opts 来跟踪此漏洞，其要求 nvme_fc_init_ctrl（） 在每次错误退出时清除该指针。此耦合是隐式的，并且提交 1a9e218195a5（nvme：从初始化拆分设备添加）通过添加第二个错误退出而使其中断。当 nvme_add_ctrl（） 失败时，nvme_fc_init_ctrl（） 跳转到 out_put_ctrl：，经过仅位于 fail_ctrl： 路径上的 ctrl->ctrl.opts = NULL，因此 nvme_fc_ctrl_free（） 释放选项，然后 nvmf_create_ctrl（） 再次释放它们： 缺陷：KASAN：nvmf_free_options+0x30/0x190 nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c：1284 中的释放后使用：nvmf_create_ctrl drivers/nvme/host/fabrics.c：1374 中的释放后使用：[内联] 按任务释放5534：nvme_fc_ctrl_free drivers/nvme/host/fc.c：2374 [内联] nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c：3605 nvme_add_ctrl（） 在 dev_set_name（） 无法分配时失败，因此这在内存压力或错误注入下可以达到。如果没有 KASAN，则会释放两次选项。与其同时清除第二个退出中的指针，不如像 nvme-tcp、nvme-rdma 和 nvme-loop 一样从列表成员身份中派生所有权：除非控制器进入传输列表，否则其free_ctrl不会保留选项。列表不能简单地填充在成功路径上，因为它就在那里。nvme-fc 通过 flush_delayed_work（） 同步运行初始连接，并且整个主机必须可在 rport->ctrl_list 上访问控制器：
    nvme_fc_unregister_remoteport（） 需要找到它来发出连接丢失信号，nvme_fc_match_disconn_ls（） 将传入的断开连接关联 LS 与仅在该窗口内分配的 ctrl->association_id 匹配，nvme_fc_resume_controller（） 需要在远程端口重新注册时需要它，而 nvme_fc_existing_controller（） 用它来拒绝与正在传输的连接争用的重复连接。将插入保留在原处，并为其之后运行的错误路径添加 fail_unlist： 标签，该标签属于 fail_ctrl： 。较早的错误路径永远不会到达插入并继续直接使用 fail_ctrl：，因此只会在控制器实际所在的位置接触列表。nvme_fc_ctrl_free（） 不能使用其他传输所free_ctrl的普通 goto，因为它仍然必须 put_device（），释放 rport 引用，并为插入之前占用的资源释放 ida 条目。对 rport->lock 下的 list_empty（） 进行采样。ctrl->ctrl.opts 现在对整个拆卸仍然有效。这并不是要修复的缺陷，但它消除了围绕旧惯用语的一些脆弱性：nvme_free_ctrl（） 在调用 ->free_ctrl（） 之前调用 nvme_auth_free（），而 ctrl_max_dhchaps（） 在设置 ctrl->>dhchap_ctxs 时不进行空检查而取消引用 ctrl-opts，而 nvme-fc 允许这样做，因为 NVMF_ALLOWED_OPTS 允许 dhchap 选项。取消引用 ctrl->opts 的 nvme sysfs 属性（如 hostnqn 和地址）会在 device_add（） 时间评估其 is_visible（） 测试一次，并在 cdev_device_del（） 之前保持可读状态。（CVE-2026-89974）

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

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

  - zram：修复 64 位大端上的插槽锁定位位置 插槽锁定是针对整个__lock字的位操作，将别名标记为两个 u32，并ac_time别名。在小端上，锁定位落在ZRAM_ENTRY_LOCK标记中保留的位置，因此混叠有效。在 64 位 big-endian 上，它会改为以 ac_time：启用 ZRAM_TRACK_ENTRY_ACTIME 时，存储来自 mark_slot_accessed（） 或 slot_free（） 的访问时间会擦除保持的锁定位，让另一个 CPU 采用相同的插槽锁定;设置了该位的访问时间值使插槽看起来永远锁定。在 big-endian 64 位上将锁定位移到单词的标志半边。（CVE-2026-90043）

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

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

  - media：cobalt：避免两次释放 ALSA 隐私数据 snd_cobalt_card_create（） 将 cobsc 存储在 sc->private_data 中并将 snd_cobalt_card_private_free（） 作为 sc->private_free安装。从该时起，snd_card_free（sc） 通过 ALSA 卡清除路径释放 cobsc。如果 cobalt_alsa_init（） 在 snd_cobalt_card_create（） 之后失败，err_exit_free 路径将先调用 snd_card_free（sc），然后先调用 kfree（cobsc）。第二次释放会再次释放相同的对象。删除明确的 kfree（cobsc） 并将所有权保留给 ALSA 卡。此问题由静态分析检查程序发现，并经手动源审查确认。
    (CVE-2026-89895)

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

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

  - drm/amd/display：避免 __is_lut_linear（） 中的除以零 __is_lut_linear（） 计算每个条目的预期值，预期值为 = i * MAX_DRM_LUT_VALUE / （大小 - 1）;如果使用单条目 LUT 调用它，则大小 - 1 为零，内核将出现除法错误 （#DE）。具有少于两个条目的 LUT 无法描述线性映射，因此请尽早返回 false，而不是除以零。（CVE-2026-89821）

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

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

  - drm/ttm：在成功还原后终止 tt->restore ttm_pool_restore_and_alloc（） 可通过 ttm_pool_restore_commit（） 成功完成还原过程，但之后不会终止 tt->restore。因此，后续的备份/还原流会观察看似已完成的还原，而实际上 shmem 句柄仍然安装在 tt->pages 中，从而导致下面的堆栈跟踪。成功完成还原后，通过释放和终止 ttm_pool_restore_and_alloc（） 中的 tt->restore 来修复此问题。20545 [309.784531] RIP： 0010：sg_alloc_append_table_from_pages+0x38c/0x490 20547 [ 309.809570] RSP：
    0018：ffffc9000623b838 EFLAGS： 00010206 20548 [ 309.814827] RAX： 0000000000001000 RBX： ffff88816e42a160 RCX： 00000000000000000 20549 [ 309.821986] RDX： 0000000000002000 RSI： 0000000000000003 RDI：
    0000000000001000 20550 [ 309.829147] RBP： ffff88816e42a168 R08： 0000000000000002 R09： 0000000007ffff000 20551 [ 309.836310] R10： ffffc9000623b928 R11： 000000000000000 R12： 000000007ffff000 20552 [ 309.843471] R13： ffff88815ba5a100 R14： 000000000000000 R15： 0000000000000001 20553 [ 309.850634] FS：
    00007f9ff305e700（0000） GS：ffff888276c94000（0000） knlGS：00000000000000000 20554 [ 309.858749] CS：0010 DS：
    0000 ES： 0000 CR0： 0000000080050033 20555 [ 309.864519] CR2： 00007f9fca701000 CR3： 00000001565e2005 CR4：
    0000000008f70ef0 20556 [ 309.871678] PKRU： 55555558 20557 [ 309.874403] 调用跟踪：20558 [ 309.876866] <TASK> 20559 [ 309.878988] sg_alloc_table_from_pages_segment+0x60/0x100 20560 [ 309.884415] ？ ttm_resource_manager_usage+0x36/0x60 [ttm] 20561 [ 309.889845] ？ xe_tt_map_sg+0x7d// 0xd0 [xe] 20562 [309.894045] xe_tt_map_sg+0x7d/0xd0 [xe] 20563 [ 309.898037] xe_bo_move+0x927/0xaa0 [xe] 20564 [309.902029] ttm_bo_handle_move_mem+0xba/0x170 [ttm] 20565 [ 309.907022] ttm_bo_validate+0xbe/0x190 [ttm] 20566 [ 309.911405] xe_bo_validate+0x9a/0x120 [xe] 20567 [ 309.915663] xe_gpuvm_validate+0xd9/0x140 [xe] 20568 [ 309.920206] drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm] 20569 [ 309.925459] ？ drm_exec_lock_obj+0x63/0x210 [drm_exec] 20570 [ 309.930627] xe_vm_validate_rebind+0x46 0xb0/ [xe] 20571 [309.935428] xe_exec_fn+0x20/0x40 [xe] 20572 [ 309.939249] drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm] 20573 [ 309.944410] xe_validation_exec_lock+0x5a/0xa0 [xe] 20574 [ 309.949385] xe_exec_ioctl+0x806/0xc30 [xe] 20575 [ 309.953639] ?ttwu_queue_wakelist+0xd9/0xf0 20576 [ 309.957935] ？ __pfx_xe_exec_fn+0x10/0x10 [xe] 20577 [ 309.962449] ？ __wake_up_common+0x73/0xa0 20578 [ 309.966482] ？ __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20579 [ 309.971263] drm_ioctl_kernel+0xa3/0x100 20580 [ 309.975209] drm_ioctl+0x213/0x440 20581 [309.978637] ？ __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20582 [ 309.983415] xe_drm_ioctl+0x67/0xd0 [xe] 20583 [309.987408] __x64_sys_ioctl+0x7f/0xd0 （CVE-2026-89815）

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

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

  - 在查询响应中，攻击者可发送本应仅存在一次的记录（例如 SOA 记录）的“named”多种副本。如果所有副本上的 RDATA 相同，记录将附加到内存中的 RDATA 集，这可导致增加负缓存的内存使用，并可能导致其他内存攻击载体。此问题影响 BIND 9 9.11.0 版本 9.18.50到 、 到 9.20.09.20.27、 9.21.09.21.25到 9.11.3-S1 到 9.18.50-S1，以及 9.20.9-S1 到 9.20.27-S1。（CVE-2026-75029）

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

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

  - usb：storage：realtek_cr：在包含定时器的芯片释放之前，修复断开连接 realtek_cr_destructor（） 调用 timer_delete（） 时的释放后使用。计时器回调可能仍在运行，并可自行重新武装，从而导致释放后使用。使用 timer_shutdown_sync（） 以等待回调并阻止进一步重新武装。请无条件执行此操作，因为ss_en可在计时器布防后进行更改。将 timer_setup（） 移至 init_realtek_cr（），以便在任何失败路径调用析构函数之前初始化计时器。通过静态分析发现。（CVE-2026-90029）

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

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

  - xhci：修复跨多个环段的 TD 上丢失的反弹缓冲区 当 TD 到达包含未与端点的 wMaxPacketSize 对齐的数据的链路 TRB 时，xhci_align_td（） 会通过保留该链路 TRB 的环段的反弹缓冲区暂不可对齐的末尾。xhci_unmap_td_bounce_buffer（） 稍后会将其取消映射，并且对于 IN 传输，将数据复制回 URB 的缓冲区。排队路径记录在 td->bounce_seg 中反弹的段，前提是 TD 从不跨越两个环段。该假设不成立：一个足够大、可以跨越三个或更多段的 TD 穿过多个链路 TRB，并且可以在每个链路 TRB 处反弹。td->bounce_seg 中只有最后一个保留，因此既不会复制回每个较早的退回缓冲区，也不会对 DMA 进行取消映射。URB 仍以等于请求长度的actual_length完成且没有错误，因此传输看起来很成功，而目标缓冲区中的 wMaxPacketSize 大小漏洞静默保留其之前的内容。它还会泄漏每个丢弃的退回的 DMA 映射。任何足够大和碎片化的批量传输都可能达到此问题。已发现 xHCI 后面有一个 USB 大容量存储设备，该设备支持 dm-verity 目标，具有 512 字节哈希块，过时数据会在其中被检测到，而不是静默消耗。设备枚举为 SuperSpeed，因此 wMaxPacketSize 为 1024，而 dm-bufio 针对每个哈希块发布一个 512 字节的 bio。verity_prefetch_io（） 使区块层将数百个 scatterlist 条目合并为一个请求，该请求最多包含 512 个 scatterlist 条目，每个条目 512 字节。每个环段有 256 个 TRB，这样的 TD 跨越三个段，每个段边界都落在 512 的奇数倍上，即与 wMaxPacketSize 不对齐。然后，dm-bufio 会缓存一个包含过时数据的哈希区块，dm-verity 会声明该元数据区块已损坏：device-mapper： verity： 8:2：元数据区块 10850 已损坏 在 https://github.com/baloo/xhci-verity qemu 下运行此操作的复制程序可用于 反弹状态（bounce_buf、bounce_dma、bounce_len、bounce_offs）已位于环段上，因此没有任何额外的内容可跟踪。继续在 td->bounce_seg 中记录最后一个反弹的区段，并在完成后，将区段从 td->start_seg 向上遍历，取消映射仍然有待跳回的每个区段。在 td->bounce_seg 而不是 td->end_seg 处停止很重要：反弹意味着 TD 继续经过该网段的链路 TRB，因此bounce_seg始终严格在end_seg之前，而较晚的 TD 可能已经在 end_seg 中启动并在那里被反弹。走那么远会将一个外来反弹缓冲区复制到此 URB 中，然后取消映射两次。如果 TD 包绕整个环，它还会保持正确遍历，因此 end_seg == start_seg。[mn：
    添加 ring->num_segs 检查以防止不可能的无限 for 循环。]（CVE-2026-90015）

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

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

  - media：rtl2832_sdr：在删除时使用 vb2_video_unregister_device（） 修复 DMA 泄漏 rtl2832_sdr_remove（） 在 USB 断开连接时运行，并在运行任何待定的流拆卸之前将 dev->udev 清除为空。当用户空间稍后关闭其文件描述符时，vb2 会调用 rtl2832_sdr_stop_streaming（），而 （） 又会调用 rtl2832_sdr_free_stream_bufs（）。该帮助程序释放每个包含以下内容的一致缓冲区：
    usb_free_coherent（dev->udev， dev->buf_size， dev->buf_list[dev->buf_num]， dev->dma_addr[dev->buf_num]）;
    usb_free_coherent（） 的 dev 参数为 NULL 时会立即返回，因此断开连接时激活的每个 DMA 流缓冲区都会静默泄漏。出于同样的原因，在 rtl2832_sdr_alloc_urbs（） 中分配的 URB 比设备更耐用。rtl2832_sdr 驱动程序在其file_operations中使用 vb2_fop_release（），因此请将 video_unregister_device（&dev->vdev） 替换为 vb2_video_unregister_device（&dev->vdev） 并在清除 dev->udev 之前将其移动。vb2_video_unregister_device（） 释放 vb2 队列，如果流处于活动状态，则 vb2 队列同步运行 rtl2832_sdr_stop_streaming（），因此在 dev->udev 仍然有效时释放 URB 和一致的 DMA 流缓冲区。vb2_video_unregister_device（） 会在内部锁定 vdev->queue->lock （vb_queue_lock），而 stop_streaming（） 会锁定v4l2_lock，所以取消注册序列周围的先前外部 mutex_lock（&dev->vb_queue_lock） / mutex_lock（&dev->v4l2_lock） 对会自行死锁并已被删除。
    dev->udev = NULL 周围的简短v4l2_lock危急区段会保留，因此任何仍保留文件描述符的 ioctl 路径可看到一致的状态。通过自动审查 INV-003 系列发现的问题，网址 https://sashiko.dev/ 为 （CVE-2026-89881）

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

ID	名称	严重性
346681	Linux Distros 未修补的漏洞：CVE-2026-90014	high
346680	Linux Distros 未修补的漏洞：CVE-2026-89984	high
346679	Linux Distros 未修补的漏洞：CVE-2026-89873	high
346678	Linux Distros 未修补的漏洞：CVE-2026-89930	critical
346677	Linux Distros 未修补的漏洞：CVE-2026-89872	medium
346676	Linux Distros 未修补的漏洞：CVE-2026-89811	high
346675	Linux Distros 未修补的漏洞：CVE-2026-89940	high
346674	Linux Distros 未修补的漏洞：CVE-2026-89841	high
346673	Linux Distros 未修补的漏洞：CVE-2026-90028	medium
346672	Linux Distros 未修补的漏洞：CVE-2026-89800	medium
346671	Linux Distros 未修补的漏洞：CVE-2026-89893	high
346670	Linux Distros 未修补的漏洞：CVE-2026-89905	high
346669	Linux Distros 未修补的漏洞：CVE-2026-89891	high
346668	Linux Distros 未修补的漏洞：CVE-2026-89973	high
346667	Linux Distros 未修补的漏洞：CVE-2026-90024	medium
346666	Linux Distros 未修补的漏洞：CVE-2026-92238	critical
346665	Linux Distros 未修补的漏洞：CVE-2026-89898	high
346664	Linux Distros 未修补的漏洞：CVE-2026-90021	medium
346663	Linux Distros 未修补的漏洞：CVE-2026-89979	high
346662	Linux Distros 未修补的漏洞：CVE-2026-90046	high
346661	Linux Distros 未修补的漏洞：CVE-2026-89880	high
346660	Linux Distros 未修补的漏洞：CVE-2026-89894	high
346659	Linux Distros 未修补的漏洞：CVE-2026-89933	medium
346658	Linux Distros 未修补的漏洞：CVE-2026-90019	medium
346657	Linux Distros 未修补的漏洞：CVE-2026-90006	high
346656	Linux Distros 未修补的漏洞：CVE-2026-89911	high
346655	Linux Distros 未修补的漏洞：CVE-2026-89855	high
346654	Linux Distros 未修补的漏洞：CVE-2026-89813	medium
346653	Linux Distros 未修补的漏洞：CVE-2026-89861	high
346652	Linux Distros 未修补的漏洞：CVE-2026-90037	critical
346651	Linux Distros 未修补的漏洞：CVE-2026-90048	critical
346650	Linux Distros 未修补的漏洞：CVE-2026-89958	high
346649	Linux Distros 未修补的漏洞：CVE-2026-89956	high
346648	Linux Distros 未修补的漏洞：CVE-2026-89799	high
346647	Linux Distros 未修补的漏洞：CVE-2026-89913	high
346646	Linux Distros 未修补的漏洞：CVE-2026-89814	high
346645	Linux Distros 未修补的漏洞：CVE-2026-81563	high
346644	Linux Distros 未修补的漏洞：CVE-2026-89804	high
346643	Linux Distros 未修补的漏洞：CVE-2026-89824	medium
346642	Linux Distros 未修补的漏洞：CVE-2026-90012	critical
346641	Linux Distros 未修补的漏洞：CVE-2026-89976	medium
346640	Linux Distros 未修补的漏洞：CVE-2026-89974	high
346639	Linux Distros 未修补的漏洞：CVE-2026-90043	high
346638	Linux Distros 未修补的漏洞：CVE-2026-89895	medium
346637	Linux Distros 未修补的漏洞：CVE-2026-89821	medium
346636	Linux Distros 未修补的漏洞：CVE-2026-89815	high
346635	Linux Distros 未修补的漏洞：CVE-2026-75029	medium
346634	Linux Distros 未修补的漏洞：CVE-2026-90029	high
346633	Linux Distros 未修补的漏洞：CVE-2026-90015	medium
346632	Linux Distros 未修补的漏洞：CVE-2026-89881	medium

检测

Nessus 的 Misc. 系列

high

high

high

critical

medium

high

high

high

medium

medium

high

high

high

high

medium

critical

high

medium

high

high

high

high

medium

medium

high

high

high

medium

high

critical

critical

high

high

high

high

high

high

high

medium

critical

medium

high

high

medium

medium

high

medium

high

medium

medium