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

  - NVIDIA Display Driver for Linux 在多实例 GPU （MIG） 分区管理中含有一个漏洞，其中内存子系统路由资源的不安全默认初始化可导致数据损坏或分区重新配置期间挂起。此漏洞的成功利用可能会导致拒绝服务。（CVE-2026-24197）

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

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

  - 适用于 Windows 和 Linux 的 NVIDIA 显示驱动程序在内核驱动程序中含有一个漏洞，用户可导致关键资源的权限分配不正确。成功利用此漏洞可能会导致数据篡改和拒绝服务。(CVE-2025-33221)

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

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

  - fat：避免 rmdir 中的父链接计数下溢 损坏的 FAT 图像可使目录 inode i_nlink不正确（例如 2，即使子目录存在）。然后，rmdir 会无条件调用 drop_nlink（dir） 并可将 i_nlink 驱动到 0，从而触发 drop_nlink（） 中的WARN_ON。在 vfat_rmdir（） 和 msdos_rmdir（） 中添加健全性检查：仅当父链接计数至少为 3 时才将其删除，否则报告文件系统错误。（CVE-2026-45915）

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

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

  - wifi：mwifiex：修复 mwifiex_adapter_cleanup（） 中的释放后使用 mwifiex_adapter_cleanup（） 函数在释放适配器结构之前对wakeup_timer使用 timer_delete（）（非同步）。这是不正确的，因为 timer_delete（） 不会等待任何运行定时器回调完成。如果在调用 mwifiex_adapter_cleanup（） 时执行 wakeup_timer 回调 （wakeup_timer_fn），则回调将继续访问适配器字段（adapter->hw_status、adapter->if_ops.card_reset 等），这些字段可由稍后在 mwifiex_remove_card（） 路径中调用的 mwifiex_free_adapter（） 释放。请改用 timer_delete_sync（） 以确保所有正在运行的定时器回调在返回之前已经完成。
    (CVE-2026-46069)

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

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

  - apparmor：修复和优化从可能未对齐的内存创建表 源 blob 可能来自用户空间，并且可能未对齐。尝试通过避免不一致的内存访问来优化复制过程。- 添加了 Fixes 标签 - 向描述添加了 Fix &;，因为这不仅优化了，还修复了潜在的不一致内存访问 [jj：删除注释触发 checkpatch 警告中重复的单词 convert] （CVE-2026-45893）

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

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

  - ext4：不将整个盘区归零 如果EXT4_EXT_DATA_PARTIAL_VALID1 从大型的未写入盘区分配初始化区块，或在结束 I/O 期间拆分未写入盘区并将其转换为初始化盘区时，需要在中间拆分盘区，当前可能存在过时数据问题。0 A B N [UUUUUUUUUUUU] U：未写入范围 [--DDDDDDDD--] D：有效数据 |<- ->|---->此范围需要初始化ext4_split_extent（） 首先尝试拆分具有 EXT4_EXT_DATA_ENTIRE_VALID1 和 EXT4_EXT_MAY_ZEROOUT 标记的 B 处的此盘区，但 ext4_split_extent_at（） 由于暂时空间不足而无法拆分此盘区。它将 B 到 N 归零，并将从 0 到 N 的整个盘区标记为写入。0 A B N [WWWWWWWWWWWW] W：写入范围 [SSDDDDDDDDZZ] Z：归零，S：过时数据 ext4_split_extent（） 然后尝试在 A 处使用EXT4_EXT_DATA_VALID2标记集拆分此范围。这一次，它成功拆分并留下了一个从 0 到 A. 0 的过时写入范围 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] 修复此问题 在 B 处拆分时EXT4_EXT_DATA_PARTIAL_VALID1 ext4_split_extent_at（） 的绕过，将 B 归零到 N 之后，不将整个盘区转换为已写入，并将其保留为未写入。其余工作就像标准的两部分拆分一样。ext4_split_extent（） 将在第二次调用 ext4_split_extent_at（） 时传递 EXT4_EXT_DATA_VALID2 标记，从而使其能够正确处理拆分。如果拆分成功，它将把从 0 到 A 的范围保持为未写入。（CVE-2026-45858）

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

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

  - scsi：csiostor：修复空指针 rn 的取消引用 rn 为空时的错误退出路径通过使用宏CSIO_INC_STATS结束取消引用空指针 rn。通过在使用宏之后添加新的错误返回路径标签来修复此问题以避免取消引用。（CVE-2026-45857）

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

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

  - can：ucan：修复 devres 生命周期 USB 驱动程序绑定到 USB 接口，任何设备托管资源都应将其生命周期绑定到接口而不是父 USB 设备。这可避免驱动程序在未以物理方式断开其设备的情况下（例如在探测延迟或配置变更时）解除绑定驱动程序时发生内存泄漏等问题。修复控制消息缓冲区生命周期，使其在驱动程序取消绑定时释放。（CVE-2026-46103）

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

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

  - tcp：监听器迁移后调用 sk_data_ready（） 当 inet_csk_listen_stop（） 将已建立的子套接字从关闭监听器迁移到同一SO_REUSEPORT组中的另一个套接字时，目标监听器通过 inet_csk_reqsk_queue_add（） 获取新的接受队列条目，但该路径从未通知目标监听器的等待程序。非阻塞 accept（） 仍然有效，因为它直接检查队列，但 poll（）/epoll_wait（） 等待程序和阻止 accept（） 调用程序也可以无限期地保持睡眠状态。在 inet_csk_listen_stop（） 中成功迁移后调用 READ_ONCE（nsk->sk_data_ready）（nsk）。但是，inet_csk_reqsk_queue_add（） 成功后，在 reuseport_migrate_sock（） 中获取的 ref 将有效地转移到 nreq->rsk_listener。然后另一个 CPU 可通过 accept（） 或监听器关闭使 nreq 出列，点击 reqsk_put（） 并丢弃该监听程序 ref。由于侦听器SOCK_RCU_FREE，因此将 nsk 的 （） 取消引用封装 post-queue_add在 rcu_read_lock（）/rcu_read_unlock（） 中，其还涵盖该路径中现有的 sock_net（nsk） 访问。reqsk_timer_handler（） 路径不需要相同的更改，原因有两个：半开请求只有在最终 ACK 之后才变得可读，其中 tcp_child_process（） 已经唤醒了监听器;并且一旦通过 inet_ehash_insert（） 导致 nreq 可见，成功路径将不再直接接触 NSK。（CVE-2026-46015）

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

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

  - power：supply：goldfish：修复 power_supply_changed（） 中的释放后使用 _before_ 请求 IRQ 的“devm_”变体 用于分配/注册“power_supply”句柄的“devm_”变体意味着“power_supply”句柄将在中断处理程序之前 _ 解除分配/取消注册（因为“devm_”自然会以反向分配顺序解除分配）。这意味着删除过程中存在争用条件，其中，中断可能恰好在释放了“power_supply”句柄后，*但是* 恰好在 IRQ 处理程序的相应取消注册运行之前触发。这将导致 IRQ 处理程序通过释放的“power_supply”句柄调用“power_supply_changed（）”。这通常会使系统崩溃或以其他方式静默地损坏内存... 请注意，在“probe（）”期间也可能发生类似的情况;_before_ 注册“power_supply”句柄时中断触发的可能性。然后，这将导致使用“power_supply_changed（）”中使用“power_supply”句柄 *uninitialized* 的糟糕情况。通过确保在注册“power_supply”句柄后 _ 请求 IRQ，修复了此 racy 释放后使用。（CVE-2026-45936）

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

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

  - serial：caif：修复 caif_serial ldisc_close（） 中的释放后使用 caif_serial 中存在一个释放后使用缺陷，其中 handle_tx（） 可能在释放 tty 后访问 ser->tty。ldisc_close（） 和数据包传输之间出现争用条件：CPU 0（关闭） CPU 1 （xmit） ------------- ------------ ldisc_close（） tty_kref_put（ser->tty） [tty 可在此处释放] <-- race window --> caif_xmit（） handle_tx（） tty = ser->tty // 悬摆 ptr tty->ops->write（） // UAF！ schedule_work（） ser_release（） unregister_netdevice（） 根本原因是，当网络设备仍然处于活动状态且可以接收数据包时，在 ldisc_close（） 中调用了 tty_kref_put（）。由于 ser 和 tty 具有 1:1 具有一致生命周期的绑定关系（ser 在 ldisc_open 中分配，并通过 unregister_netdevice 在 ser_release 中释放，并且每个 ser 恰好绑定一个 tty），因此我们可以安全地将 tty 引用释放延迟到网络设备未注册的 ser_release（）。通过在 unregister_netdevice（） 之后将 tty_kref_put（） 从 ldisc_close（） 移至 ser_release（） 来修复此问题。这可确保只要网络设备存在，tty 引用就会保留，从而防止 UAF。注意：我们将 ser->tty 保存在 unregister_netdevice（） 之前，因为 ser 嵌入在 netdev 的隐私数据中，并将与 netdev （needs_free_netdev = true） 一起释放。如何重现：
    在 ldisc_close（） 的开头添加 mdelay（500） 以扩大争用窗口，然后运行重现程序 [1]。注意：当使用PORT_UNKNOWN串行端口时（例如，QEMU 中的 /dev/ttyS3，没有正确的串行后端），handle_tx（） 中存在单独的死循环问题。即使没有此修补程序，此死循环也存在，很可能是由于串行核心中 uart_write_room（） 与 uart_write（） 之间的不一致所导致。已在单独的修补程序 [2] 中解决此问题。KASAN 报告：
    ==================================================================缺陷：KASAN：在 handle_tx+0x5d1/0x620 中的释放后使用 在地址 ffff8881131e1490 的读取中，按任务 caif_uaf_trigge/9929 读取的大小为 1 调用跟踪：
    <TASK> dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP： 0033：0x7f615df2c0d7 按任务 9930 分配： 由任务 64 释放： 上一次可能相关的工作创建： 有缺陷的地址属于位于 ffff8881131e1000 的对象，该对象属于大小为 2048 的缓存 kmalloc-cg-2k 有缺陷的地址位于已释放的 2048 字节区域内的 1168 字节处 [ffff8881131e1000、ffff8881131e1800） 有缺陷的地址属于物理页面： page_owner 跟踪页面作为分配页面进行跟踪 上次释放的 pid 9778 tgid 9778 堆栈跟踪： 有缺陷地址周围的内存状态：ffff8881131e1380： fb fb fbffff8881131e1400： fb fb fb >ffff8881131e1480： fb fb ^ ffff8881131e1500： FB FB FB FB FB FB FB FB FF FFF8881131E1580： FB FB FB FB ================================================================== [1]：
    https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]： https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u （CVE-2026-45866）

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

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

  - erofs：修复尾部 dirents 的越界 nameoff 处理目前，我们已具备 nameoff 的边界检查，但是尾部 dirents 很特殊，因为 namelens 是通过未经检查 nameoffs 的 strnlen（） 计算得出。如果构建的 EROFS 具有 nameoff >= maxsize 的尾部 dirent，则 maxsize - nameoff 可能下溢，导致 strnlen（） 读取越过目录块。nameoff0 也应经过验证是否为 'sizeof（struct erofs_dirent）' 的倍数 [1]。[1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com （CVE-2026-46078）

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

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

  - dm mirror：修复 create_dirty_log（） 中的整数溢出 create_dirty_log（） 中的参数计数计算在针对 argc 进行验证之前执行“*args_used = 2 + param_count”。当用户通过设备映射程序表字符串提供接近UINT_MAX的param_count时，这个无符号的加法会回绕为一个小值，从而导致后续的“argc < *args_used”检查被绕过。溢出的param_count随后作为 argc 传递到 dm_dirty_log_create（），从而可能造成 argv 数组上的越界读取。通过在执行加法之前比较 param_count 和 argc - 2 来修复，遵循相同文件中的 parse_features（） 使用的相同模式。由于已经保证 argc >= 2，因此减法是安全的。
    (CVE-2026-46023)

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

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

  - FastNetMon Community Edition 及之前版本 1.2.9 的 BGP MP_REACH_NLRI IPv6 属性解码器中包含多个越界读取。src/bgp_protocol.cpp 中的函数 decode_mp_reach_ipv6（） 在第 156 行包含一个 TODO 注释，明确确认“我们应添加健全性检查，以避免在属性内存阻断后执行读取操作”。该函数在未验证是否存在足够数据的情况下将原始指针转换为结构类型（第 158 行），使用攻击者控制的 length_of_next_hop 字段确定 memcpy 大小（第 181 行），并通过取消引用从多个攻击者控制的偏移计算出的指针来计算prefix_length（第 189 行）。然后将prefix_length用于计算number_of_bytes_required_for_prefix，其变成 memcpy 长度（第 202 行），且未检查剩余缓冲区大小。（CVE-2026-48688）

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

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

  - udf：修复分区描述符附加簿记 挂载具有重复分区描述符的构建的 UDF 图像可触发 . handle_partition_descriptor part_descs_loc[]（） 按分区号去重条目，但附加的插槽从不记录 partnum。因此重复的分区描述符被反复附加，并且num_part_descs不断增长。一旦表已满，即使插入按num_part_descs索引，增长路径仍会从 partnum 调整分配大小。
    如果partnum已经与PART_DESC_ALLOC_STEP对齐，则ALIGN（partnum， step）可以保留旧容量，下一个附加写入超过表的末尾。将 partnum 存储在附加的插槽中，并将大小从下一个附加计数中增长，以便重复数据删除和容量跟踪遵循相同的模型。（CVE-2026-45991）

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

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

  - tpm：tpm_i2c_infineon：修复 get_burstcount（） 失败时的局部性泄漏 get_burstcount（） 可在超时时返回 -EBUSY。发生这种情况时，该函数会直接返回，而不释放在 tpm_tis_i2c_send（） 开头获取的局部性。使用 goto out_err 确保 get_burstcount（） 失败时的正确清理。（CVE-2026-45941）

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

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

  - 电源：电源：act8945a：修复 power_supply_changed（） 中的释放后使用 _before_ 请求 IRQ 的“devm_”变体用于分配/注册“power_supply”句柄的“devm_”变体意味着“power_supply”句柄将在中断处理程序之前_ 解除分配/取消注册（因为“devm_”自然会以反向分配顺序释放）。这意味着删除过程中存在争用条件，其中，中断可能恰好在释放了“power_supply”句柄后，*但是* 恰好在 IRQ 处理程序的相应取消注册运行之前触发。这将导致 IRQ 处理程序通过释放的“power_supply”句柄调用“power_supply_changed（）”。这通常会使系统崩溃或以其他方式静默地损坏内存... 请注意，在“probe（）”期间也可能发生类似的情况;_before_ 注册“power_supply”句柄时中断触发的可能性。然后，这将导致使用“power_supply_changed（）”中使用“power_supply”句柄 *uninitialized* 的糟糕情况。通过确保在注册“power_supply”句柄后 _ 请求 IRQ，修复了此 racy 释放后使用。（CVE-2026-45867）

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

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

  - netfilter：nf_tables：恢复重置路径中的commit_mutex使用情况 当具有“-m set”规则的 nft reset、ipset 列表和 iptables-nft 同时运行时，它会导致 commit_mutex、nfnl_subsys_ipset 和 nlk_cb_mutex 之间产生循环锁定依赖关系。以前的修补程序可确保同时运行单个重置处理程序，因此不再需要commit_mutex来防止此情况。（CVE-2026-45901）

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

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

  - crypto：atmel-tdes - 修复 DMA 同步方向 CPU 消耗 DMA 输出之前，必须与 dma_sync_single_for_cpu（） （dma_sync_single_for_device（） 同步 ->dma_addr_out。使用错误的方向可在不相干的平台上返回过时的缓存数据。（CVE-2026-46077）

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

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

  - gfs2：修复 iomap 内联数据写入路径中的释放后使用 iomap->inline_data 仍指向 dibh->b_data时，gfs2_iomap_begin（） 中通过 release_metapath（） 过早释放内联数据缓冲区头 （dibh）。当 iomap_write_end_inline（） 稍后尝试写入内联数据区域时，这会造成释放后使用。缺陷序列：1. gfs2_iomap_begin（） 调用 gfs2_meta_inode_buffer（） 以将 inode 元数据读入 dibh 2。设置 iomap->inline_data = dibh->b_data + sizeof（struct gfs2_dinode） 3.调用调用 brelse（dibh） 的 release_metapath（），将 refcount 降至 0 4。kswapd 回收页面（在 syzbot 报告中稍后 ~39 毫秒） 5.iomap_write_end_inline（） 尝试 memcpy（） 到 iomap->inline_data 6.KASAN 检测对已释放内存的释放后使用写入 通过将 dibh 存储在 iomap->private 中并使用 gfs2_iomap_begin（） 中的 get_bh（） 递增其引用计数进行修复。内联写入完成后，缓冲区随后会在 gfs2_iomap_end（） 中正确释放，从而确保页面在整个 iomap 操作中保持活动状态。注意：C 复制器无法解决此问题。此补丁基于对 KASAN 报告的分析，以及显示缓冲区头在使用前已释放的代码审查。[agruenba： 在 gfs2_iomap_begin（） 中获取缓冲区头引用以避免在 gfs2_iomap_get（） 和 gfs2_iomap_alloc（） 中发生泄漏。]（CVE-2026-45984）

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

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

  - xen-netback：拒绝来自客户机的零队列配置 恶意或有缺陷的 Xen 客户机可将 0 写入 xenbus 密钥 multi-queue-num-queues。后端中的 connect（） 函数仅验证上限 （requested_num_queues > xenvif_max_queues） 而非零，从而允许 requested_num_queues=0 到达 vzalloc（array_size（0， sizeof（struct xenvif_queue））），从而触发 WARN_ON_ONCE（！size）
    __vmalloc_node_range（）。在 panic_on_warn=1 的系统上，这允许客户机至主机拒绝服务。
    Xen 网络接口规范要求队列计数必须大于零。添加零检查以匹配 xen-blkback 中已有的验证，自添加多队列支持以来，xen-blkback 就已包含此防护。（CVE-2026-45890）

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

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

  - net：rds：修复复制错误时的 MR 清理 __rds_rdma_map（） 在 get_mr（） 成功后将 sg/pages 所有权传递给传输。如果在该时间点之后将生成的 Cookie 复制回用户空间失败，则在丢弃 MR 引用之前，错误路径不得再次释放这些资源。从 put_user（） 失败分支删除重复的解锁/释放，以便仅通过现有的最终清除路径处理 MR 拆卸。（CVE-2026-46053）

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

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

  - rxrpc：修复 RESPONSE 数据包的重新解密 如果 RESPONSE 数据包在处理过程中发生临时故障，它可能以部分解密状态结束，然后重新排队以进行重试。只需丢弃数据包即可修复此问题；我们将发送另一个 CHALLENGE 数据包，从而引发进一步的响应。
    同样，如果在生成 RESPONSE 时收到错误，则丢弃传入的 CHALLENGE 数据包；服务器将发送另一个 CHALLENGE。（CVE-2026-45988）

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

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

  - btrfs：修复 btrfs_quota_enable（） 中找不到 ref 密钥时的无效叶访问 如果 btrfs_search_slot_for_read（） 返回 1，则表示未找到任何大于或等于所要求密钥的密钥的密钥，这表示我们已到达树的末尾，因此路径无效。如果发生这种情况，我们需要跳出循环并停止，而不是继续并访问无效的路径。
    (CVE-2026-45974)

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

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

  - ipvs：在 dev 宕机时不保持dest_dst netdev 通知程序 ip_vs_dst_event（） 和使用即将宕机的 dev 缓存 dst 的代码之间存在争用。由于可在处理程序完成后通知已关闭设备的 FIB，因此有可能在未删除 dest 之前，返回有效路由并在泄露的 dev 引用中重新缓存。要防止在处理程序丢弃旧dest_dst之后立即将新附加到 dest，请添加 netif_running（） 检查以确保通知程序处理程序当前并未针对正在关闭的设备运行。（CVE-2026-45917）

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

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

  - power：supply：bq25980：修复 power_supply_changed（） 中的释放后使用 _before_ 请求 IRQ 的“devm_”变体用于分配/注册“power_supply”句柄的“devm_”变体意味着“power_supply”句柄将在中断处理程序之前 _ 解除分配/取消注册（因为“devm_”自然会以反向分配顺序解除分配）。这意味着删除过程中存在争用条件，其中，中断可能恰好在释放了“power_supply”句柄后，*但是* 恰好在 IRQ 处理程序的相应取消注册运行之前触发。这将导致 IRQ 处理程序通过释放的“power_supply”句柄调用“power_supply_changed（）”。这通常会使系统崩溃或以其他方式静默地损坏内存... 请注意，在“probe（）”期间也可能发生类似的情况;_before_ 注册“power_supply”句柄时中断触发的可能性。然后，这将导致使用“power_supply_changed（）”中使用“power_supply”句柄 *uninitialized* 的糟糕情况。通过确保在注册“power_supply”句柄后 _ 请求 IRQ，修复了此 racy 释放后使用。（CVE-2026-45879）

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

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

  - rcu：修复由于 softirq 提交 5f5fa7ea89dc 导致的 rcu_read_unlock（） 死循环（rcu：不在 __rcu_read_unlock（）） 中使用负嵌套深度）会从 __rcu_read_unlock（） 删除递归保护代码。因此，我们在启用 ftrace 的情况下，可在 raise_softirq_irqoff（） 中调用死循环，如下所示： 警告： CPU：0 PID：在 kernel/trace/trace.c：3021 中的 0 __ftrace_trace_stack.constprop.0+0x172/0x180 模块链接于：
    my_irq_work（O） CPU：0 UID：0 PID：0 通信：swapper/0 受感染：G O 6.18.0-rc7-dirty #23 PREEMPT（full） 受感染：[O]=OOT_MODULE 硬件名称：QEMU Standard PC （i440FX + PIIX，1996 年），BIOS 1.15.0-1 2014 年 4 月 1 日 RIP：0010：__ftrace_trace_stack.constprop.0+0x172/0x180 RSP：0018：ffffc900000034a8 EFLAGS：00010002 RAX：
    00000000000000000 RBX： 0000000000000004 RCX： 00000000000000000 RDX： 0000000000000003 RSI： ffffffff826d7b87 RDI： ffffffff826e9329 RBP： 0000000000090009 R08： 0000000000000005 R09： ffffffff82afbc4c R10：
    0000000000000008 R11：00000000000011d7a R12：0000000000000000 R13：ffff888003874100 R14：0000000000000003 R15：ffff8880038c1054 FS：000000000000000（0000） GS：ffff8880fa8ea000（0000） knlGS：000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：000055b31fa7f540 CR3：00000000078f4005 CR4：0000000000770ef0 PKRU：55555554调用跟踪： <IRQ> trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0
    __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70
    __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0
    __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70
    __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0
    __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70
    __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 __is_insn_slot_addr+0x54/0x70 kernel_text_address+0x48/0xc0 __kernel_text_address+0xd/0x40 unwind_get_return_address+0x1e/0x40 arch_stack_walk+0x9c/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 __raise_softirq_irqoff+0x61/0x80
    __flush_smp_call_function_queue+0x115/0x420 __sysvec_call_function_single+0x17/0xb0 sysvec_call_function_single+0x8c/0xc0 </IRQ> 提交 b41642c87716（rcu：修复因 IRQ 工作导致的 rcu_read_unlock（） 死循环）通过在调用 irq_work_queue_on（） 之前设置标记，修复了 IRQ 工作的 rcu_read_unlock_special（） 中的无限循环。通过在调用 raise_softirq_irqoff（） 之前设置相同的标记来修复此问题，并将该标记重命名为 defer_qs_pending 以更常见。（CVE-2026-45957）

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

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

  - crypto：nx - 修复 nx842_crypto_{alloc，free} 中的反弹缓冲区泄漏_ctx 使用 BOUNCE_BUFFER_ORDER 通过 __get_free_pages（） 分配反弹缓冲区（顺序 2 = 4 页），但分配错误路径和 nx842_crypto_free_ctx（） 都使用 free_page（） 释放缓冲区。请改用具有匹配顺序的 free_pages（）。（CVE-2026-46068）

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

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

  - netfilter：nft_counter：使用旋转锁序列化重置 添加全局静态旋转锁以序列化计数器提取+重置操作，从而防止并发转储和重置欠载运行值。在获取总数之前进行锁定，以便两个并行重置不能同时读取相同的计数器值，然后都减去它们。为简单起见，使用全局锁，因为重置不频繁。如果这成为瓶颈，稍后可以用每网锁替换。（CVE-2026-45897）

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

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

  - FastNetMon Community Edition through 在 1.2.9 MikroTik 路由器集成插件中包含一个操作系统命令注入漏洞。src/mikrotik_plugin/fastnetmon_mikrotik.php （行 107-108） 中的 _log（） 函数通过将参数直接串联 $msg 到 exec（） 调用中来构造 shell 命令：
    exec（echo 'date' \- {FASTNETMON] - . $msg . \ >> . $FILE_LOG_TMP）。这在模式上与 Juniper 插件漏洞相同。$msg该变量包含来自命令行参数的未审查的攻击数据。能够影响 argv[] 值的攻击者可注入任意 shell 命令。修复方法是将 exec（） 替换为 file_put_contents（） 或使用 escapeshellarg（）。（CVE-2026-48695）

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

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

  - erofs：修复 z_erofs_lz4_handle_overlap（） 中未签名的下溢 某些构建的图像可具有非法 （！partial_decoding & m_llen < m_plen） 盘区，LZ4 就地解压缩路径可能被错误命中，但无法正确处理（outpages < inpages）： outpages - inpages 封装为大值，后续的 rq->out[] 访问读取越过 decompressed_pages 数组。但是，这些构建的情况可在正常 LZ4 非原位路径中正确导致损坏报告。让我们添加一个额外的检查来修复此问题以进行向后移植。可重现的图像（base64 编码的 gzipped blob）：
    H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6 FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1 （CVE-2026-45999）

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

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

  - KVM：SVM：添加缺少的 LBR MSR 保存/还原处理 MSR_IA32_DEBUGCTLMSR 和 LBR MSR 目前未由 KVM_GET_MSR_INDEX_LIST 枚举，且无法通过 KVM_SET_MSRS 设置 LBR MSR。因此，保存/还原完全中断。通过将 MSR 添加到 msrs_to_save_base 并允许在启用了 LBR 虚拟化时仅从用户空间写入 LBR MSR（因为它们是只读 MSR），修复了此问题。此外，要在 L2 运行时正确还原 L1 的 LBR，请确保从 svm_copy_vmrun_state（） 中捕获的 VMCB01 保存区域复制 LBR。请注意，对于 VMX，这还修复了未将 MSR_IA32_DEBUGCTLMSR 报告为 MSR 以进行保存/还原的缺陷。注意 #2，多报 Intel 上的MSR_IA32_LASTxxx是可以的，因为 KVM 已经处理了不受支持的读取和写入，这要归功于提交 b5e2fec0ebc3（KVM：忽略无任何效果的 DEBUGCTL MSR）（kvm_do_msr_access（） 会将不受支持的用户空间写入转换为 nop）。[sean：使用 LBRV 检查进行防护，按摩变更日志]（CVE-2026-46014）

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

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

  - cpuidle：当只有一种空闲状态可用时跳过调控器 在某些平台（没有 power-mgt DT 节点的 PowerNV 系统）中，cpuidle 可能仅注册一个空闲状态。如果该单个状态是轮询状态（状态 0），则阶梯调控器可能会错误地将状态 1 视为第一个可用状态并传递越界索引。这可导致调用 NULL enter 回调，最终导致系统崩溃。[ 13.342636] cpuidle-powernv：仅贪睡可用 [ 13.351854] 错误指令地址：0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 通过在 cpuidle_select（） 中添加 bail-out（） 来修复此问题，该 bail-out 在 state_count <= 1 时直接返回状态 0，绕过调速器并保持刻度运行。（CVE-2026-45968）

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

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

  - FastNetMon 社区版通过 1.2.9 在数据包捕获缓冲区分配中包含整数溢出漏洞。在 src/packet_storage.hpp 中，allocate_buffer（） 函数使用无符号 int（32 位）算术将memory_size_in_bytes计算为“buffer_size_in_packets * （max_captured_packet_size + sizeof（fastnetmon_pcap_pkthdr_t）） + sizeof（fastnetmon_pcap_file_header_t）”。max_captured_packet_size=1500 且 sizeof（fastnetmon_pcap_pkthdr_t）=16 时，每个数据包大约需要 1516 个字节。如果buffer_size_in_packets超过大约 2,832,542，乘法，则乘法溢出，导致分配比预期小得多。随后的 write_packet（） 调用会写入超出分配的缓冲区，从而导致堆损坏。buffer_size_in_packets值派生自 ban_details_records_count 配置参数，该参数使用 atoi（） 进行解析，不进行溢出检查。（CVE-2026-48690）

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

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

  - 恢复 hwmon：（ibmpex） 修复高/低存储中的释放后使用 这会恢复提交 6946c726c3f4c36f0f049e6f97e88c510b15f65d。Jean Delvare 指出，此修补程序并未完全解决所报告的问题，其实际上引入了（新的）争用条件，而且实际上可能一开始就不需要它。各种人工智能评论都同意这一点。特定且相关的 AI 反馈：此重新排序会将驱动程序数据设置为 NULL，然后再删除以下循环中的传感器属性。ibmpex_show_sensor（） 通过 dev_get_drvdata（） 检索此驱动程序数据，但在取消引用该数据以访问 data->sensors[] 之前不检查其是否为空。如果用户空间进程在此删除函数运行时读取传感器文件（如 temp1_input），它是否会与此处的 dev_set_drvdata（...， NULL） 调用争用并在 ibmpex_show_sensor（） 中崩溃？在清除驱动程序数据之前保留调用 device_remove_file（） 的原始顺序会更安全吗？device_remove_file（） 应等待任何活动 sysfs 回调完成，这可能已经阻止此修补程序想要修复的释放后使用。恢复有问题的修补程序。如果能够证明最初报告的所谓争用条件确实存在，则可随时通过完整的补丁重新引入此问题。（CVE-2026-45914）

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

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

  - erofs：修复 ztailpacking pclusters 的内联数据读取失败 ztailpacking pclusters 的压缩作品集必须有效，才能将这些 pcluster 添加到 I/O 链。否则，z_erofs_decompress_pcluster（） 可能会假设其已经有效，然后触发空指针取消引用。它有点难以重现，因为内联数据与压缩索引的末尾位于同一块中，压缩索引通常在之前读取。但是，如果在 read_mapping_folio（） 运行时到达致命信号，仍可能发生这种情况，如下所示： erofs： （设备 dm-1）：
    z_erofs_pcluster_begin：无法获取内联数据 -4 无法处理虚拟地址0000000000000008的内核空指针取消引用...PC：z_erofs_decompress_queue+0x4c8/0xa14 LR：
    z_erofs_decompress_queue+0x160/0xa14 SP：ffffffc08b3eb3a0 x29： ffffffc08b3eb570 x28： ffffffc08b3eb418 x27： 0000000000001000 x26： ffffff8086ebdbb8 x25： ffffff8086ebdbb8 x24： 0000000000000001 x23：
    0000000000000008 x22： 00000000fffffffb x21： dead000000000700 x20： 00000000000015e7： ffffff808babb400 x18： ffffffc089edc098 x17： 00000000c006287d x16： 00000000c006287d x15： 0000000000000004 x14：
    ffffff80ba8f8000 x13： 0000000000000004 x12： 00000006589a77c9 x11： 0000000000000015 x10： 0000000000000000 x9 ： 00000000000000000 x8 ： 0000000000000000 x7 ： 000000000000000 x6 ： 000000000000003f x5：
    0000000000000040 x4 ： fffffffffffffffe0 x3 ： 0000000000000020 x2 ： 0000000000000008 x1 ： 00000000000000000 x0 ： 000000000000000000 调用跟踪：z_erofs_decompress_queue+0x4c8/0xa14 z_erofs_runqueue+0x908/0x97c z_erofs_read_folio+0x128/0x228 filemap_read_folio+0x68/0x128 filemap_get_pages+0x44c/0x8b4 filemap_read+0x12c/0x5b8 generic_file_read_iter+0x4c/0x15c do_iter_readv_writev+0x188/0x1e0 vfs_iter_read+0xac/0x1a4 backing_file_read_iter+0x170/0x34c ovl_read_iter+0xf0/0x140 vfs_读取+0x28c/0x344 ksys_read+0x80/0xf0 __arm64_sys_read+0x24/0x34 invoke_syscall+0x60/0x114 el0_svc_common+0x88/0xe4 do_el0_svc+0x24/0x30 el0_svc+0x40/0xa8 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1bc/0x1c0 通过在向 I/O 链分配和添加 pcluster 之前读取内联数据，来修复此问题。（CVE-2026-45943）

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

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

  - RDMA/rxe：在 rxe_rcv rxe_rcv（） 中的 payload_size（） 之前验证 pad 和 ICRC 目前仅检查传入数据包是否至少在使用 header_size payload_size（） 之前是 （pkt） 字节。但是，payload_size（） 会从 pkt->paylen 中减去攻击者控制的 BTH pad 字段和RXE_ICRC_SIZE：
    payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad（pkt） - RXE_ICRC_SIZE 这意味着即使短数据包包含足够的固定标头字节，它仍然可以使 payload_size（） 下溢。仅要求 header_size（pkt） + RXE_ICRC_SIZE 也是不够的，因为具有伪造的非零 BTH 焊盘的数据包仍可保留 payload_size（） 负值并将下溢值传递给后续接收路径用户。根据 payload_size（） 要求的最小长度来验证 pkt->paylen，从而修复此问题：
    header_size（pkt） + bth_pad（pkt） + RXE_ICRC_SIZE。（CVE-2026-46043）

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

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

  - net：stmmac：修复启用拆分标头时的 oops 对于 GMAC4，启用拆分标头时，在某些极少数情况下，硬件不会用负载填充第一个描述符的 buf2。因此，如果 buf2 不是最后一个描述符，就不能假设它始终完全填充。否则，将会错误计算第二个描述符的 buf2 长度并造成 oops：无法处理虚拟地址 ffff00019246bfc0 上的内核分页请求...x2：0000000000000040 x1：ffff00019246bfc0 x0：ffff00009246c000 调用跟踪：
    dcache_inval_poc+0x28/0x58 （P） dma_direct_sync_single_for_cpu+0x38/0x6c
    __dma_sync_single_for_cpu+0x34/0x6c stmmac_napi_poll_rx+0x8f0/0xb60 __napi_poll.constprop.0+0x30/0x144 net_rx_action+0x160/0x274 handle_softirqs+0x1b8/0x1fc ... 为修复此问题，RDES3 寄存器中的 PL 位字段将用于所有描述符，无论它是否为最后一个描述符。CVE-2026-45940

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

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

  - net/smc：避免 smc_clc_wait_msg 中的过早 lgr 访问 在连接与链接组关联之前，握手仍处于早期阶段时可接收到 CLC 拒绝。smc_clc_wait_msg（） 中的拒绝处理会更新首次联系拒绝的链路组级别同步状态，但该状态仅在链路组设置完成后才存在。相应地保护链接组更新，并保持每个套接字对等机诊断处理不变。这样可保留已建立的链路组上下文的现有sync_err处理，并避免在可用之前接触链路组状态。（CVE-2026-46027）

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

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

  - sched/rt：跳过目前在 rto_next_cpu（） 中执行的 CPU 当托管 CPU 绑定的 RT 任务、非 CPU 绑定的 RT 任务，以及卡在内核空间的 CFS 任务时，CPU0 会过载。当其他 CPU 从 RT 任务切换到非 RT 任务时，将触发 RT 负载平衡 （LB）;启用 HAVE_RT_PUSH_IPI 后，它们会将 IPI 发送到 CPU0 以驱动rto_push_irq_work_func的执行。在 CPU0 上push_rt_task时，若 next_task->prio < rq->donor->prio，则 resched_curr（） 设置NEED_RESCHED，而推送操作完成后，CPU0 会调用 rto_next_cpu（）。由于在此情况下仅 CPU0 过载，理想情况下 rto_next_cpu（） 应返回 -1（无需更多 IPI）。但是，LB 期间调用 tell_cpu_to_push（） 的多个 CPU 会递增 rd->rto_loop_next。即使 rd->rto_cpu 设置为 -1，rd->rto_loop 和 rd->rto_loop_next 之间的不匹配也会强制 rto_next_cpu（） 从 -1 重新开始搜索。在 CPU0 保持过载状态（满足 rt_nr_migratory & rt_nr_total > 1）的情况下，系统会重新选择该 CPU0，导致 CPU0 自行排队irq_work，并反复发送自 IPI。只要 CPU0 保持过载状态且其他 CPU 运行 pull_rt_tasks（），它就会陷入无限自我 IPI 循环，从而由于连续自我中断而触发 CPU 硬锁定。触发场景如下：cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr（rq） pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc（rto_loop_next） rd->rto_loop ！= next rto_next_cpu irq_work_queue_on rto_push_irq_work_func 通过过滤 rto_next_cpu（） 中的发起 CPU 修复冗余 self-IPI。此解决方案已经过验证，可有效消除虚假的自我 IPI 并防止 CPU 硬锁定的情况。（CVE-2026-45919）

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

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

  - SUNRPC：修复错误路径中的 gss_auth kref 泄漏gss_alloc_msg提交 5940d1cf9f42 （SUNRPC：重新平衡 auth_gss.c 中的 kref） 添加了 kref_get（&gss_auth->kref） 调用以平衡在 gss_release_msg（） 中完成的 gss_put_auth（），但当 kstrdup_const（） 失败时忘记在错误路径中添加相应的 kref_put（）。如果service_name为非 NULL 且 kstrdup_const（） 失败，则该函数会跳至调用 put_pipe_version（） 和 kfree（gss_msg） 的 err_put_pipe_version，但从不释放gss_auth引用。这会导致 kref 泄漏，其中 gss_auth 结构永远不会得到释放。添加 gss_free_callback（） 的前向声明并调用 err_put_pipe_version 错误路径中的 kref_put（） 以正确释放之前的引用。（CVE-2026-45964）

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

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

  - xfrm：修复反向路径icmp_route_lookup ip_rt_bug争用 icmp_route_lookup（） 执行多种路由查找以找到发送 ICMP 错误消息的合适路由，并对 XFRM （IPsec） 策略进行特殊处理。查找顺序为：1. 首先，查找 ICMP 回复的输出路由 （dst = 原始来源） 2.
    传递策略检查 3 的 xfrm_lookup（）。如果阻断 （-EPERM） 或 dst 不是本地的，则输入反向路径 4。在反向路径中，调用 xfrm_decode_session_reverse（） 以获取fl4_dec，这将反转原始数据包的流（saddr<->daddr 交换） 5.如果 fl4_dec.saddr 为本地（我们是原始目标），则使用
    __ip_route_output_key（） 用于输出路由查找 6.如果 fl4_dec.saddr 不是本地的（我们是转发节点），则使用 ip_route_input（） 模拟反向数据包的输入路径 7。最后，通过具有XFRM_LOOKUP_ICMP标记的 xfrm_lookup（） 传递 rt2 该缺陷在步骤 6 中发生：以 fl4_dec.daddr（原始数据包的源）作为目标调用 ip_route_input（）。如果此地址在初始检查和 ip_route_input（） 调用之间变为本地地址（例如，由于并发 ip 地址添加），则 ip_route_input（） 将返回 dst.output 设置为 ip_rt_bug 的本地路由。此路由接着会用于 ICMP 输出，造成 dst_output（） 调用 ip_rt_bug（），进而触发WARN_ON：------------[ cut here ]------------ 警告：
    net/ipv4/route.c：1275 at ip_rt_bug+0x21/0x30， CPU#1 调用跟踪： <TASK> ip_push_pending_frames+0x202/0x240 icmp_push_reply+0x30d/0x430 __icmp_send+0x1149/0x24f0 ip_options_compile+0xa2/0xd0 ip_rcv_finish_core+0x829/0x1950 ip_rcv+0x2d7/0x420 __netif_receive_skb_one_core+0x185/0x1f0 netif_receive_skb+0x90/0x450 tun_get_user+0x3413/0x3fb0 tun_chr_write_iter+0xe4/0x220 ... 通过在 ip_route_input（） 之后检查 rt2->rt_type 来修复此问题。如果RTN_LOCAL，则无法将路由用于输出，因此将其视为错误。复制程序需要修改内核来扩大争用窗口，因此不适合将其用作自我测试。它可在以下网址获得：
    https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81 (CVE-2026-45905)

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

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

  - pinctrl：single：修复 pcs_add_gpio_func（） 中的 refcount 泄漏 of_parse_phandle_with_args（） 返回一个device_node指针（其 refcount 在 gpiospec.np 中递增）。循环遍历所有 phandle，但从不释放引用，从而在每次迭代时造成 refcount 泄漏。添加 of_node_put（） 调用，以便在提取所需参数后释放引用，并在 devm_kzalloc（） 失败时在错误路径中释放引用。此缺陷由我们的静态分析工具检测到，并通过我的代码审查进行验证。（CVE-2026-45868）

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

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

  - ALSA：aloop：修复格式更改停止期间的对等机运行时 UAF loopback_check_format（） 可能会在使用不再匹配正在运行的捕获流的参数开始时停止捕获端。提交 826af7fa62e3（ALSA：aloop：修复 PCM 触发时的 racy 访问）将对等机查找移动到 cable->lock 下，但实际的 snd_pcm_stop（） 在放置该锁定之后仍会运行。并发关闭可从 cable->streams[] 清除捕获条目，并在回放触发路径仍保留过时对等机子流指针时分离或释放其运行时。在终止 cable->lock 之前，保留每根电缆的传输中对等机停止计数，并使 free_cable（） 在分离运行时之前等待这些停止。这样会保留现有行为，同时明确对等运行时生命周期。（CVE-2026-46090）

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

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

  - ext4：执行PARTIAL_VALID1清零后终止盘区缓存 拆分中间的未写入盘区，并在已设置 EXT4_EXT_MAY_ZEROOUT 和 EXT4_EXT_DATA_VALID2 标记的情况下将其转换为在 ext4_split_extent（） 中初始化的盘区时，可能会留下过时的未写入盘区。假设我们有一个未写入的文件，并且中间缓冲了写入，但未启用dioread_nolock，它会将区块作为写入的范围分配。0 A B N [UUUUUUUUUUUU] 磁盘盘区 U：未写入盘区 [UUUUUUUUUUUUU] 盘区状态树 [--DDDDDDDD--] D：有效数据 |<- ->|---->需要初始化此范围ext4_split_extent（） 首先尝试拆分具有 EXT4_EXT_DATA_PARTIAL_VALID1 和 EXT4_EXT_MAY_ZEROOUT 标记的 B 处的此盘区，但 ext4_split_extent_at（） 由于暂时空间不足而无法拆分此盘区。它将 B 到 N 归零，并将整个盘区保留为未写入。0 A B N [UUUUUUUUUUUUU] 磁盘上的盘区 [UUUUUUUUUUU] 盘区状态树 [--DDDDDDDDZZ] Z： 归零的数据 ext4_split_extent（） 然后尝试在设置EXT4_EXT_DATA_VALID2标记的 A 处拆分此盘区。这一次，它成功拆分并留下从 A 到 N 的写入范围 A B N [UUWWWWWWWWWW] 磁盘上的范围 W：写入范围 [UUUUUUUUUUUU] 范围状态树 [--DDDDDDDDZZ] 最后 ext4_map_create_blocks（） 仅将范围 A 到 B 插入范围状态树，并在状态树中留下一个过时的未写入范围。0 A B N [UUWWWWWWW] 磁盘上的盘区 W：写入盘区 [UUWWWWWWWWUU] 盘区状态树 [--DDDDDDDDZZ] 修复此问题，在清零第二部分之后始终缓存盘区状态条目。（CVE-2026-45892）

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

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

  - crypto：ccree - 修复 cc_mac_digest（） 中的内存泄漏 如果 cc_map_hash_request_final（） 无法阻止潜在的内存泄漏，则添加 cc_unmap_result（）。（CVE-2026-45986）

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

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

  - FastNetMon Community Edition through 1.2.9 存在一个缓冲区溢出，这是一个与 CVE-2026-48686 和 CVE-2026-48689不同的漏洞。（CVE-2026-48696）

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

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

  - md/raid10：修复检查操作和 nowait 请求的死锁 运行数组检查时，它将提高障碍，此时正常请求将被阻断并增加 nr_pending 值以指示 wait_barrier（） 中存在待定工作。NOWAIT 请求不会阻断，因此会立即返回错误，此外也不会增加 wait_barrier（） 中的nr_pending。上游变更提交 43806c3d5b9b（raid10：清理 raid10_make_request 处的内存泄漏）添加了对 raid_end_bio_io（） 的调用以修复 NOWAIT 请求遇到此条件时的内存泄漏。raid_end_bio_io（） 最终会调用 allow_barrier（），且它会无条件执行 atomic_dec_and_test（&conf->nr_pending），即使 NOWAIT 的情况中未发生相应的递增nr_pending亦然。如果在应用程序对相同数组执行 nowait IO 时启动检查操作，即可轻松查看此情况。这会由于值下溢而导致死锁状态nr_pending因此 md 重新同步线程会在等待 nr_pending == 0 时卡住。遇到此条件时数组的 r10conf 状态输出：崩溃> struct r10conf barrier = 1， nr_pending = { counter = -41 }， nr_waiting = 15， nr_queued = 0， 等待 raise_barrier（） 的线程和其他请求卡住在 wait_barrier（） 上的md_sync线程示例： md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040：2+flush-253：4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>]
    __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>]
    __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 （CVE-2026-46050）

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

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

  - s390/cio：修复设置 DMA 掩码之前css_alloc_subchannel（）“css_alloc_subchannel（）”调用“device_initialize（）”中的设备生命周期处理。如果“dma_set_coherent_mask（）”或“dma_set_mask（）”失败，错误路径会直接释放子通道结构，从而绕过设备型号引用计数。调用 'device_initialize（）' 之后，必须通过 'put_device（）' 释放嵌入式结构设备，允许释放回调释放容器结构。通过丢弃带有“put_device（）”的初始设备引用而非直接调用“kfree（）”来修复错误路径。这可确保正确的设备生命周期处理，并避免潜在的释放后使用或双重释放问题。
    (CVE-2026-45981)

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

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

  - ALSA：ctxfi：向 S/PDIF 的默认 RSR 添加回退 spdif_passthru_playback_get_resources（） 使用 atc->pll_rate 作为 MSR 计算循环的 RSR。但是，pll_rate仅在 atc_pll_init（） 中更新，而没有在 hw_pll_init（） 中更新，因此它在卡片初始化之后仍为 0。当 spdif_passthru_playback_setup（） 跳过 32000 Hz 的 atc_pll_init（） 时，（rsr * desc.msr） 始终变为 0，从而导致循环无限旋转。添加回退以在 atc->为 0 时使用 atc->pll_rate rsr。这反映了硬件状态，因为 hw_card_init（） 已将 PLL 配置为默认 RSR。（CVE-2026-46049）

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

ID	名称	严重性
317291	Linux Distros 未修补的漏洞：CVE-2026-24197	medium
317290	Linux Distros 未修补的漏洞：CVE-2025-33221	medium
317281	Linux Distros 未修补的漏洞：CVE-2026-45915	medium
317280	Linux Distros 未修补的漏洞：CVE-2026-46069	high
317279	Linux Distros 未修补的漏洞：CVE-2026-45893	high
317278	Linux Distros 未修补的漏洞：CVE-2026-45858	medium
317277	Linux Distros 未修补的漏洞：CVE-2026-45857	medium
317276	Linux Distros 未修补的漏洞：CVE-2026-46103	medium
317275	Linux Distros 未修补的漏洞：CVE-2026-46015	high
317274	Linux Distros 未修补的漏洞：CVE-2026-45936	high
317273	Linux Distros 未修补的漏洞：CVE-2026-45866	high
317272	Linux Distros 未修补的漏洞：CVE-2026-46078	high
317271	Linux Distros 未修补的漏洞：CVE-2026-46023	medium
317270	Linux Distros 未修补的漏洞：CVE-2026-48688	high
317269	Linux Distros 未修补的漏洞：CVE-2026-45991	high
317268	Linux Distros 未修补的漏洞：CVE-2026-45941	medium
317267	Linux Distros 未修补的漏洞：CVE-2026-45867	high
317266	Linux Distros 未修补的漏洞：CVE-2026-45901	medium
317265	Linux Distros 未修补的漏洞：CVE-2026-46077	medium
317264	Linux Distros 未修补的漏洞：CVE-2026-45984	high
317263	Linux Distros 未修补的漏洞：CVE-2026-45890	medium
317262	Linux Distros 未修补的漏洞：CVE-2026-46053	high
317261	Linux Distros 未修补的漏洞：CVE-2026-45988	critical
317260	Linux Distros 未修补的漏洞：CVE-2026-45974	medium
317259	Linux Distros 未修补的漏洞：CVE-2026-45917	medium
317258	Linux Distros 未修补的漏洞：CVE-2026-45879	high
317257	Linux Distros 未修补的漏洞：CVE-2026-45957	high
317256	Linux Distros 未修补的漏洞：CVE-2026-46068	high
317255	Linux Distros 未修补的漏洞：CVE-2026-45897	medium
317254	Linux Distros 未修补的漏洞：CVE-2026-48695	high
317253	Linux Distros 未修补的漏洞：CVE-2026-45999	high
317252	Linux Distros 未修补的漏洞：CVE-2026-46014	medium
317251	Linux Distros 未修补的漏洞：CVE-2026-45968	medium
317250	Linux Distros 未修补的漏洞：CVE-2026-48690	high
317249	Linux Distros 未修补的漏洞：CVE-2026-45914	high
317248	Linux Distros 未修补的漏洞：CVE-2026-45943	high
317247	Linux Distros 未修补的漏洞：CVE-2026-46043	critical
317246	Linux Distros 未修补的漏洞：CVE-2026-45940	medium
317245	Linux Distros 未修补的漏洞：CVE-2026-46027	high
317244	Linux Distros 未修补的漏洞：CVE-2026-45919	medium
317243	Linux Distros 未修补的漏洞：CVE-2026-45964	medium
317242	Linux Distros 未修补的漏洞：CVE-2026-45905	medium
317241	Linux Distros 未修补的漏洞：CVE-2026-45868	medium
317240	Linux Distros 未修补的漏洞：CVE-2026-46090	high
317239	Linux Distros 未修补的漏洞：CVE-2026-45892	medium
317238	Linux Distros 未修补的漏洞：CVE-2026-45986	medium
317237	Linux Distros 未修补的漏洞：CVE-2026-48696	medium
317236	Linux Distros 未修补的漏洞：CVE-2026-46050	medium
317235	Linux Distros 未修补的漏洞：CVE-2026-45981	medium
317234	Linux Distros 未修补的漏洞：CVE-2026-46049	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

high

high

medium

medium

medium

high

high

high

high

medium

high

high

medium

high

medium

medium

high

medium

high

critical

medium

medium

high

high

high

medium

high

high

medium

medium

high

high

high

critical

medium

high

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

medium