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

  - hwrng：core - 使用 RCU 和 work_struct 修复争用条件 当前，hwrng_fill在 hwrng_fillfn（） 线程退出之前不会清除。由于 hwrng_unregister（） 在 rng_mutex 锁定之外读取hwrng_fill，并发 hwrng_unregister（） 可针对同一任务再次调用 kthread_stop（）。此外，如果在 hwrng_register（） 之后立即调用 hwrng_unregister（），可能从未执行过停止的线程。因此，即使在 hwrng_unregister（） 返回之后，hwrng_fill 仍然是脏的。在这种情况下，对 hwrng_register（） 的后续调用将无法启动新线程，hwrng_unregister（） 将在同一个释放的任务上调用 kthread_stop（）。在两种情况下，都将发生释放后使用：refcount_t：0 上的加法;释放后使用。
    警告：...at lib/refcount.c：25 refcount_warn_saturate+0xec/0x1c0 调用跟踪：kthread_stop+0x181/0x360 hwrng_unregister+0x288/0x380 virtrng_remove+0xe3/0x200 此修补程序通过保护 rng_mutex 锁定中的全局hwrng_fill指针修复争用，因此 hwrng_fillfn（） 线程仅停止一次，并且在保留锁定的情况下序列化对 kthread_run） 和 kthread_stop（） 的调用。为了避免在保持锁定的情况下停止 hwrng_fillfn（） 时发生死锁，我们将current_rng转换为 RCU，以便 get_current_rng（） 可以在不保持锁定的情况下读取current_rng。为了从 put_rng（） 中删除锁定，我们还将实际清理延迟为work_struct。由于 get_current_rng（） 不再返回ERR_PTR值，因此已从其调用程序中删除 IS_ERR（） 检查。由于 hwrng_fill受到rng_mutex锁保护，hwrng_fillfn（） 无法再清除自身hwrng_fill。因此，如果在丢弃 current_rng 之后直接返回 hwrng_fillfn（），则稍后将在释放的task_struct上调用 kthread_stop（）。要解决此问题，hwrng_fillfn（） 现在会调用 schedule（） 以使任务保持活动直到停止。kthread_stop（） 调用也从 hwrng_unregister（） 移动到 drop_current_rng（），从而确保在 current_rng 变为 NULL 的所有可能路径上调用 kthread_stop（），这样线程就不会一直等待。（CVE-2026-45949）

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

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

  对于直到 1.2.9 版本的 FastNetMon Community Edition，其中 dynamic_binary_buffer_t 类 (src/dynamic_binary_buffer.hpp) 中存在基于堆的差一缓冲区溢出。五个方法（append_dynamic_buffer、append_data_as_pointer、append_data_as_object_ptr、memcpy_from_ptr、memcpy_from_object_ptr）使用了不正确的边界检查形式“if (offset + length > maximum_internal_storage_size + 1)”，而不是正确的“if (offset + length > maximum_internal_storage_size)”。这允许在堆分配的缓冲区末尾后恰好写入一个字节。该类广泛用于 BGP 消息编码/解码、NetFlow 模板处理和 Flow Spec NLRI 构造。攻击者如果能够向 FastNetMon 实例发送网络流量（NetFlow、sFlow、IPFIX 或 BGP），就可以触发此溢出，并通过破坏堆元数据实现任意代码执行。值得注意的是，append_byte() 方法使用了正确的边界检查，证实了这种不一致性。(CVE-2026-48689)

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

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

  - 在直到 1.2.9 版本的 FastNetMon Community Edition 中，Juniper 路由器集成插件中包含操作系统命令注入漏洞。src/juniper_plugin/fastnetmon_juniper.php（行 117-118）中的 _log() 函数通过将参数 $msg 直接串联到 exec() 调用中来构造 shell 命令：
    exec(echo `date` \- {FASTNETMON] - . $msg . \ >> . $FILE_LOG_TMP)。$msg 变量包含从命令行参数 argv[1] 到 argv[3] 派生的未审查数据，这些数据代表攻击的 IP 地址、方向和功率。虽然 FastNetMon 的 C++ 核心目前通过 inet_ntoa() 传递 IP 地址（仅产生安全的点分十进制表示法），但 PHP 脚本未执行任何输入验证或 shell 转义。如果该脚本由另一个业务流程系统直接调用，或者如果未来的代码更改传递了源自字符串的 IP，则可以注入任意命令。正确的补丁是将 exec() 替换为 file_put_contents()，或对所有参数使用 escapeshellarg()。(CVE-2026-48687)

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

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

  - ipmi：ssif：出错时清理 kthread 如果在创建 ssif kthread 之后、IPMI 主代码启动 ssif 接口之前发生错误，则不会停止 ssif kthread。因此，如果 kthread 正在运行，请确保其在错误条件下停止。（CVE-2026-46044）

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

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

  - LoongArch：为 syscall 分派表添加 spectre 边界 LoongArch syscall 编号由用户空间直接控制，但没有 array_index_nospec（） 边界来防止访问超出 syscall 函数指针表。（CVE-2026-45993）

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

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

  - ext4：修复 e4b 位图不一致报告 在混合大页面工作负载下的压力测试期间发现一个位图不一致问题。Ext4 报告了多种 e4b 位图检查失败，例如：
    ext4_mb_complex_scan_group：2508：根据组信息，组 350、8179 个释放群集。但得到了 8192 个区块 分析和实验证实，该问题是由页面迁移和位图修改之间的争用条件引起的。虽然这个计时窗口极窄，但在实践中还是被打的：
    folio_lock ext4_mb_load_buddy __migrate_folio检查引用计数folio_mc_copy __filemap_get_folio folio_try_get（folio）......mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock 此问题的根本原因是，load_buddy的快速路径只增加了作品集的引用计数，不足以防止并发作品集迁移。我们观察到作品集迁移过程会获得作品集锁定。因此，我们可以通过检查锁定状态来判断是否在load_buddy中走快速路径。如果 folio 被锁定，我们选择慢速路径（获取锁定）来关闭此并发窗口。此外，此更改还解决了以下问题：启用 DOUBLE_CHECK 宏以检查与位图相关的问题时，可能会触发以下错误：
    Group 324 中字节 784（6272） 处的损坏：f in copy ！= ff on disk/prealloc 分析显示这是误报。存在一个特定的争用窗口，位图和群组描述符会暂时变得不一致，从而导致此错误报告：ext4_mb_load_buddy ext4_mb_load_buddy
    __filemap_get_folio（create|lock） folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio（no lock） ......mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits（e4b->bd_bitmap） folio_unlock 原始逻辑假设由于从磁盘新加载位图时调用 mb_cmp_bitmaps，因此本文档锁定足以防止并发访问。但是，这会忽略一个特定的争用条件：如果另一个进程尝试加载 buddy 并发现作品集已处于最新状态，它将立即开始使用它，而不保持作品集锁定。（CVE-2026-45942）

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

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

  - tpm2-sessions：修复 tpm2_read_public（） 中缺少 tpm_buf_destroy（） 的问题 tpm2_read_public（） 调用 tpm_buf_init（） 但无法在两个退出路径上调用 tpm_buf_destroy（），从而导致页面分配泄露：1. 当 name_size（） 返回错误（无法识别的哈希算法）时，该函数会在不破坏缓冲区的情况下直接返回。2. 在成功路径上，缓冲区在返回前永远不会被破坏。函数中的所有其他错误路径在返回前会正确调用 tpm_buf_destroy（）。通过添加缺失的 tpm_buf_destroy（） 调用来修复这两个问题。（CVE-2026-46096）

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

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

  - drm/exynos：vidi：在 vidi_connection_ioctl（） 中使用 priv->vidi_dev 进行 ctx 查找 vidi_connection_ioctl（） 从 drm_dev->dev 检索driver_data以获取结构vidi_context指针。但是，drm_dev->dev 是 exynos-drm 主设备，其中包含的driver_data不是 vidi 组件设备，而是完全不同的设备。这可导致各种缺陷，从空指针取消引用和垃圾值访问，到不幸的情况下的越界错误、释放后使用错误等等。为了解决此问题，我们需要在绑定/取消绑定期间在 exynos_drm_private->vidi_dev 中存储/删除 vidi 设备指针，然后在 ioctl（） 中读取此exynos_drm_private>vidi_dev以获得正确的结构vidi_context指针。（CVE-2026-45956）

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

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

  - KVM：nSVM：避免清除 vmcb12 中的VMCB_LBR svm_copy_lbrs（） 始终在目标 VMCB 中标记为脏VMCB_LBR。不过，nested_svm_vmexit（） 用来将 LBR 复制到 vmcb12，而清除 vmcb12 中的干净位并未在架构上定义。将 vmcb_mark_dirty（） 移动到调用程序，但在 vmcb12 中将其丢弃。这也有利于不会将整个 VMCB 传递至 svm_copy_lbrs（） 的传入重构。（CVE-2026-46071）

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

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

  - netfilter：nft_set_rbtree：检查匿名集中的部分重叠 在区间相邻（其中忽略了结束元素）的情况下，用户空间提供优化的表示。因此，现有部分重叠检测逻辑会跳过对启动元素的匿名集检查。但是，可以添加与此匿名重叠的间隔，其中两个启动元素具有相同的元素，例如A-B、A-C，其中 C < B. 开始结束 A B 开始结束 A C 还原对重叠开始元素的检查以报告重叠。（CVE-2026-45873）

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

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

  - gfs2：修复gfs2_fill_super错误路径中的内存泄漏 修复将文件系统转换到读写模式失败时 gfs2_fill_super（） 错误处理路径中的两个内存泄漏。首次泄漏：kthread 对象（thread_struct、task_struct 等）当 gfs2_freeze_lock_shared（） 在 init_threads（） 成功后失败时，创建的内核线程（logd 和 quotad）永远不会销毁。发生这种情况是因为 fail_per_node 标签未调用 gfs2_destroy_threads（）。第二次泄漏：配额位图缓冲区（8192 字节） 如果 gfs2_make_fs_rw（） 在 gfs2_quota_init（） 成功后但在其他操作完成之前失败，则永远不会释放分配的配额位图。此补丁将线程清理移动到fail_per_node标签，以统一处理所有错误路径。
    gfs2_destroy_threads（） 检查空指针时，可以安全无条件地调用。在 gfs2_make_fs_rw（） 中添加了配额清理，以正确处理配额初始化成功但随后撤回文件系统的撤回情况。线程泄漏回溯（gfs2_freeze_lock_shared失败）：未引用的对象0xffff88801d7bca80（大小 4480）： copy_process+0x3a1/0x4670 kernel/fork.c：2422 kernel_clone+0xf3/0x6e0 kernel/fork.c：2779 kthread_create_on_node+0x100/0x150 kernel/kthread.c：478 init_threads+0xab/0x350 fs/gfs2/ops_fstype.c：611 gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c：1265 配额泄漏回溯（gfs2_make_fs_rw失败）： 未引用对象0xffff88812de7c000（大小 8192）：
    gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c：1409 gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c：149 gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c：1275 （CVE-2026-45961）

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

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

  - net：qrtr：ns：修复驱动程序 remove（） 中的释放后使用 在 remove 回调中，如果数据包在调用 destroy_workqueue（） 之后但在 sock_release（） 之前到达，则 qrtr_ns_data_ready（） 回调将尝试将工作排队，从而造成释放后使用问题。通过在 qrtr_ns_init（） 期间保存默认的“sk_data_ready”回调并用它来替换 remove（） 开头的 qrtr_ns_data_ready（） 回调，修复了此问题。这样可以确保即使数据包在 destroy_workqueue（） 之后到达，也不会取消引用工作结构。请注意，还需要确保在破坏工作队列之前完成 RX 线程，因为线程可能正在使用 qrtr_ns_data_ready（） 回调。
    (CVE-2026-46047)

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

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

  - thermal：core：修复热区调控器清理问题 如果将热调控器添加到正在注册的热区后 thermal_zone_device_register_with_trips（） 发生故障，则不会相应地从中删除调控器，这可能导致内存泄漏。反过来，thermal_zone_device_unregister（） 在未事先获取热区锁定的情况下调用 thermal_set_governor（），这可能与通过 sysfs 的调控器更新争用，并且在这种情况下可能导致释放后使用。通过添加两个 thermal_set_governor（） 调用来解决这些问题，一个指向 thermal_release（） 以从给定的热区删除调控器，另一个添加到热区注册错误路径，以覆盖热区设备注册之前的故障。（CVE-2026-46021）

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

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

  - media：rc：igorplugusb：注意一致性规则 在控制请求中，USB 请求结构可能受到某些 HC 上的 DMA 的约束。因此，它必须遵守 DMA 一致性规则。单独分配。
    (CVE-2026-46091)

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

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

  - net：ks8851：恢复对 IRQ 处理程序周围的 BH 的禁用 如果驱动程序执行 ks8851_irq（） 并且已发送 TX 数据包，则驱动程序通过 netif_wake_queue（） 启用 TX 队列，该可将 TX softirq 计划为该设备的数据包排队。如果设置了 CONFIG_PREEMPT_RT=y，并且 MAC 也接收到了一个数据包，则 ks8851_rx_pkts（） 会调用 netdev_alloc_skb_ip_align（） 为接收到的数据包分配 SKB。如果在启用 BH 的情况下调用 netdev_alloc_skb_ip_align（），则 netdev_alloc_skb_ip_align（） 结尾的 local_bh_enable（） 将触发待定的 softirq 处理，最终可能调用 .xmit 回调 ks8851_start_xmit_par（）。ks8851_start_xmit_par（） 将尝试锁定结构ks8851_net_par .lock 自旋锁，且已由从中调用 ks8851_start_xmit_par（） 的 ks8851_irq（） 锁定。
    这会导致内核报告的死锁，包括下面列出的跟踪。如果未设置CONFIG_PREEMPT_RT，则自提交 0913ec336a6c0（net：ks8851：修复 SPI 芯片变体的死锁）后，也可以在 RX FIFO 中不接收数据包的情况下触发死锁。从 ks8851_irq（） 中的 spin_unlock_bh（&ks->statelock） 返回时将处理待定的 softirqs，这也会触发死锁。通过禁用关键部分（包括 IRQ 处理程序）周围的 BH 来修复此问题，从而防止在这些关键部分期间触发 net_tx_action（） softirq。一旦重新启用 BH，并在 IRQ 处理程序结束时，当所有其他 IRQ 处理程序操作完成后，将触发 net_tx_action（） softirq。__schedule从 schedule_rtlock+0x1c/0x34 schedule_rtlock 从 rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked 从 rt_spin_lock+0x60/0x9c rt_spin_lock 从 ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par 从 netdev_start_xmit+0x20/0x44 netdev_start_xmit 从 dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit 从 sch_direct_xmit+0xb8/0x25c sch_direct_xmit 从 __qdisc_run+0x1f8/0x4ec __qdisc_run 从 qdisc_运行+0x1c/0x28 qdisc_run从 net_tx_action+0x1f0/0x268 net_tx_action 从 handle_softirqs+0x1a4/0x270 handle_softirqs
    __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip 从 __alloc_skb+0xd8/0x128 __alloc_skb
    __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb 从 ks8851_irq+0x388/0x4d4 ks8851_irq 从 irq_thread_fn+0x24/0x64 irq_thread_fn 从 irq_thread+0x178/0x28c irq_thread 从 kthread+0x12c/0x138 kthread 从 ret_from_fork+0x14/0x28 （CVE-2026-46031）

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

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

  - fbdev：defio：从 struct 的生命周期断开延迟的 I/O fb_info 保持 struct fb_deferred_io_state中延迟的 I/O 状态。在初始化延迟的 I/O 的过程中分配实例，仅在最终映射关闭后将其删除。如果 fb_info 和包含的延迟 I/O 同时消失，请清除 struct fb_deferred_io_state.info 以使映射无效。任何访问都将导致 SIGBUS 信号。修复了一个长期存在的问题，即在用户空间仍具有活动的图形内存映射时发生设备热拔出。热拔出可释放 struct fb_info 的实例。访问内存将在未定义的状态下运行。（CVE-2026-46065）

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

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

  - staging：greybus：lights：避免在分配通道数组之前gb_lights_light_config（） 存储channel_count进行空取消引用。如果 kcalloc（） 失败，gb_lights_release（） 将迭代非零计数并取消引用 light->channels，其为 NULL。先分配通道，然后再发布channels_count，这样清除路径就不能遍历空指针。（CVE-2026-45978）

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

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

  - ext2：拒绝 ext2_iget（） 中具有零i_nlink和有效模式的 inode ext2_iget（） 当 i_mode 为零或设置了 i_dtime 时，（） 已经拒绝i_nlink == 0 的 inode，并将它们视为已删除。但是，具有非零模式和零 dtime 的 i_nlink == 0 的情况会漏掉。由于 ext2 没有孤列表，这种组合只能由文件系统损坏导致 - 合法的 inode 删除始终在释放 inode 之前设置i_dtime或清除i_mode。特制的图像可以利用此漏洞向 VFS 呈现此类 inode，然后 VFS 通过 ext2_unlink（）、ext2_rename（） 和 ext2_rmdir（） 触发 drop_nlink（） （fs/inode.c） 内部的WARN_ON： 警告： CPU：3 PID：609 at fs/inode.c：336 drop_nlink+0xad/0xd0 fs/inode.c：336 CPU：3 UID：0 PID：609 通信： syz-executor 未受 6.12.77感染 + #1 调用跟踪： <TASK> inode_dec_link_count include/linux/fs.h：2518 [内联] ext2_unlink+0x26c/0x300 fs/ext2/namei.c：295 vfs_unlink+0x2fc/0x9b0 fs/namei.c：4477 do_unlinkat+0x53e/0x730 fs/namei.c：4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c：4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c：78 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 警告：CPU：0 PID：646 at fs/inode.c：336 drop_nlink+0xad/0xd0 fs/inode.c：336 CPU：0 UID：0 PID：646 通信：syz.0.17 未受感染 6.12.77+ #1 调用跟踪： <TASK> inode_dec_link_count include/linux/fs.h：2518 [内联] ext2_rename+0x35e/0x850 fs/ext2/namei.c：374 vfs_rename+0xf2f/0x2060 fs/namei.c：5021 do_renameat2+0xbe2/0xd50 fs/namei.c：5178
    __x64_sys_rename+0x7e/0xa0 fs/namei.c：5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c：78 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 警告：CPU：0 PID：634 at fs/inode.c：336 drop_nlink+0xad/0xd0 fs/inode.c：336 CPU：0 UID：0 PID：634 comm：syz-executor 未受感染 6.12.77+ #1 调用跟踪： <TASK> inode_dec_link_count include/linux/fs.h：2518 [内联] ext2_rmdir+0xca/0x110 fs/ext2/namei.c：311 vfs_rmdir+0x204/0x690 fs/namei.c：4348 do_rmdir+0x372/0x3e0 fs/namei.c：4407
    __x64_sys_unlinkat+0xf0/0x130 fs/namei.c：4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c：78 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 扩展现有 i_nlink == 0 检查以同样捕获此情况，通过 ext2_error（） 报告损坏并返回 -EFSCORRUPTED。这会在加载时拒绝 inode，并阻止其访问任何 namei.c 路径。由 Linux 验证中心 （linuxtesting.org） 与 syzkaller 一起发现。（CVE-2026-46002）

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

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

  - md/raid5：修复 retry_aligned_read（） 中的软锁定 当 retry_aligned_read（） 遇到重叠条带时，它会通过 raid5_release_stripe（） 释放该条带，从而将其置于无锁的 released_stripes llist 中。在下一个 raid5d 循环迭代中，release_stripe_list（） 会将条带化耗尽至handle_list（因为原始 IO 设置STRIPE_HANDLE），但 retry_aligned_read（） 在 handle_active_stripes（） 之前运行并通过 find_get_stripe（） -> list_del_init（） 从handle_list删除条带化。这阻止 handle_stripe（） 处理条带化以解决重叠，从而导致无限循环和软锁定。在失败路径中使用含有 temp_inactive_list 的 __release_stripe（） 而非 raid5_release_stripe（），以便条带化不会通过released_stripes llist，来修复此问题。这允许 raid5d 跳出其循环，并且 handle_stripe（） 最终处理条带时重叠将得到解决。（CVE-2026-46051）

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

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

  - iommu/vt-d：使用 PASID 表之前对其进行刷新缓存 将新分配的初始化零的 PASID 表的地址写入 PASID 目录条目时，请在此 PASID 表的 CPU 缓存刷新之后（而不是在其之前）进行该操作，以避免此 PASID 表可能已经被非相干的 IOMMU 硬件使用而其在 RAM 中的内容仍然是一些随机旧数据的时间窗口， 未初始化零。
    (CVE-2026-45862)

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

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

  - mm：修复迁移期间延迟的拆分队列争用 migrate_folio_move（） 记录来自 src 的延迟拆分队列状态并在 DST 重播。在 remove_migration_ptes（src， dst， 0） 之后重播会使 dst 在重新排队前可见，因此并行 rmap-removal 路径可将 dst 部分映射标记并触发 deferred_split_folio（） 中的 WARN。在 remove_migration_ptes（） 之前移动重新排队，以便在延迟拆分队列再次可见之前使其回到延迟拆分队列上。由于迁移此时仍保持锁定的 dst，因此当 folio_trylock（） 失败时，将 deferred_split_scan（） 重新排队作品集。否则，完全映射的未充分利用的作品集可能会被 shrinker 出列并静默地从 split_queue 中丢失。[ziy@nvidia.com：移动注释]（CVE-2026-46017）

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

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

  - power：supply：wm97xx：修复 power_supply_changed（） 中的空指针取消引用 在“probe（）”中，分配/注册“power_supply”句柄之前调用“request_irq（）”。如果在对“request_irq（）”和“power_supply_register（）”的调用之间触发中断，“power_supply”句柄将在“wm97xx_bat_update（）”的“power_supply_changed（）”中使用未初始化（从中断处理程序触发）。
    这将导致“NULL”指针取消引用，因为 通过确保在注册“power_supply”句柄之后 _ 请求 IRQ 来修复此 racy 的“空”指针取消引用。由于 IRQ 现在是“probe（）”中最后请求的内容，因此请删除用于释放 IRQ 的错误路径。而是添加一个用于在 IRQ 请求失败时取消注册“power_supply”句柄。（CVE-2026-45869）

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

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

  - ext4：修复 fs 关闭时 dirtyclusters 双倍递减 fstests generic/388 偶尔会在 ext4_put_super（） 中重现与脏群集计数相关的警告：警告：CPU：7 PID：76064 at fs/ext4/super.c：1324 ext4_put_super+0x48c/0x590 [ext4] 跟踪失败显示触发警告的原因是s_dirtyclusters_counter值为 -1。IOW，这似乎是虚假的递减，而不是某种泄漏。对脏簇计数增量的进一步跟踪和生成输出的 LLM 扫描将原因确定为 ext4_mb_mark_diskspace_used（） 和调用方 ext4_mb_new_blocks（） 之间的错误路径中的双重递减。首先，请注意 generic/388 是关机与 fsstress 测试，因此生成一组随机操作和关机注入。在有问题的情况下，关闭会触发从 ext4_mb_mark_context（） 发出的 ext4_handle_dirty_metadata（） 调用返回错误。
    此时更改的值为非零，因此 ext4_mb_mark_diskspace_used（） 不会在错误从 ext4_mb_mark_context（） 冒泡后退出。相反，前者会递减两个群集计数器，并返回最多 ext4_mb_new_blocks（） 的错误。后者落入 ！ar->len out 路径，这会第二次递减脏群集计数器，进而造成不一致。若要避免此问题并简化此代码路径中群集预留的所有权，请将计数器减少提升到调用程序中的一个位置。这更清楚表明，在 ！delalloc 的情况下，ext4_mb_new_blocks（） 负责获取群集预留（通过 ext4_claim_free_clusters（））并释放，而不管群集预留最终是否因失败而被消耗或返回。（CVE-2026-45920）

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

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

  - HID：intel-ish-hid：修复 ishtp_bus_remove_all_clients 中的 NULL-ptr-deref 在温重置流期间，如果在仍枚举客户端时发生重置，cl->device 指针可能为空。在未进行 NULL 检查的情况下访问 cl->device->reference_count 会导致内核错误。此问题是在多单元热重启压力连接期间发现的。为 cl->device 添加防御性 NULL 检查，以确保在此类密集测试条件下的稳定性。KASAN：范围 [0000000000000000-0000000000000007] 工作队列中的 null-ptr-deref：ish_fw_update_wq fw_reset_work_fn 调用跟踪：ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp] ishtp_reset_handler+0x85/0x1a0 [intel_ishtp] fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc] （CVE-2026-45877）

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

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

  - xfs：修复 xfs_alloc_buftarg（） 中的资源泄漏 在错误路径中，调用 fs_put_dax（） 以删除 DAX 设备引用。（CVE-2026-46005）

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

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

  - RDMA/uverbs：在 ib_uverbs_post_send ib_uverbs_post_send（） 中使用wqe_size之前先对其进行验证，在未经任何验证的情况下使用来自用户空间的cmd.wqe_size，然后将其传递到 kmalloc（） 并将分配的缓冲区用作结构ib_uverbs_send_wr。如果用户提供较小的 wqe_size 值（如 1），kmalloc（） 将成功执行，但后续对 user_wr->opcode、user_wr->num_sge 和其他字段的访问将会超出分配的缓冲区进行读取，从而导致从内核堆内存发生越界读取。这可能会将敏感的内核信息泄漏到用户空间。此外，提供过大的wqe_size可在内存分配路径中触发警告，此问题由 syzkaller 所报告。这与 ib_uverbs_unmarshall_recv（） 不一致，后者会在继续操作之前正确验证 wqe_size >= sizeof（struct ib_uverbs_recv_wr）。为 ib_uverbs_post_send（） 添加相同的验证以确保wqe_size至少为 sizeof（struct ib_uverbs_send_wr）。（CVE-2026-45856）

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

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

  - iommu/vt-d：去除 PASID 条目之前清除存在位 Intel VT-d 可扩展模式 PASID 表条目包含 512 位（64 字节）。去除条目时，当前实现会使用多种 64 位写入操作立即将整个 64 字节结构归零。由于 IOMMU 硬件可能使用多个内部事务（例如，四个 128 位突发）获取这 64 字节，因此在整个条目处于活动状态 （P=1） 时将其更新或归零存在读取损坏的风险。如果硬件提取与 CPU 将条目清零的同时发生，硬件可观察到不一致的状态，从而导致不可预测的行为或虚假错误。通过实施建议的所有权握手，按照 VT-d 规范（部分 6.5.3.3）中的无效软件指南进行操作：1. 仅清除 PASID 条目的“Present”（P） 位。2. 继续操作之前，使用 dma_wmb（） 确保清除的位对硬件可见。3.
    执行所需的失效序列（PASID 缓存、IOTLB 和 Device-TLB 刷新）以确保硬件已释放所有缓存的引用。4. 只有在刷新完成后，才将 PASID 条目的剩余字段清零。此外，在 pasid_set_present（） 中添加一个 dma_wmb（），以确保在设置 Present 位之前，硬件可查看 PASID 条目的所有其他字段。（CVE-2026-45894）

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

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

  - net：ipv6：修复 seg6 和 rpl lwtunnels 中的 NOREF dst 使用 seg6_input_core） 和 rpl_input（） 调用 ip6_route_input（），后者在 skb 上设置 NOREF dst，然后将其无条件传递给调用 dst_hold（） 的 dst_cache_set_ip6（）。在 PREEMPT_RT 上，ksoftirqd 处于可抢占状态，且更高优先级的任务可通过共享 nexthop 上的并行 FIB 查找，释放查找和缓存之间的底层pcpu_rt。简化的争用序列：ksoftirqd/X 更高优先级的任务（相同 CPU X）-----------
    -------------------------------- seg6_input_core（，skb）/rpl_input（skb） dst_cache_get（） -> 缺少 ip6_route_input（skb） -> ip6_pol_route（，skb，flags） [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB 查找解决了 fib6_nh [nhid=N route] -> rt6_make_pcpu_route（） [创建 pcpu_rt，refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg（fib6_nh.rt6i_pcpu， NULL， pcpu_rt） [插槽为空，存储成功]
    -> skb_dst_set_noref（skb， dst） [dst 为 pcpu_rt，refcount 仍然是 1] rt_genid_bump_ipv6（） -> fib6_sernum 升级 [fib6_sernum从 W 到 Z] ip6_route_output（） -> ip6_pol_route（） -> FIB 查找解决了 fib6_nh [nhid=N] -> rt6_get_pcpu_route（） pcpu_rt->sernum ！= fib6_sernum [W <> Z，过时] -> prev = xchg（rt6i_pcpu， NULL） -> dst_release（prev） [prev is pcpu_rt， refcount 1->0， dead] dst = skb_dst（skb） [dst 为死pcpu_rt] dst_cache_set_ip6（dst） -> dst_hold（） on dead dst -> WARN / use-after-free 要使争用发生，ksoftirqd 必须可抢占（PREEMPT_RT而无PREEMPT_RT_NEEDS_BH_LOCK），并且并发任务必须能够释放pcpu_rt。共享 nexthop 对象提供这样的路径，因为指向同一 nhid 的两个路由共享相同的fib6_nh及其rt6i_pcpu条目。修复 seg6_input_core（） 和 rpl_input（），方法是在 ip6_route_input（） 之后调用 skb_dst_force（），在缓存前将 NOREF dst 强制转换为 refcounted dst。输出路径不受影响，因为 ip6_route_output（） 已返回 refcounted dst。（CVE-2026-46099）

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

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

  - KVM：nSVM：如果 L1 未拦截未处理的 VMMCALL，则引发 #UD 如果 L2 处于活动状态、L1 不想拦截 VMMCALL、nested_svm_l2_tlb_flush_enabled（） 为 true、并且超级调用不是某个受支持的 Hyper-V 超级调用，则显式合成 VMMCALL 的 #UD。当满足上述所有条件时，KVM 将拦截 VMMCALL，但绝不将其转发到 L1，即让 L2 进行超级调用，就像它是 L1 一样。TLFS 对此情况没有说明很多内容，因此请遵循架构行为，其中指出如果未被拦截，则 VMMCALL #UDs。适时地通过存根化新 API 而不是其使用的帮助程序来进行 2 换 1 存根交易。最后剩下的单个存根也将很快被删除。[sean：重写变更日志和注释，标记稳定版本，删除僵尸的存根]（CVE-2026-46076）

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

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

  - ipvs：跳过 csum 检查的 IPv6 扩展标头 如果协议标头前面有扩展标头，则 IPv6 的协议校验和验证将失败。iph->len 已包含其偏移，因此请使用该偏移来修复问题。（CVE-2026-45850）

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

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

  - net：usb：catc：启用基本端点检查 catc_probe（） 在未验证端点描述符的情况下，使用硬编码端点管道填充三个 URB：- 用于 TX/RX 的 usb_sndbulkpipe（usbdev， 1） 和 usb_rcvbulkpipe（usbdev， 1） - 用于中断状态的 usb_rcvintpipe（usbdev， 2） 畸形 USB 设备可能会通过与驱动程序假设的传输类型不同的传输类型呈现这些端点。为端点数字添加一个catc_usb_ep枚举，在整个过程中替换魔术常量。在 usb_set_interface（） 之后添加 usb_check_bulk_endpoints（） 和 usb_check_int_endpoints（） 调用，以在使用前验证端点类型，在探测时拒绝描述符不匹配的设备。类似于 - 提交 90b7f2961798（net：usb：rtl8150：
    启用基本端点检查），修复了 rtl8150 中的问题。（CVE-2026-45923）

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

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

  - btrfs：修复因区块分配中的非连续间隙而导致的 EEXIST 中止 我观察到多个系统在 btrfs_create_pending_block_groups（） 中的 insert_dev_extents（） 时中止。以下是来自强制区块分配（通常在 CONFIG_BTRFS_EXPERIMENTAL 之后）的此类中止的示例堆栈跟踪，但理论上这可发生在任何 DUP 区块分配上。[81.801]
    ------------[ cut here ]------------ [81.801] BTRFS： 事务已中止（错误 -17） [81.801] 警告：
    fs/btrfs/block-group.c：2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs]， CPU#1： bash/319 [81.802] 链接的模块：virtio_net btrfs xor zstd_compress raid6_pq null_blk [81.803] CPU：1 UID：0 PID：319 Comm：bash Kdump：已加载 未受感染 6.19.0-rc6+ #319 无 [81.803] 硬件名称：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS Arch Linux 1.17.0-2-2 04/01/2014 [81.804] RIP：
    0010：btrfs_create_pending_block_groups+0x723/0x770 [btrfs] [81.806] RSP：0018：ffffa36241a6bce8 EFLAGS：
    00010282 [81.806] RAX：000000000000000d RBX：ffff8e699921e400 RCX：000000000000000 [81.807] RDX：
    0000000002040001 RSI：00000000ffffffef RDI：ffffffffc0608bf0 [81.807] RBP：00000000ffffffffef R08：
    ffff8e69830f6000 R09： 0000000000000007 [81.808] R10： ffff8e699921e5e8 R11： 0000000000000000 R12：
    ffff8e6999228000 [81.808] R13： ffff8e6984d82000 R14： ffff8e69966a69c0 R15： ffff8e69aa47b000 [81.809] FS：
    00007fec6bdd9740（0000） GS：ffff8e6b1b379000（0000） knlGS：000000000000000 [81.809] CS：0010 DS：0000 ES：
    0000 CR0： 0000000080050033 [81.810] CR2： 00005604833670f0 CR3： 0000000116679000 CR4： 000000000000006f0 [81.810] 调用跟踪： [81.810] [81.810] <TASK> __btrfs_end_transaction+0x3e/0x2b0 [btrfs] [81.811] btrfs_force_chunk_alloc_store+0xcd/0x140 [btrfs] [81.811] kernfs_fop_write_iter+0x15f/0x240 [81.812] vfs_write+0x264/0x500 [81.812] ksys_write+0x6c/0xe0 [81.812] do_syscall_64+0x66/0x770 [81.812] entry_SYSCALL_64_after_hwframe+0x76/0x7e [81.813] RIP： 0033：0x7fec6be66197 [81.814] RSP：
    002b：00007fffb159dd30 EFLAGS：00000202 ORIG_RAX：0000000000000001 [81.815] RAX：ffffffffffffffda RBX：
    00007fec6bdd9740 RCX： 00007fec6be66197 [81.815] RDX： 0000000000000002 RSI： 0000560483374f80 RDI：
    0000000000000001 [81.816] RBP： 0000560483374f80 R08： 0000000000000000 R09： 0000000000000000 [81.816] R10：
    0000000000000000 R11： 0000000000000202 R12： 0000000000000002 [81.817] R13： 00007fec6bfb85c0 R14：
    00007fec6bfb5ee0R15： 00005604833729c0 [81.817] [81.817] </TASK> irq 事件戳：20039 [81.818] hardirqs 上次启用时间（20047）： [<ffffffff99a68302>] __up_console_sem+0x52/0x60 [81.818] hardirqs 上次禁用时间（20056）： [<ffffffff99a682e7>] __up_console_sem+0x37/0x60 [81.819] softirqs 上次启用时间 （19470）：
    [<ffffffff999d2b46>] __irq_exit_rcu+0x96/0xc0 [81.819] softirqs 上次禁用时间为 （19463）：
    [<ffffffff999d2b46>] __irq_exit_rcu+0x96/0xc0 [81.820] ---[ 结束跟踪 000000000000000000 ]--- [81.820] BTRFS：btrfs_create_pending_block_groups：2876 中的错误（设备 dm-7 状态 A）：errno=-17 对象已存在 使用 drgn 检查这些中止时，我观察到重叠chunk_maps的模式。请注意第一个区块的条带 1 在物理地址中如何与第二个区块的条带 0 重叠。物理起始 物理结束长度 逻辑类型条带
    ---------------------------------------------------------------------------------------------------- 0x0000000102500000 0x0000000142500000 0x0000000641d00000 1.0G META|DUP 0/2 0x0000000142500000 0x0000000182500000 1.0G 0x0000000641d00000 META|DUP 1/2 0x0000000142500000 0x0000000182500000 1.0G 0x0000000601d00000 META|DUP 0/2 0x0000000182500000 0x00000001c2500000 1.0G 0x0000000601d00000 META|DUP 1/2 现在这怎么可能发生？所有区块分配均为 ---truncated--- （CVE-2026-45934）

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

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

  - ext4：在提交 I/O 之前拆分时，不设置 EXT4_GET_BLOCKS_CONVERT 在启用了 dioread_nolock 的情况下，在 EOF 内 DIO 和回写期间分配区块时，EXT4_GET_BLOCKS_PRE_IO 设置为拆分现有的大型未写入盘区。但是调用 ext4_split_convert_extents（） 时设置了EXT4_GET_BLOCKS_CONVERT，可能会导致过时数据问题。假设我们有一个未写入的范围，然后 DIO 写入后半部分。[UUUUUUUUUUUUUUUUUU] 磁盘盘区 U：未写入盘区 [UUUUUUUUUUUUUUUUU] 盘区状态树 |<- ->|----> dio 写入此范围 首先，ext4_iomap_alloc（） 调用 ext4_map_blocks（），并设置了 EXT4_GET_BLOCKS_PRE_IO、EXT4_GET_BLOCKS_UNWRIT_EXT 和 EXT4_GET_BLOCKS_CREATE 标记。ext4_map_blocks（） 找到此范围并调用集EXT4_GET_BLOCKS_CONVERT和上述标记的 ext4_split_convert_extents（）。然后，ext4_split_convert_extents（） 在设置了 EXT4_EXT_MAY_ZEROOUT、EXT4_EXT_MARK_UNWRIT2 和 EXT4_EXT_DATA_VALID2 标记的情况下调用 ext4_split_extent（），并调用 ext4_split_extent_at（） 来拆分设置了 EXT4_EXT_DATA_VALID2、EXT4_EXT_MARK_UNWRIT1、EXT4_EXT_MAY_ZEROOUT 和 EXT4_EXT_MARK_UNWRIT2 标记的后半部分。但是，由于暂时缺少 -ENOSPC，ext4_split_extent_at（） 无法插入盘区。它将前半部分归零，但将整个磁盘上的盘区转换为自EXT4_EXT_DATA_VALID2标记设置以来的已写入，但将后半部分保留为未写入的盘区状态树。[0000000000SSSSSS] 数据 S：过期数据，0：归零 [WWWWWWWWWWWWW] 磁盘上的范围 W：写入范围 [WWWWWWWUUUUUU] 范围状态树 最后，如果 DIO 未能将数据写入磁盘，一旦缓存的范围条目消失，后半部分的过时数据将暴露出来。通过在提交 I/O 之前拆分未写入盘区时不传递EXT4_GET_BLOCKS_CONVERT修复此问题，并在这种情况下使 ext4_split_convert_extents（） 将整个盘区范围归零，同时在盘区状态树中标记盘区以保持一致性。（CVE-2026-45985）

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

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

  - KVM：SVM：如果 EFER，则为 INVLPGA 注入 #UD。SVME=0 #UD 当 EFER.SVME 未设置。添加检查以便在 EFER 时正确注入 #UD。SVME=0。[sean：stable@ 的标签]（CVE-2026-46082）

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

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

  - nfsd：在 idmap 查找期间从不延迟请求 在 v4 请求复合参数解码期间，部分 ops（例如
    SETATTR） 可触发 idmap 查找上调。当这些上调响应的延迟超过允许的时间限制时，cache_check（） 会将该请求标记为延迟并使其终止。这阻止执行nfs4svc_encode_compoundres，因此会话槽标记NFSD4_SLOT_INUSE永远不会被清除。由于插槽将被标记为正在使用，后续客户端请求将因NFSERR_JUKEBOX而失败，从而使 SEQUENCE 操作失败。通过确保 nfs4svc_decode_compoundargs（） 期间 RQ_USEDEFERRAL 标记始终清除来修复此问题，因为任何 v4 请求都不应被延迟。（CVE-2026-45983）

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

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

  - net：qrtr：ns：在 ctrl_cmd_bye（） 期间释放节点 节点在即将关闭时发送 BYE 数据包。因此，名称服务器应向所有远程和本地观察者公告删除该节点，并且最终释放该节点。但当前，即使在处理 BYE 数据包之后，名称服务器也不会释放节点内存。这会导致节点内存泄漏。因此，请从 Xarray 列表中删除该节点并在 ctrl_cmd_bye（） 成功和失败时释放节点内存。（CVE-2026-46038）

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

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

  - iommu/vt-d：去除上下文条目之前清除存在位 去除上下文条目时，当前实现使用多种 64 位写入将整个 128 位条目清零。这将创建一个窗口，硬件可在此获取已撕裂条目，其中某些字段已归零而“Present”位仍处于设置状态，从而导致不可预测的行为或虚假错误。尽管 x86 提供强写入排序，编译器可能会对上下文条目的两个 64 位半部的写入重新排序。即使没有编译器重新排序，硬件提取也不能保证对于多个 CPU 写入是原子性的。通过实施建议的所有权握手，与 VT-d 规范（部分 6.5.3.3）中的无效软件指南保持一致：1. 首先仅清除上下文条目的“Present”（P） 位，以表示所有权从硬件过渡到软件。2. 使用 dma_wmb（） 确保清除的位对 IOMMU 可见。3.执行所需的缓存和上下文缓存失效，以确保硬件不再缓存引用该条目。4. 只有在失效完成后才将条目完全归零。此外，将 dma_wmb（） 添加到 context_set_present（） 以确保在“Present”位可见前完成条目完全初始化。（CVE-2026-45944）

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

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

  - RDMA/mana_ib：禁用 RSS QP 破坏时的 RX 转向 RSS QP 遭到破坏（如 DPDK 退出）时，mana_ib_destroy_qp_rss（） 会破坏 RX WQ 对象，但不会在固件中禁用 vPort RX 转向。
    这会留下过时的转向配置，该配置仍然指向已销毁的 RX 对象。如果流量继续到达（例如，对等虚拟机仍在传输），且随后启动 VF 接口 （mana_open），则固件可能会使用旧 RX 对象中的过时 CQ ID 提供完成。以太网驱动程序可针对新的 TX CQ 重复使用这些 CQ ID，从而导致 RX 完成登陆 TX CQ：警告：
    mana_poll_tx_cq+0x1b8/0x220 [mana] （is_sq == false） 警告：mana_gd_process_eq_events+0x209/0x290（cq_table 查找失败） 通过在销毁 RX WQ 对象之前禁用 vPort RX 转向来修复此问题。请注意，此处无法使用 mana_fence_rqs（），因为隔离完成是在 CQ 上提供的，CQ 由用户模式（例如 DPDK）轮询，并且内核驱动程序不可见。将禁用逻辑重构到 mana_en 中的共享 mana_disable_vport_rx（） 中，导出供mana_ib使用，以替换重复的代码。以太网驱动程序的 mana_dealloc_queues（） 也已更新，可调用此通用函数。（CVE-2026-46084）

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

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

  - libceph：防止 ceph_handle_auth_reply（） 中潜在的 null-ptr-deref 如果类型 CEPH_MSG_AUTH_REPLY 的消息的协议和结果都包含零值，则当前不将其视为错误。如果 ac->negotiating == true 且 ac->protocol > 0，则会导致设置 ac->protocol = 0 和 ac->ops = NULL。此后，ac->protocol ！= 协议检查返回 false，并且不会调用 init_protocol（）。随后会调用 ac->ops->handle_reply（），这将导致空指针取消引用，原因是 ac->ops 仍然是 NULL。此修补程序将对 ac->protocol ！= 协议的检查更改为 ！ac->protocol，因为这还包括消息中协议被设置为零的情况。这会造成消息被视为包含错误的认证协议。（CVE-2026-46024）

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

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

  - netfilter：nfnetlink_queue：分段前进行 shared-unconfirmed 检查 Ulrich 报告 nfqueue 的回归：如果应用程序未设置“F_GSO”功能标记并且接收到具有未确认nf_conn条目的 gso 数据包，则所有数据包现在都会被丢弃而不是排队，因为检查在 skb_gso_segment（） 之后进行。在这种情况下，我们确实拥有 skb 及其相关连接跟踪条目的独家所有权。使用计数增加是由于通过 skb_gso_segment（） 发生skb_clone。
    移动检查，使其与已执行的数据包与聚合的数据包相匹配。然后，注释除第一个段外的各个段，以便我们可以在重新注入时进行第二次检查。对于正常情况下，用户空间进行顺序重新注入，这可避免数据包丢失：第一个重新注入的段继续遍历并确认条目，其余段观察已确认的条目。同时，简化 nf_ct_drop_unconfirmed（）：我们只关心带有 refcnt > 1 的未确认条目，不需要特殊情况的垂死条目。
    这只会发生在 UDP 上。对于 TCP，唯一未经确认的数据包将为 TCP SYN，这些数据包不由 GRO 聚合。下一个修补程序将添加一个 udpgro 测试用例以涵盖此情况。（CVE-2026-45859）

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

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

  - FastNetMon Community Edition 在 1.2.9 端口 50052 上暴露一个没有认证机制的 gRPC API 服务器。服务器使用 grpc：：InsecureServerCredentials（） 初始化（src/fastnetmon.cpp第 477 行），并且源代码注释明确确认“侦听给定地址，无任何认证机制。”src/api.cpp 中的所有 RPC 方法（ExecuteBan、ExecuteUnBan、GetBanlist、GetTotalTrafficCounters 等）均未执行任何凭据验证。ExecuteBan 和 ExecuteUnBan 方法会触发安全关键操作：可黑洞网络流量的 BGP 路由公告，以及通过 popen（） 执行外部通知脚本。拥有本地网络访问权限的攻击者可以禁止任意 IP 地址（导致合法流量拒绝服务）、解除主动攻击（禁用 DDoS 缓解措施）以及触发脚本执行。也没有将只读监控与破坏性管理操作分开的基于角色的访问控制。（CVE-2026-48692）

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

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

  - misc：ibmasm：修复 ibmasm_handle_mouse_interrupt（） 中的 OOB MMIO 读取 当硬件的队列读取器或写入器索引超过 REMOTE_QUEUE_SIZE （60） 时，ibmasm_handle_mouse_interrupt（） 会执行越界 MMIO 读取。遭入侵的服务处理器可在断言中断之前，将超出范围的值写入读写器 MMIO 寄存器，以触发此漏洞。由于在每次循环迭代时都会从硬件重新读取编写器，因此也可以在循环开始后将其设置为超出范围的值。
    根本原因是 get_queue_reader（） 和 get_queue_writer（） 返回直接传递到 get_queue_entry（） 的原始 readl（） 值，后者会计算：queue_begin + reader * sizeof（struct remote_input），不进行边界检查。然后将这个未经检查的 MMIO 地址传递到 memcpy_fromio（），从非预期设备寄存器读取 8 字节。对于足够大的值，该地址完全位于 PCI BAR 映射之外，从而触发计算机检查异常。通过在对 get_queue_entry（） 进行任何调用之前，在循环正文顶部对 REMOTE_QUEUE_SIZE 检查两个索引来修复。对于超出范围的值，在中断前通过 set_queue_reader（） 将读取器寄存器重置为 0，以便在损坏的硬件状态为暂时性时可以恢复正常队列操作。（CVE-2026-46022）

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

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

  - PCI：端点：pci-epf-ntb：删除重复的资源拆卸 epf_ntb_epc_destroy（） 复制调用程序稍后应执行的拆卸。这会导致.allow_link失败或执行.drop_link时 oops。删除辅助函数。同时删除 pci_epc_put（）。EPC 设备引用计数与 configfs EPC 群组生命周期相关联，.drop_link 路径中的 pci_epc_put（） 就足够了。（CVE-2026-46009）

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

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

  - ocfs2：拆分 dio 完成中的事务以避免信用耗尽 在 ocfs2 dio 操作期间，JBD2 可能会通过以下调用跟踪报告警告：ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle输出： JBD2： kworker/6:2 想要过多的 credits credits：5450 rsv_credits：0 max：5449 为防止超出 credits 限制，请修改 ocfs2_dio_end_io_write（） 以处理批量事务中的盘区。此外，重新定位 ocfs2_del_inode_from_orphan（）。只有在区段树更新完成后，才应从孤立列表中删除孤立的 inode。如此可确保如果在扩展树更新过程中发生崩溃，不会将过时块留在 EOF 之外。此修补程序还更改了用于更新 inode 大小和删除 orphan 的逻辑，使其与 ext4_dio_write_end_io（） 类似。只有在一切看起来都不错时才会执行这两个操作。最后，感谢 Jans 和 Joseph 提供缺陷修复原型和建议。（CVE-2026-46080）

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

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

  - net：qrtr：ns：限制节点总数 目前，名称服务器不会限制其处理的节点数量。如果恶意客户端开始注册随机节点，这可成为攻击载体，从而导致内存耗尽。因此，将最大节点数限制为 64。请注意，64 的限制是基于当前平台要求所选择的。如果将来要求发生变化，可以增加此限制。
    (CVE-2026-46003)

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

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

  - net：qrtr：ns：限制最大查找次数当前代码未对客户端可以执行的查找次数进行边界检查。尽管代码将查找限制为本地客户端，但仍可能让恶意本地客户端通过同一套接字发送大量NEW_LOOKUP消息。通过将全局最大查找次数限制为 64 来修复此问题。由于名称服务器最多只允许一个本地观察者，此全局查找计数将确保查找保持在限制范围内。
    请注意，64 的限制是基于当前平台要求所选择的。如果将来要求发生变化，可以增加此限制。（CVE-2026-46026）

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

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

  - scsi：sd：修复 device_add（&disk_dev） 失败时缺失的 put_disk（） 如果 device_add（&sdkp->disk_dev） 失败，put_device（） 运行 scsi_disk_release（），从而释放scsi_disk但保留引用的 gendisk。sd_probe（） 中的 device_add_disk（） 错误路径调用 put_disk（gd）;在此处调用 put_disk（gd） 以镜像该清理。（CVE-2026-45997）

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

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

  - FastNetMon Community Edition 在 1.2.9 Juniper 路由器集成插件中包含配置注入漏洞。在 src/juniper_plugin/fastnetmon_juniper.php 中， $IP_ATTACK 变量（从 argv[1] 接收）在第 69 行和第 90 行直接插值到 Juniper NETCONF set-configuration 命令中，而无任何验证或审查。第 69 行： $conn->load_set_configuration（set routing-options static route {$IP_ATTACK} community 65535:666 discard）。第 90 行： $conn->load_set_configuration（delete routing-options static route {$IP_ATTACK}/32）。能够控制 IP 地址字符串的攻击者可通过在换行符后嵌入任意 set/delete 命令来注入其他 Juniper CLI 配置命令。这可能会修改路由器的路由表、防火墙过滤器、用户帐户，或可通过 NETCONF 访问的任何其他配置元素。影响是路由器全部遭到破坏。（CVE-2026-48694）

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

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

  - KVM：nSVM：在第一个 L2 VMRUN 之后始终将 NextRIP 用作 vmcb02 的 NextRIP 对于禁用了 NRIPS 的客户机，L1 在运行注入了软中断的 L2 时不提供 NextRIP，而是在运行当前 RIP 之前前推进。KVM 使用当前 RIP 作为 vmcb02 中的 NextRIP 来仿真无 NRIPS 的 CPU。但是，在 L2 首次运行后，CPU 和/或 KVM 将更新 NextRIP ，当前 RIP 不再是用于 vmcb02 中的正确值。因此，在保存/还原之后，当且仅在嵌套运行待定时才使用当前 RIP，否则使用 NextRIP。给予soft_int_next_rip相同的处理方式，因为它是相同的逻辑，只是针对更窄的用例。[肖恩：给soft_int_next_rip同样的待遇]（CVE-2026-46059）

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: algif_aead - snapshot IV for async AEAD requests AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling. Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.
    (CVE-2026-46028)

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

ID	名称	严重性
317183	Linux Distros 未修补的漏洞：CVE-2026-45949	medium
317182	Linux Distros 未修补的漏洞：CVE-2026-48689	critical
317181	Linux Distros 未修补的漏洞：CVE-2026-48687	critical
317180	Linux Distros 未修补的漏洞：CVE-2026-46044	medium
317179	Linux Distros 未修补的漏洞：CVE-2026-45993	medium
317178	Linux Distros 未修补的漏洞：CVE-2026-45942	high
317177	Linux Distros 未修补的漏洞：CVE-2026-46096	medium
317176	Linux Distros 未修补的漏洞：CVE-2026-45956	high
317175	Linux Distros 未修补的漏洞：CVE-2026-46071	medium
317174	Linux Distros 未修补的漏洞：CVE-2026-45873	medium
317173	Linux Distros 未修补的漏洞：CVE-2026-45961	medium
317172	Linux Distros 未修补的漏洞：CVE-2026-46047	high
317171	Linux Distros 未修补的漏洞：CVE-2026-46021	medium
317170	Linux Distros 未修补的漏洞：CVE-2026-46091	medium
317169	Linux Distros 未修补的漏洞：CVE-2026-46031	high
317168	Linux Distros 未修补的漏洞：CVE-2026-46065	high
317167	Linux Distros 未修补的漏洞：CVE-2026-45978	medium
317166	Linux Distros 未修补的漏洞：CVE-2026-46002	medium
317165	Linux Distros 未修补的漏洞：CVE-2026-46051	medium
317164	Linux Distros 未修补的漏洞：CVE-2026-45862	high
317163	Linux Distros 未修补的漏洞：CVE-2026-46017	medium
317162	Linux Distros 未修补的漏洞：CVE-2026-45869	medium
317161	Linux Distros 未修补的漏洞：CVE-2026-45920	high
317160	Linux Distros 未修补的漏洞：CVE-2026-45877	medium
317159	Linux Distros 未修补的漏洞：CVE-2026-46005	medium
317158	Linux Distros 未修补的漏洞：CVE-2026-45856	high
317157	Linux Distros 未修补的漏洞：CVE-2026-45894	high
317156	Linux Distros 未修补的漏洞：CVE-2026-46099	high
317155	Linux Distros 未修补的漏洞：CVE-2026-46076	high
317154	Linux Distros 未修补的漏洞：CVE-2026-45850	medium
317153	Linux Distros 未修补的漏洞：CVE-2026-45923	medium
317152	Linux Distros 未修补的漏洞：CVE-2026-45934	medium
317151	Linux Distros 未修补的漏洞：CVE-2026-45985	medium
317150	Linux Distros 未修补的漏洞：CVE-2026-46082	medium
317149	Linux Distros 未修补的漏洞：CVE-2026-45983	medium
317148	Linux Distros 未修补的漏洞：CVE-2026-46038	medium
317147	Linux Distros 未修补的漏洞：CVE-2026-45944	high
317146	Linux Distros 未修补的漏洞：CVE-2026-46084	high
317145	Linux Distros 未修补的漏洞：CVE-2026-46024	high
317144	Linux Distros 未修补的漏洞：CVE-2026-45859	high
317143	Linux Distros 未修补的漏洞：CVE-2026-48692	high
317142	Linux Distros 未修补的漏洞：CVE-2026-46022	high
317141	Linux Distros 未修补的漏洞：CVE-2026-46009	medium
317140	Linux Distros 未修补的漏洞：CVE-2026-46080	medium
317139	Linux Distros 未修补的漏洞：CVE-2026-46003	medium
317138	Linux Distros 未修补的漏洞：CVE-2026-46026	medium
317137	Linux Distros 未修补的漏洞：CVE-2026-45997	medium
317136	Linux Distros 未修补的漏洞：CVE-2026-48694	high
317135	Linux Distros 未修补的漏洞：CVE-2026-46059	medium
317134	Linux Distros 未修补的漏洞：CVE-2026-46028	medium

检测

Nessus 的 Misc. 系列

medium

critical

critical

medium

medium

high

medium

high

medium

medium

medium

high

medium

medium

high

high

medium

medium

medium

high

medium

medium

high

medium

medium

high

high

high

high

medium

medium

medium

medium

medium

medium

medium

high

high

high

high

high

high

medium

medium

medium

medium

medium

high

medium

medium