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

  - of：reserved_mem：避免 alloc_reserved_mem_array（） 失败时 post-init UAF 如果 alloc_reserved_mem_array（） 失败，全局指针“reserved_mem”将继续引用存在于__initdata中的reserved_mem_array。导出 of_reserved_mem_lookup（） 供 init 后使用，这将取消引用释放的内存并触发释放后使用。因此当 alloc_reserved_mem_array（） 失败时，将reserved_mem_count重置为 0。（CVE-2026-74352）

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

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

  - net：phy：sfp： sfp_i2c_mdiobus_destroy sfp_i2c_mdiobus_create（） 中的释放mii_bus使用 mdio_i2c_alloc（） 分配普通（非 devm）的 I2C MDIO 总线，并进行注册。sfp_i2c_mdiobus_destroy（） 仅取消注册总线并清除 sfp->i2c_mii而不调用 mdiobus_free（）。随后清除对总线的唯一引用时，会泄漏结构mii_bus。每当删除实例化了 MDIO 总线的 copper/RollBall SFP 模块时，都会发生此问题：sfp_sm_main（） 采用全局拆卸路径并调用 sfp_i2c_mdiobus_destroy（）。驱动程序取消绑定时 sfp_cleanup（） 会直接释放 sfp->i2c_mii，这就是为什么泄露只在模块热删除时触发，而不是在取消绑定时触发。释放 sfp_i2c_mdiobus_destroy（） 中的总线以匹配 sfp_i2c_mdiobus_create（） 中完成的分配。（CVE-2026-72391）

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

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

  - mmc：sdhci-esdhc-imx：在暂停期间禁用 irq 以修复未处理的中断 使用 WIFI 带外唤醒时，出现 irq xxx： nobody careed 警告。这是因为当 device_may_wakeup（） 返回 false 时，usdhc 中断未在系统暂停期间禁用。导致此问题的事件顺序：1. 系统在未禁用 usdhc 中断的情况下进入暂停状态（因为 device_may_wakeup（） 对 usdhc 设备返回假） 2.WIFI 带外唤醒通过 GPIO 中断 3 触发系统恢复。
    WIFI 在 usdhc 完全恢复前发送 Card 中断 4.usdhc 仍处于运行时挂起状态，无法正确处理中断 5.未处理的中断触发 nobody careed 警告 通过在暂停期间无条件地禁用 usdhc 中断并在恢复期间重新启用它来修复此问题，无论唤醒功能如何。这可确保在暂停/恢复转换期间不处理任何中断。（CVE-2026-68464）

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

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

  - mm/memory_hotplug：修复错误路径中错误的 altmap 传递 在 create_altmaps_and_memory_blocks（） 中，当 arch_add_memory（） 成功且启用 memmap_on_memory 时，将从 params.altmap 分配 vmemmap 页面。如果 create_memory_block_devices（） 随后失败，错误路径会调用具有空 altmap（而非 params.altmap）的 arch_remove_memory（）。此缺陷可导致内存损坏。由于 altmap 为 NULL，vmemmap_free（） 会回退到通过 free_pages（） 而非 altmap 将 vmemmap 页面释放到系统好友分配器中。然后，arch_remove_memory（） 立即破坏此内存的物理线性映射。这会将无主页面注入好友分配器，如果系统稍后尝试分配和使用这些释放的页面，则会造成计算机检查或内存损坏。
    通过将 params.altmap 传递到错误路径中的 arch_remove_memory（） 来修复此问题。（CVE-2026-72212）

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

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

  - drm/rockchip：inno-hdmi：切换到 drmm_kzalloc（） 驱动程序利用 drmm_encoder_init（） 初始化编码器，并通过向 drmm_add_action（） 注册 drm_encoder_cleanup（） 自动处理清理。但是，包含编码器部件的内部结构会使用 devm_kzalloc（） 进行分配，这会在从 Rockchip DRM 驱动程序调用 component_bind_all（） 时发生。组件框架进一步确保将其释放为绑定期间声明的所有资源的一部分，这从 component_unbind_all（） 触发。当 DRM 设备的引用最终通过 rockchip_drm_unbind（） 中的 drm_dev_put（） 终止时，drmm_encoder_alloc_release（） 会尝试访问现已发布的编码器结构，从而导致释放后使用。通过从设备管理的分配切换到 drm 管理的分配，确保在编码器清理时仍可访问驱动程序的内部结构。
    (CVE-2026-74422)

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

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

  - Bluetooth：btmtk：修复错误路径alloc_mtk_intr_urb URB 泄漏 当 btmtk_isopkt_pad（） 失败时，之前分配的 URB 不会释放，从而泄漏 urb 结构。返回错误前添加 usb_free_urb（）。（CVE-2026-74301）

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

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

  - irqchip/crossbar：在 crossbar_domain_free（） 中使用正确的索引crossbar_domain_free（） 重置域数据，然后使用出空的 irq_data->hwirq 成员作为索引来重置条目并 irq_map[] 以安全条目写入相关交叉寄存器。这意味着它永远不会释放正确的索引并保持交叉寄存器与源中断的连接处于活动状态。如果它不会重置域数据，则情况会更糟，因为 irq_data->hwirq 保留源中断号，但映射和寄存器索引都需要相应的 GIC SPI 号而不是源中断号。这甚至可能导致越界访问，因为源中断数可能大于最大索引空间。使用父域irq_data的 GIC SPI 索引修复此问题。（CVE-2026-72153）

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

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

  - net：lan743x：在 PCI11x1x 探测序列期间使用 lan743x_hardware_init（） 调用 pci11x1x_strap_get_status（） 之前初始化eth_syslock旋转锁。该帮助程序通过 lan743x_hs_syslock_acquire（） 获取以太网子系统硬件锁定，该协议依赖于适配器>eth_syslock_spinlock序列化访问。当前仅在读取带状状态后才会初始化旋转锁。启用 CONFIG_DEBUG_SPINLOCK 时，采用归零的初始化旋转锁可使旋转锁调试检查跳脱。
    通过在读取挂带状态之前初始化适配器>eth_syslock_spinlock修复，这样探测路径就永远不会尝试锁定未初始化的自旋锁。（CVE-2026-72037）

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

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

  - fbdev：efifb：修复 efifb_probe（） 中的内存泄漏 由于提交 73ce73c30ba9（fbdev：将 video= option 字符串传输至调用程序;明确所有权）预期调用程序释放了从 fb_get_options（） 返回的字符串，但是该字符串并未在 efifb_probe（） 中释放。通过在设置后释放选项字符串来修复此问题。（CVE-2026-72273）

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

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

  - llc：修复 llc_ui_autobind（） 中的 SAP refcount 泄漏 llc_ui_autobind（） 在选择动态 LSAP 后打开 SAP。llc_sap_open（） 返回调用者拥有的引用，llc_sap_add_socket（） 对 SAP 哈希表中套接字的成员资格进行第二个引用。llc_ui_bind（） 在添加套接字后放弃调用者的引用，但 llc_ui_autobind（） 保留它。关闭套接字时，llc_sap_remove_socket（） 仅释放套接字引用，而使 SAP 处于llc_sap_list状态，sk_count == 0。这是用户可见的，因为重复的自动绑定和关闭周期可消耗所有动态 SAP 值并使之后的自动绑定因 -EUSERS 而失败。在与 llc_ui_bind（） 的所有权模型相匹配的自动绑定成功后放弃调用程序的引用。（CVE-2026-72022）

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

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

  - nvdimm/btt：释放 btt_init（） 错误路径中的 arena 由 discover_arenas（） 或 create_arenas（） 分配的 arenas 在 btt_init（） 中的某些错误路径上未释放。BTT 初始化失败时，此问题会泄漏内存。从受影响的错误路径调用 free_arenas（） 以释放分配。[ as：提交消息并记录编辑 ]（CVE-2026-72224）

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

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

  - RDMA/irdma：修复 CQ MR 注册期间的 OOB 读取 Sashiko 指出之前修补程序期间的一个不相关缺陷： https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com 此变更通过消除未正确设置的 cqmr->split 字段，改为直接检查 CQ 大小调整功能标记，来修复此缺陷。cqmr->split字段本质上用于跟踪是否设置了IRDMA_FEATURE_CQ_RESIZE，但直到CQ创建时才进行设置，即CQ内存注册（引用它的唯一其他地方）。因此，在 MR 注册期间，其始终为假，因此将导致 irdma_handle_q_mem 填充 cqmr->shadow，甚至包括针对 GEN_2 HW 及其他版本：
    cqmr->shadow = （dma_addr_t）arr[req->cq_pages];问题是，对于 GEN_2 和更高版本，req->cq_pages 可能正好等于 iwmr->page_cnt，因此等于 arr 的大小，这将导致 OOB 被读取。（CVE-2026-74346）

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

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

  - ntfs3：rt->used 处的 cap RESTART_TABLE自由链遍历器构建的 NTFS3 磁盘映像在挂载时触发内核内无限循环，从而在多 CPU 主机上的 ~22s 秒内挂起挂载线程并触发软锁定监视程序（因 kernel.softlockup_panic=1 混乱）。可从发行版上的桌面 USB 自动挂载访问此缺陷，其中 udisks2 将 NTFS 签名路由到树内 ntfs3 驱动程序（Arch 系列和越来越多的 Fedora / openSUSE / RHEL 部署）;其他地方的CAP_SYS_ADMIN级手动安装。check_rstbl（） 的第二个遍历器迭代以 rt->first_free 为首的自由条目单链表，迭代计数没有上限：for （off = ff; off;）{ if （off == RESTART_ENTRY_ALLOCATED） return false; off = le32_to_cpu（*（__le32 *）Add2Ptr（rt， off））; if （off > ts - sizeof（__le32）） return false; }现有防护涵盖三个退出：列表结尾 （off == 0）、使用中标记 （off == RESTART_ENTRY_ALLOCATED） 和越界 （off > ts - sizeof（__le32））。这三者都不能阻止越界循环。构建的磁盘RESTART_TABLE，其自由链包含自循环或 A->B->偏移满足以下条件的循环：- 在范围 [sizeof（struct RESTART_TABLE）， ts - sizeof（__le32）] - （off
    - sizeof（struct RESTART_TABLE）） % rsize == 0 传递所有现有防护并永久旋转挂载时间线程。通过手工伪造 2 MB NTFS3 图像以 UML 重现，其日志 RESTART_TABLE first_free = 0x18，其偏移0x18的条目将 0x18 存储为下一个指针;通过树内 ntfs3 驱动程序挂载的伪造镜像再也不会返回。通过 rt->used 绑定步行器。合法自由链上的每个条目都是唯一的，总插槽数为 ne = le16_to_cpu （rt->used）。访问超过 ne 个插槽的遍历是构造畸形的;将其作为损坏的RESTART_TABLE拒绝。安装此修补程序后，伪造映像的挂载返回 -EINVAL 和一条log_replay失败消息，并且 mkntfs 生成的合法映像将干净利落（在同一 UML 工具中验证）。（CVE-2026-72193）

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

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

  - wifi：mt76：mt7996：修复 mt7996_mac_write_txwi_80211（） 中可能的空指针取消引用 对于注入的帧（例如通过 radiotap），mac80211 可传递 info->control.vif = NULL，如 struct ieee80211_tx_info 中明确说明。在mt7996_mac_write_txwi_80211例程中执行 ieee80211_vif_is_mld（） 之前检查 vif 指针，以避免可能的空指针取消引用。
    (CVE-2026-74322)

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

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

  - net/sched：sch_hfsc：不使类成为被动两次 update_vf（）在单次出列期间，当类的子 qdisc（如 codel/fq_codel）在出队时丢弃其最后一个数据包时，为同一类从两个位置调用（）：1. 子项调用 qdisc_tree_reduce_backlog（），现在子项为空，后者调用 hfsc_qlen_notify（） -> update_vf（cl， 0， 0） 并将类变为被动（cl_nactive在层次结构中递减）。2. 然后 hfsc_dequeue（） 调用 update_vf（cl， qdisc_pkt_len（skb）， cur_time） 对出列的字节进行充电。在第二次调用中，该类已经是被动的，但它的子 qdisc 仍然是空的，因此 update_vf（） 再次go_passive：if （cl->qdisc->q.qlen == 0 &&; cl->cl_flags &; HFSC_FSC） go_passive = 1;
    然后，循环内的 cl_nactive == 0 检查会跳过叶，这不会清除go_passive，因此过时的go_passive会传播到父并第二次递减其cl_nactive。即使这些同级仍积压，仍有其他活动子进程的父级将被驱动至 cl_nactive == 0 并从 vttree 中删除。它们再也不会出列，并且 qdisc 停止。通过仅在类实际处于活动状态时布防go_passive来修复此问题，这样已经被动的类不再触发第二个被动转换。字节统计 （cl->cl_total += len） 仍会对每个上级运行，因此出列的字节继续只计数一次。（CVE-2026-74284）

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

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

  - ieee802154：修复 dgram_recvmsg（） 中的内核信息泄漏 KMSAN 报告了 move_addr_to_user（） 中的内核信息泄漏： 缺陷： KMSAN：include/linux/instrumented.h：131 instrument_copy_to_user中的内核信息泄漏 [内联] 缺陷： KMSAN：include/linux/uaccess.h：205 _inline_copy_to_user中的内核信息泄漏 [内联] 缺陷： KMSAN：_copy_to_user+0xcc/0x120 lib/usercopy.c：26 中的内核信息泄漏 instrument_copy_to_user include/linux/instrumented.h：131 [内联] _inline_copy_to_user include/linux/uaccess.h：205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c：26 copy_to_user include/linux/uaccess.h：236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c：302
    ____sys_recvmsg+0x232/0x610 net/socket.c：2925 ... Uninit 存储到内存位置：ieee802154_addr_to_sa include/net/ieee802154_netdev.h：369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c：739 发生该问题的原因是当地址模式为“IEEE802154_ADDR_NONE”时，“struct ieee802154_addr”的“pan_id”字段处于未初始化状态。执行流程如下：1. '__ieee802154_rx_handle_packet（）' 在堆栈上声明一个本地 'struct ieee802154_hdr hdr'。2. “ieee802154_hdr_pull（）”调用“ieee802154_hdr_get_addr（）”将源地址和目的地址解析到此结构中。3. 如果地址模式为“IEEE802154_ADDR_NONE”，“ieee802154_hdr_get_addr（）”之前仅设置“模式”字段，而“pan_id”字段则包含未初始化的堆栈内存。4. 这个未初始化的“pan_id”稍后会通过“ieee802154_addr_to_sa（）”复制到“dgram_recvmsg（）”中的“struct sockaddr_ieee802154”。5. 最后，“move_addr_to_user（）”将套接字地址结构复制到用户空间，导致泄漏未初始化的字节。
    当模式为“IEEE802154_ADDR_NONE”时，通过使用“memset”将“ieee802154_hdr_get_addr（）”中的地址结构归零来修复此问题。（CVE-2026-72441）

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

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

  - f2fs：修复 f2fs_balance_fs（） 中可能发生的死锁 当 f2fs 文件系统空间几乎耗尽时，会遇到如下死锁问题： INFO：任务 A：1890 被阻断超过 120 秒。Tainted： G O 6.12.41-g3fe07ddf05ab #1 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 task：A state：D stack：0 pid：1890 tgid：1626 ppid：1153 flags：0x00000204 调用跟踪：__switch_to+0xf4/0x158
    __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 folio_wait_bit+0x20/0x38 folio_wait_writeback+0x54/0xc8 truncate_inode_partial_folio+0x70/0x1e0 truncate_inode_pages_range+0x1b0/0x450 truncate_pagecache+0x54/0x88 f2fs_file_write_iter+0x3e8/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 信息：任务 kworker/u8：11：2680853 被阻断超过 120 秒。Tainted： G O 6.12.41-g3fe07ddf05ab #1 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 task：kworker/u8：11 state：D stack：0 pid：2680853 tgid：2680853 ppid：2 flags：0x00000208 工作队列：writeback wb_workfn （flush-254：0） 调用跟踪：
    __switch_to+0xf4/0x158 __schedule+0x27c/0x908时间表+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 __filemap_get_folio+0x214/0x348 pagecache_get_page+0x20/0x70 f2fs_get_read_data_page+0x150/0x3e8 f2fs_get_lock_data_page+0x2c/0x160 move_data_page+0x50/0x478 do_garbage_collect+0xd38/0x1528 f2fs_gc+0x240/0x7e0 f2fs_balance_fs+0x1a0/0x208 f2fs_write_single_data_page+0x6e4/0x730 f2fs_write_cache_pages+0x378/0x9b0 f2fs_write_data_pages+0x2e4/0x388 do_writepages+0x8c/0x2c8 __writeback_single_inode+0x4c/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x200 信息：任务 kworker/u8：8：2641297 阻塞超过 120 秒。Tainted： G O 6.12.41-g3fe07ddf05ab #1 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。
    task：kworker/u8：8 state：D stack：0 pid：2641297 tgid：2641297 ppid：2 flags：0x00000208 工作队列：writeback wb_workfn （flush-254：0） 调用跟踪：__switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_write_inode+0xf4/0x328
    __writeback_single_inode+0x370/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x20 信息：任务 B：1902 被阻断超过 120 秒。受感染：
    G O 6.12.41-g3fe07ddf05ab #1 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。
    task：B state：D stack：0 pid：1902 tgid：1626 ppid：1153 flags：0x0000020c 调用跟踪：__switch_to+0xf4/0x158
    __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_map_blocks+0x94c/0x1110 f2fs_file_write_iter+0x228/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 信息：任务同步：2769849 被阻断超过 120 秒。污染：G ---truncated--- （CVE-2026-68460）

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

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

  - mlxsw：修复 mlxsw_sp_vrs_lpm_tree_replace（） 中的 refcount 泄漏 当 mlxsw_sp_vrs_lpm_tree_replace（） 在替换某些 VR 后失败时，错误回滚循环不会正确恢复之前的替换。
    循环递减索引，但无法更新 vr 指针，该指针仍指向造成失败的 VR。因此，条件和回滚调用始终在同一个 VR 上运行，可能会对其多次调用 mlxsw_sp_vr_lpm_tree_replace（），而从不回滚较早的 VR。
    这些 VR 继续保留对通过 mlxsw_sp_lpm_tree_hold（） 获取的new_tree的引用，从而泄漏new_tree的引用计数。通过使用更新后的索引重新初始化错误循环中的 vr 进行修复： vr = &mlxsw_sp->router->vrs[i];以便循环正确迭代实际替换的所有 VR。
    (CVE-2026-72307)

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

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

  - drm/syncobj：修复 drm_syncobj_find_fence（） 提交 18226ba52159（drm/syncobj：拒绝 drm_syncobj_find_fence 中的无效标记）中的内存泄漏忘记考虑以下事实：drm_syncobj_find（） 采用对 syncobj 的引用并在不丢弃引用的情况下提早返回，从而导致内存泄漏。报告者：Sam Spencer <sam.spencer@arm.com> （CVE-2026-74393）

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

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

  - i2c：mlxbf：修复 mlxbf_i2c_init_resource（） 中的释放后使用 如果 devm_platform_get_and_ioremap_resource（） 返回错误，mlxbf_i2c_init_resource（） 会在读取 tmp_res->io 以获取错误代码之前释放tmp_res。这会导致释放后使用。释放 tmp_res 之前保存错误代码。（CVE-2026-72140）

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

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

  - RDMA/bnxt_re：避免显示内核指针 使用 rdma 工具转储 MR 上的信息时，我们转储作为内核指针的mr_hwq。无需向最终用户公开此值。所以要避免它。（CVE-2026-72498）

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

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

  - leds：uleds：修复潜在的缓冲区越界读取 用户空间提供的名称字符串不保证以 null 结尾，因此对其使用 strchr（） 可导致缓冲区越界读取。当LED类器件使用所述字符串时，也会发生同样的情况。请使用 strnchr（） 代替并明确检查名称字符串是否正确地以 null 结尾来修复此问题。（CVE-2026-72241）

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

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

  - .NET 中包含不受信任控制领域的功能，允许未经授权的攻击者通过网络泄露信息。（CVE-2026-62902）

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

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

  - power：supply：cpcap-battery：修复导致引用泄漏的缺少 nvmem_device_put（） 在 cpcap_battery_detect_battery_type（） 中，成功或读取失败路径上的 nvmem_device_put（） 不会释放通过 nvmem_device_find（） 获取的 nvmem 设备的引用，从而导致永久引用泄漏。驱动程序对后续电池属性读取的重试逻辑可重增此泄露，使 nvmem 设备永远无法得到释放。由代码审查发现。（CVE-2026-72214）

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

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

  - mm/damon/sysfs-schemes：放置 scheme_add_dirs（） 内部错误的统计信息 damon_sysfs_scheme_add_dirs（） 在 stats 目录设置完成后设置 tried_regions 目录。当 tried_regions 目录设置失败时，设置函数确保释放尝试区域目录的引用。
    因此错误路径应该从 stats 目录开始引用设置成功的目录对象。但是，错误路径放置的是 tried_regions 目录，而不是 stats 目录。
    直接造成泄漏统计目录对象。更糟糕的是，如果 tried_regions 目录设置从初始分配开始失败，则方案>tried_regions字段仍保持未初始化状态。错误路径中的以下 kobject_put（&scheme->tried_regions->kobj） 调用将取消引用未初始化的内存。设置失败应该不常见。但一旦发生，后果就相当糟糕了。通过正确放置 stats 目录而不是 tried_regions 目录修复了此问题。此问题由 Sashiko 发现 [1]。（CVE-2026-72176）

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

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

  - fbdev：hecubafb：修复 hecubafb_probe（） 中可能出现的内存泄漏 错误路径上未释放为 fb_deferred_io_init（） 中的 pagerefs 分配的内存。通过调用 fb_deferred_io_cleanup（） 修复它。
    (CVE-2026-72274)

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

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

  - netfilter：xt_cluster：拒绝哈希匹配中的模板 conntracks xt_cluster_mt（） 将任何非 NULL nf_ct_get（） 结果视为完全初始化的 conntrack 并将其传递至 xt_cluster_hash（）。原始表 CT 目标在正常连接跟踪处理之前将模板连接跟踪附加到 skb->_nfct，这会导致状态混淆错误。模板具有IPS_TEMPLATE状态，但还没有用于哈希的有效元组，因此 xt_cluster_hash（） 可在归零的 l3num 字段中命中其 WARN_ON（） 路径。在对模板连接跟踪进行哈希处理之前将其拒绝。这与针对模板对象的现有 netfilter 处理相匹配，并避免哈希不完整的连接跟踪状态。（CVE-2026-72256）

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

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

  - net：pfcp：为 PFCP netdevs 分配每个 cpu 的 tstats PFCP 使用 dev_get_tstats64（） 作为其ndo_get_stats64回调，但 pfcp_link_setup（） 不请求NETDEV_PCPU_STAT_TSTATS。因此，net 核心会对 PFCP 设备保留 dev->tstats NULL。创建 PFCP rtnetlink 设备可在构建RTM_NEWLINK通知时立即向新 netdev 要求统计数据。这会到达 dev_get_tstats64（） 并取消引用空 dev->tstats 指针。在 PFCP 链接设置期间将 pcpu_stat_type 设置为 NETDEV_PCPU_STAT_TSTATS，以便网核分配 dev_get_tstats64（） 预期的存储。（CVE-2026-74286）

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

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

  - memstick：ms_block：拒绝报告过多区块的卡 msb_ftl_initialize（） 根据无边界的卡区块计数计算区域计数：msb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE;...
    对于 （i = 0;i < msb->zone_count; i++） msb->free_block_count[i] = MS_BLOCKS_IN_ZONE;msb->block_count 是卡值。msb_read_boot_blocks（） 从板卡启动页面读取number_of_blocks，然后对其进行字节交换。
    free_block_count 是固定的 int[MS_MAX_ZONES]。MS_MAX_ZONES为 16，因此有效指数为 0 到 15。上述 init 循环按zone_count对其编制索引。msb_mark_block_used（） 和 msb_mark_block_unused（） 按 pba / MS_BLOCKS_IN_ZONE 对其进行索引，对于高达 block_count - 1 的 PBA。一张卡最多可报告 65535 个区块。高于 8192 （MS_MAX_ZONES * MS_BLOCKS_IN_ZONE） 的block_count让 PBA 指数达到 16。这会写入过去 free_block_count[] 并损坏结构msb_data。较大的计数也会使 init 循环经过结尾。真正的记忆棒最多有 16 个区域。所以它最多有 8192 个区块。msb_ftl_initialize（） 现在拒绝报告超过 MS_MAX_ZONES * MS_BLOCKS_IN_ZONE 区块的卡。（CVE-2026-68478）

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

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

  - Microsoft QUIC 中的释放后使用允许未经授权的攻击者通过网络泄露信息。
    (CVE-2026-62898)

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

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

  - spi：xilinx：使用 FIFO 占用寄存器确定缓冲区大小 驱动程序用于确定 FIFO 大小的方法有问题。它目前的作用是：它停止 SPI 硬件并写入 TX FIFO 寄存器，直到 TX FIFO FULL 在状态寄存器中断言。但是硬件不仅有 FIFO，它还有一个可以容纳字节的移位寄存器。可以看出，当向FIFO写入一个字节时（当SPI硬件停止时），TX FIFO EMPTY仍然是空的。因此，例如，如果我们的 FIFO 大小为 16，则当前方法返回 17。这是一个问题，至少在 irq 模式下使用驱动程序时是这样。为 TX FIFO 确定的大小也与 RX FIFO 相同。当 SPI 事务想要写入 FIFO 大小或更多字节时，会发生以下情况，例如，对于 16 字节的 FIFO 大小：驱动程序停止 SPI 硬件并将 17 字节写入 TX FIFO，启动 SPI 硬件并进入睡眠状态。然后硬件移出 17 个字节（FIFO + 移位寄存器）并同时将字节读入 RX FIFO，但它只有 16 个位置，因此它丢失了一个字节。然后 TX 空 FIFO 断言，再次唤醒驱动程序，该驱动程序具有快速路径并从 RX FIFO 读取 16 字节，但在读取最后第 17 个字节（丢失）之前，它会执行以下操作：sr = xspi->read_fn（xspi->regs + XSPI_SR_OFFSET）;如果 （！（sr &; XSPI_SR_RX_EMPTY_MASK）） { xilinx_spi_rx（xspi）; rx_words--; }它读取状态寄存器并检查 RX FIFO 是否不为空。但在我们的情况下，它是空的。因此，此检查会在 while 循环中旋转，并永久锁定驱动程序。此修补程序修复了用于确定 FIFO 大小的逻辑。
    (CVE-2026-74276)

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

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

  - drm/v3d：拒绝间接 CSD 设置中无效的间接 BO 句柄 v3d_get_cpu_indirect_csd_params（） 会从用户空间提供的句柄中查找间接缓冲区对象，但从不检查结果。虚假或过时句柄使 drm_gem_object_lookup（） 返回 NULL，然后存储在 info->indirect 中，稍后只有在间接 CSD 作业运行时才会取消引用，从而将用户空间错误在内核中转变为空指针取消引用。查找失败时立即使用 -ENOENT 退出，以便在提交时拒绝错误句柄。（CVE-2026-72327）

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

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

  - fbdev：vesafb：修复 vesafb_probe（） 中的内存泄漏 自提交 73ce73c30ba9（fbdev：将 video= option 字符串传输至调用程序;明确所有权）预期由调用程序释放从 fb_get_options（） 返回的字符串。但是该字符串未在 vesafb_probe（） 中释放。通过在设置后释放选项字符串来修复此问题。（CVE-2026-72266）

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

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

  - dmaengine：dma-axi-dmac：正确释放 struct axi_dmac_desc 调用 axi_dmac_prep_peripheral_dma_vec（） 中的 axi_dmac_alloc_desc（） 时，使用 axi_dmac_free_desc（） 完全释放失败路径中的描述符。
    (CVE-2026-72475)

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

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

  - ALSA：usb-audio：qcom：流启用失败时清除已打开 启用时，已在验证service_interval前设置 subs->opened;无效间隔会跳转到响应标签而不将其清除，因此子流会停滞在 -EBUSY 处，直到禁用或断开连接。清除启用错误路径中的 subs->open。
    (CVE-2026-72445)

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

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

  - hwmon：（aspeed-g6-pwm-tach） 防止除以零的风扇 RPM 计算 Sashiko 报告：在 aspeed-g6-pwm-tacho 驱动程序中，aspeed_tach_val_to_rpm（） 函数使用转速表值计算风扇 RPM。但是，在执行除法之前，它不会检查转速表值是否为零。如果硬件报告的转速表值为 0（这可能是由于极快的脉冲、卡住的边缘或硬件故障而发生的），则计算的tach_div评估为 0。后续调用以 tach_div 作为除数的 do_div（） 会触发除以零异常，从而导致内核错误。
    检查零的除数以修复问题。（CVE-2026-72394）

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

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

  - octeontx2-af：设置失败时释放 BPID 位图 nix_setup_bpids（） 使用使用普通 kcalloc（） 的 rvu_alloc_bitmap（） 分配 bp->bpid。如果 BPID 映射数组的以下任一 devm_kcalloc（） 分配失败，函数返回时不释放位图。请在从这些错误路径返回之前释放 BPID 位图。（CVE-2026-72050）

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

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

  - lockd：当 nlm_do_fopen（） 失败时插入nlm_file泄漏 客户端可通过提供底层导出拒绝的文件句柄重复导致 nlm_do_fopen（） 失败。kzalloc_obj（） 在 nlm_lookup_file（） 中成功后，新分配的nlm_file尚未插入 nlm_files[]。nlm_do_fopen（） 失败路径跳至out_unlock，后者释放nlm_file_mutex并在返回而不释放分配，因此每次失败都会泄露一个nlm_file。通过 out_free 路由失败，使 kfree（） 在函数返回之前运行。（CVE-2026-72219）

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

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

  - .NET Framework 中的整数溢出或回绕允许未经授权的攻击者在本地执行代码。
    (CVE-2026-62897)

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

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

  - net/sched：act_ct：修复两个错误路径中的nf_connlabels泄漏 tcf_ct_fill_params（） 在存在TCA_CT_LABELS时调用 nf_connlabels_get（）（设置 put_labels），但两个之后的错误站点使用裸返回而非 goto err，从而跳过 err： nf_connlabels_put（） 清理。它们还位于 p->put_labels = put_labels 赋值之前，因此 tcf_ct_params_free（） 回退也不会释放计数。这些路径上的每个失败RTM_NEWACTION都会泄漏一个nf_connlabels引用：net->ct.labels_used 已递增且永不释放。可通过 netns 上的CAP_NET_ADMIN访问该操作，即从 default-userns 内核中的非特权用户命名空间访问。影响：通过网络命名空间（例如通过用户命名空间）CAP_NET_ADMIN的非特权用户在两个错误路径中每RTM_NEWACTION失败泄露一个nf_connlabels引用;net->ct.labels_used 永远不会发布。err： 标签可从两个站点安全访问：p->tmpl 仍为 NULL（kzalloc'd，尚未分配）且 nf_ct_put（NULL） 为非 op，因此不需要内联释放。（CVE-2026-72430）

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

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

  - reset：sunxi：修复 ioremap 失败时的内存区域泄漏 在 sunxi_reset_init（） 中，当 ioremap（） 失败时，通过 request_mem_region（） 获取的内存区域不会释放，从而导致资源泄漏。添加err_mem_region标签以在释放数据结构之前正确释放内存区域。
    (CVE-2026-68475)

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

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

  - ocfs2：修复 ocfs2_assure_trans_credits 中的空h_transaction取消引用 [缺陷] 当日志在 DIO 完成期间中止时，通过未写入的盘区直接写入可造成 ocfs2_assure_trans_credits（） 中的内核错误。崩溃是空指针取消引用造成的一般保护错误。[原因] ocfs2_dio_end_io_write（） 在直接写入的未写入盘区中循环，并在单个日志句柄下标记每个写入盘区。如果在更新盘区树时日志中止（例如，在 I/O 错误之后），则句柄将保持中止状态，并清除其事务指针。盘区合并将该失败视为不严重并报告成功，因此循环会继续使用句柄。
    ocfs2_assure_trans_credits（） 读取句柄的剩余信用，但不首先检查句柄是否已中止，并且该读取会取消引用已清除的事务指针。[修复]句柄本身中记录了日志中止，因此调用者应该测试句柄，而不是依赖返回的错误。让 ocfs2_assure_trans_credits（） 执行此操作，就像其他 ocfs2 日志帮助程序已执行的操作一样，并在句柄中止时返回 -EROFS。（CVE-2026-72163）

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

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

  - fpga：dfl：在 dfh_get_param_size（） 中添加边界检查 dfh_get_param_size（） 可返回大于特征区域的参数大小，因为循环边界检查是在递增大小之前计算的。如果在同一迭代中设置 EOP（参数结尾）位，则返回膨胀的大小，而不对最大值进行重新验证。当恶意的 FPGA 设备提供特制的 DFHv1 参数标头时，这可导致 create_feature_instance（） 调用大小大于 ioremap'd 区域的 memcpy_fromio（）。在大小递增后添加边界检查，以确保累计大小永远不会超过要素边界。
    (CVE-2026-72158)

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

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

  - Bluetooth：hci_qca：修复非 serdev 设备的 qca_setup（） 中的空指针取消引用 hu->serdev 对于通过非 serdev 路径附加的hci_uart为 NULL，但 qca_setup（） 会无条件调用 serdev_device_get_drvdata（hu->serdev） 并取消引用结果，从而造成空指针取消引用。通过使用空检查保护取消引用来修复，与 qca_setup（） 的其余部分一致。（CVE-2026-74304）

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

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

  - drm/panthor：修复在提供平铺程序 OOM 服务之前逐出群组时的泄漏 群组 ref 与待定tiler_oom_work相关联，因此如果取消有效，我们需要将其释放。（CVE-2026-72386）

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

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

  - usb：atm：ueagle-atm：在 .disconnect（） 中等待预固件加载。ueagle-atm 在 .probe（） 中使用异步 request_firmware_nowait（），但不等待其完成，即使在 .disconnect（） 中也不会;
    因此，如果同时拔下设备，则其拆卸会与此同时运行。尽管这种不一致值得单独解决，但它多年来也在 syzbot 中触发了多个错误报告（其中一些是自动关闭的），其中固件 sysfs 回退机制 （CONFIG_FW_LOADER_USER_HELPER） 在删除期间在设备目录中创建了固件子目录，这显然可能会在 kernfs 中遇到意外情况，具体取决于添加和删除操作在哪个点争用。（见链接。模式为：usb ?-?：直接固件加载 ueagle-atm/eagle？。fw 失败，出现错误 -2 usb ?-?：回退到 sysfs 回退：ueagle-atm/eagle？。fw <ERROR> 调用跟踪：...kernfs_create_dir_ns sysfs_create_dir_ns create_dir kobject_add_internal kobject_add_varg kobject_add class_dir_create_and_add get_device_parent device_add fw_load_sysfs_fallback fw_load_from_user_helper firmware_fallback_sysfs
    _request_firmware request_firmware_work_func ... （在 fw_load_sysfs_fallback（） 之后观察到一些变化，例如 [1]。在查看 kernfs 端时，可以通过等待 .disconnect（） 处理程序中的预固件加载来修复 ueagle-atm 端。此更改的方法与 Andrey Tsygunka [2] 之前的工作类似（.disconnect（） 中的 wait_for_completion（），但在设计/实现方面相对不同;使用 Originally-by 标签进行学分分配。这已经通过以下测试： - 用于检查错误路径的合成复制器;- 用于检查固件上传路径的 USB 小工具（虚拟设备）;- 用于检查设备 ID 重新枚举路径的 QEMU 设备仿真器;（后两者由 Claude 编写;此提交中没有其他代码/文本。）链接（首次报告年份）： 2025 https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d 2025 https://syzbot.org/bug?extid=9af8471255ac36e34fd42024 https://syzbot.org/bug?extid=306212936b13e520679d 2023 https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 2022 https://syzbot.org/bug?extid=782984d6f1701b526edb 2021 https://syzbot.org/bug?id=f3f221579f4ef7e9691281f3c6f56c05f83e8490 2021 https://syzbot.org/bug?id=84d86f0d71394829df6fc53daf6642c045983881 2021 https://syzbot.org/bug?id=3302dc1c0e2b9c94f2e8edb404eabc9267bc6f90 [1] https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 [2] https://lore.kernel.org/lkml/20250410093146.3776801-2-aitsygunka@yandex.ru/ （CVE-2026-68456）

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

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

  - wifi：mwifiex：修复多次漫游迭代后的永久忙碌扫描 为使固件进入睡眠状态，驱动程序必须确认之前收到的睡眠请求。evets 的正常顺序是这样的：EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE
    ->唤醒。在发送 sleep-confirm 命令之前，驱动程序必须确保没有正在运行或等待完成的命令。mwifiex_ret_802_11_associate（） 在正常节能管理流之外处理关联命令响应时，会无条件地设置 ps_state = PS_STATE_AWAKE。如果EVENT_SLEEP在关联命令正在执行时到达，则在解析关联命令响应时PRE_SLEEP ps_state，并且强制的 AWAKE 将对其进行覆盖。从不发送延迟的 sleep-confirm。可正确确认后续scan_start命令，但固件不会生成scan_result事件。扫描请求永不完成，来自用户空间的其他请求因 -EBUSY 而失败。在对 IW412 和 W8997进行测试后，我只能触发 IW412 错误，并观察到固件的行为不同。在进行 IW412 身份验证/关联过程时，固件仍会发送EVENT_SLEEP。在相同条件下，A W8997 似乎在关联期间抑制了节能，因此即使在使用下述循环（>12 小时）进行长时间测试后，PRE_SLEEP也不会与关联响应重合。根据 IW412经验，触发EVENT_SLEEP的命令之间的延迟被确定为 ~20 毫秒。当驱动程序输出调试信息 （debug_mask = 0x00000037） 时，自然会发生此延迟，在这种情况下，当运行测试 1 时，忙扫描问题会重复出现，如下所述。如果命令之间的延迟小于 ~20 毫秒，则固件会保持唤醒状态，且在运行相同测试时无法重现此问题。host_mlme=false 路径的行为也不同。在这种情况下，整个身份验证/关联事务由一个命令 （HostCmd_CMD_802_11_ASSOCIATE） 执行，并且在命令运行时固件不会发出EVENT_SLEEP。删除分配，以便只在与节能事件处理相关的路径和主工作队列上操纵ps_state，从而进行正确的休眠确认。执行了以下循环测试（启用调试输出）：1） 在两个 AP（一个 5GHz，一个 2.4GHz）之间强制漫游，SSID相同。使用 wpa_cli 触发漫游行为，迭代间隔休眠 2 秒。2） 强制断开与 AP 1 的连接并与 AP 2 的连接，测试扫描。使用 wpa_cli 触发连接变更，迭代间隔休眠 2 秒。每次测试在每台设备中运行至少 3 小时。（CVE-2026-68469）

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

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

  - drm/xe/hw_engine：修复错误路径中托管 BO 的双重释放 hw_engine_init（） 中的错误路径通过 xe_bo_unpin_map_no_vm（） 显式释放使用 xe_managed_bo_create_pin_map（） 分配的 BO。由于托管 BO 已注册 devm 清理操作，当探测失败期间 devm 展开时，这会造成双重释放。删除显式释放并让 devm 处理它，与所有其他 xe_managed_bo_create_pin_map（） 调用程序一致。（从提交 e459a3bdeb117be496d7f229e2ea1f6c9fe4080b 中精选出的内容）（CVE-2026-72361）

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

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

  - 在 BlueZ 中发现一个缺陷。音频/视频远程控制配置文件 （AVRCP） 实现中对 GetFolderItems 响应中数据包长度字段的验证不足，允许范围内的恶意蓝牙设备造成越界内存读取。此漏洞影响 parse_media_element（） 和 parse_media_folder（） 函数，可导致 bluetoothd 后台程序崩溃，从而导致拒绝服务 （DoS）。它还可能暴露敏感的堆内存内容。
    利用此漏洞需要用户交互才能与恶意设备配对。（CVE-2026-75032）

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

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

  - vmalloc：修复 is_vm_area_hugepages（） 中的空指针取消引用 find_vm_area（） 可在指定的地址不是有效的 vmalloc 区域时返回 NULL。在取消引用返回值之前检查返回值以避免内核崩溃。（CVE-2026-74327）

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

ID	名称	严重性
337836	Linux Distros 未修补的漏洞：CVE-2026-74352	high
337835	Linux Distros 未修补的漏洞：CVE-2026-72391	high
337834	Linux Distros 未修补的漏洞：CVE-2026-68464	medium
337833	Linux Distros 未修补的漏洞：CVE-2026-72212	high
337832	Linux Distros 未修补的漏洞：CVE-2026-74422	medium
337831	Linux Distros 未修补的漏洞：CVE-2026-74301	medium
337830	Linux Distros 未修补的漏洞：CVE-2026-72153	high
337829	Linux Distros 未修补的漏洞：CVE-2026-72037	medium
337828	Linux Distros 未修补的漏洞：CVE-2026-72273	medium
337827	Linux Distros 未修补的漏洞：CVE-2026-72022	medium
337826	Linux Distros 未修补的漏洞：CVE-2026-72224	medium
337825	Linux Distros 未修补的漏洞：CVE-2026-74346	medium
337824	Linux Distros 未修补的漏洞：CVE-2026-72193	medium
337823	Linux Distros 未修补的漏洞：CVE-2026-74322	medium
337822	Linux Distros 未修补的漏洞：CVE-2026-74284	medium
337821	Linux Distros 未修补的漏洞：CVE-2026-72441	high
337820	Linux Distros 未修补的漏洞：CVE-2026-68460	medium
337819	Linux Distros 未修补的漏洞：CVE-2026-72307	medium
337818	Linux Distros 未修补的漏洞：CVE-2026-74393	medium
337817	Linux Distros 未修补的漏洞：CVE-2026-72140	high
337816	Linux Distros 未修补的漏洞：CVE-2026-72498	high
337815	Linux Distros 未修补的漏洞：CVE-2026-72241	high
337814	Linux Distros 未修补的漏洞：CVE-2026-62902	medium
337813	Linux Distros 未修补的漏洞：CVE-2026-72214	high
337812	Linux Distros 未修补的漏洞：CVE-2026-72176	medium
337811	Linux Distros 未修补的漏洞：CVE-2026-72274	medium
337810	Linux Distros 未修补的漏洞：CVE-2026-72256	medium
337809	Linux Distros 未修补的漏洞：CVE-2026-74286	medium
337808	Linux Distros 未修补的漏洞：CVE-2026-68478	medium
337807	Linux Distros 未修补的漏洞：CVE-2026-62898	high
337806	Linux Distros 未修补的漏洞：CVE-2026-74276	medium
337805	Linux Distros 未修补的漏洞：CVE-2026-72327	medium
337804	Linux Distros 未修补的漏洞：CVE-2026-72266	medium
337803	Linux Distros 未修补的漏洞：CVE-2026-72475	high
337802	Linux Distros 未修补的漏洞：CVE-2026-72445	medium
337801	Linux Distros 未修补的漏洞：CVE-2026-72394	medium
337800	Linux Distros 未修补的漏洞：CVE-2026-72050	high
337799	Linux Distros 未修补的漏洞：CVE-2026-72219	high
337798	Linux Distros 未修补的漏洞：CVE-2026-62897	high
337797	Linux Distros 未修补的漏洞：CVE-2026-72430	medium
337796	Linux Distros 未修补的漏洞：CVE-2026-68475	medium
337795	Linux Distros 未修补的漏洞：CVE-2026-72163	medium
337794	Linux Distros 未修补的漏洞：CVE-2026-72158	medium
337793	Linux Distros 未修补的漏洞：CVE-2026-74304	medium
337792	Linux Distros 未修补的漏洞：CVE-2026-72386	medium
337791	Linux Distros 未修补的漏洞：CVE-2026-68456	medium
337790	Linux Distros 未修补的漏洞：CVE-2026-68469	high
337789	Linux Distros 未修补的漏洞：CVE-2026-72361	high
337788	Linux Distros 未修补的漏洞：CVE-2026-75032	medium
337787	Linux Distros 未修补的漏洞：CVE-2026-74327	medium

检测

Nessus 的 Misc. 系列

high

high

medium

high

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

high

high

high

medium

high

medium

medium

medium

medium

medium

high

medium

medium

medium

high

medium

medium

high

high

high

medium

medium

medium

medium

medium

medium

medium

high

high

medium

medium