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 依赖供应商报告的程序包是否存在进行判断。

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

  - btrfs：修复使用 flushoncommit 时死锁克隆内联范围在提交 b48c980b6a7e 中（btrfs：修复使用 flushoncommit 时 reflink 和事务提交之间的死锁） 修复了使用 flushoncommit 选项挂载 fs 时 reflink 和事务提交之间的死锁。当必须将内联盘区的数据复制到目标文件时，会发生这种情况。但是，仅在目标偏移为 0 时修复了该问题，而错过了偏移大于零时的情况。通过确保我们在将内联盘区的数据复制到目标文件时i_size获取更新来修复此问题。
    Syzbot 报告此问题并造成以下跟踪：信息：任务 kworker/u8：3：57 被阻断超过 143 秒。未受感染 syzkaller #0 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 task：kworker/u8：3 state：D stack：21600 pid：57 tgid：57 ppid：2 task_flags：0x4208160 flags：0x00080000 工作队列：writeback wb_workfn （flush-btrfs-129） 调用跟踪： <TASK> context_switch kernel/sched/core.c：5402 [内联] __schedule+0x16f9/0x5500 kernel/sched/core.c：7204 __schedule_loop kernel/sched/core.c：7283 [内联] schedule+0x164/0x360 kernel/sched/core.c：7298 wait_extent_bit fs/btrfs/extent-io-tree.extent-io-tree.（extent-io-tree） c：905 [内联] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c：2008 btrfs_lock_extent fs/btrfs/extent-io-tree.h：152 [内联] btrfs_invalidate_folio+0x440/0xc00 fs/btrfs/inode.c：7718 extent_writepage fs/btrfs/extent_io.c：1848 [内联] extent_write_cache_pages fs/btrfs/extent_io.c：2552 [内联] btrfs_writepages+0x12f3/0x2410 fs/btrfs/extent_io.c：2684 do_writepages+0x32e/0x550 mm/page-writeback.c：2571 __writeback_single_inode+0x133/0x10e0 fs/fs-writeback.c：1764 writeback_sb_inodes+0x97f/0x1980 fs/fs-writeback.c：2056 wb_writeback+0x445/0xb00 fs/fs-writeback.c：2241 wb_do_writeback fs/fs-writeback.c：2388 [内联] wb_workfn+0x3fd/0xf20 fs/fs-writeback.c：2428 process_one_work+0x98b/0x1630 kernel/workqueue.c：3318 process_scheduled_works kernel/workqueue.c：3401 [内联] worker_thread+0xb49/0x1140 kernel/workqueue.c：3482 kthread+0x388/0x470 kernel/kthread.c：436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 </TASK> INFO：任务 syz.0.145:8523 阻断超过 143 秒。未受感染 syzkaller #0 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。
    task：syz.0.145 state：D stack：22752 pid：8523 tgid：8522 ppid：5850 task_flags：0x400140 flags：0x00080002 调用跟踪： <TASK> context_switch kernel/sched/core.c：5402 [inline] __schedule+0x16f9/0x5500 kernel/sched/core.c：7204 __schedule_loop kernel/sched/core.c：7283 [inline] schedule+0x164/0x360 kernel/sched/core.c：7298 wb_wait_for_completion+0x3e8/0x790 fs/fs-writeback.c：227
    __writeback_inodes_sb_nr+0x24c/0x2d0 fs/fs-writeback.c：2847 try_to_writeback_inodes_sb+0x9a/0xc0 fs/fs-writeback.c：2895 btrfs_start_delalloc_flush fs/btrfs/transaction.c：2182 [内联] btrfs_commit_transaction+0x813/0x2fc0 fs/btrfs/transaction.c：2371 btrfs_sync_file+0xdf4/0x1230 fs/btrfs/file.c：1822 generic_write_sync include/linux/fs.h：2663 [内联] btrfs_do_write_iter+0x6a9/0x840 fs/btrfs/file.c：1473 new_sync_write fs/read_write.c：595 [内联] vfs_write+0x629/0xba0 fs/read_write.c：688 ksys_write+0x156/0x270 fs/read_write.c：740 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [inline] do_syscall_64+0x15f/0x560 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：
    0033：0x7f5a0bdece59 RSP：002b：00007f5a0b446028 EFLAGS：00000246 ORIG_RAX：0000000000000001 RAX：
    ffffffffffffffda RBX：00007f5a0c065fa0 RCX：00007f5a0bdece59 RDX：000000000000029f RSI：0000200000
    ---truncated--- (CVE-2026-74318)

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

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

  - net：thunderbolt：通过将 frame_count tbnet_poll（） 绑定边界修复 frags[] 溢出 将多帧 ThunderboltIP 数据包组装为一个 skb。第一帧进入 skb 线性区域，并且每增加一帧都会添加为页面片段。skb_add_rx_frag（skb， skb_shinfo（skb）->nr_frags， page， hdr_size， frame_size， TBNET_RX_PAGE_SIZE - hdr_size）;因此，一个包含 frame_count 帧的数据包会以 frame_count - 1 个片段结束。tbnet_check_frame（） 仅将对等机提供的frame_count限制为 TBNET_RING_SIZE/4 （64），而后者远高于 MAX_SKB_FRAGS（默认为 17）。发送包含 19 个或以上小帧的数据包的对等体会将nr_frags推送到 MAX_SKB_FRAGS 度以上，因此 skb_add_rx_frag（） 会写入 skb_shinfo（）->frags[] 之后，并在共享信息后损坏内存。将数据包绑定的开头紧缩为 MAX_SKB_FRAGS + 1，这样数据包生成的片段就不会超过 frags[] 所能容纳的数量。这与其他接收路径（例如 f0813bcd2d9d）等最近的 skb frags 溢出补丁相匹配（net：wwan：t7xx：修复 RX 路径中潜在的 skb->frags 溢出）和 600dc40554dc（net：usb：cdc-phonet：修复 rx_complete（））中的 skb frags[] 溢出）。（CVE-2026-72157）

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

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

  - net：ipip：需要设备 netns 中的CAP_NET_ADMIN，以便 changelink ipip_changelink（） 最多在两个 netn 上操作，即 dev_net（dev） 和隧道链接 netns t->net。当设备创建或移动到运行请求的 netns 以外的 netns 中时，它们会有所不同。rtnl changelink 路径仅针对 dev_net（dev） 检查CAP_NET_ADMIN，因此拥有该处特权但不在 t->net 中的调用方可重写 t->net 中的隧道。在解析任何属性之前，在其顶部的 rtnl_dev_link_net_capable（） 上浇口 ipip_changelink（）。（CVE-2026-72053）

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

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

  - ipv4：igmp：修复 igmp_gq_start_timer（） 中潜在的 UAF 设备拆卸 （inetdev_destroy） 和传入的 IGMP 查询处理 （igmp_rcv） 之间存在争用条件，导致 IGMP 定时器回调中出现释放后使用。在设备析构过程中，inetdev_destroy（） 会丢弃对 in_device 的主要引用，这可能会将其引用计数降至 0。in_device内存的实际释放通过 RCU 延迟（使用 call_rcu（））。同时，igmp_rcv（） 在 RCU 读取锁定下运行并获取in_device指针。由于该内存受到 RCU 保护，因此即使 CPU-0 的引用计数命中了 0，它也可以安全地取消引用in_device。
    但是，如果 CPU-0 调用 igmp_gq_start_timer（） 并重新布防定时器，则它会尝试使用 in_dev_hold（） 获取引用。这会将引用计数从 0 增加到 1，从而触发 refcount_t： 在 0 警告时添加。由于 in_device 内存仍计划在 RCU 宽限期后释放（因为释放回调不会再次检查引用计数），所以会在定时器仍布防时释放设备。定时器到期时，它访问释放的内存，从而导致内核错误。如果设备已被破坏，则使用 refcount_inc_not_zero（）（通过新的帮助程序 in_dev_hold_safe（））防止获取引用来修复此问题。如果 refcount 为 0，则不布防计时器。IPv6 MLD 中的一个类似问题已在后续修补程序中修复。（CVE-2026-72323）

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

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

  - ALSA：seq：清除读取时的变量事件指针 snd_seq_read（） 在扩展负载之前将排队的变量长度事件标头复制到用户空间。排队的变量长度事件在内部使用SNDRV_SEQ_EXT_CHAINED，并且 data.ext.ptr 指向第一个扩展单元格。读取端在复制之前从 data.ext.len 中剥离 SNDRV_SEQ_EXT_* 位，但不影响 data.ext.ptr。因此，用户空间排序器客户端可将直接变量事件写入自身并从返回的标头读回扩展单元内核地址。清除 copy_to_user（） 之前的临时标头指针。原始的排队事件保持不变，并且仍传递到 snd_seq_expand_var_event（），因此负载扩展继续使用内部链。（CVE-2026-74339）

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

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

  - ASoC：拓扑：使用之前检查 PCM 和 DAI 名称字符串 拓扑对象在固定大小的 UAPI 数组中存储多个 PCM 和 DAI 名称。其他拓扑解析器路径会先通过有界的 strnlen（） 检查来验证这些字段，然后再将其用作 C 字符串，但 PCM 和 DAI 路径仍然会将一些固定大小的数组直接传递至 strlen（）、devm_kstrdup（）、DAI 查找和诊断打印。因此，具有非 NUL 结束的 PCM、DAI 或流功能名称的格式错误拓扑 blob 可使解析器读取超过固定大小字段的末尾。在未结束的 PCM 和 DAI 名称字段作为 C 字符串使用之前，将其拒绝。
    (CVE-2026-74291)

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

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

  - RDMA/bnxt_re：为 SQ 添加最大插槽检查 必须根据 HW 支持的最大插槽来验证变量 WQE 模式。最大支持值为 64K。添加最大值和最小值检查，如果用户提供的值大于支持的最大值和零，则将失败。（CVE-2026-72497）

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

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

  - ntfs：避免为空闲群集预读状态分配堆get_nr_free_clusters（） 在发布预计算的空闲群集计数、设置 NVolFreeClusterKnown（） 和唤醒 vol->free_waitq 之前分配临时file_ra_state。如果该分配失败，工作线程将在不设置标记或唤醒等待程序的情况下返回，因此等待空闲计数的调用程序可能会无限期地阻塞。预读状态仅在扫描位图时同步使用。将其保留在堆栈中并通过地址将其传递给预读帮助程序。这消除了早期分配失败路径，而不是添加发布保守计数并唤醒等待队列的特殊情况。零初始化堆栈上状态，因为 file_ra_state_init（） 仅设置 ra_pages 和 prev_pos。将相同的处理应用于
    __get_nr_free_mft_records（） ），扫描具有相同短期预读状态的 MFT 位图。
    (CVE-2026-72202)

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

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

  - ASoC：SOF：ipc3-control：修复 put/get bytes_ext中的堆溢出 ipc_control_data缓冲区分配为 kzalloc（max_size），其中 max_size 涵盖整个结构sof_ipc_ctrl_data，包括其灵活的数组负载。但是，bytes_ext_put 和 _bytes_ext_get 中的边界检查会直接将用户数据长度与max_size进行比较，忽略了 cdata->data 与分配中的 sizeof（struct sof_ipc_ctrl_data） 字节偏移。这允许通过 ALSA TLV kcontrol 接口从非特权用户空间写入最多超过堆缓冲区终点的 sizeof（struct sof_ipc_ctrl_data） 字节，并同样允许过度读取 get 路径中的相邻堆数据。修复所有边界检查，从max_size中减去 sizeof（*cdata），以便它们反映 cdata->data 偏移处的实际可用空间。还修复了 bytes_ext_put 中写入 cdata->data 而非 cdata，从而造成相同溢出的错误路径还原。
    (CVE-2026-72262)

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

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

  - can：bcm：更新筛选器和定时器值时添加锁定 KCSAN 检测到，当传入的 CAN 流量上同时运行 bcm_rx_handler（）、bcm_rx_timeout_handler（） 或 bcm_rx_thr_handler（） 时，更新定时器和过滤器内容时，会同时访问可在 bcm_rx_setup（） 中覆盖的定时器值。使用以 RX 处理程序中的匹配范围取得的新 per-op bcm_rx_update_lock保护 bcm_rx_setup（） 中的定时器 （ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg） 和过滤器 （nframes/flags/frames/last_frames） 更新。memcpy_from_msg（） 在采取锁定之前暂存到临时缓冲区中，因为它可以休眠并且不得在旋转锁下运行。始终在不保留bcm_rx_update_lock的情况下调用 hrtimer_cancel（），因为 bcm_rx_timeout_handler（）/bcm_rx_thr_handler（） 采用相同的锁定，并且运行的回调否则会针对取消程序死锁。还关闭相关的争用：
    bcm_rx_setup（） 在已安装帧内容后，将已存储回复帧can_id中的 RTR 标记作为单独的未受保护步骤清除，因此并发 bcm_rx_handler（） 可在仍然设置CAN_RTR_FLAG的情况下传输过时回复。将该规范化折叠到初始帧准备中（在用于更新的暂存缓冲区上，直接在新操作的 op->frame 预注册上），这样安装的帧始终在原子上自洽。bcm_rx_handler（） 的RX_RTR_FRAME检查现在会在决定是否调用 bcm_can_tx（） 之前，拍摄受锁定保护的 op->flags 快照，但不会跨该调用保留锁定。此外，还在 bcm_can_tx（） 中拍摄 currframe 的受锁定保护快照，以免被 bcm_tx_setup（） 中的内容更新部分覆盖。最后检查 TX_RESET_MULTI_IDX/SETTIMER 是否重置了 bcm_can_tx（） 中两个锁定部分之间的 op->currframe。忽略对 bcm_rx_thr_handler（） 中间隔为零的 hrtimer_forward（） 的调用。bcm_rx_setup（） 在取消此定时器之前可能已kt_ival2并发清除，因此请检查bcm_rx_update_lock内的kt_ival2。（CVE-2026-72121）

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

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

  - xprtrdma：重新发布畸形回复的接收缓冲区 rpcrdma_wc_receive（） 在将成功的接收分派到 rpcrdma_reply_handler（） 之前，会减少每次完成的传输的接收计数。
    处理程序必须在返回之前发布替换的接收 WR，除非代表的所有权已移动到其他地方，例如在反向通道路径上。提交 2ae50ad68cd7（xprtrdma：关闭唤醒 RPC 发送者与发布接收之间的窗口）将 Receive 重填从每次回复之前运行的 rpcrdma_wc_receive（） 移动到 rpcrdma_reply_handler（），以便在重新发布之前解析响应者的信用授予。bad-version 和 short-reply 退出永远不会到达该 refill：它们回收 rep 并在不调用 rpcrdma_post_recvs（） 的情况下返回。因此，远程对等端可以通过发送比固定传输标头短或带有无法识别的 RPC/RDMA 版本的持续回复流来耗尽客户端已发布的接收队列。每个此类回复都会消耗一个已发布的 Receive，而不替换它。
    队列清空后，对等机的下一次发送找不到已发布的接收，传输将停止，直到重新连接。回收 rep 之后，通过共享的 repost 末尾路由两个畸形回复退出，针对最近接受的信用授予 buf->rb_credits 重新填充。这两个退出都不会更新拥塞窗口，因此根据之前的授权获得的 RPC 会保持飞行等待回复。较小的重填目标会让格式错误的回复流将发布的接收计数递增到批次底部，而拥塞窗口仍允许rb_credits RPC;然后，对这些 RPC 的大量有效回复可使已发布的接收溢出，并且由于客户端使用零rnr_retry_count连接，单一 RNR NAK 会终止连接。当 rpcrdma_post_recvs（） 从内部rb_credits进行计算时，针对 rb_credits 重新填充也会还原提交 2ae50ad68cd7（xprtrdma：关闭唤醒 RPC 发送者与发布接收之间的窗口）之前应用到畸形回复的目标。
    从连接建立开始，rb_credits至少有一个，因此重新发布路径始终保持 Receives。（CVE-2026-72464）

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

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

  - net：序列化 enqueue_to_backlog（） 中的 netif_running（） 检查 Syzbot 报告了 fib_rules_lookup（） 中的 KASAN slab-after-free-after-use-later-free（）。根本原因是争用条件，其中数据包可在设备取消注册期间（如在 netns 退出期间）逃逸 backlog 刷新。提交 e9e4dd3267d0（net：取消注册期间不处理设备 backlog）在 enqueue_to_backlog（） 中引入了无锁 netif_running（） 检查，以防止将数据包排入取消注册的设备队列。但是，这会创建一个 TOCTOU 争用窗口。无锁发送器（如 veth_xmit）可在 dev_close（） 清除IFF_UP之前通过检查。如果发送器随后延迟，flush_all_backlogs（） 可以在发送器获取 backlog 锁定并将数据包排队之前运行并完成。数据包随后会从刷新中逸出，并稍后在处理时触发 UAF。通过将 netif_running（） 检查移到 backlog 锁定中来修复此问题。这会将检查与刷新工作（也会获取锁定）序列化。然后，我们要么在刷新运行之前将数据包排队（以便它得到刷新），要么在刷新/关闭完成后检查 netif_running（），以便它被丢弃。（CVE-2026-72493）

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

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

  - ASoC：meson：aiu：验证写入的枚举值 AIU HDMI 和内部编解码器 mux 放置回调会使用写入的枚举值和 snd_soc_enum_item_to_val（），然后再检查该值对枚举是否有效。在转换枚举项之前拒绝超出范围的值，与 G12A HDMI 和内部编解码器多路复用器控件已完成的验证匹配。（CVE-2026-74294）

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

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

  - bpf：取消映射值上的特殊字段 回收映射更新和删除值被替换或回收时当前调用的路径 bpf_obj_free_fields（）。这使得字段销毁取决于更新/删除操作的上下文。对于跟踪程序，这可能包括 NMI 上下文，其中引用的 kptr 析构函数、uptr 取消固定和图形根销毁通常不安全。为可重用值路径引入 bpf_obj_cancel_fields（）。它仅对定时器、工作队列和task_work字段执行 NMI 安全清除。需要完全销毁的字段将保持附加到回收值，并由最终清理路径销毁。将数组与哈希选项卡更新/删除/回收路径切换至此取消帮助程序。保留 bpf_obj_free_fields（） 以进行最终映射销毁和bpf_mem_alloc析构函数。预分配的哈希标签没有分配器析构函数，因此 teardown 会继续遍历普通元素和额外元素，并完全销毁其字段。这有意放宽特殊字段的映射更新/删除的 eager-free 语义。依赖于更新/删除后立即变为空白的回收映射槽的程序所依赖的行为无法在不卸载任意析构函数的情况下从每个 BPF 执行环境安全实现。此变更可能会打破程序对急切释放字段的假设。如果是这样，我们才能将语义放宽为取消，仅当将来 irqs_disabled（） 为真时。但是，从理论上讲，急切地重用的映射值已经具有较弱的保证，因为并行用户可以在新元素再次可见之前重新创建释放的字段。（CVE-2026-74314）

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

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

  - 已修复 Linux 内核中的下列漏洞：ntfs: validate resident index root values on lookup Resident $INDEX_ROOT values carry index header fields that callers consume after lookup.
    Some callers already validate parts of the layout before walking entries, but those checks are scattered and do not cover all root header invariants, such as entries_offset alignment and lower bound, index_length, and allocated_size consistency. The resident root resize paths now keep these header fields consistent while the value size changes: ntfs_ir_truncate() lowers index.allocated_size before shrinking the resident value, and ntfs_ir_reparent() grows the resident value before publishing a larger root header. Lookup-time validation can therefore cover these invariants without tripping over the driver's own resize paths. Add $INDEX_ROOT to the minimum resident value size table and validate the resident index header fields before returning the attribute from lookup. Require 8-byte aligned index header fields, a sane entries_offset, an index_length within allocated_size, allocated_size within the resident value, and enough entry space for at least an index entry header. The shared validator already rejects non-resident records for resident-only attribute types, including $INDEX_ROOT. (CVE-2026-72199)

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

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

  - vhost/net：只有在 vhost-net 初始化每个未完成 zerocopy TX 描述符的一个ubuf_info并将其传递至后端套接字之后，才能完成 zerocopy ubufs。然后，网络堆栈可在释放所有 skb 引用之前克隆一个 zerocopy skb。例如，batman-adv fragmentation 到达 skb_split（），后者调用 skb_zerocopy_clone（） 并递增相同的 ubuf_info refcount。vhost_zerocopy_complete（） 当前将每个 ubuf 回调视为已完成的 vhost 描述符。它会取消引用 ubuf->ctx，写入描述符完成状态，并终止vhost_net_ubuf_ref，即使回调仅释放克隆的 skb 引用也是如此。因此，后端重置可在另一个克隆的 skb 仍带有相同ubuf_info时等待并释放vhost_net_ubuf_ref。随后的完成会取消引用释放的 ubufs 指针。
    KASAN 将过时完成报告为： 缺陷： KASAN： vhost_zerocopy_complete+0x1d7/0x1f0 中的释放后使用 SLAB： KASAN： vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit 中的释放后使用 设置后端时从 vhost_net_ioctl（） 分配释放的对象，并在删除后端之后通过 kfree_rcu（）/kvfree_rcu_bulk 释放， 而延迟的 skb 完成量仍达到 vhost_zerocopy_complete（）。在接触 vhost 状态之前遵从通用 ubuf_info refcount，并且仅对最终的 ubuf 引用运行 vhost 描述符完成。这与克隆的 zerocopy skb 的 msg_zerocopy_complete（） 所有权规则相匹配。
    (CVE-2026-74310)

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

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

  - hwmon：（pmbus/core） 在 pmbus_reg2data_vid（） 已打开编码时，无论驱动程序配置vrm_version如何，都要遵守 pmbus_data2reg_vid（pmbus_data2reg_vid VR11 ） 中的vrm_version。任何选择非VR11 VID 模式并公开稳压器（或 hwmon vout 设置器）的驱动程序都会向PMBUS_VOUT_COMMAND发送危险的错误代码 -- 例如，要求 200 mV 的 nvidia195mv 部分会将 VR11 钳位编码为 500 mV，并将其编码为 0xB2，芯片将其解释为 1080 mV。镜像 pmbus_reg2data_vid（），以便通过读取写入往返。（CVE-2026-72397）

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

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

  - fs：拒绝通过未映射的 fsuid 或 fsgid 创建O_TMPFILE vfs_tmpfile（） 从未检查调用方的 fsuid 和 fsgid 映射到文件系统中。在 id 映射未涵盖调用方 fs{u，g}id 的 id 映射挂载上，->tmpfile（） 实例通过 inode_init_owner（） 初始化新 inode，其中 mapped_fsuid（）/mapped_fsgid（） 返回 INVALID_UID/INVALID_GID，而临时文件最终归 （uid_t）-1 所有。
    所有其他创建路径都已经拒绝此操作：may_o_create（） （O_CREAT） 和 may_create_dentry（） （mkdir、mknod、symlink、link） 通过 fsuidgid_has_mapping（） 通过 -EOVERFLOW 退出，正好是为了无法使用文件系统无法代表的所有者创建对象。O_TMPFILE也不例外：它是I_LINKABLE创建的，之后 linkat（2） 可以将其拼接到命名空间中，因此必须有相同的保证。将缺少的 fsuidgid_has_mapping（） 检查添加到 vfs_tmpfile（）。在非 id 映射的挂载上，调用程序的 fs{u，g}id 始终映射在超级块的用户命名空间中，因此该处无操作并且仅在未映射调用程序的 idmap 挂载上生效。它适用于设置FS_ALLOW_IDMAP并实现 ->tmpfile（） （tmpfs、ext4、btrfs、xfs、f2fs 等）的所有文件系统，以及 overlayfs，其上层临时文件创建通过 backing_tmpfile_open（） 通过 vfs_tmpfile（） 进行漏斗。（CVE-2026-72379）

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

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

  - can：bcm：在为 RTR 回复验证 bcm_rx_setup（） 中的帧长度 bcm_tx_setup（） 在为 TX_SETUP 安装帧之前根据 CAN/CAN FD DLC 限制验证 cf->len，但 bcm_rx_setup（） 从未对通过具有 RX_RTR_FRAME 的 RX_SETUP 配置的 RTR 回复帧执行相同的操作。（CVE-2026-72114）

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

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

  - scsi：lpfc：修复 lpfc_sli4_driver_resource_setup（） 中的内存泄漏 在某些早期退出错误路径中，未释放使用 mempool_alloc（） 为 mboxq 分配的内存。通过在上次使用后将 mempool_free（） 调用移到较早的时间点来修复此问题。（CVE-2026-72087）

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

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

  - bpf：在 check_mem_access（） 中缩小 retval 范围之前重置寄存器边界 BPF 验证程序处理 LSM 挂钩返回值的上下文加载时，会调用 __mark_reg_s32_range（） 以将寄存器缩小到挂钩的有效范围。但是，__mark_reg_s32_range（） 使用 max_t（）/min_t（） 将新范围与寄存器的现有边界相交，而不是替换它们。如果目标寄存器带有来自先前指令（例如BPF_MOV64_IMM）的过时边界，则交集可能会产生比实际范围更窄的范围。然后，校验器会认为自己知道寄存器的确切值，而在运行时会加载实际的挂钩返回值，从而造成可用于绕过 BPF 内存安全检查的校验器/运行时不匹配。else 分支已调用 mark_reg_unknown（） 在任何缩小前重置寄存器状态。在is_retval路径中应用相同的重置，以便在之前清除过时边界
    __mark_reg_s32_range（） 相交。（CVE-2026-72111）

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

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

  - net/liquidio：终止缓存的 VF pci_dev LUT PF SR-IOV 通过使用 pci_get_device（） 迭代，启用路径缓存 VF pci_dev指针 dpiring_to_vfpcidev_lut[] 。这些条目不拥有引用，因为迭代器会在每个步骤中丢弃以前的设备引用。之后处理缓存的指针时会取消引用OCTEON_VF_FLR_REQUEST。将缓存的 VF 映射替换为邮箱 DPI 环上的运行时查找：从 q_no 派生 VF 索引，通过导出的 PCI IOV 帮助程序解析 VF，使用 PF 指针和 VF ID 进行验证，然后发出 pcie_flr（） 并通过 pci_dev_put（） 删除引用。删除未使用的 VF 查找表初始化和清理。（CVE-2026-72329）

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

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

  - can：bcm：添加缺失的设备引用计数以删除 CAN 过滤器 sashiko-bot 指出，isotp.c 中的并发设备取消注册问题也存在于 bcm.c 代码中。raw.c 提交 c275a176e4b6 的以前补丁（can：raw：为内存泄漏补丁添加缺失的引用计数）引入了一项netdevice_tracker，也解决了 bcm.c 的问题。bcm_release（）、bcm_delete_rx_op（） 和 bcm_notifier（） 依靠 dev_get_by_index（ifindex） 重新查找rx_op的设备，然后再取消其过滤器的注册。如果并发NETDEV_UNREGISTER已从 ifindex 表中取消列出设备，则该查找会失败，并且静默跳过 can_rx_unregister（），留下指向即将释放的 bcm_op/套接字的过时 CAN 过滤器。从 rx 过滤器注册到 bcm_rx_setup（） 的那一刻起直到 bcm_rx_unreg（） 中取消注册为止，保留 op->rx_reg_dev 上的 netdev_hold（）/netdev_put（） 跟踪引用，并且直接在 bcm_release（） 和 bcm_delete_rx_op（） 中使用该引用，而非通过 ifindex 重新查找设备。（CVE-2026-72113）

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

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

  - bpf：通过uprobe_multi数据access_ok保护__get_user访问 据 sashiko [1] 报告，我们需要先使用 access_ok 检查用户空间数据边界，然后再使用 __get-user 获取数据边界。[1] https://lore.kernel.org/bpf/20260610145235.CB1441F00893@smtp.kernel.org/ （CVE-2026-74258）

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

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

  - dm-verity：使错误计数器成为原子型错误计数器 v->corrupted_errs 不是原子型，因此可能受到争用条件的影响。由于争用，可能会跳过对 dm_audit_log_target（max-corrupted-errors） 的调用。（CVE-2026-72096）

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

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

  - Bluetooth：ISO：修复畸形的 ISO_END/CONT 处理 核心规范（C 部分第 4 卷 sec 5.4.5）未排除空ISO_CONT、ISO_END 数据包。如果它们是最后一个，我们目前会拒绝它们。如果控制器发送错误格式的序列 ISO_START -> rx_len = 4，ISO_CONT skb->len 4，ISO_START以 ISO_CONT 结束负载，我们将泄漏 conn->rx_skb。如果控制器发送过长的ISO_END，skb_put将发生错误。如果控制器发送的发送太短ISO_END我们会接受。通过 conn->rx_skb ！= NULL 标记未完成的ISO_START修复。skb_put前正确检查 skb->len。合并 ISO_CONT/END 代码路径，因为它们需要相同的初始检查。
    拒绝过短的 ISO_END 数据包。（CVE-2026-72334）

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

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

  - net/sched：sch_taprio：将直接出列调用替换为扫视和qdisc_dequeue_peeked 当 taprio 的软件路径窥视非节省工作的子 qdisc 时，子 qdisc 会隐藏在其gso_skb中偷窥的 skb;
    然后，taprio_dequeue_from_txq（） 通过直接子 ->dequeue（） 调用获取数据包，该调用会忽略该隐藏，使偷窥的 skb 孤立，并使子的 qlen/backlog 去同步。使用 qfq 子项时，这会在空列表中重新输入子项并取消引用 NULL，从而导致普通出口时来自 softirq 的内核出错。像 sch_red 和 sch_sfb 现在一样通过 qdisc_dequeue_peeked（） 获取数据包。帮助程序首先返回子进程隐藏的 skb，当无 skb 时则无操作，因此节省子进程不受影响，并且门控路径现在消耗其长度计入预算的 skb。（CVE-2026-72035）

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

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

  - ocfs2：在 inode 读取期间验证快速符号链接目标 ocfs2_validate_inode_block（） 在向文件系统的其余部分暴露之前，已经拒绝了多个不一致的独立 dinode。快速符号链接需要相同的处理。零群集符号链接被视为快速符号链接，随后通过 page_get_link（） 和 ocfs2_fast_symlink_read_folio（） 进行读取。该路径在内联负载上使用 strnlen（），然后将长度 + 1 字节复制到作品集中。如果损坏的 dinode 存储的i_size不适合内联区域或在 i_size 省略终止 NUL，则该副本会读取超过 inode 区块缓冲区的末尾。拒绝其i_size超过内联快速符号链接容量，或其内联负载在验证 inode 块时i_size未完全以 NUL 终止的零群集符号链接双节点。这可防止畸形快速符号链接到达读取路径。验证重现了此内核报告：ocfs2_fast_symlink_read_folio+0x12c/0x1f0 中的 KASAN 释放后使用 RIP：0033：0x7f5c6d859aa7 读取大小为 3905 调用跟踪：dump_stack_lvl+0x66/0xa0 （？：？） print_report+0xce/0x630 （？：？） ocfs2_fast_symlink_read_folio+0x12c/0x1f0 （fs/ocfs2/inode.c：？） srso_alias_return_thunk+0x5/0xfbef5 （？：？）
    __virt_addr_valid+0x19f/0x330 （？：？） kasan_report+0xe0/0x110 （？：？） kasan_check_range+0x105/0x1b0 （？：？）
    __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)（CVE-2026-74350）

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

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

  - pmdomain：imx93-blk-ctrl：提取 PHY 作为 DSI/CSI 的共享域 MIPI DSI 和 CSI 域共享时钟和重置的控制位，如果一个域禁用共享资源而另一个域仍处于活动状态，则可能导致错误行为。若要修复此问题，请引入一个共享的 MIPI PHY 电源域来拥有公共资源，并使 DSI 和 CSI 成为其子域。这可确保共享位得到正确管理，不会在使用中时被禁用。（CVE-2026-72009）

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

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

  - coresight：platform：延迟连接计数器的增量，直到 alloc 成功 coresight_add_out_conn（） 会在调用 devm_krealloc_array（） 之前递增 nr_outconns，在调用 devm_kmalloc（） 之前再次递增。如果任一分配失败，则在相应数组条目为 NULL 或未初始化垃圾时计数器已被升级。coresight_add_in_conn（） 对 nr_inconns 和 devm_krealloc_array（） 具有相同的问题。在两种情况下，探测都会返回 -ENOMEM，进而导致 coresight_get_platform_data（） 调用 coresight_release_platform_data（） 进行清除。该函数最多可迭代 nr_outconns（或 nr_inconns）个条目，并无条件取消引用每个指针，命中 NULL 或垃圾条目并发生错误，而不是顺利失败。通过将计数器增量移至所有分配成功之后进行修复，以便结构在任何错误路径上始终保持一致。（CVE-2026-72485）

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

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

  - 9p：跳过无缓存模式下的 nlink 更新，修复 WARN_ON v9fs_dec_count（） 无条件调用常规文件上的 drop_nlink（），即使 inode 的 nlink 已为零。在无缓存模式下，客户端在每个操作中从服务器（事实来源）重新提取 inode 元数据，因此当 v9fs_remove（） 返回时，本地缓存的 nlink 可能已经反映了 post-unlink 值：1. 客户端发起 unlink，服务器对其进行处理并将 nlink 设置为 0 2.客户端在 unlink 返回前重新提取 inode 元数据 （nlink=0） 3.客户端的 v9fs_remove（） 成功完成 4.客户端调用 v9fs_dec_count（），后者在 nlink=0 上调用 drop_nlink（） 在繁重的 unlink 工作负载下很容易触发此争用，例如 stress-ng 的 unlink 压力源，从而产生以下警告： 警告：fs/inode.c：417 at drop_nlink+0x4c/0xc8 调用跟踪：
    drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ... 在无缓存模式下，服务器是授权的，而 inode 即将消失，因此在本地调整 nlink 不会买到任何东西。当 CACHE_META 和 CACHE_LOOSE 均未设置时完全跳过 v9fs_dec_count（），这样可以避免警告并删除一类 nlink 争用（两个并行取消链接器观察 nlink > 0 并都调用 drop_nlink（）），单独使用 nlink == 0 防护只会缩小而不是关闭。
    (CVE-2026-72170)

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

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

  - mtd：mchp23k256：将 SPI 匹配数据用于芯片端头 该驱动程序将芯片容量信息存储在 OF 匹配表和 SPI id 表中。Probe 目前使用 of_device_get_match_data（），因此即使 SPI id 表选择了不同的部分，非 OF SPI modalias 匹配也会回退到mchp23k256_caps。使用 spi_get_device_match_data（），以便在缺少 OF 匹配数据时消耗 SPI id-table driver_data。这保留了现有的默认回退，同时避免了仅 id-table 匹配时出现错误的 MTD 几何。
    (CVE-2026-68467)

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

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

  - mm/mm_init：修复 ZONE_DEVICE 的未初始化结构页 如果 DAX 内存热插拔到早期区段的空置子区段，section_activate（） 会重用未优化的启动内存。但是，compound_nr_pages（） 仍假设 vmemmap 优化有效，并且仅初始化减少的结构页数。因此，剩余的尾部结构页面处于未初始化状态，这可在之后导致意外行为或崩溃。通过在计算要初始化的结构页数时将早期部分视为未优化来修复此问题。（CVE-2026-72172）

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

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

  - xprtrdma：修复 ADDR_CHANGE rpcrdma_cm_event_handler（） 上的 ep kref 不平衡，当事件在 RDMA_CM_EVENT_ESTABLISHED 之前到达时，（） fallthrough through to disconnected： label on RDMA_CM_EVENT_ADDR_CHANGE and call rpcrdma_ep_put（） 但没有匹配的 get。然后，kref 在连接拆卸期间下溢，rpcrdma_xprt_disconnect（） 在释放的 ep 上运行。正常连接生命周期中的引用计数：
    rpcrdma_ep_create（） kref_init ->1 rpcrdma_xprt_connect（） ep_get ->2（post_recvs 之前） RDMA_CM_EVENT_ESTABLISHED ep_get ->3 RDMA_CM_EVENT_DISCONNECTED ep_put ->2 rpcrdma_xprt_drain（） ep_put ->1 rpcrdma_xprt_disconnect（） 尾部 ep_put ->0 （ep_destroy） 在 rpcrdma_xprt_connect（） 中取得的连接时间，当存在未完成的 Receives 时，就在 rpcrdma_post_recvs（） 之前拍摄， 通过rpcrdma_xprt_drain来平衡。ESTABLISHED 之前的 ADDR_CHANGE 没有 get 消耗，因此它的 put 将计数降至 1，然后 drain put 释放 ep，而 rpcrdma_xprt_disconnect（） 仍保留指向它的指针。通过 xchg（） 在先前的re_connect_status上分派修复：对于 prev == 0（预先建立），唤醒连接等待程序并返回不放置;对于 prev == 1，调用 rpcrdma_force_disconnect（） 并返回。case-1 arm 依赖于后续 RDMA_CM_EVENT_DISCONNECTED 事件（在仍连接的cm_id上调用 rdma_disconnect（） 时可靠地传递）来平衡 ESTABLISHED get;rpcrdma_xprt_drain（） 继续仅平衡该连接时间 get。任何其他先验值都表示拆卸已在执行中。
    (CVE-2026-72469)

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

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

  - xen/pvcalls：为 rsp[] 编制索引之前绑定后端响应req_id pvcalls_front_event_handler（） 直接从后端提供的环响应中获取req_id，并将其用于为 memcpy（） 和存储的固定大小的 bedata->rsp[] 数组编制索引，无需范围检查。恶意或有缺陷的后端可设置req_id过PVCALLS_NR_RSP_PER_RING并驱动越界写入超出 bedata 分配。req_id 也会在线路字段 rsp->req_id 为 u32 时声明为 int，因此仅对有符号值进行范围检查是不够的：后端req_id 0xffffffff变为 -1、通过 >= PVCALLS_NR_RSP_PER_RING 测试并索引 bedata->rsp[-1]。将req_id声明为 u32，以便单个边界覆盖两端。发送超出范围req_id的后端已违反线路协议，因此，与其静默终止响应，不如记录一次并停止信任后端：set bedata->disabled。事件处理程序随后会忽略进一步的响应，等待响应的请求路径会返回 -EIO，而非永久阻断。这反映了 xen-netback 使用 （xenvif_fatal_tx_err（）） 的致命错误处理。pvcalls 前端当前信任其后端，因此这不是典型的 Xen 安全问题，但它对于针对恶意后端（机密和解聚部署）强化 PV 前端很重要。（CVE-2026-72380）

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

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

  - RDMA/bnxt_re：固件拆卸后释放 CQ 切换页面 仅在固件拆卸完成后才释放切换页面，以便在 bnxt_qplib_destroy_cq（） 期间到达的 NQ 中断不会将切换值写入已释放的页面。在bnxt_qplib_destroy_cq之后移动 free_page（）。（CVE-2026-72499）

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

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

  - netfilter：nft_fib：拒绝 netdev 出口挂钩上的 fib 表达式。netdev 出口基本链取消引用 nft_in（pkt） 中的 fib 表达式在传输路径上为 NULL，导致 eval 时的空指针取消引用。nft_fib_validate（） 使用NF_INET_* 值掩盖挂钩，但 netdev 挂钩编号是为它们设置别名的单独枚举 （NF_NETDEV_EGRESS == NF_INET_LOCAL_IN），因此出口链通过验证然后出错。添加 nft_fib_netdev_validate（），将每个结果/标志限制在其读取的设备所在的 netdev 挂钩中：输入设备案例（OIF、OIFNAME、ADDRTYPE 含 F_IIF）用于入口，输出设备案例（含 F_OIF 的 ADDRTYPE）用于出口，将无设备标记的 ADDRTYPE 添加到两者。也将 nft_fib_validate（） 限制为 NFPROTO_IPV4/IPV6/INET，这样NF_INET_* 掩码就不会应用到其他系列的挂钩。（CVE-2026-72254）

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

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

  - OpenStack Octavia 通过 18.0.0 错误处理服务质量 （QoS） 策略授权。通过将其他项目的 QoS 策略与 amphora 相关联，经过认证的用户可能会阻止删除该策略。
    所有 Octavia 部署均受到影响。（CVE-2026-74248）

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

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

  - xprtrdma：修复 bcall 代表泄漏和未绑定的扫视 rpcrdma_is_bcall（） 解码回复的首个单词以确定帧是否为反向信道调用。该解码路径中的两个问题可使较短或畸形回复泄漏接收缓冲区并耗尽接收队列。首先，推测性偷窥 p = xdr_inline_decode（xdr， 0）;/* 五个 P++ 读取跟随 */ 要求 xdr_inline_decode（） 提供零字节，从而返回 xdr->p 而不咨询 xdr->end。然后，随后的五个 __be32 读取最多可穿过 20 字节，越过线路负载进入过时的 regbuf 内容，并将回复错误分类为反向信道调用。其次，在后窥视 p = xdr_inline_decode（xdr， 3 * sizeof（*p））;if （unlikely（！p）） 返回 true;短标头 ARM 在不调用 rpcrdma_bc_receive_call（） 的情况下返回 true。与调用者的契约是，真正的 return 将 rep 的所有权转移到反向通道路径：rpcrdma_reply_handler（） if （rpcrdma_is_bcall（r_xprt， rep）） return;/* 裸返回，跳过 out_post */ ...out_post：
    rpcrdma_post_recvs（r_xprt， credits + ...）;因为 rpcrdma_bc_receive_call（） 从未运行过，所以没有人接受 rep，但rpcrdma_reply_handler仍然超过 rpcrdma_rep_put（） 和 rpcrdma_post_recvs（） 的裸返回。具有持久性 DMA 映射的接收缓冲区的 rep 在 rb_all_reps 上被孤立，仅在传输拆卸时释放。此完成不重新发布任何内容，因此仅当较晚的前向信道回复达到 out_post 并且 rpcrdma_post_recvs（） 分配一个新的 rep 进行回填时，才会回收其插槽;缺少该流量时，接收队列将耗尽，并且对等机的发送会绘制 RNR NAK。在零长度扫视后通过咨询 xdr->end 进行修复，这样除非仍有 20 字节的线路负载，否则无法运行五个__be32读取。需要针对 xdr->end 进行字节精确比较，因为非 4 对齐的接收会将流的字数向上舍入到超过真实负载的位置。还会从短标头臂返回 false，以便回复落入正常out_norqst清理链（rpcrdma_rep_put（） 加 rpcrdma_post_recvs（））。（CVE-2026-72466）

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

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

  - ksmbd：为 FSCTL 突变使用 opener 凭据 SET_SPARSE，SET_ZERO_DATA 和 SET_COMPRESSION 在打开的 SMB 句柄上操作，但使用当前 ksmbd 工作线程凭据调用 VFS xattr、fallocate 或 fileattr 辅助函数。这些帮助程序可以独立于 SMB 句柄访问掩码重新验证 inode 权限、所有权和 LSM 策略。打开句柄时，使用目标文件中捕获的凭据运行每个操作。将凭据处理保留为这些单文件 FSCTL 的本地，而不是将会话凭据应用到完整的 IOCTL 处理程序，后者还包含无句柄和多句柄操作。
    (CVE-2026-68457)

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

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

  - afs：修复 inode 的重新初始化，特别是 ->lock_work 似乎在 slab 的 init 函数中对 afs_vnode：：lock_work 进行一次初始化并不足以work_structs。这导致DEBUG_OBJECTS调试内容在运行 generic/131 xfstest 时偶尔发出警告： ODEBUG：activate not available （活动状态 0） 对象：0000000016d8760f 对象类型：work_struct提示：afs_lock_work+0x0/0x220 WARNING： lib/debugobjects.c：629 at debug_print_object+0x4b/0x90， CPU#3：
    locktest/7695 ... CPU：3 UID：0 PID：7695 通信：locktest 受感染：G S 7.1.0-build3+ #2771 PREEMPT ... RIP：
    0010：debug_print_object+0x65/0x90 ... 调用跟踪： <TASK> ？ __pfx_afs_lock_work+0x10/0x10 debug_object_activate+0x122/0x170 insert_work+0x25/0x60 __queue_work+0x2e0/0x340 queue_delayed_work_on+0x48/0x70 afs_fl_release_private+0x57/0x70 locks_release_private+0x5c/0xa0 locks_free_lock+0xe/0x20 posix_lock_inode+0x55f/0x5b0 locks_lock_inode_wait+0x81/0x140 ？ file_write_and_wait_range+0x50/0x70 afs_lock+0xcd/0x110 fcntl_setlk+0x10d/0x260 do_fcntl+0x24e/0x5b0
    __do_sys_fcntl+0x6a/0x90 do_syscall_64+0x11e/0x310 entry_SYSCALL_64_after_hwframe+0x71/0x79 通过在分配 inode 后重新初始化 ->lock_work 来修复此问题。此外，在逐出 inode 时刷新 ->lock_work 以确保它并非仍在运行。（CVE-2026-72375）

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

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

  - drm/radeon：修复 radeon_align_pitch（） 中的整数溢出 radeon_align_pitch（） 具有与旧的 amdgpu 辅助函数相同的溢出问题：对齐舍入加法和最终的“aligned * cpp”计算都可溢出有符号的整数。如果换行，radeon_mode_dumb_create（） 最终可能会返回无效的音高或创建零大小的哑缓冲区。通过将 check_add_overflow（） 用于对齐舍入并使用 check_mul_overflow（） 进行最终间距计算，在溢出时返回 0 来修复此问题。同时拒绝 radeon_mode_dumb_create（） 中的零间距和大小。使用 sqry 通过基于 AST 的调用图分析发现。（CVE-2026-74417）

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

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

  - IB/mlx5：修复传输域回滚并提早初始化 lb 互斥体 mlx5_ib_alloc_transport_domain（） 分配传输域然后可能在 mlx5_ib_enable_lb（） 中失败。在这种情况下，分配的 TD 将会泄漏。通过在 mlx5_ib_enable_lb（） 返回错误时释放 TD 来修复此问题。同样在 no-loopback-capability 成功分支中显式返回 0，并将 dev->lb.mutex 初始化移至 mlx5_ib_stage_init_init（）。（CVE-2026-74397）

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

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

  - xprtrdma：将 req 回收与 RPC 完成分离 rl_kref 以前通过单个 refcount 提供两个不同的生命周期：它会在 Reply 何时唤醒其 RPC 任务进行门控，以及当 rpcrdma_req 何时可以返回到其空闲池。仅当 SGE 需要 DMA 取消映射 （sc_unmap_count > 0） 时，封送路径才采用发送端引用，这使得仅携带预注册缓冲区的发送成为异常：回复处理程序将 rl_kref 从 1 降至 0，并在 HCA 可能仍从其发送缓冲区进行 DMA 读取时释放 req。给rl_kref一个更窄的工作。RPC 层在插槽分配发出 req 时采用一个引用。rpcrdma_prepare_send_sges（） 在 WR 准备成功后无条件获取发送端引用。xprt_rdma_free_slot（） 和 xprt_rdma_bc_free_rqst（） 丢弃 RPC 层引用;
    rpcrdma_sendctx_unmap（） 丢弃发送端引用。只有在两位所有者都签字后，req 才会返回其免费池。删除了 rpcrdma_prepare_send_sges（） 中现有的 kref_init（&req->rl_kref） 调用。初始化移动到插槽分配路径（xprt_rdma_alloc_slot和 rpcrdma_bc_rqst_get），释放回调在 req 返回到空闲池之前重新布防rl_kref。封送路径中的重新初始化会丢弃条目时已存在的 RPC 层引用。以下有三个不变量：- rpc_rqst持有的任何rpcrdma_req具有 rl_kref >= 1。xprt_rdma_alloc_slot（）、rpcrdma_bc_rqst_get（） 和 xprt_rdma_alloc_slot（） 中的 backlog-wake 分支在发布 req 之前kref_init rl_kref。如果没有此不变量，在插槽分配和封送之间中止的 RPC 任务（例如，gss_refresh call_connect期间发生故障或发出信号）将针对零的 refcount 驱动 xprt_release（） -> xprt_rdma_free_slot（） -> kref_put，从而使refcount_t饱和并搁浅插槽。- 仅在 WR 准备成功后获取发送端引用。rpcrdma_prepare_send_sges（） 中的映射失败运行 rpcrdma_sendctx_cancel（），其会 DMA 取消映射 sendctx 并在不接触 rl_kref 的情况下清除sc_req。sendctx 环穿过含有 sc_req == NULL 的 rpcrdma_sendctx_put_locked（） 和 rpcrdma_sendctxs_destroy（） 跳过条目，因此突发 -EIO 封送组失败无法阻止 reqs 关闭rb_send_bufs。- 释放回调重新武装rl_kref以便下一个使用者在满足不变量的情况下进入。回复现在直接完成 RPC。
    rpcrdma_reply_handler（） 调用 rpcrdma_complete_rqst（） 代替非 LocalInv 分支上的kref_put。LocalInv 分支已从 frwr_unmap_async（） 完成 RPC，不受影响。由于发送端引用现在可超过 RPC 完成，因此连接破坏会耗尽其无信号的发送从未在之后有信号完成以遍历环路的 sendctx 条目。在重置请求缓冲区之前，rpcrdma_sendctxs_destroy（） 遍历活动范围并在每个条目上使用非 NULL sc_req运行 rpcrdma_sendctx_unmap（），并且在 rpcrdma_xprt_disconnect（） 中移到 rpcrdma_reqs_reset（） 之前，因此释放发送端引用时 reqs 仍处于预重置状态。漏在反向通道路径上造成拆卸排序危险。在新的生命周期中，从 rpcrdma_req_release（） 释放 bc_prealloc req 会将其重新添加到 bc_pa_list。xprt_rdma_destroy（） 中的断开连接在 xprt_destroy_backchannel（） 已清空 bc_pa_list 之后运行，因此耗尽的 reqs 否则将会泄漏。xprt_rdma_destroy（） 现在会在断开连接后第二次运行 xprt_rdma_bc_destroy（xprt， 0） 以回收它们。（CVE-2026-72473）

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

ID	名称	严重性
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
335586	Linux Distros 未修补的漏洞：CVE-2026-74318	medium
335585	Linux Distros 未修补的漏洞：CVE-2026-72157	high
335584	Linux Distros 未修补的漏洞：CVE-2026-72053	high
335583	Linux Distros 未修补的漏洞：CVE-2026-72323	critical
335582	Linux Distros 未修补的漏洞：CVE-2026-74339	medium
335581	Linux Distros 未修补的漏洞：CVE-2026-74291	medium
335580	Linux Distros 未修补的漏洞：CVE-2026-72497	high
335579	Linux Distros 未修补的漏洞：CVE-2026-72202	high
335578	Linux Distros 未修补的漏洞：CVE-2026-72262	high
335577	Linux Distros 未修补的漏洞：CVE-2026-72121	high
335576	Linux Distros 未修补的漏洞：CVE-2026-72464	high
335575	Linux Distros 未修补的漏洞：CVE-2026-72493	critical
335574	Linux Distros 未修补的漏洞：CVE-2026-74294	high
335573	Linux Distros 未修补的漏洞：CVE-2026-74314	high
335572	Linux Distros 未修补的漏洞：CVE-2026-72199	critical
335571	Linux Distros 未修补的漏洞：CVE-2026-74310	critical
335570	Linux Distros 未修补的漏洞：CVE-2026-72397	high
335569	Linux Distros 未修补的漏洞：CVE-2026-72379	medium
335568	Linux Distros 未修补的漏洞：CVE-2026-72114	high
335567	Linux Distros 未修补的漏洞：CVE-2026-72087	medium
335566	Linux Distros 未修补的漏洞：CVE-2026-72111	high
335565	Linux Distros 未修补的漏洞：CVE-2026-72329	critical
335564	Linux Distros 未修补的漏洞：CVE-2026-72113	high
335563	Linux Distros 未修补的漏洞：CVE-2026-74258	high
335562	Linux Distros 未修补的漏洞：CVE-2026-72096	medium
335561	Linux Distros 未修补的漏洞：CVE-2026-72334	high
335560	Linux Distros 未修补的漏洞：CVE-2026-72035	high
335559	Linux Distros 未修补的漏洞：CVE-2026-74350	critical
335558	Linux Distros 未修补的漏洞：CVE-2026-72009	high
335557	Linux Distros 未修补的漏洞：CVE-2026-72485	high
335556	Linux Distros 未修补的漏洞：CVE-2026-72170	high
335555	Linux Distros 未修补的漏洞：CVE-2026-68467	high
335554	Linux Distros 未修补的漏洞：CVE-2026-72172	high
335553	Linux Distros 未修补的漏洞：CVE-2026-72469	high
335552	Linux Distros 未修补的漏洞：CVE-2026-72380	high
335551	Linux Distros 未修补的漏洞：CVE-2026-72499	high
335550	Linux Distros 未修补的漏洞：CVE-2026-72254	high
335549	Linux Distros 未修补的漏洞：CVE-2026-74248	medium
335548	Linux Distros 未修补的漏洞：CVE-2026-72466	critical
335547	Linux Distros 未修补的漏洞：CVE-2026-68457	critical
335546	Linux Distros 未修补的漏洞：CVE-2026-72375	high
335545	Linux Distros 未修补的漏洞：CVE-2026-74417	high
335544	Linux Distros 未修补的漏洞：CVE-2026-74397	high
335543	Linux Distros 未修补的漏洞：CVE-2026-72473	critical

检测

Nessus 的 Misc. 系列

high

high

high

medium

critical

medium

medium

high

high

critical

medium

medium

high

high

high

high

high

critical

high

high

critical

critical

high

medium

high

medium

high

critical

high

high

medium

high

high

critical

high

high

high

high

high

high

high

high

high

medium

critical

critical

high

high

high

critical