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

  - bpf：保护 conntrack opts 错误写入 conntrack 查找和分配 kfuncs 采用一个 opts 指针以及一个 opts__sz 参数。校验器只检查 opts__sz 描述的内存范围，但只要内部查找或分配帮助程序返回错误，封装程序就会无条件地写入 opts->error。如果无效大小小于 opts->error 结尾，则该写入可能会超出校验器检查的范围。持续为无效参数返回 NULL，但只有在提供的大小包含字段时才通过 opts->error 报告错误。这样保留了针对受支持的 12 字节和 16 字节布局，以及其他仍包含 opts->error 的无效大小的错误报告。（CVE-2026-72423）

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

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

  - mmc：vub300：修复探查故障时的释放后使用 vub300 驱动程序使用 vub300->kref 管理其控制器状态，在最后一个引用丢失时 vub300_delete（） 释放 mmc 主机。但是，布防非活动定时器之后的探测错误路径仍会绕过该生命周期规则，如果 mmc_add_host（） 失败，则会直接转向 mmc_free_host（）。争用时段介于布防不活动计时器与达到探测错误之间 mmc_add_host（） 失败后展开：探测线程定时器/工作队列 ------------ --------------- kref_init（&vub300->kref） ref = 1 kref_get（&vub300->kref） ref = 2，计时器 ref add_timer（inactivity_timer） 在一秒钟后触发 | |比赛窗口 |<----------------------------------------------------> |mmc_add_host（mmc） 非活动定时器触发 vub300_queue_dead_work（） kref_get（） ref = 3 queue_work（deadwork） mmc_add_host（） 失败 timer_delete_sync（） mmc_free_host（mmc） 释放 vub300 死工作运行释放后使用 不活动超时为一秒，因此这需要 mmc_add_host（） 失败并耗时超过一秒。实际中不太可能发生此情况，但错误路径仍然是错误的。timer_delete_sync（） 仅等待定时器回调本身。它不会刷新回调可能已经排队的死工作。因此，在探测错误路径直接释放备份 mmc 主机（包括 vub300 存储）时，排队的死工作仍可保留 kref。使用与断开连接相同的生命周期机制修复此问题。清除 vub300->interface 以便计时器回调和任何排队的死工作提早返回并丢弃其引用，然后丢弃初始探测引用并返回而不err_free_host。（CVE-2026-72073）

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

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

  - vxlan：修复 vxlan_gro_prepare_receive（） 中潜在的 null-ptr-deref。在 vxlan_gro_prepare_receive（） 运行时，udp_tunnel_sock_release（） 可将 sk->sk_user_data 设置为空。让我们检查 rcu_dereference_sk_user_data（） 在 skb_gro_remcsum_init（） 之后是否为空。（CVE-2026-74406）

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

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

  - cifs：验证 DFS 参照字符串偏移 parse_dfs_referrals（） 验证响应头和参照数组是否适合接收到的缓冲区，但每个参照也包含服务器提供的字符串偏移。这些偏移用于计算 DfsPath 和 NetworkAddress 字符串指针，而不检查它们是否仍指向响应缓冲区内部。因此，畸形参照可使计算的指针超过缓冲区的末尾。产生的负max_len随后传递到 cifs_strndup_from_utf16（），非 Unicode 路径将其作为size_t转发到 kstrndup（），从而允许 strnlen（） 越界读取。在派生字符串指针之前验证每个字符串偏移。
    (CVE-2026-72318)

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

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

  - net/mlx5e：修复 HV VHCA 统计数据代理注册争用 mlx5e_hv_vhca_stats_create（） 通过 mlx5_hv_vhca_agent_create（） 注册统计数据代理。帮助程序在 agents_lock 下的 hv_vhca->agents[type] 中发布代理，并立即在 HV VHCA 工作队列上计划异步控制失效，然后再返回 mlx5e。异步无效调用控制代理的无效回调，其会读取管理程序控制块并将命令转发到 mlx5e_hv_vhca_stats_control（）。该回调可以：- 调用 cancel_delayed_work_sync（&priv->stats_agent.work） 或 - 调用 queue_delayed_work（priv->wq， &sagent->work， sagent->delay）。但是，delayed_work 和 priv->stats_agent.agent 仅在 mlx5_hv_vhca_agent_create（） 返回到 mlx5e 后才会被初始化： agent = mlx5_hv_vhca_agent_create（...）;/* 发布 + 无效 */ ...priv->stats_agent.agent = 代理;/* 太晚 */ INIT_DELAYED_WORK（&priv->stats_agent.work， ...）;/* 太晚 */ 如果异步控制路径在上述两个分配之前运行，则它可以：- 在 timer.function 为 NULL 的未初始化delayed_work上操作。queue_delayed_work（） 会无条件调用 add_timer（），因此当定时器到期时，定时器 softirq 会调用空函数指针。- 稍后在定时器已在定时器轮中排队时通过 INIT_DELAYED_WORK（） 重新初始化该定时器，从而损坏 hlist（当上一个存储段节点仍指向此条目时，entry.pprev 已清除）。- 当工作线程最终运行时，mlx5e_hv_vhca_stats_work（） 会读取 sagent->agent （NULL） 并在 mlx5_hv_vhca_agent_write（） 中取消引用它。通过以下方式修复此问题：- 在调用 mlx5_hv_vhca_agent_create（） 之前初始化 priv->stats_agent.work，以便在控制回调观察到该工作时始终处于有效状态。
    - 将 struct mlx5_hv_vhca_agent **ctx_update out 参数添加到 mlx5_hv_vhca_agent_create（）。帮助程序在发布到 hv_vhca->agents[] 并触发agents_update流之前将代理指针写入 *ctx_update，因此之后从该流调用的任何回调都已经看到有效的 priv->stats_agent.agent。这避免了控制回调参与代理初始化。
    同时，通过 READ_ONCE（）/WRITE_ONCE（） 访问 priv->stats_agent.agent，以通过工作线程进行跨 CPU 访问，并清除 agent_create（） 失败路径中的 priv->stats_agent.buf。（CVE-2026-72342）

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

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

  - net/9p：修复 p9_client_rpc 中发生致命信号时出现无限循环 以类型 P9_TFLUSH 调用 p9_client_rpc（） 且传输没有对等项（例如，由没有 9p 服务器的管道备份的 fd 传输）时，致命信号会造成无限循环：再次：err = io_wait_event_killable（req->wq， ...） /* SIGKILL 唤醒任务， 返回 -ERESTARTSYS */ if （err == -ERESTARTSYS &&; c->status == Connected &&; type == P9_TFLUSH） {sigpending = 1; clear_thread_flag（TIF_SIGPENDING）; goto again; } clear_thread_flag（） 在跳回 io_wait_event_killable（） 之前清除TIF_SIGPENDING。signal_pending_state（） 检查TIF_SIGPENDING，发现其为零，然后任务再次进入休眠状态。该任务只能在调用 signal_wake_up（） 并再次设置TIF_SIGPENDING的下一个信号传递时唤醒。当这种情况发生时，循环会重复，清除TIF_SIGPENDING，然后无限期地再次休眠。这在实践中由 coredump_wait（） 触发：当多线程进程中的线程导致 coredump（例如，通过来自 Syscall 用户分派的 SIGSYS）时，coredump_wait（） 会将 SIGKILL 发送到所有其他线程并等待它们调用 mm_release（）。如果其中一个线程在没有对等机的 fd 传输上在 p9_client_rpc（） 中被阻断，它将进入 P9_TFLUSH 循环并且永远不会调用 mm_release（），因此 coredump_wait（） 永远停止： INFO：task syz.0。18:676 被屏蔽超过 143 秒。未受感染 6.12.77+ #1 task：syz.0.18 state：D stack：27600 pid：676 tgid：673 ppid：630 flags：0x00000004 调用跟踪： <TASK> context_switch kernel/sched/core.c：5344 [内联]
    __schedule+0xcb4/0x5d50 kernel/sched/core.c：6724 __schedule_loop kernel/sched/core.c：6801 [内联] schedule+0xe5/0x350 kernel/sched/core.c：6816 schedule_timeout+0x253/0x290 kernel/time/timer.c：2593 do_wait_for_common kernel/sched/completion.c：95 [内联] __wait_for_common+0x409/0x600 kernel/sched/completion.c：116 wait_for_common kernel/sched/completion.c：127 [内联] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c：264 coredump_wait fs/coredump.c：448 [inline] do_coredump+0x854/0x4350 fs/coredump.c：629 get_signal+0x1425/0x2730 kernel/signal.c：2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c：337 exit_to_user_mode_loop kernel/entry/common.c：111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h：328 [inline]
    __syscall_exit_to_user_mode_work kernel/entry/common.c：207 [内联] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c：218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c：84 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 修复：清除 P9_TFLUSH 重试循环中的TIF_SIGPENDING前检查 fatal_signal_pending（）。此时 TIF_SIGPENDING 仍处于设置状态，因此 fatal_signal_pending（） 可正确工作。如果致命信号待定，请跳至recalc_sigpending以还原TIF_SIGPENDING并将 -ERESTARTSYS 返回给调用程序。回到 的稳定内核 5.4中也存在相同的缺陷。在这些内核上，父进程的第二个 SIGKILL（如 kill_and_wait（） 在超时后重试）会提前中断无限循环，从而导致僵尸进程和关闭延迟，而非永久的 D 状态挂起，但潜在的缺陷是一样的。由 Linux 验证中心 （linuxtesting.org） 与 syzkaller 一起发现。（CVE-2026-72166）

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

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

  - sunrpc：修复未初始化的 xprt_create_args 结构 在堆栈上分配 xprt_create_args 结构而不在 rpc_sysfs_xprt_switch_add_xprt_store（） 中进行初始化。虽然有些字段是手动填充的，但 srcaddr、bc_xps 和 flags 等关键字段包含未初始化的堆栈垃圾。这可导致：1. xs_setup_xprt（） 取消引用垃圾 srcaddr 时发生内核错误 2.srcaddr 指向敏感堆栈数据时的信息泄漏 3.若标志设置随机位则无法预测的行为 修复方法是将结构归零初始化，确保所有未使用的字段均为 NULL/0，进而防止传输设置代码对垃圾数据起作用。（CVE-2026-72150）

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

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

  - 已修复 Linux 内核中的下列漏洞：ntfs: add bounds check before accessing EA entries in ntfs_ea_lookup and ntfs_listxattr, this verifies that there is enough space in the EA entry before accessing the next_entry_offset field of the EA entry. (CVE-2026-72208)

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

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

  - md/raid1：修复写入失败时的writes_pending和屏障引用泄漏 raid1_make_request（） 在调用 raid1_write_request（） 之前通过 md_write_start（） 获取writes_pending引用。raid1_write_request（） 中的多个失败路径完成 bio 并在未到达正常写入完成路径的情况下返回，从而导致跳过相应的 md_write_end（）。使 raid1_write_request（） 返回指示写入请求是否已成功排队的状态。这允许 raid1_make_request（） 在 raid1_write_request（） 失败时调用 md_write_end（）。此外，如果 wait_blocked_rdev（） 在 wait_barrier（） 成功后失败，则不会释放相关的屏障引用。请在从该路径返回之前调用 allow_barrier（） 以保持屏障核算平衡。（CVE-2026-72440）

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

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

  - Bluetooth：6lowpan：保持 debugfs 控件之间的 L2CAP conn get_l2cap_conn（） 查找 hdev 保护下的 LE hci_conn，但随后在读取 hcon->l2cap_data 之前和 lowpan_control_write（） 稍后取消引用 conn->hcon 之前终止该保护。断开连接或设备关闭可中断该窗口中的相同 L2CAP 连接。有缺陷的情况涉及两条路径，每一列显示该路径中的顺序：6LoWPAN 控件写入：HCI 断开连接/设备关闭：1. get_l2cap_conn（） 找到 hcon 1。
    hci_disconn_cfm（） 调度和 hcon->l2cap_data。L2CAP 断开连接回调。2. get_l2cap_conn（） 丢弃 hdev 2.l2cap_conn_del（） 清除保护并返回 conn。hcon->l2cap_data 并终止 L2CAP 连接引用。3. lowpan_control_write（） 读作 3.hci_conn_del（） 删除并终止 conn->hcon。HCI 连接。当 hdev 仍处于锁定状态时引用与 l2cap_conn_hold_unless_zero（） 的 L2CAP 连接，并在 debugfs 命令最后一次使用 conn 后放弃该引用。这反映了现有的 L2CAP ACL 接收端切换，并在离开 hdev 保护之后保持连接可取消引用。导出现有帮助程序，以便bluetooth_6lowpan模块可以使用相同的生命周期基元。验证再现了此内核报告：缺陷：KASAN：lowpan_control_write+0x374/0x520 中的 slab-after-free 使用 有缺陷的地址属于位于 ffff888111b9d000 的对象，该对象属于大小为 1024 的缓存 kmalloc-1k 有缺陷的地址位于已释放的 1024 字节区域内的 0 字节处 [ffff888111b9d000、ffff888111b9d400） 读取大小为 8 调用跟踪：dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 lowpan_control_write+0x374/0x520 （net/bluetooth/6lowpan.c：1131）srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110
    __debugfs_file_get+0xf7/0x400 full_proxy_write+0x9e/0xd0 vfs_write+0x1b0/0x810 ksys_write+0xd2/0x170 dnotify_flush+0x32/0x220 do_syscall_64+0x115/0x6a0 （arch/x86/entry/syscall_64.c：87） entry_SYSCALL_64_after_hwframe+0x77/0x7f 按任务堆栈分配：kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 __kasan_kmalloc+0xaa/0xb0 l2cap_conn_add+0x45/0x520 l2cap_chan_connect+0xac6/0xd90 l2cap_sock_connect+0x216/0x350 __sys_连接+0x101/0x130
    __x64_sys_connect+0x40/0x50 do_syscall_64+0x115/0x6a0 （arch/x86/entry/syscall_64.c：87） entry_SYSCALL_64_after_hwframe+0x77/0x7f 按任务堆栈释放：kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 hci_conn_hash_flush+0xc0/0x140 hci_dev_close_sync+0x41a/0xb00 hci_dev_close+0x12f/0x160 hci_sock_ioctl+0x157/0x570 sock_do_ioctl+0xf7/0x210 sock_ioctl+0x32f/0x490 __x64_sys_ioctl+0xc7/0x110 do_syscall_64+0x115/0x6a0 （arch/x86/entry/syscall_64.c：87） entry_SYSCALL_64_after_hwframe+0x77/0x7f kasan_record_aux_stack+0xa7/0xc0 insert_work+0x32/0x100 __queue_work+0x262/0xa60 queue_work_on+0xad/0xb0 l2cap_connect_cfm+0x4ef/0x670 hci_le_remote_feat_complete_evt+0x247/0x430 hci_event_packet+0x360/0x6f0 hci_rx_work+0x2ae/0x7a0 process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 （CVE-2026-72336）

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

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

  - bpf：修复了 lru 锁定上的 NMI/tracepoint 重新进入死锁 NMI 和跟踪点 BPF 程序可重新进入 bpf_lru_pop_free（）/push_free（） 已经在相同 CPU 上持有的每个 CPU 或全局 LRU 锁定，即 AA 死锁。Lockdep 报告 &l->lock 上不一致的 {INITIAL USE} -> {IN-NMI} （syzbot c69a0a2c816716f1e0d5），并且 &loc_l->lock 上可能检测到递归锁定 （syzbot 18b26edb69b2e19f3b33）。之前基于 trylock 和 rqspinlock 的补丁（请参阅链接）因可靠性受到影响而被破坏。此修补程序将每个 LRU 锁定站点转换为rqspinlock_t并为某些故障窗口添加恢复路径以避免节点泄漏。故障恢复：- *_pop_free 顶层：返回 NULL;
    prealloc_lru_pop（） 已将其视为非自由元素 （-ENOMEM）。- 跨 CPU 窃取：跳过受害者的锁定loc_l，尝试下一个 CPU。- 窃取后本地锁定失败：将被盗节点发布到无锁的每 CPU free_llist;此 CPU 上的下一个弹出窗口会拾取它。- push_free失败：标记节点 pending_free=1。
    __local_list_flush（）、__local_list_pop_pending（） 从pending_list回收节点。
    __bpf_lru_list_shrink_inactive（） 从非活动列表中回收节点。活动列表中的节点由 __bpf_lru_list_shrink（） 回收，或在 __bpf_lru_list_rotate_active（） 将其降级为非活动列表之后回收。
    (CVE-2026-74337)

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

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

  - net：watchdog：修复引用计数跟踪争用 受到指责的提交将监视程序代码中未跟踪的 dev_hold（）/dev_put（） 调用转换为使用跟踪的 dev_hold_track（）/dev_put_track（） 调用（后来重命名/接口为 netdev_hold（） 和 netdev_put（））。通过引入 dev->watchdog_dev_tracker 来存储引用跟踪信息而不增加 netdev_watchdog_up（） 和 dev_watchdog（） 之间的同步，它启用了可同时覆盖或释放此指针的争用条件，从而导致列表损坏崩溃 syzbot 报告：list_del损坏，ffff888114a18c00->next 是 lib/list_debug.c：52 的空内核缺陷！Oops： invalid opcode： 0000 [#1] SMP KASAN PTI CPU： 1 UID： 0 PID： 91 Comm： kworker/u8：5 Not tainted syzkaller #0 PREEMPT（lazy） 硬件名称：
    Google Google Compute Engine/Google Compute Engine，BIOS Google 2026 年 5 月 9 日 工作队列：events_unbound linkwatch_event RIP：0010：__list_del_entry_valid_or_report.cold+0x22/0x2a lib/list_debug.c：52 调用跟踪：
    <TASK> __list_del_entry_valid include/linux/list.h：132 [内联] __list_del_entry include/linux/list.h：246 [内联] list_move_tail include/linux/list.h：341 [内联] ref_tracker_free+0x1a7/0x6c0 lib/ref_tracker.c：329 netdev_tracker_free include/linux/netdevice.h：4491 [内联] netdev_put include/linux/netdevice.h：4508 [内联] netdev_put include/linux/netdevice.h：4504 [内联] netdev_watchdog_down net/sched/sch_generic.c：600 [内联] dev_deactivate_many+0x28c/0xfe0 net/sched/sch_generic.c：1363 dev_deactivate+0x109/0x1d0 net/sched/sch_generic.c：1397 linkwatch_do_dev net/core/link_watch.c：184 [内联] linkwatch_do_dev+0xd3/0x120 net/core/link_watch.c：166
    __linkwatch_run_queue+0x3a5/0x810 net/core/link_watch.c：240 linkwatch_event+0x8f/0xc0 net/core/link_watch.c：314 process_one_work+0xa0e/0x1980 kernel/workqueue.c：3314 process_scheduled_works kernel/workqueue.c：3397 [内联] worker_thread+0x5ef/0xe50 kernel/workqueue.c：3478 kthread+0x370/0x450 kernel/kthread.c：436 ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 此修补程序具有三个协调的部件：1） 添加 dev->watchdog_lock 和 dev->watchdog_ref_held 以序列化监视程序操作。2） 从 netif_carrier_on（） 中删除 netdev_watchdog_up（） 调用：这确保了仅从 process/BH 上下文（通过 linkwatch 工作队列 dev_activate（））调用 netdev_watchdog_up），从而允许使用 spin_lock_bh（） 进行同步。3） 同步监视程序和监视程序定时器：使用 tx_global_lock 和 watchdog_lock 保护 netdev_watchdog_up（）。仅在 netdev_watchdog_up（） 中分配新的跟踪器（如果尚未存在）。在 dev_watchdog（） 中，确保如果定时器是由 dev_watchdog（） 自行重新计划，还是同时由 netdev_watchdog_up（） 重新计划，则不会释放跟踪器。（CVE-2026-74264）

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

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

  - netfilter：nf_conntrack_sip：访问 skb_dst（） 前先对其进行验证 tc ingress 和 openvswitch 不保证路由信息可用。这些子系统使用连接跟踪帮助程序基础架构，如果 sip_external_media 设置为 1（默认情况下作为模块参数禁用），则 SIP 帮助程序依赖 skb_dst（） 存在。这样可有效地禁用这些子系统的sip_external_media切换，而不会导致崩溃。（CVE-2026-72253）

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

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

  - mm/hugetlb：修复 hugetlb cgroup rsvd 充值/取消充值不匹配 在 alloc_hugetlb_folio（） 中，单一h_cg指针用于 rsvd 和非 rsvd hugetlb cgroup 充值。设定 map_chg 后，hugetlb_cgroup_charge_cgroup_rsvd（） 会将带电的 cgroup 存储在 h_cg 中，但紧随其后的 hugetlb_cgroup_charge_cgroup（） 会使用非 rsvd cgroup 指针覆盖h_cg。因此，hugetlb_cgroup_commit_charge_rsvd（） 将错误的（非 rsvd）cgroup 指针存储到作品集的 rsvd 插槽中。
    以后释放 folio 时，free_huge_folio（） 会无条件同时调用 hugetlb_cgroup_uncharge_folio（） 和 hugetlb_cgroup_uncharge_folio_rsvd（）。rsvd 取消充电会从作品集读回错误的 cgroup，并减少从未为该 cgroup 充电的计数器，进而造成page_counter下溢： page_counter下溢：-512 nr_pages=512 WARNING： mm/page_counter.c：61 at page_counter_cancel 通过引入一个专门用于 rsvd 充电路径的单独h_cg_rsvd指针来修复此问题， 通过其充值、提交和错误取消充电路径保持 rsvd 和非 rsvd 充电完全独立。（CVE-2026-72213）

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

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

  - configfs_lookup（）：失败时不让 ->s_dentry 悬摆 通常，当它指向的 dentry 变为负数时（实际上是在驱逐时），会清除 ->s_dentry。然而，这只有在入口首先变得积极时才会发生;在 inode 分配失败的情况下，dentry 永远不会变为正数，因此
    根本不会调用 ->d_iput（）。我们手动完成 configfs_d_iput（） （丢弃对 configfs_dirent 的引用）通常会完成的部分操作，但我们不会清除那里的 ->s_dentry。尽管它很草率，但在 configfs_create_{dir，link}（） 的情况下并不重要 - configfs_dirent放弃对它的唯一引用是无法存活的。但是，对于 configfs_lookup（），它 *确实* 存活下来，有一个指向很快将释放的 dentry 的悬摆指针将其置于其 ->s_dentry。该目录中的后续 getdents（2） 最终将取消引用该指针以便获取 inode 号。释放后使用... 这是最小的补丁;正确的方法是只有在我们知道我们有一个 inode 后才在 dentry 和 configfs_dirent 之间建立链接，但这需要更多的手术，而且这个错误自 2006 年以来就一直存在，所以......
    (CVE-2026-74359)

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

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

  - ntfs：拒绝仅限常驻属性的非常驻记录共享查找时间属性验证器拒绝非常驻$FILE_NAME$VOLUME_NAME和记录，因为它们的格式需要常驻值，并且调用程序将返回的记录作为常驻属性来处理。其他仅驻留属性类型仍通过通用的非驻留映射对检查。这留下了真正的居民/非居民工会混淆路径。Inode 加载会进行查找 $STANDARD_INFORMATION ，然后在不检查 a->non_resident 的情况下读取data.resident.value_offset。ntfs_inode_sync_standard_information（） 在更新标准信息值时会执行相同的操作。ntfs_write_volume_flags（） 还直接查找 $VOLUME_INFORMATION 和读取data.resident.value_offset。 $INDEX_ROOT dir.c 和 index.c 中的调用程序在消耗常驻索引根值之前依赖于相同的查找契约。拒绝共享验证器中所有仅限居民的属性类型的非居民记录。保留现有$FILE_NAME的 和 $VOLUME_NAME behavior，但通过辅助函数将其分解并将其扩展到 $STANDARD_INFORMATION、 、 $OBJECT_ID$VOLUME_INFORMATION$INDEX_ROOT、 和 $EA_INFORMATION。对于 $OBJECT_ID 和 $EA_INFORMATION 这是仅限常驻格式的合同强化;此修补程序仅拒绝非常驻形式，并且不为这些类型添加新的常驻值验证。（CVE-2026-72198）

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

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

  - dm-verity：修复 FEC 计算中的缓冲区溢出 dm-verity-fec 中存在缓冲区溢出：if （neras &&
    *neras <= v->fec->roots） fio->erasures[（*neras）++] = i;这允许 *neras 到达根 + 1（后增量将其推过根）。然后将此值作为no_eras传递给 decode_rs8（）。在 RS 解码器 （lib/reed_solomon/decode_rs.c：113-121） 内，纠删定位器多项式循环写入 lambda[j]，其中 j 可以到达 nroots + 1，在 lambda[] 结尾之后一个元素（大小为 nroots + 1，有效索引 0..nroots）。越界写入落在 syn[0] 上，进而损坏综合症缓冲区。（CVE-2026-72098）

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

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

  - tpm：tpm_tis_spi：在 wait_for_tmp_stat（） 中使用 wait_woken（） wait_event_interruptible_timeout（） 在将当前任务状态设置为TASK_INTERRUPTIBLE后评估其状况。使用 CONFIG_DEBUG_ATOMIC_SLEEP 这会在使用 IRQ 等待路径时触发警告：tpm_tis_status（） tpm_tis_spi_read_bytes（） tpm_tis_spi_transfer_full（） spi_bus_lock（） mutex_lock（） 通过以下措施解决此问题：1. 仅在任务运行时调用 wait_tpm_stat_cond（）。2. 使用 wait_woken（） 等待更改。
    (CVE-2026-72152)

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

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

  - can：bcm：跟踪 ANYDEV 超时/节流操作的单一源接口 匹配帧从多个接口到达时，具有活动 RX 超时和/或节流定时器的 ANYDEV rx op （ifindex == 0） 没有定义的语义：bcm_rx_handler（） 可针对不同 CPU 上的同一 op 并发运行，从而对 bcm_rx_timeout_handler（） 争用 hrtimer_cancel（）/ bcm_rx_starttimer（），并导致虚假RX_TIMEOUT通知和last_frames损坏。同样的并发会使来自不同接口的节流多路复用帧破坏 op 共享的单一 rx_ifindex/rx_stamp 字段。添加 op->if_detected 以在配置超时/节流计时器时跟踪发送匹配帧的第一个接口，并拒绝该操作的任何其他接口的帧。声明是在 hrtimer_cancel（） 接触 op->timer 之前在 bcm_rx_handler（） 中确定的，因此被拒绝的帧永远不会干扰声明接口的监视程序。通过独立于 kt_ival1/kt_ival2 的 RX_RTR_FRAME 将 RTR 模式操作排除在外，因为这些操作可能短暂保存较早的非 RTR 配置的过时值。当 SETTIMER 重新配置定时器值时，声明会在 NETDEV_UNREGISTER 上的 bcm_notify（） 和 bcm_rx_setup（） 中释放。仅在 NETREG_REGISTERED dev->reg_state 中的 CAN 设备上可以（重新）声明涵盖 bcm_notify（） 中的版本，其中 reg_state 变为NETREG_UNREGISTERING直到 synchronize_net（）。（CVE-2026-72115）

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

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

  - SELinux：避免 selinux_sctp_bind_connect（） 中的sk_socket取消引用 selinux_sctp_bind_connect（） 取消引用 sk->sk_socket 以将结构套接字 * 传递到 selinux_socket_bind（） 和 selinux_socket_connect_helper（）。但是，从 ASCONF softirq 路径 （sctp_process_asconf） 调用该挂钩时，没有文件引用可以保证 sk->sk_socket 不是 NULL。setsockopt 调用程序（bindx、connectx、set_primary、sendmsg connect）保留文件引用，不受影响。selinux_socket_bind（） 和 selinux_socket_connect_helper（） 都会立即解析 sock->sk，从不将结构套接字 * 用于任何其他内容。将内部逻辑重构为直接获取 struct sock * 的辅助函数，这样 selinux_sctp_bind_connect（） 就永远不需要接触 sk->sk_socket。
    (CVE-2026-72242)

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

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

  - nvdimm/btt：处理 BTT 通道获取中的优先权 BTT 通道在 BTT I/O 期间序列化对每个通道元数据和工作区状态的访问。btt-check 单元测试报告 BTT 写入期间的数据不匹配，这是因为通道采集中存在争用情况，可导致静默数据损坏。现有车道模型将旋转锁与每个 CPU 递归计数一起使用。该递归模型在 BTT 通道处于可抢占状态后停止有效：另一个任务可以在同一个 CPU 上运行、观察非零递归计数、绕过锁定并并并发使用相同的通道。BTT 通道也在 arena_write_bytes（） 呼叫之间保持。该路径会到达 nsio_rw_bytes（），从而通过 nvdimm_flush（） 刷新写入。某些提供程序刷新回调可能会休眠，从而使旋转锁成为通道生存期的错误基元。将基于自旋锁的递归模型替换为动态分配的每通道互斥体数组，并无条件地进行车道锁定。添加 might_sleep（） 以捕获任何未来的原子上下文调用程序。通过 ndctl 单元测试 btt-check.sh 发现。
    (CVE-2026-74365)

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

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

  - nfs：使用 nfsi->rwsem 保护文件锁定列表的遍历 Lingfeng 发现一个缺陷并提出了两种解决方案，但两者似乎都有问题。通常，我们不能在迭代文件锁定列表时释放 flc_lock，以避免文件锁定的释放后使用 （UAF） 问题。但是，像 nfs_delegation_claim_locks 和 nfs4_reclaim_locks 这样的函数无法遵守此规则，因为recover_lock或nfs4_lock_delegation_recall可能需要很长时间。为解决此问题，NFS 切换为使用 nfsi->rwsem 来提供相同的保护，nfs_reclaim_locks 也遵循此方法。尽管 nfs_delegation_claim_locks 改用 so_delegreturn_mutex，但这还不够充分，因为单个 inode 可以有多个 nfs4_state 实例。因此，补丁为在此情况下也使用 nfsi->rwsem。此外，在提交 c69899a17ca4（NFSv4：VFS 字节范围锁定的更新必须具有 stateid 更新的原子性）之后，函数 nfs4_locku_done 和 nfs4_lock_done 也会违反此规则，因为它们在不保留 nfsi->rwsem 的情况下调用locks_lock_inode_wait。仅添加此保护即可导致许多死锁，因此改为将对 locks_lock_inode_wait 的调用移至_nfs4_proc_setlk。关于提交 c69899a17ca4 修复的缺陷（NFSv4：VFS 字节范围锁定的更新必须是具有 stateid 更新的原子性的），已在提交 0460253913e5 后解决（NFSv4：nfs4_do_open（） 未正确触发状态恢复），因为在调用 nfs4_do_reclaim 之前耗尽所有插槽，从而阻止沿此路径进行并发 stateid 更改。此外，nfs_delegation_claim_locks 也不会造成此并发，从
    使用 NFS_DELEGATED_STATE 调用 _nfs4_proc_setlk，不会发送任何 RPC，因此不会调用 nfs4_lock_done。
    因此，nfs_delegation_claim_locks 的nfs4_lock_delegation_recall是第一次设置 stateid。（CVE-2026-72472）

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

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

  - smb：客户端：修复 DIO 提交后卸载时忙碌的目录项警告 c68337442f03（cifs：修复卸载后使用的忙碌目录项） 通过在 cifs_kill_sb（） 中刷新deferredclose_wq修复了 cifs 中延迟关闭文件导致未在 umount 中释放目录项引用计数的问题。但是，cifs DIO 路径受到由延迟的 dentry 引用计数释放所造成的相同的 dentry 忙碌问题的影响： [dio] [cifsd] [close + umount] netfs_unbuffered_write_iter_locked ...cifs_demultiplex_thread netfs_unbuffered_write cifs_issue_write netfs_wait_for_in_progress_stream [1] ...
    netfs_write_subrequest_terminated netfs_subreq_clear_in_progress netfs_wake_collector // 唤醒 [1] netfs_put_subrequest netfs_put_request queue_work（system_dfl_wq， xxx） [2] // dio 写入返回cifs_close
    _cifsFileInfo_put // cfile->count 2->1 --cfile->count [3] // 卸载cifs_kill_sb kill_anon_super // 触发了警告！ shrink_dcache_for_umount [4] [system_dfl_wq] [5] netfs_free_request ...
    _cifsFileInfo_put // cfile->count 1->0 --cfile->count queue_work（fileinfo_put_wq， xxx） [fileinfo_put_wq] [6] cifsFileInfo_put_work cifsFileInfo_put_final dput 如果在 [5] 之前触发 umount 路径，将导致警告： 缺陷：Dentry 00000000eab1f070{i=9a917b66ae404fec，n=test} 仍在使用 （1） [卸载 cifs cifs] cifs_evict_inode（） 中现有的每个 inode ictx->io_count等待无济于事： 它位于 inode 逐出路径中，路径在 shrink_dcache_for_umount（） 已经警告繁忙的 dentries 之后运行。通过添加每个超级块的 outstanding-rreq 计数器（在 cifs_init_request（） 中递增，在 cifs_free_request（） 中递减）来修复此问题。在 cifs_kill_sb（） 的 kill_anon_super（） 之前，等待此计数器达到 0，这保证了此 sb 的所有cleanup_work都已运行，因此所有相关的 cfile 放在fileinfo_put_wq或serverclose_wq上都排队。然后耗尽工作队列，从而删除 dentry refs。这是有针对性的等待，而不是刷新整个系统的system_dfl_wq。
    (CVE-2026-72315)

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

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

  - xfrm：修复 xfrm 异步恢复中的 dev 释放后使用 xfrm 异步恢复 将 skb->dev refcnt 保留到transport_finish后。但是，xfrm_rcv_cb可以将 skb->dev 修改为隧道 dev，而无需采用设备引用，例如 vti_rcv_cb。后续异步恢复将减少隧道设备的引用计数，导致隧道 dev 的 uaf 和原始 dev 的 refcnt 泄漏，具体如下所示：
    unregister_netdevice：等待 vti1 释放。使用计数 = -2 隐藏原始 skb->dev 以修复 refcnt 不平衡。xfrm_rcv_cb 设置的新 skb->dev 可与设备拆卸争用。将 rcu 保护扩展到xfrm_rcv_cb和transport_finish以防止争用。（CVE-2026-72463）

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

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

  - vhost：修复非空环的vhost_get_avail_idx vhost_get_avail_idx应报告其是否已更新 vq->avail_idx。相反，它返回是否已使用所有条目，这通常是相同的。但并非总是如此 - 在 drivers/vhost/net.c 中，当启用可合并缓冲区时，驱动程序会检查合并的条目是否足够大以存储传入的数据包。如果没有，驱动程序将重新启用通知，其中可用条目仍在环中。来自 vhost_get_avail_idx 的错误返回值会通过vhost_enable_notify传播，如果客户机没有进展，则造成主机动态锁定，因为 vhost 将立即禁用通知并使用可用条目进行重试。这回到提交 d3bb267bbdcb（vhost：缓存 vhost_enable_notify（） 中的 avail 索引），其更改了 vhost_enable_notify（） 以比较新读取的 avail 索引与 vq->last_avail_idx，而不是以前缓存的 vq->avail_idx。提交 7ad472397667（vhost：将 smp_rmb（） 移至 vhost_get_avail_idx（）），然后在重构 vhost_enable_notify（） 以调用统一的 vhost_get_avail_idx（） 时进行相同的比较。显而易见的补丁是让vhost_get_avail_idx按照注释的指示进行操作，并报告是否已添加新条目。（CVE-2026-74356）

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

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

  - tcp：强制关闭子套接字之前清除sock_ops cb 标记 子套接字通过 sk_clone_lock（） 继承监听器的bpf_sock_ops_cb_flags。如果其在 tcp_v4_syn_recv_sock（） / tcp_v6_syn_recv_sock（） 中的设置失败，则通过 put_and_exit 释放子程序，其中 inet_csk_prepare_forced_close（） 会终止套接字锁定，而 tcp_done（） 会在没有套接字锁定的情况下运行。如果继承了BPF_SOCK_OPS_STATE_CB_FLAG，tcp_done（） -> tcp_set_state（） 会调用 tcp_call_bpf（），这将预期锁定并跳闸 sock_owned_by_me（）：
    WARNING： include/net/sock.h：1799 at tcp_set_state+0x433/0x550 RIP： 0010：tcp_set_state+0x433/0x550 include/net/sock.h：1799 调用跟踪： <IRQ> tcp_done+0xba/0x250 net/ipv4/tcp.c：5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c：1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c：926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c：2164 </IRQ> 在子进程建立之前就已经释放， 因此它不应运行任何sock_ops回调。清除其在 inet_csk_prepare_for_destroy_sock（） 中的 cb 标记，这是 IPv4、IPv6 和 chtls 强制关闭路径的公共点，以及也到达从未建立的子进程上的 tcp_done（） 的公共点 dispose_child->syn_recv_sock（）。（CVE-2026-74268）

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

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

  - bpf，fork：在访问 ->bpf_storage 的 bailouts 之前擦除 - 当前，copy_process（） 可在初始化 p->bpf_storage 之前破解到 free_task（），使用此调用图（此处显示 ！CONFIG_MEMCG 的情况）：copy_process dup_task_struct arch_dup_task_struct [复制整个task_struct，包括 ->bpf_storage 成员] [RLIMIT_NPROC检查失败] delayed_free_task free_task bpf_task_storage_free rcu_dereference（task->bpf_storage） bpf_local_storage_destroy 在这种情况下，bpf_local_storage_destroy（） 在其上运行的新生任务的 ->bpf_storage 成员是父项 ->bpf_storage 指针的普通副本，而不是真正的初始化指针。这会导致不良问题（内核挂起、UAF）。
    只要调用 fork（） 的进程已插入到任务存储映射中，就可以访问此权限。
    (CVE-2026-72110)

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

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

  - espintcp：使用 sk_msg_free_partial 修复部分发送 sk_msg_free_partial（） 确保每次迭代时 skmsg 的一致性，而无需手动处理取消收费和偏移。这简化了代码，并修复了未发送完整内容时 skmsg 核算中的一些缺陷。（CVE-2026-72041）

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

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

  - net：mana： 验证 NIC 报告的数据包长度 在将 RX CQE 中报告的数据包长度传递到 skb 处理之前，验证其长度。CQE 由 NIC 设备提供，不应盲目信任。（CVE-2026-72065）

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

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

  - 已修复 Linux 内核中的下列漏洞：ntfs: validate index entries on reading Validate index entries immediately after reading an index root or index block from disk. This eliminates repeated checks in lookup and readdir, and reduce the risk of missing checks in those paths.
    (CVE-2026-72201)

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

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

  - selinux：检查 TCP Fast Open 上的连接相关权限 与 Landlock 类似，引入 TCP Fast Open 支持时未更新 SELinux，以确保使用 TCP Fast Open 时检查与连接相关的权限。更新其 socket_sendmsg（） 挂钩，以便在传递 MSG_FASTOPEN 时调用 selinux_socket_connect（）。
    (CVE-2026-72243)

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

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

  - PCI：访问之前检查 ROM 标头和数据结构地址 在计算机上运行 stress-ng 时x86_64会遇到崩溃： 缺陷：无法处理地址的页面错误：ffa0000007f40000 RIP：
    0010：pci_get_rom_size+0x52/0x220 调用跟踪： <TASK> pci_map_rom+0x80/0x130 pci_read_rom+0x4b/0xe0 kernfs_file_read_iter+0x96/0x180 vfs_read+0x1b1/0x300 我们的分析显示，ROM 空间的起始地址为 0xffa0000007f30000，大小为 0x10000。由于 ROM 空间损坏，在调用 readl（pds） 之前，pds 的值为 0xffa0000007f3ffff，其已指向 ROM 空间端，调用 readl（） 会读取 4 个字节，因此会造成越界访问并触发崩溃。通过添加图像标头和数据结构检查修复此问题。我们还在 arm64 机器上发现另一个崩溃：无法处理虚拟地址 ffff8000dd1393ff 上的内核分页请求 内存中止信息：ESR = 0x0000000096000021 EC = 0x25：DABT（当前 EL），IL = 32 位 SET = 0，FnV = 0 EA = 0，S1PTW = 0 FSC = 0x21：对齐错误 调用跟踪与 x86_64 相同，但崩溃原因是数据结构地址未与 4 对齐， 和 arm64 计算机报告对齐错误。通过添加对齐检查修复此问题。[bhelgaas：
    缩短函数名，封装注释] （CVE-2026-72487）

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

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

  - scsi：xen：scsiback：释放 TMR submit-failure 路径上的命令标签 scsiback_device_action（） 在 scsiback_get_pend_req（） 中获取命令标签并使用 target_submit_tmr（） 提交任务管理请求。
    当 target_submit_tmr（） 失败时，它返回 < 0，并且 scsiback 跳转到 err： 标签，这会发送响应但不释放任何内容，从而泄露标签。影响：每当 target_submit_tmr（） 失败时，pvSCSI 客户机可通过发出 VSCSIIF_ACT_SCSI_ABORT 或 RESET 请求，泄露 LUN 会话的命令标签，从而停止 LUN。
    此处不能使用 transport_generic_free_cmd（）。当 target_submit_tmr（） 返回错误时，它已运行 __target_init_cmd（） （因此 se_cmd->cmd_kref 是 1，而不是零），并且在其 target_get_sess_cmd（） 错误路径上，它已通过 core_tmr_release_req（） 释放 se_cmd->se_tmr_req，同时保持SCF_SCSI_TMR_CDB集和指针悬摆。然后，让命令释放运行 target_free_cmd_mem（） 将双重释放se_tmr_req。在此路径中也使用相同的帮助程序，它仅返回标签。（CVE-2026-72086）

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

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

  - RDMA/nldev：修复访问 mr->pd 时的锁定 Sashiko 指出，由于rereg_mr，PD 实际上是可变的，并且 nldev 中的所有接触都是争用的。使用 mr->device 代替 mr->pd->device。获取 PD 重新跟踪 ID 更加棘手。为避免打扰所有快乐路径，请添加一个 rdma_restrack_sync（） 操作，它有点类似于 flush_workqueue（） 或 synchronize_irq（）：在它返回之后，所有对 mr 的旧 nldev 接触都消失了，一切都会看到新的 PD。如此可安全接触 PD 指针。
    (CVE-2026-74334)

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

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

  - dlm：修复在有序send_queue中添加消息句柄 在触发大量请求并在网络上触发大量 DLM 消息的基准测试场景中，可能是 mh->seq 未按照最旧的 seq 编号排序。dlm_receive_ack需要此排序，因为 before（mh->seq， seq） 将停止检查在节点>send_queue末尾排序的较旧序列号。未对 before（mh->seq， seq） 进行正确排序的副作用是引用计数问题和释放后使用。
    我只能在实验性 DLM 分支和使用 io_uring 的用户空间 DLM 基准测试中重现此问题。更改此设置后，我不再遇到任何引用计数的发送缓冲区问题。（CVE-2026-74401）

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

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

  - i2c：imx：修复 SMBus 块读取为 0（原子）时锁定的总线 SMBus 3.1 6.5.7 允许块读取字节计数为 0，但原子（轮询）路径将其作为 -EPROTO 拒绝。更糟糕的是，它返回时没有 NACK+STOP：下一个接收周期已经开始，因此目标继续保持 SDA，总线保持卡住，直到此 i2c 控制器的电源循环。读取 I2DR 以获得计数同样会布防计数> I2C_SMBUS_BLOCK_MAX路径上的下一个字节，它也会直接返回 -EPROTO 并保持总线保持不变。同时处理两者：NACK 正在传输的虚拟字节 （TXAK） 并扩展 msgs->len，以便现有的最后一个字节处理发出 STOP;虚拟字节被丢弃。计数为 0 是有效的空块读取;超过 I2C_SMBUS_BLOCK_MAX 的计数仍被报告为 -EPROTO，但仅在释放总线之后才会报告。中断驱动的路径具有来自后续提交的相同缺陷，已单独修复，因为它带有不同的 Fixes： 标签和稳定范围。（CVE-2026-72142）

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

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

  - RDMA/siw：修复端点/套接字关联处理 通过 siw_socket_disassoc（） 解除套接字与端点的关联可能会释放该端点上的最后一个引用并将其释放。因此，调用该函数后不要清除端点套接字指针，而应在调用该函数之后清除端点套接字指针。这修复了一个：缺陷：KASAN：siw_cm_work_handler （drivers/infiniband/sw/siw/siw_cm.c：1053 drivers/infiniband/sw/siw/siw_cm.c：1075） 中的释放后使用 （drivers/infiniband/sw/siw/.c：1075） 在建立连接期间处理畸形 MPA 请求后，会造成新端点被关闭。（CVE-2026-74345）

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

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

  - ALSA：seq：避免调整大小期间过时的 FIFO 单元格 snd_seq_fifo_resize（） 仍需要在等待 FIFO 用户之前发布替换池。阻断 snd_seq_read（） 在休眠时保持 f->use_lock，因此并发发送者必须能够排入新池队列并唤醒该阅读器，而不是针对关闭的旧池失败。但是，snd_seq_fifo_event_in（） 会在事件采用 f->lock 之前复制事件，如果 copy_to_user） 或 snd_seq_expand_var_event（） 失败，snd_seq_read（） 可以出列信元，并在以后调用 snd_seq_fifo_cell_putback（）。如果调整大小可交换 f->pool 并在两者之间分离 oldhead，则任一路径都可以在快照后重新链接 old-pool 信元。该过时单元位于耗尽的 oldhead 列表外部，使 oldpool->counter 保持高位，并可让 snd_seq_pool_delete（） 等待已停用的池耗尽。保留 snd_seq_fifo_resize（） 中现有的等待前交换顺序，但在任何 FIFO 重新链接之前拒绝过时的信元。重新验证 f->lock 下的 event-in 单元格，并针对已发布的替换池重试这些单元格，并释放过时的 putback 单元格，而不是将它们链接回 FIFO。有缺陷的情况涉及两条路径，每一列显示该路径中的顺序：调整路径大小：
    重新链接路径：1. 分配新池。1. 采取 f->use_lock。2. 将 f->pool 交换到 newpool 和 2.复制或出列 old-pool 分离 oldhead。oldpool 关闭前的单元格。3. 标记 oldpool 关闭和 3.等待 FIFO 用户之后，到达更晚的重新链接点。调整已发布的 newpool 大小。4. 释放 oldhead 并删除 4.
    在 oldpool 之后重新链接 old-pool 单元格。调整分离的 oldhead 大小。5. 放弃 f->use_lock。重现者报告在预期池拆卸路径中阻断了一个 resize ioctl： signal： resize iteration=98 target_pool=4 超出 250ms （elapsed=251ms） diagnostic： resize_tid=651 wchan=snd_seq_pool_done diagnostic： resize_tid=651 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90 snd_seq_fifo_resize+0x193/0x1e0 snd_seq_ioctl_set_client_pool+0x214/0x260 snd_seq_ioctl+0x119/0x540
    __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f 具有较大池的第二次运行命中相同的目标路径：signal： resize iteration=32 target_pool=64 超过 250ms （elapsed=251ms） 诊断：resize_tid=663 wchan=snd_seq_pool_done diagnostic： resize_tid=663 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90 snd_seq_fifo_resize+0x193/0x1e0 snd_seq_ioctl_set_client_pool+0x214/0x260 snd_seq_ioctl+0x119/0x540 __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f （CVE-2026-74261）

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

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

  - RDMA/bnxt_re：将 dpi 变量初始化为零 系统只会针对 BNXT_RE_ALLOC_WC_PAGE 进行初始化，但是会针对所有情况进行复制。因此将 dpi 初始化为 0。（CVE-2026-72501）

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

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

  - bpf：在加载时拒绝可休眠的 BPF_LSM_CGROUP 程序 cgroup shim 在 rcu_read_lock_dont_migrate（） 下运行，因此我们不应在此处附加任何可休眠的 BPF 程序。向校验程序添加支持，以明确拒绝尝试加载目标为 LSM cgroup 附件的可休眠 BPF 程序。
    如果没有此问题，我们在调用 bpf_get_dentry_xattr（） 时会从标记为 BPF_F_SLEEPABLE附加到 file_open 的 BPF_LSM_CGROUP 程序中得到以下崩溃： 缺陷：sleeping 函数从 kernel/locking/rwsem.c：1567 的无效上下文中调用 in_atomic（）： 0， irqs_disabled（）： 0， non_block： 0， PID： 34317， name： load preempt_count： 0， 预期：0 RCU 嵌套深度：2，预期：0 调用跟踪：down_read+0x76/0x480 ext4_xattr_get+0x11f/0x700 __vfs_getxattr+0xf0/0x150 bpf_get_dentry_xattr+0xbb/0xf0 bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85 __cgroup_bpf_run_lsm_current+0x326/0x840 bpf_trampoline_6442534646+0x62/0x14d security_file_open+0x34/0x60 do_dentry_open+0x340/0x1260 vfs_open+0x7a/0x440 path_openat+0x1bac/0x30a0 libbpf 为每个 libbpf 提供每个 .s 命名的部分变体可休眠程序类型（lsm_cgroup除外），反映了各 cgroup LSM 程序旨在仅在不可休眠环境中运行。上述 splat 是通过直接使用 bpf（2） 绕过 libbpf 而获得的。
    (CVE-2026-74338)

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

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

  - netfs：修复遍历子请求列表时的屏障 修复在重试中遍历子请求列表时使用的屏障，因为有可能看到应用程序线程刚刚添加的子req。（CVE-2026-72355）

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

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

  - 已修复 Linux 内核中的下列漏洞：ntfs: centalize $INDEX_ROOT header validation Add a dedicated helper to perform stricter validation of $INDEX_ROOT and use it for both directory inodes and named index inodes. This keeps the root size and header geometry checks consistent across both read paths. (CVE-2026-72204)

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

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

  - net/sched：sch_teql：引入slaves_lock以避免争用条件和 UAF teql 主>从链接列表未受到保护以防止多次写入。它可以从 teql_master_xmit（）、teql_dequeue（）、teql_init（） 和 teql_destroy（） 并发进行修改，而无需保留任何列表锁定或 RCU 保护。zdi-disclosures@trendmicro.com 已证实，qdisc 在 RCU 宽限期后释放，但在另一个 CPU 上运行的 teql_master_xmit（） 仍可将过时指针保留到列表中，从而导致释放后使用 slab：缺陷：KASAN：teql_master_xmit+0xf0f/0x16b0 中的释放后使用 任务 poc/332 在地址 ffff888013fb0440 处读取大小为 8 释放的 512 字节区域 [ffff888013fb0400， ffff888013fb0600） （kmalloc-512） 补丁？添加每个主slaves_lock自旋锁，该旋转锁将主>从的所有突变以及 teql_destroy） 和 teql_qdisc_init（） 中的 NEXT_SLAVE（） 链接序列化。
    teql_master_xmit（） 也针对这些更新采用相同的slaves_lock。用 __rcu 注释主>从和每个从属的 ->next 指针，并在接触到的任何地方使用适当的 RCU 访问器：
    rcu_assign_pointer（） 在写入器侧（在 slaves_lock 下），rcu_dereference_protected（） 用于写入端负载（也在 slaves_lock 下），rcu_dereference_bh（） 用于 teql_master_xmit（） 中的负载，rtnl_dereference（） 用于 teql_master_open（）/teql_master_mtu（） 中的负载，它们在 RTNL 下运行。将其与 teql_master_xmit（） 中列表遍历的 rcu_read_lock_bh（）/rcu_read_unlock_bh（） 配对，以便读者要么观察到完全链接的列表，要么被推迟到正在运行的突变完成。更新了 teql_master_xmit（） 中的两个早期返回路径，以便在返回之前释放 RCU-bh 读取端关键部分，因为保留该路径将永久禁用该 CPU 上的 BH。（CVE-2026-72390）

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

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

  - gpio：mvebu：在 unbind 上释放通用芯片 irq_alloc_domain_generic_chips（） 分配必须通过 irq_domain_remove_generic_chips（） 释放的通用芯片数据。devres 操作 mvebu_gpio_remove_irq_domain（） 仅调用 irq_domain_remove（），仅在设置了 IRQ_DOMAIN_FLAG_DESTROY_GC 时才释放通用芯片。
    请先显式调用 irq_domain_remove_generic_chips（），然后再调用 irq_domain_remove（）。（CVE-2026-72324）

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

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

  - can：isotp：对 so->rx_lock 下的 TX 状态转换进行序列化 TX 状态机 （so->tx.state） 由三种上下文驱动：声明并继续传输的 sendmsg（）、消耗 Flow Control/echo 帧的 RX 路径，以及两个超时停止传输的 hrtimers。将 sendmsg（） 中的无锁 cmpxchg（） 声明与在 so->rx_lock 别处进行的 hrtimer_cancel（） 调用混合，留下窗口中的帧或定时器回调可能对已继续的状态起作用，从而损坏不相关的传输。so->rx_lock 现在涵盖了 TX 声明的整个生命周期：sendmsg（） 将其用于检查 so->tx.state 是否ISOTP_IDLE、将其切换到 ISOTP_SENDING、升级 so->tx_gen 和耗尽之前传输的定时器 - 所有这些都作为一个关键部分进行。
    isotp_rcv_fc（）/isotp_rcv_cf（） 已经通过 isotp_rcv（） 在此锁定下运行，而 isotp_rcv_echo（） 现在自行获取，因此它们都无法观察到声明中传输。这也意味着当另一个线程同时声明或完成传输时，不能再将传输传递传递到 sendmsg（） 的清理路径（信号或发送错误），因此这些路径可无条件地取消定时器和重置状态。
    isotp_release（） 以相同的方式声明套接字，因此争用的 sendmsg（） 会看到一致的ISOTP_SHUTDOWN并跳过布防其定时器或发送。只有 hrtimer 回调保留在 so->rx_lock 之外，因为它们在其他地方的 so->rx_lock 取消下运行，并且自行获取它会死锁。So->tx_gen 可让他们识别他们超时的传输是否仍是当前活动的传输，因此他们不会针对已完成或已被取代的传输报告错误。（CVE-2026-72124）

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

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

  - ipmi：修复事件传递中的用户引用计数下溢 ipmi_alloc_recv_msg（user） 获取由接收消息拥有的临时用户引用，然后 ipmi_free_recv_msg（） 再次将其删除。如果在为较早的用户分配接收消息后事件传递失败，handle_read_event_rsp（） 会使用 ipmi_free_recv_msg（） 回滚这些消息。该回滚路径在释放每条消息之后仍会明确终止 user->refcount。额外的放置可释放在 intf->users 上保持链接的用户，因此当 ipmi_alloc_recv_msg（） 尝试获取其他引用时，以后的事件传递可能会取消引用已释放的用户或跳闸refcount_t的零时加号警告。删除过时的显式放置和现已失效的用户分配。保留 list_del（） 和 ipmi_free_recv_msg（） 调用;它们是必需的回滚操作。（CVE-2026-72042）

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

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

  - fs/ntfs3：采用磁盘上的页面大小时调整 log->one_page_buf 大小 log_replay（） 使用从主机选择的页面大小分配日志>one_page_buf PAGE_SIZE： log->one_page_buf = kmalloc（log->page_size， GFP_NOFS）;之后，当找到重新启动区域时，采用磁盘上记录的日志页大小：t32 = le32_to_cpu（log->rst_info.r_page->sys_page_size）;if （log->page_size ！= t32） {log->l_size = log->orig_file_size; log->page_size = norm_file_page（t32， &log->l_size， t32 == DefaultLogPageSize）; }如果磁盘上的页面大小大于用于初始分配的大小，log->page_size 会增长，但one_page_buf保持原始的较小大小。然后，后续未对齐的 read_log_page（） 将 log->page_size 字节读入较小的擦除缓冲区：page_buf = page_off ？log->one_page_buf：*buffer;err = ntfs_read_run_nb_ra（ni->mi.sbi， &ni->file.run， page_vbo， page_buf， log->page_size， NULL， &log->read_ahead）;溢出分配。当挂载脏 NTFS 卷，其日志的格式大于挂载主机上最初分配的缓冲区（例如，配置了 4K 擦除缓冲区的主机上挂载的 64K 日志卷）时可访问此漏洞。
    当采用的磁盘页大小超过用于初始分配的大小时，one_page_buf增长。krealloc（） 失败时，原始缓冲区保持不变，并由现有错误路径释放。
    (CVE-2026-72470)

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

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

  - octeontx2-pf：修复初始化失败时的 SQB 指针泄漏 otx2_init_hw_resources（） 在多个后续设置步骤之前初始化 SQ aura 和池资源。失败时，err_free_sq_ptrs 仅释放 SQB 页面，而留下 per-SQ sqb_ptrs数组。将 otx2_free_sq_res（） 用于 SQ 展开路径，即使尚未分配 sq->sqe 也可使其释放sqb_ptrs。我们正在开发的用于内核内存管理缺陷的实验性分析工具在分析 v6.13-rc1 时，首先标记此缺陷。该工具仍在开发中，尚未公开可用。手动检查确认 v7.1.1 中仍然存在该缺陷。x86_64 allyesconfig 版本未显示新警告。由于我们没有 OcteonTX2 PF 设备和相应的 AF 邮箱设置进行测试，因此无法执行运行时测试。
    (CVE-2026-72023)

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

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

  - ntfs：检测映射对 LCN 累加器溢出 NTFS 映射对解析器将相对 LCN 增量累积成有符号的整数。损坏的属性可导致该新增超出可表示范围。
    一个损坏的运行列表形状将累积的 LCN 设置为 S64_MAX，然后在下一个映射对条目中添加 delta 1。签名的溢出未定义，可将无效的运行列表转换为一组不同的物理群集。在存储下一个运行之前检查 LCN 添加是否存在溢出。（CVE-2026-72200）

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

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

  - nvmet-tcp：修复错误路径中的页面片段缓存泄漏 在 nvmet_tcp_alloc_queue（） 中，当在分配过程期间关闭连接时（例如，nvmet_tcp_set_queue_sock（） 返回 -ENOTCONN），错误处理先跳至out_destroy_sq，然后跳至out_ida_remove，而不会耗尽页面片段缓存。
    尽管在某些错误路径中调用 nvmet_tcp_free_cmd（） 以释放单个页面片段，但队列>pf_cache保留的底层页面缓存引用永远不会释放。使用 pf_cache 的第一个分配是对 nvmet_tcp_alloc_cmd（） 进行 queue->connect 的调用，这是在 ida_alloc（） 成功返回后发生的。这会导致每次在分配期间连接失败时都将发生页面泄漏，如果连接反复打开和关闭，可导致随着时间的推移而耗尽内存。通过在释放 out_ida_remove 标签中的队列结构之前调用 page_frag_cache_drain（），来修复此问题。（CVE-2026-74386）

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

ID	名称	严重性
335636	Linux Distros 未修补的漏洞：CVE-2026-72423	high
335635	Linux Distros 未修补的漏洞：CVE-2026-72073	high
335634	Linux Distros 未修补的漏洞：CVE-2026-74406	critical
335633	Linux Distros 未修补的漏洞：CVE-2026-72318	critical
335632	Linux Distros 未修补的漏洞：CVE-2026-72342	high
335631	Linux Distros 未修补的漏洞：CVE-2026-72166	medium
335630	Linux Distros 未修补的漏洞：CVE-2026-72150	high
335629	Linux Distros 未修补的漏洞：CVE-2026-72208	critical
335628	Linux Distros 未修补的漏洞：CVE-2026-72440	high
335627	Linux Distros 未修补的漏洞：CVE-2026-72336	high
335626	Linux Distros 未修补的漏洞：CVE-2026-74337	medium
335625	Linux Distros 未修补的漏洞：CVE-2026-74264	high
335624	Linux Distros 未修补的漏洞：CVE-2026-72253	high
335623	Linux Distros 未修补的漏洞：CVE-2026-72213	high
335622	Linux Distros 未修补的漏洞：CVE-2026-74359	high
335621	Linux Distros 未修补的漏洞：CVE-2026-72198	high
335620	Linux Distros 未修补的漏洞：CVE-2026-72098	critical
335619	Linux Distros 未修补的漏洞：CVE-2026-72152	high
335618	Linux Distros 未修补的漏洞：CVE-2026-72115	high
335617	Linux Distros 未修补的漏洞：CVE-2026-72242	high
335616	Linux Distros 未修补的漏洞：CVE-2026-74365	high
335615	Linux Distros 未修补的漏洞：CVE-2026-72472	critical
335614	Linux Distros 未修补的漏洞：CVE-2026-72315	high
335613	Linux Distros 未修补的漏洞：CVE-2026-72463	critical
335612	Linux Distros 未修补的漏洞：CVE-2026-74356	high
335611	Linux Distros 未修补的漏洞：CVE-2026-74268	critical
335610	Linux Distros 未修补的漏洞：CVE-2026-72110	high
335609	Linux Distros 未修补的漏洞：CVE-2026-72041	critical
335608	Linux Distros 未修补的漏洞：CVE-2026-72065	critical
335607	Linux Distros 未修补的漏洞：CVE-2026-72201	critical
335606	Linux Distros 未修补的漏洞：CVE-2026-72243	high
335605	Linux Distros 未修补的漏洞：CVE-2026-72487	high
335604	Linux Distros 未修补的漏洞：CVE-2026-72086	high
335603	Linux Distros 未修补的漏洞：CVE-2026-74334	high
335602	Linux Distros 未修补的漏洞：CVE-2026-74401	critical
335601	Linux Distros 未修补的漏洞：CVE-2026-72142	medium
335600	Linux Distros 未修补的漏洞：CVE-2026-74345	critical
335599	Linux Distros 未修补的漏洞：CVE-2026-74261	low
335598	Linux Distros 未修补的漏洞：CVE-2026-72501	medium
335597	Linux Distros 未修补的漏洞：CVE-2026-74338	high
335596	Linux Distros 未修补的漏洞：CVE-2026-72355	critical
335595	Linux Distros 未修补的漏洞：CVE-2026-72204	high
335594	Linux Distros 未修补的漏洞：CVE-2026-72390	high
335593	Linux Distros 未修补的漏洞：CVE-2026-72324	medium
335592	Linux Distros 未修补的漏洞：CVE-2026-72124	high
335591	Linux Distros 未修补的漏洞：CVE-2026-72042	high
335590	Linux Distros 未修补的漏洞：CVE-2026-72470	high
335589	Linux Distros 未修补的漏洞：CVE-2026-72023	medium
335588	Linux Distros 未修补的漏洞：CVE-2026-72200	critical
335587	Linux Distros 未修补的漏洞：CVE-2026-74386	medium

检测

Nessus 的 Misc. 系列

high

high

critical

critical

high

medium

high

critical

high

high

medium

high

high

high

high

high

critical

high

high

high

high

critical

high

critical

high

critical

high

critical

critical

critical

high

high

high

high

critical

medium

critical

low

medium

high

critical

high

high

medium

high

high

high

medium

critical

medium