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

  - net：macb：关闭时丢弃正在传输的 Tx SKB MACB 驱动程序从此永远泄漏尚未标记为完成的传出 SKB。他们生活在排队>tx_skb中，在没有悔意或检查的情况下被释放。macb_free_consistent（） 会在一些代码路径中被调用，但只有 close 才会触发添加的表达式。在 macb_open（） 和 macb_alloc_consistent（） 失败情况下，队列的tx_skb刚刚被分配并且为空。（CVE-2026-72017）

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

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

  - irqchip/ts4800：修复 remove 时缺少的链式处理程序清理 驱动程序在使用 irq_set_chained_handler_and_data（） 探测期间会为父中断安装链式处理程序，但是 remove 函数未清除此处理程序。这会留下一个悬摆处理程序，其可能会在删除驱动程序后的父中断触发时被调用，进而可能访问已释放的内存并造成内核崩溃。
    此外，通过 irq_of_parse_and_map（） 获取的parent_irq不会存储，因此无法在 remove 函数中访问。此外，在探测期间创建的中断映射未得到正确处置。通过以下方式修复此问题：- 在探测中保存parent_irq - 清除 ts4800_ic_remove（） 中含有 NULL 的链式处理程序 - 在删除域之前丢弃所有 IRQ 映射以防止资源泄漏 （CVE-2026-72384）

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

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

  - remoteproc：qcom：修复自定义dump_segments添加失败时的泄漏 如果失败，在将区域添加到“dump_segments”之前释放 qcom_add_minidump_segments（） 中的“name”minidump_region分配。否则，“名称”不会被跟踪并且永远不会被 qcom_minidump_cleanup（） 释放。添加到“dump_segments”失败时返回错误。（CVE-2026-72216）

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

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

  - ata：libata-core：拒绝无效的并发定位范围计数 ata_dev_config_cpr（） 从并发定位范围日志的 buf[0] 中获取范围描述符的数量（最多 255），设备报告的范围描述符与 GPL 目录中的日志大小无关。然后，在两个没有边界的地方以固定的 32 字节步幅执行计数：此处读取的日志，以及 INQUIRY VPD 页面 B9h 发射器，后者将每个范围一个描述符写入固定的 2048 字节ata_scsi_rbuf中。报告计数大于其自身日志的设备会使读取缓冲区溢出（超过 512 字节 slab 时最多 7704 字节），而超过 62 的计数会使发出端的响应缓冲区溢出。探测时，根据设备返回的日志和 VPD B9h 响应缓冲区可以保存的描述符数（ATA_DEV_MAX_CPR，源自 rbuf 大小）绑定计数一次。拒绝超出范围的计数并发出警告;这将发射器保持在边界内，没有单独的更改。（CVE-2026-72030）

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

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

  - cxl/region：区域创建期间阻止区域删除 展开范围锁定，重命名regions_lock，以在 construct_region（） 和 attach_target（） 之间的关键时期以及 device_add（） 和注册删除操作之间的时间段内禁用区域删除。否则，用户空间可能混淆内核。这可能会违反区域在完成 cxl_add_to_region（） 之前保持注册状态的假设。这可违反 devm_add_action_or_reset（） 使用实时“struct cxl_region”的假设。该区域消失在这些窗口之外也没问题，因为它反映了保持适当锁定位置的设备热插拔流。（CVE-2026-74273）

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

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

  - md/raid5：避免中断条带化批次时R5_Overlap争用 KCSAN 报告 sh->dev[i].flags 上的 break_stripe_batch_list（） 与 raid5_make_request（） 中的争用（明文写入与原子位 op）.。和 ..一种可能的情况是：CPU1 CPU2 break_stripe_batch_list（sh1） -> 处理 sh2 -> lock（sh2）
    -> sh2->batch_head = NULL -> unlock（sh2） -> test_and_clear_bit（R5_Overlap， sh2->dev[i].flags） -> wake_up_bit（sh2->dev[i].flags） raid5_make_request（） -> add_all_stripe_bios（sh2） -> lock（sh2） -> stripe_bio_overlaps（sh2） 返回 true batch_head为 NULL，因此 sh2 上存在新的 bio 重叠 bio -> true -> set_bit（R5_Overlap， sh2->dev[i].flags） -> unlock（sh2） -> wait_on_bit（sh2->dev[i].flags） -> sh2->dev[i].flags = sh1->dev[i].flags &; ~R5_Overlap No wait_up_bit（），CPU2 可能永远wait_on_bit（）... 修复方式： - 扩展保护区域。- 未保留 head_sh->stripe_lock时使用 batch_head 的设备标记的快照。- 将 sh/head_sh->batch_head = NULL 移至受保护区域的末尾，并且 现在任何并发 add_all_stripe_bios（） 抓取 sh->stripe_lock： - 请参阅 batch_head ！= null，并且 被锁定下的 stripe_bio_overlaps（） 拒绝（无R5_Overlap等待） ，或 ， - 仅在设置了 dev[i].flags 并且之前的 R5_Overlap 等待程序工作之后才会看到 batch_head == NULL。KCSAN 报告：
    ================================================ 缺陷：KCSAN：break_stripe_batch_list / CPU 0 上的任务 4042 对 8 字节0xffff8e89c8117548写入（标记）raid5_make_request中的数据争用：
    raid5_make_request+0xea0/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0
    __submit_bio+0x2ec/0x390 submit_bio_noacct_nocheck+0x457/0x710 submit_bio_noacct+0x2a7/0xc20 submit_bio+0x56/0x250 blkdev_direct_IO+0x54c/0xda0 blkdev_write_iter+0x38f/0x570 aio_write+0x22b/0x490 io_submit_one+0xa51/0xf70 __x64_sys_io_submit+0xf7/0x220 x64_sys_call+0x1907/0x1c60 do_syscall_64+0x130/0x570 entry_SYSCALL_64_after_hwframe+0x76/0x7e 通过 CPU 5 上的任务 4010 读取到 8 字节的0xffff8e89c8117548： break_stripe_batch_list+0x249/0x480 handle_stripe_clean_event+0x720/0x9b0 handle_stripe+0x32fb/0x4500 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7e0/0xba0 md_thread+0x15a/0x2d0 kthread+0x1e3/0x220 ret_from_fork+0x37a/0x410 ret_from_fork_asm+0x1a/0x30 值已更改：0x0000000000000019 -> 0x0000000000000099 --> R5_Overlap （CVE-2026-72420）

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

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

  - ocfs2：修复 ocfs2_sum_rightmost_rec 中的 UBSAN array-index-out-of-bounds [缺陷] 在 inode 的嵌入式范围列表中将磁盘损坏设置l_next_free_rec为 0 时，在该文件的下次写入中触发 UBSAN 错误。[原因] ocfs2_sum_rightmost_rec（） 计算 i = le16_to_cpu（el->l_next_free_rec） - 1 并在未验证 i 的情况下访问 el->l_recs[i]。当 l_next_free_rec 为 0 时，i 变为 -1;当 l_next_free_rec 超过 l_count 时，i 将超出数组的末尾。任一种情况均违反 UBSAN 上的 l_recs[] __counted_by_le（l_count） 注释并触发 UBSAN。[修复]在 ocfs2_validate_inode_block（） 中读取 inode 时验证 inode 的嵌入式范围列表：l_count必须非零且不大于 inode 块可以容纳的大小，并且l_next_free_rec不得超过 l_count。在读取时，在 b-tree 代码索引 l_recs[] 越界之前，损坏的列表会遭到拒绝。（CVE-2026-72162）

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

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

  - ksmbd：解析 ACE 之前拒绝尺寸过小的 DACL parse_dacl（） 通过比较符合 DACL 大小的最小 ACE 数，限制攻击者控制的 ACE 计数。DACL 大小字段为 16 位，但表达式减去 sizeof（struct smb_acl）。由于 sizeof（） 无符号，小于 ACL 标头的 DACL 大小会下溢到大型size_t。恶意客户端可通过以下命令来达到此目的：SMB2_SET_INFO （InfoType=SMB2_O_INFO_SECURITY） -> smb2_set_info_sec（） -> set_info_sec（） -> parse_sec_desc（） -> parse_dacl（） -> init_acl_state（...， 0xffff） -> init_acl_state（...， 0xffff） -> kmalloc_objs（...， 0xffff） 因此，畸形的安全描述符可使num_aces通过防护并驱动大型临时 ACL 状态和指针数组分配。在执行减法之前拒绝小于 struct smb_acl的 DACL，这样下溢就无法绕过 ACE 计数检查。（CVE-2026-72382）

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

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

  - macsec：不读取 macsec_encrypt（） 中未设置的 MAC 标头 macsec_encrypt（） 通过 eth_hdr（skb） （skb->head + skb->mac_header） 读取以太网标头，以 memmove（） 转发 12 个源/目标 MAC 字节并为 SecTAG 腾出空间。在 AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS 传输路径上，skb 到达 macsec ndo_start_xmit（） 时 MAC 标头未设置，因此 eth_hdr（skb） 解析为 skb->head + （u16）~0 并且读取越界：12 字节堆过度读取，同样作为帧的外部源/目标 MAC 在线路上发出。KASAN 报告 macsec_start_xmit（） 上的 6.0slab-越界读取;在当前主线上，CONFIG_DEBUG_NET 版本将其标记为 skb_mac_header（） 中的未设置 mac 标头。在 TX 路径上，L2 标头位于 skb->data，因此请使用此目的使用提交 96cc4b69581d 添加的 skb_eth_hdr（（）（macvlan：不假设 macvlan_broadcast（）） 中设置了 mac_header）。（CVE-2026-72019）

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

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

  - ASoC：mediatek：mt8192：检查探测 MT8192 期间的运行时恢复 AFE 探测在从硬件重新初始化 regmap 缓存时临时启用运行时 PM，但它使用 pm_runtime_get_sync（） 而不检查返回值。如果运行时恢复失败，探测会在设备无效的情况下继续进行，且 pm_runtime_get_sync（） 可能会使 PM 使用计数保持递增。regmap_reinit_cache（） 失败路径也会在丢弃临时 PM 引用之前和清除pm_runtime_bypass_reg_ctl之前返回。使用 pm_runtime_resume_and_get（） 以便恢复失败不泄漏使用计数，并且在丢弃所有 regmap_reinit_cache（） 结果上的探测 PM 引用后清除临时绕过标记。（CVE-2026-72260）

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

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

  - sctp：修复 sctp_free_addr_wq（） 中的addr_wq_timer争用 sctp_free_addr_wq（） 之前在按住 addr_wq_lock 时使用 timer_delete（） 删除addr_wq_timer。但是，timer_delete（） 不能保证当前正在运行的定时器处理程序已完成。这会导致与 sctp_addr_wq_timeout_handler（） 争用，其中处理程序在释放addr_waitq后仍可能运行、获取addr_wq_lock及访问已释放的内存，从而导致释放后使用。通过在进行addr_wq_lock之前调用 timer_shutdown_sync（） 来修复此问题。
    这可保证任何正在运行的计时器处理程序已完成，并防止在拆卸期间重新布防计时器，从而确保后续清理安全。（CVE-2026-72383）

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

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

  - fs/resctrl：修复将伪锁定区域的 RMID 双重添加到释放列表 伪锁定群组的 RMID 在创建时将其释放。卸载时，rmdir_all_sub（） 会无条件释放所有群组的所有 RMID，从而导致双重释放伪锁定群组的 RMID。此操作的后果是，原始释放导致伪锁定群组的 RMID 被添加到rmid_free_lru链接列表，然后第二个释放再次尝试将相同的 RMID 条目添加到rmid_free_lru。不双重释放伪锁定群组的 RMID。（CVE-2026-72015）

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

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

  - KVM：x86：如果 vCPU 此后禁用了 PV EOI，则忽略待定的 PV EOI 如果 vCPU 自发出请求后已禁用 PV EOI 请求，则忽略 KVM 的内部服务待定 PV EOI 请求。如果读取 pv_eoi_get_user（） 中的客户机内存失败（即 pv_eoi_test_and_clr_pending（） 提早退出，*并且* vCPU 也禁用 PV EOI，则断言已启用 PV EOI 将失败。位于 arch/x86/kvm/lapic.c：3338！ 的内核缺陷哎呀：无效操作码：0000 [#1] SMP CPU：4 UID：1000 PID：890 通信：pv_eoi_test 未受感染 7.0.0-d585aa5894d8-vm #337 抢占 硬件名称：QEMU Standard PC （Q35 + ICH9， 2009）， BIOS 0.0.0 02/06/2015 RIP： 0010：kvm_lapic_sync_from_vapic+0x12b/0x140 [kvm] 调用跟踪： <TASK> kvm_arch_vcpu_ioctl_run+0x1075/0x1c30 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0xb40 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> 模块链接于：kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- （CVE-2026-72284）

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

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

  - OPP：修复 OPP 添加和查找之间的争用 dev_pm_opp_add_dynamic（） 和 dev_pm_opp_find_freq_exact（） 之间存在争用条件： CPU0（添加） CPU1（查找）-------------------------------
    ------------------------------ _opp_add（） mutex_lock（） list_add（&new_opp->node， head） mutex_unlock（）
    _opp_table_find_key（） mutex_lock（） dev_pm_opp_get（opp） kref_get（） mutex_unlock（） kref_init（&new_opp->kref） dev_pm_opp_put（） kref_put_mutex（） 新添加的 OPP 在初始化其 kref 之前将其插入列表中。并发查找可发现此 OPP 并在其仍未初始化时增加其引用计数，从而导致引用计数损坏和潜在的过早释放。通过初始化修复此问题
    ->kref 和 ->opp_table，然后通过 list_add（） 使 OPP 可见。这可确保任何并发查找都能观察到完全初始化的对象。[ Viresh： 更新了提交日志 ]（CVE-2026-74405）

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

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

  - gpio：tegra：不为GPIO方向tegra_gpio_direction_input（）调用pinctrl，且tegra_gpio_direction_output（）已直接对GPIO控制器方向寄存器编程。其他 pinctrl_gpio_direction_input/output（） 调用不会添加 Tegra pinctrl 操作，因为 Tegra pinmux 操作提供 GPIO 请求/释放处理，但不提供gpio_set_direction挂钩。额外调用仍会进入 pinctrl 核心并采用 pctldev->mutex。共享 GPIO 用户可在按住其每行旋转锁的同时调用方向路径，因此此多余的 pinctrl 方向调用可以在原子上下文中休眠。这是由我们的静态分析工具发现的，然后通过手动检查 tegra_gpio_probe（）、Tegra GPIO 方向回调和 Tegra pinctrl 操作来确认。已检查的路径具有默认的非休眠结构gpio_chip而方向回调仍进入 pinctrl 互斥体路径。定向运行时验证保持相同的非休眠芯片注册并驱动：
    gpio_shared_proxy_direction_output（） gpiod_direction_output_raw_commit（） tegra_gpio_direction_output（） pinctrl_gpio_direction_output（） Lockdep 报告了保留共享 GPIO 旋转锁且 pinctrl_get_device_gpio_range（） 加堆栈上的 tegra_gpio_direction_output（） 的情况下原子休眠警告。请勿将整个芯片标记为can_sleep以覆盖此纸：can_sleep 描述 get（）/set（） 是否可以休眠，Tegra 值访问是否为 MMIO。删除多余的 pinctrl 方向调用，并在现有请求/自由路径中保留 pinctrl 参与。（CVE-2026-72063）

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

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

ID	名称	严重性
335651	Linux Distros 未修补的漏洞：CVE-2026-72017	medium
335650	Linux Distros 未修补的漏洞：CVE-2026-72384	medium
335649	Linux Distros 未修补的漏洞：CVE-2026-72216	high
335648	Linux Distros 未修补的漏洞：CVE-2026-72030	high
335647	Linux Distros 未修补的漏洞：CVE-2026-74273	high
335646	Linux Distros 未修补的漏洞：CVE-2026-72420	high
335645	Linux Distros 未修补的漏洞：CVE-2026-72162	high
335644	Linux Distros 未修补的漏洞：CVE-2026-72382	high
335643	Linux Distros 未修补的漏洞：CVE-2026-72019	high
335642	Linux Distros 未修补的漏洞：CVE-2026-72260	medium
335641	Linux Distros 未修补的漏洞：CVE-2026-72383	high
335640	Linux Distros 未修补的漏洞：CVE-2026-72015	high
335639	Linux Distros 未修补的漏洞：CVE-2026-72284	high
335638	Linux Distros 未修补的漏洞：CVE-2026-74405	high
335637	Linux Distros 未修补的漏洞：CVE-2026-72063	high
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

检测

Nessus 的 Misc. 系列

medium

medium

high

high

high

high

high

high

high

medium

high

high

high

high

high

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