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

  - thunderbolt：property：拒绝 dir_len < 4 以防止size_t下溢 在非根路径中，
    __tb_property_parse_dir（） 从 entry->length 获取dir_len（u16 加宽为 size_t）。当条目>长度< 4：1 时，会出现两个不同的 OOB 条件。非根路径以 kmemdup（&block[dir_offset]， sizeof（*dir->uuid） ...） 开头，始终从 dir_offset读取 4 个 dword。tb_property_entry_valid（） 仅强制执行 dir_offset + entry->length <= block_len，因此构建的条目dir_offset接近属性块的末尾，entry->length 为 0..3 通过该门，但让 UUID 副本从该块中运行（例如，500-dword 块中的 dir_offset = 497，dir_len = 3 读取块 [497..501]）。2. 在 kmemdup 之后，content_len = dir_len - 4 下溢size_t到 ~SIZE_MAX，nentry 变为 SIZE_MAX / 4，条目遍历在每次迭代时运行 OOB，直到条目验证失败或内核在未映射的页面上 oops。
    拒绝 UUID kmemdup *之前*非根路径上的dir_len < 4，这将关闭两个漏洞。还会将 INIT_LIST_HEAD（&dir->properties） 上移到目录分配之后，这样调用 tb_property_free_dir（） 的新错误返回路径（以及现有的 uuid-alloc 失败路径）会看到一个可漫步的列表，而不是 list_for_each_entry_safe（） 会 oops 的零初始化的空 next/prev。（CVE-2026-63892）

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

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

  - Input：xpad - 修复共享按钮的越界访问 xpadone_process_packet（） 直接从 urb->actual_length 接收 len，并将其用于索引 data[len - 18] 或 data[len - 26] 中的共享按钮字节。
    由于 len 和 data[0] 都在设备的控制之下，因此损坏的控制器可发送actual_length < 18（例如 5 字节）的 GIP_CMD_INPUT 数据包并到达此代码路径，从而导致超出实际数组的访问。通过计算偏移量并检查数据包长度的边界来修复此问题。（CVE-2026-63943）

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

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

  - wifi：mac80211：ieee80211_ml_epcs IEEE80211_MLE_STA_EPCS_CONTROL_LINK_ID 中的边界检查link_id 0x000f，因此从PRIO_ACCESS ML 元素PER_STA_PROFILE子元素提取的link_id可能是 0..15。
    sdata->link[] 有 IEEE80211_MLD_MAX_NUM_LINKS （15） 个条目（索引 0..14），使索引 15 越界。
    连接的WiFi 7 AP可以通过发送具有PER_STA_PROFILE子元素（link_id = 15）的EPCS启用响应操作帧来触发此漏洞。只要 EPCS 已启用，便可访问 unsolicited-notification 路径 （dialog_token = 0），而无需事先请求任何客户端。sdata->link[15] 会读入 sdata->activate_links_work（INIT_LIST_HEAD后嵌入list_head为非 NULL 的wiphy_work）的第一个单词，因此对结果的 NULL 检查不会捕获无效访问。然后将垃圾指针传递到 ieee80211_sta_wmm_params（），从而取消引用 link->sdata 并造成内核崩溃。通过提交 162d331d833d 修复了 ieee80211_ml_reconfiguration（） 的同类缺陷（wifi：mac80211：ieee80211_ml_reconfiguration 中的边界检查link_id）。（CVE-2026-64030）

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

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

  - mm/page_alloc：修复具有init_on_free __GFP_ZEROTAGS语义的巨大零作品集的标签初始化目前有点奇怪，但实际上此标记只会与 __GFP_ZERO 和
    __GFP_SKIP_KASAN。如果以 init_on_free 运行，则会在 __free_pages_prepare（） 期间将页面归零，从而跳过分配路径上的清零。但是，使用__GFP_ZEROTAG集进行分配时，post_alloc_hook（） 不仅会跳过清除页面内容，还会跳过清除标记内存。不通过__GFP_ZEROTAGS清除标记与之后将通过 set_pte_at（） 映射到用户空间的大多数页面无关：set_pte_at（） 和好友将检测到标签尚未初始化（PG_mte_tagged未设置），并对其进行初始化。但是，对于将通过标记为特殊的 PMD 映射的巨大零作品集，将不会执行此初始化，最终会暴露仍然为页面设置的任何标记。文档 （Documentation/arch/arm64/memory-tagging-extension.rst） 指出，当页面首次映射到用户空间时，分配标记设置为 0。启用init_on_free时，这不再适用于巨大的零对开本。通过将 __GFP_ZEROTAGS 与 __GFP_ZERO 分离，将是否也要清除页面内容传递给 tag_clear_highpages（），来修复此问题。反转 tag_clear_highpages（） 返回值的含义以具有更清晰的语义。在确保页面在释放时具有非 0 标签集后，通过修改 check_buffer_fill arm64/mte 自我测试以使用 2 MiB 区域，以巨大的零作品集重现（请注意，在引导过程中，我们实际上不会初始化标签，而仅在页面标记中设置KASAN_TAG_KERNEL）。$ ./check_buffer_fill 1..20 ...不正常 17 检查含有私有映射、同步错误模式和 mmap 内存的初始标签 不正常 18 检查含有私有映射、同步错误模式和 mmap/mprotect 内存的初始标签... 此代码需要更多清理;接下来我们将解决这个问题，例如将__GFP_ZEROTAGS与__GFP_SKIP_KASAN解耦。[akpm@linux-foundation.org：s/__GPF_ZERO/__GFP_ZERO/，根据 David]（CVE-2026-64130）

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

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

  - 低于 1.3.9c 和 1.3.10rc3 的 ProFTPD 在 mod_sftp 模块中包含一个基于堆的缓冲区溢出漏洞，允许经认证的低权限攻击者通过发送超过 fxp.c 组件中 16 KB 重组缓冲区的构建 SFTP 数据包片段来实现任意代码执行。攻击者可提供超大片段以触发条件不正确的重新分配、损坏池免费表元数据、覆盖 root_fs BSS 全局指针以引用假文件系统结构，以及通过构建的 RENAME 请求将 pr_fsio_stat（） 重定向到 system（）。（CVE-2026-63090）

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

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

  - bpf：传播来自 visit_tailcall_insn 提交的错误 e40f5a6bf88a（bpf：更正末尾调用的堆栈活动性）添加了 visit_tailcall_insn（），但未检查其返回值。（CVE-2026-63864）

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

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

  - 解析 .rdp 连接文件的 selectedmonitors 字段时，3.x（通过 3.27.1影响）之前3.28.0的 FreeRDP 在 freerdp_client_rdp_file_apply_to_settings（） （client/common/file.c） 中包含一个双重释放漏洞。通过 settings 对象分配 MonitorIds 数组，并且在不清除 settings->MonitorIds 的情况下，在 strtoul 错误路径上释放指向该数组的原始非拥有指针，使其悬摆;在拆卸时，freerdp_settings_free（） 会再次释放相同的缓冲区。如果攻击者诱使受害者打开带有超大监控令牌的特制 .rdp 文件，则可以在默认配置下的任何 FreeRDP CLI 客户端 （xfreerdp/sdl-freerdp/wlfreerdp） 中触发大小控制的双重释放。（CVE-2026-64621）

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

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

  - 隧道：不假设 iptunnel_pmtud_check_icmp（） 中的传输标头 在某些情况下，可在未设置 skb 传输标头的情况下调用 iptunnel_pmtud_check_icmp（）。这会触发越界访问，因为 （typeof（skb->transport_header））~0U 为 65535。在确保 skb 线性部分中存在 icmp->type 后，根据 IPv4 网络标头访问 icmp 标头。请注意，iptunnel_pmtud_check_icmpv6（）） 没有问题。（CVE-2026-63992）

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

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

  - batman-adv：bla：避免通过丢弃的接口对声明进行空指针取消引用 在未保留rtnl_lock的情况下，可能会将 hardif 作为 meshif 的主接口检索，然后（在此接口上操作时）与 mesh 接口解耦。在这种情况下，meshif 仍然存在，但从主 hardif 到 meshif 的指针设置为 NULL。必须首先检查mesh_iface为非 NULL，然后才能继续使用 meshif 发送 ARP 请求。（CVE-2026-64094）

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

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

  - ASoC：编解码器：pcm512x：修复 pcm512x_overclock_xxx_put（） 中的空指针取消引用 在 pcm512x 芯片组驱动程序中，pcm512x_overclock_xxx_put（） 定义为通用混合器 kcontrol，而非 DAPM kcontrol，因此不得通过 snd_soc_dapm_kcontrol_to_dapm（） 访问结构snd_soc_dapm_context。这会导致空指针取消引用，因此必须对其进行修改以使用 snd_soc_component_to_dapm（）。（CVE-2026-64107）

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

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

  - mm/migrate_device：修复 migrate_vma_insert_huge_pmd_page 中的 pgtable 泄漏 当 migrate_vma_insert_huge_pmd_page（） 由于 PMD 检查失败而跳至unlock_abort时，之前通过 pte_alloc_one（） 分配的 pgtable 永远不会释放，从而导致内存泄漏。添加了free_abort标签以释放错误路径中的 pgtable。（CVE-2026-63953）

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

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

  - usb：musb：omap2430：修复 omap2430_probe（） 中的释放后使用 在 omap2430_probe（） 中，of_node_put（np） 会在最后一次访问 np 之前过早调用，如果节点的引用计数降至零，则会导致释放后使用。在成功路径和错误路径中最后一次使用 np 之后移动 of_node_put（） 调用。
    (CVE-2026-63906)

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

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

  - iio：adc：mt6359：修复 mt6358_read_imp 中未检查的返回值 在 mt6358_read_imp（） 中，变量 val_v 传递给 regmap_read（），但未检查返回值。如果读取失败，val_v 将保持未初始化状态，其随机堆栈内容随后会作为测量结果进行报告。将val_v初始化为零以确保在总线故障时报告可预测值并防止潜在的堆栈数据泄漏。这还可以满足静态分析器的要求，否则可能会将变量标记为未初始化而使用。（CVE-2026-63936）

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

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

  - erofs：修复未对齐盘区的托管缓存争用 引入未对齐的压缩盘区后，可能发生以下争用：[线程 1] [线程 2] （z_erofs_fill_bio_vec） <handle a Z_EROFS_PREALLOCATED_FOLIO folio> ...filemap_add_folio （1） （z_erofs_bind_cache） <the same folio is found..> .. .. 再次folio_attach_private （2） filemap_add_folio （3） 由于 （1） 已执行但 （2） 尚未执行，因此由于 folio->private 仍Z_EROFS_PREALLOCATED_FOLIO，其他线程可能在 z_erofs_bind_cache（） 中发现不同 pcluster 的同一受管 folio 并再次调用 filemap_add_folio（）。通过在使 folio 在受管缓存中可见之前显式清除 folio->private 来修复此问题，以便另一个 pcluster 可以像我们对其他共享用例 [1] 一样在锁定的受管作品集上等待。此问题仅影响未对齐的数据压缩（例如，带有 zstd 的“-E48bit”）。[1] 提交 9e2f9d34dd12（erofs：正确处理构建的图像之外的重叠 pclusters）最初是为了处理构建的重叠盘区而引入的，但它也解决了未对齐的盘区。（CVE-2026-64031）

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

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

  - net：garp：修复 garp_pdu_parse_attr 中的无符号整数下溢 接收端 GARP 属性解析器计算具有反向操作数的 dlen：dlen = sizeof（*ga） - ga->len;ga->len 是在线属性长度，包含 GARP 属性标头。对于具有数据的普通属性，ga->len 大于 sizeof（*ga），因此无符号算术中的减法下溢。结果值随后传递给其长度参数为 u8 的 garp_attr_lookup（）。截断后，解析的数据长度通常不再与为本地注册的属性存储的长度匹配，因此会忽略接收到的加入/退出事件。这会中断通用属性（如 GVRP VLAN 注册属性）的 GARP 接收路径。计算数据长度为属性长度减去标头长度。（CVE-2026-63868）

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

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

  - IIO：ADC：NXP-SAR-ADC：修复 write_raw 中的除以零问题 在将采样频率值用作除数之前，先对其进行验证检查。用户在 sampling_frequency sysfs 属性中写入零或负值会在内核中触发除零操作。此外，当计算的周期计数小于 NXP_SAR_ADC_CONV_TIME 时，防止无符号整数下溢，这会将 u32 inpsamp 封装成一个巨大的值。（CVE-2026-63935）

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

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

  - bridge：mcast：修复删除桥接端口时可能的释放后使用 启用了每个 VLAN 多播嗅探时，桥接将迭代所有桥接端口，在每个端口上禁用每个端口多播上下文，并改为启用每个 {port， VLAN} 多播上下文。禁用每 VLAN 组播嗅探时，会发生相反的情况。启用全局组播嗅探后，网桥将迭代所有网桥端口，并在每个端口上启用每端口组播上下文。禁用多播嗅探时，会发生相反的情况。上述方案可导致在单个桥接端口上同时启用两种上下文（每端口和每{端口，VLAN}）的情况：# ip 链路添加名称 br1 up 类型桥接 mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip 链路添加名称 dummy1 up 主 br1 类型虚拟 # ip 链路设置 dev br1 类型桥接 mcast_vlan_snooping 1 # ip 链路设置 dev br1 类型桥接 mcast_snooping 0 # ip 链路将 dev br1 类型桥接设置为 1 mcast_snooping这不是预期的，它是自下面引用的提交以来的一个问题。在此提交之前，删除桥接端口时，br_multicast_disable_port（） 会在刷新 VLAN 时禁用每个端口的多播上下文，而每个 {port， VLAN} 的多播上下文会被禁用。此提交后，br_multicast_disable_port（） 仅在禁用每 VLAN 多播嗅探的情况下禁用每端口多播上下文。如果在删除桥接端口时同时启用了该端口这两种类型的上下文，则在释放桥接端口时，每个端口多播上下文将保持启用状态，从而导致释放后使用 [1]。如果启用了每 VLAN 多播嗅探，则通过阻止桥接在切换全局多播嗅探时启用/禁用每个端口多播上下文来修复。[1] ODEBUG：释放活动（活动状态 0）对象：ffff88810f8bda78 对象类型：timer_list提示：
    br_ip6_multicast_port_query_expired （net/bridge/br_multicast.c：1927） WARNING： lib/debugobjects.c：629 at debug_print_object+0x1b1/0x3e0， CPU#5： swapper/5/0 [...]调用跟踪： <IRQ> __debug_check_no_obj_freed （lib/debugobjects.c：1116） kfree （mm/slub.c：2620 mm/slub.c：6250 mm/slub.c：6565） kobject_cleanup （lib/kobject.c：689） rcu_do_batch （kernel/rcu/tree.c：2617） rcu_core （kernel/rcu/tree.c：2869） handle_softirqs （kernel/softirq.c：622） __irq_exit_rcu （kernel/softirq.c：656 kernel/softirq.c：496 kernel/softirq.c：735） irq_exit_rcu （kernel/softirq.c：752） sysvec_apic_timer_interrupt （arch/x86/kernel/apic/apic.c：1061 （discriminator 47） arch/x86/kernel/apic/apic.c：1061 （鉴别器 47）） </IRQ> （CVE-2026-64032）

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

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

  - Bluetooth：hci_sync：修复同时发布 rcu_read_lock（） 和 hci_dev_lock（hdev） 之后的 hci_le_create_cis_sync hci_le_create_cis_sync（） 取消引用 conn->conn_timeout 中的 UAF。连接指针通过 hdev->conn_hash.list 上受 RCU 保护迭代获取，一旦释放这些锁，此指针将无效。并发断开连接可释放解锁与取消引用之间的hci_conn，造成释放后使用读取。hci_conn_del（） 中的取消机制无法阻止此情况，因为 hci_le_create_cis_pending（） 排队时hci_create_cis_sync data=NULL： hci_cmd_sync_queue（hdev， hci_create_cis_sync， NULL， NULL）;当 hci_conn_del（） 以 data=conn 出列时：hci_cmd_sync_dequeue（hdev， NULL， conn， NULL）;由于 NULL ！= conn，因此 _hci_cmd_sync_lookup_entry（） 中的查找从不匹配，并且不会取消待定的工作项。通过在仍保留锁时将 conn->conn_timeout 保存到本地变量来修复此问题，这样在解锁之后就永远不会取消引用过时的连接指针。这类缺陷与认可 035c25007c9e 所修复的缺陷类型相同（蓝牙：hci_sync：修复 le_read_features_complete 上的 UAF），后者解决了不同函数中的相同模式。该漏洞是使用开源自动化安全审计平台 （https://github.com/0sec-labs0sec.ai） 识别的。（CVE-2026-63944）

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

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

  - net：ena：PHC：设置时间戳输出前检查返回代码 无论 ena_com_phc_get_timestamp（） 成功还是失败，ena_phc_gettimex64（） 都会设置输出参数。当 ena_com_phc_get_timestamp（） 返回错误时，时间戳参数可能包含未初始化的堆栈内存（例如，当 PHC 禁用或处于阻止状态时）或无效的硬件值。通过 PTP ioctl 将这些内容传递到用户空间既是安全问题（信息泄漏），也是正确性缺陷。通过在释放锁定后检查返回代码且仅在成功时设置输出时间戳修复。
    (CVE-2026-63837)

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

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

  - mm/vma：如果从 mmap（） 调用 mmap_prepare（），则不尝试取消映射 VMA mmap_prepare 钩子功能包括从现有“堆栈”驱动程序（即能够调用其他驱动程序/文件系统 mmap 钩子的驱动程序）的 mmap（） 钩子调用 mmap_prepare（） 的功能
    OverlayFS、SHM）。作为mmap_prepare操作功能的一部分，我们在出现错误时通过取消映射 VMA 来处理错误。这适用于通常的mmap_prepare情况，因为我们在枫树中建立 VMA 的最后一刻调用此操作。但是，mmap（） 挂钩会将未完全建立的 VMA 指针传递给分离的调用程序（这是 mmap_prepare（） 工作背后的动机）。因此，尝试取消映射处于此状态的 VMA 将会产生问题，最明显的症状是 vma_mark_detached（） 中的警告，因为 VMA 已分离。这也是不必要的 - mmap（） 处理程序将在出错时清理 VMA。因此，无论 mmap 操作是通过兼容性层还是直接完成，此修补程序都会修复此问题。如果是前者，则我们不会尝试 VMA 清理，如果是后者，则我们会尝试。此修补程序还更新了 userland VMA 测试以反映更改。（CVE-2026-53373）

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

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

  - firmware：arm_ffa：验证框架通知消息布局 框架通知在共享 RX 缓冲区中携带间接消息。在使用报告的偏移和大小之前对其进行验证，拒绝零长度负载，并确保任何非标头负载从 UUID 字段开始，而不是在消息标头中间。对 kmemdup（） 和 UUID 解析路径使用经过验证的偏移和大小值，这样格式错误的固件数据就无法驱动越界读取或过大分配。
    (CVE-2026-64081)

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

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

  - RDMA/rtrs：修复路径文件创建清理中的释放后使用 在 rtrs_srv_create_path_files（） 的错误路径中，可能已经创建了 sysfs 根文件夹，并且可能已经初始化了 srv_path->kobj。如果后续步骤失败，清除当前先调用 kobject_put（&srv_path->kobj），然后再调用 rtrs_srv_destroy_once_sysfs_root_folders（srv_path）。kobject_put（） 可能会删除对 srv_path->kobj 的最后引用并调用释放回调 rtrs_srv_release（），从而释放srv_path。然后，以下对 rtrs_srv_destroy_once_sysfs_root_folders（srv_path） 的调用会在内部取消引用srv_path以访问 srv_path->srv，从而导致释放后使用。在 rtrs_srv_create_path_files（） 返回成功之前到达此失败路径，因此不涉及成功路径生命周期处理。通过在调用 kobject_put（&srv_path->kobj） 之前破坏 sysfs 根文件夹修复此问题，以便在帮助程序访问期间srv_path仍然有效。此问题是由我正在开发的静态分析工具发现的。（CVE-2026-64033）

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

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

  - ip6：vti：在 vti6_siocdevprivate（） 中使用 ip6_tnl.net。在本系列的 1/2 修补程序之后，vti6_update（） 通过 t->net 断开和重新链接隧道。vti6_siocdevprivate（） 仍使用 dev_net（dev） 进行冲突查找。对于通过 IFLA_NET_NS_FD 移动的隧道，dev_net（dev） 是新的 netns，而不是 t->net。
    然后，迁移的隧道中的 SIOCCHGTUNNEL 运行：net = dev_net（dev） /* 迁移的 netns */ t = vti6_locate（net， &p1， false） /* 在 t->net 中未达到目标 */ ...t = netdev_priv（dev） vti6_update（t， &p1， false） /* 改变 t->net 的哈希 */ 迁移的 netns 中的调用程序会选择与创建 netns 中的隧道相匹配的参数。
    在 dev_net（dev） 中进行查找，未找到任何内容。vti6_update（） 会针对这些参数在创建 netns 哈希存储桶的头部预加迁移的隧道。稍后在创建 netns 中的查找会解析到已迁移的设备。xfrm receive 通过调用方控制的设备发送匹配的数据包。可从非特权用户命名空间访问 （unshare --user --map-root-user --net）。容器主机上的跨租户范围。
    将非回退设备上的 SIOCCHGTUNNEL 路径切换为使用 t->net 进行查找。查找现在匹配 netns vti6_update（） 操作。还在查找前添加 ns_capable（self->net->user_ns，CAP_NET_ADMIN）。案例顶部的检查针对的是 dev_net（dev）->user_ns，迁移后即为攻击者的 netns。那里的调用程序可以选择 self->net 中不存在的参数，查找返回 NULL，t 变为 self，vti6_update（） 将设备插入创建 netns 哈希。新的检查还要求在创建 netns user_ns中CAP_NET_ADMIN。回退设备上的 SIOCADDTUNNEL 和 SIOCCHGTUNNEL 保持 dev_net（dev），等于该处的 init_net。（CVE-2026-63921）

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

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

  - iio：buffer：修复 iio_buffer_enqueue_dmabuf（） 中的 DMA 隔离泄漏 iio_buffer_enqueue_dmabuf（） 通过将初始 kref 设置为 1 的 kmalloc_obj（）+dma_fence_init（） 分配结构iio_dma_fence（104 字节，kmalloc-128）。然后调用 dma_resv_add_fence（），后者采用第二个引用 （kref=2），并将原始指针存储在 block->fence 中。在成功路径上，该函数返回时不调用 dma_fence_put（） 释放初始引用，因此每个缓冲区排队都会永久泄漏一个 kmalloc-128 分配。iio_buffer_cleanup（） 工作项仅释放 iio_buffer_signal_dmabuf_done（） 在完成信号期间获取的临时引用;从不释放来自 dma_fence_init（） 的初始引用。在 240kHz 下有四个 iio_rwdev 实例，每个缓冲区有 512 个样本，每秒产生 ~1875 kmalloc-128 分配，与观察到的板块增长完全匹配。ftrace 测试确认从未触发 dma_fence_destroy 事件。通过在 dma_resv_add_fence（） 之后调用 dma_fence_put（） 进行修复，将隔离的所有权转移至 DMA 保留对象。收到信号后，DMA 隔离随后会正确弃用。（CVE-2026-63929）

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

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

  - drm/amdgpu：GEM_OP GET_MAPPING_INFO amdgpu_gem.c：1050 的 kvcalloc（args->num_entries， sizeof（*vm_entries）， GFP_KERNEL） 中的检查num_entries直接使用用户提供的num_entries，不进行任何上限检查。由于 num_entries 是 __u32而 sizeof（drm_amdgpu_gem_vm_entry） 为 32 字节，大型num_entries会产生超过 INT_MAX 的分配，从而在 __kvmalloc_node_noprof（） 中触发警告，从而在 CONFIG_PANIC_ON_WARN=y 系统上造成内核警告、TAINT_WARN和错误。在调用 kvzalloc（） 以通过 -EINVAL 及早拒绝超大num_entries之前，添加大小边界检查。（从提交 1fe7bf5457f6efd7be60b17e23163ba54341d73d 中精选出的内容）（CVE-2026-63878）

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

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

  - xfrm：esp：还原合并的单 frag 长度门控 ESP 就地快速路径会在 esp_output_head（） 中附加 esp_output_tail（） 的尾部，然后再分配目标页面 frag。头侧门目前分别检查 skb->data_len 和尾部，但尾部代码从组合后的拖车 skb->data_len 中分配一个目的地碎片。当组合对齐长度超过页面时，拒绝 page-frag 快速路径。否则，skb_page_frag_refill（） 可能会在目标 sg 仍跨组合 skb->data_len 时回退到单个页面。为 IPv4 和 IPv6 还原此组合长度页面门控。（CVE-2026-63912）

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

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

  - iio：imu： st_lsm6dsx：修复已标记 FIFO 缓冲区中的堆栈泄漏 已标记 FIFO 路径在包含 __aligned（8） 但无初始值设定项的堆栈上声明iio_buff，但是结构中有一个漏洞，随后将随着ST_LSM6DSX_SAMPLE_SIZE字节 （6） 被复制而泄漏到用户空间，但是该漏洞与时间戳之间的空间不会初始化。提交 c14edb4d0bdc （iio：imu：st_lsm6dsx 修复对齐和数据泄漏问题） 将未标记的 FIFO 路径移动到 hw->scan 中的 kzalloc'd 缓冲区，但对于带标记的路径，它仅添加了对齐限定符，而没有添加初始值设定项:(只需对堆栈上的结构进行零初始化即可修复此问题。（CVE-2026-63967）

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

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

  - KVM：SEV：根据缓冲区的实际大小检查 PSC 请求索引 处理页状态变更 （PSC） 请求时，请针对暂存区域的有效大小验证 PSC 缓冲区，如果客户机提供的指针不完全位于 GHCB 共享缓冲区的开头，则此区域可能小于最大大小。（CVE-2026-63938）

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

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

  - USB：serial：belkin_sa：验证中断状态长度 Belkin 中断回调将中断数据视为四字节状态报告，并读取偏移 2 和 3 处的 LSR/MSR 字段。中断输入缓冲区长度派生自端点 wMaxPacketSize，并且短中断传输可能会使用较小的actual_length成功完成。在解析状态字段之前检查已完成的中断数据包长度，以便忽略短中断端点和短的成功数据包，而不是造成越界或过时的状态字节读取。KASAN 报告如下：缺陷：KASAN：大小为 1 的 belkin_sa_read_int_callback（） 读取中的 slab-out-of-bound 调用跟踪：belkin_sa_read_int_callback（） （drivers/usb/serial/belkin_sa.c：202） __usb_hcd_giveback_urb（） （drivers/usb/core/hcd.c：1630） dummy_timer（） （？：？）（CVE-2026-63903）

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

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

  - xfrm：检查 xfrm_state_mtu中的下溢 Leo Lin 报告 esp 组件中的越界写入问题：
    xfrm_state_mtu（） 返回 u32，但在无符号 modulo-2^32 空间中使用从小 MTU 参数中减去的受攻击者影响的 header_len + authsize + net_adj 执行其算术运算。无名用户可安装具有大型认证密钥（XFRMA_ALG_AUTH_TRUNC，如 hmac（sha512）、64 字节密钥、64 字节截干的 IPv4 ESP 隧道 SA）、配置小型接口 MTU（68 字节）并将XFRMA_TFCPAD设为大值。随后通过隧道发送单个 UDP 数据报时，xfrm_state_mtu（） 下溢至接近 2^32 的值，esp_output（） 通过以下方式将其作为签名的 int 使用： padto = min（x->tfcpad， xfrm_state_mtu（x， mtu_cached）） esp.tfclen = padto - skb->len （分配给 int） esp.tfclen 最终变成负值（例如 -207）。当将其传递到 esp_output_fill_trailer（） 内部的 memset（） 时，它被符号扩展为size_t，从而在 skb_tail_pointer（skb） 处产生 ~16 EB 的零写入。KASAN 将其记录为大小为 18446744073709551537 地址的写入 addr ffff888.... 检查下溢并返回 1。这造成 sendmsg 尝试因 ENETUNREACH 而失败。（CVE-2026-64009）

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

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

  - accel/amdxdna：修复 aie2_populate_range（） 中的mm_struct引用泄漏 aie2_populate_range（） 在不调用 mmput（mm） 的情况下跳回 again 标签，从而导致向 mm_struct 泄漏引用。再次跳转到之前添加缺失的 mmput（）。（CVE-2026-63873）

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

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

  - vxlan：在 skb_tunnel_check_pmtu（） skb_tunnel_check_pmtu（） 可更改 skb->head 之后不重用缓存的 ip_hdr（） 值。在 skb_tunnel_check_pmtu（） 之后重复使用old_iph可导致 UAF。替代 drivers/net/bareudp.c 和 drivers/net/geneve.c 中所做的 ip_hdr（skb）。由 Sashiko 发现。（CVE-2026-63993）

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

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

  - gfs2：修复 gfs2_qd_dealloc gfs2_qd_dealloc（） 中的释放后使用，作为来自 gfs2_qd_dispose（） 的 RCU 回调调用，释放 qd 后通过 qd->qd_sbd 访问超级块对象 sdp。这样做是为了减少sd_quota_count并唤醒sd_kill_wait。但是，当 RCU 回调运行时，gfs2_put_super（） 可能已经通过 free_sbd（） 释放 sdp。在卸载期间调用 gfs2_quota_cleanup（） 时可能发生这种情况：它通过 call_rcu（） 处置配额对象，然后以 60 秒超时等待sd_kill_wait。如果超时过期，或者如果 gfs2_gl_hash_clear（） 在等待完成后触发其他 qd_put（） 调用来安排更多 RCU 回调，则 gfs2_put_super（） 将继续释放超级块，而引用超级块的 RCU 回调仍在待定中。在 gfs2_put_super（） 中的 free_sbd（） 前添加一个 rcu_barrier（），以确保所有待定的 RCU 回调（包括 gfs2_qd_dealloc）在释放超级块之前完成。（CVE-2026-63804）

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

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

  - ipv6：rpl：修复 ipv6_rpl_srh_decompress（） 中的 hdrlen 溢出 ipv6_rpl_srh_decompress（） 计算：
    outhdr->hdrlen = （（（n + 1） * sizeof（struct in6_addr）） >> 3）;hdrlen __u8。对于 n >= 127，结果超过 255 并静默截断。当 n=127 （cmpri=15， cmpre=15， pad=0， hdrlen=16）： （128 * 16） >> 3 = 256，截断为 0 时__u8 然后，ipv6_rpl_srh_rcv（） 中的调用程序将压缩的标头放在 buf + （（ohdr->hdrlen + 1） << 3）。若 hdrlen=0，则为 buf + 8，但解压缩的区域会占用 buf[0..2055]（8 字节标头加上 128 个完整地址）。压缩的标头与解压缩的数据重叠，ipv6_rpl_srh_compress（） 写入此重叠，从而损坏转发数据包的路由标头。exthdrs.c：546 的现有防护> 255 检查 （n + 1），这可防止 n+1 溢出未签名的字符（segments_left 字段），但无法防止计算的 hdrlen 溢出__u8。
    n=127 通过，因为 128 <= 255，但 hdrlen=256 不适合。将边界收紧到 （n + 1） > 127。这将 n 封装在 126，给出 hdrlen = （127 * 16） >> 3 = 254，这符合 __u8。压缩的标头随后位于 buf + （（254 + 1） << 3） = buf + 2040，正好超过解压缩区域 （buf[0..2039]）。无重叠。
    127 个段远远超出了任何现实的 RPL 部署。（CVE-2026-63984）

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

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

  - bridge：修复 netlink 路径中原子上下文中的休眠问题 自从提交 25c71c75ac87 中引入桥接端口的 netlink 配置路径（bridge：通过 netlink 桥接端口参数）以来，始终使用周围的桥接锁定来调用 br_setport（）。当时这个决定是有道理的：桥接锁保护桥接及其端口的 STP 状态，当时该函数仅处理三个与 STP 相关的 netlink 属性（成本、优先级和状态）。如今，br_setport（） 处理的属性太多了，而且大多数属性都不需要桥接锁定：* 桥接标记：仅需要 RTNL。通过数据路径无锁读取。可以在 net-next 中添加注释。* FDB 端口刷新：仅需要 FDB 锁定。* 多播属性：仅需要多播锁定。* 群组转发掩码：仅需要 RTNL。通过数据路径无锁读取。可以在 net-next 中添加注释。* 备份端口和 NHID：仅需要 RTNL。通过数据路径无锁读取。这是个问题，因为当某些桥接端口标志变更时，桥接会调用 dev_set_promiscuity（），而此函数自下述提交后可休眠，进而导致类似 [1] 的 splat。通过缩小桥接锁定的范围并仅在处理需要桥接锁定的三个 STP 相关属性时采用桥接锁定来修复此问题。这与多播属性一致，其中每个属性都获取多播锁定，而不是对所有相关属性具有一个关键部分。[1] 缺陷：从 net/core/dev_addr_lists.c：1262 的无效上下文调用休眠函数 in_atomic（）： 1， irqs_disabled（）： 0， non_block： 0， pid： 356，名称：bridge preempt_count：201，预期：0 RCU 嵌套深度：0，预期：0 bridge/356 持有的 2 个锁： #0：
    ffffffff919473a0 （rtnl_mutex）{+.+.}-{4:4}， at： rtnetlink_rcv_msg （net/core/rtnetlink.c：80 net/core/rtnetlink.c：7002） #1： ffff888115072d58 （&br->lock）{+...}-{3:3}， at： br_setlink （./include/linux/spinlock.h：348 net/bridge/br_netlink.c：1117） Preemption 已禁用： 0x0 硬件名称：
    Bochs Bochs， BIOS Bochs 01/01/2011 调用跟踪： <TASK> dump_stack_lvl （lib/dump_stack.c：94 lib/dump_stack.c：120） __might_resched.cold （kernel/sched/core.c：9163） netif_rx_mode_run （net/core/dev_addr_lists.c：1262） netif_rx_mode_sync （net/core/dev_addr_lists.c：1428） dev_set_promiscuity （net/core/dev_api.c：289） br_manage_promisc （net/bridge/br_if.c：135 net/bridge/br_if.c：172） br_port_flags_change （net/bridge/br_if.c：242 net/bridge/br_if.c：747） br_setport （net/bridge/br_netlink.c：1000） br_setlink （net/bridge/br_netlink.c：1118） rtnl_bridge_setlink （net/core/rtnetlink.c：5572） rtnetlink_rcv_msg （net/core/rtnetlink.c：7005） netlink_rcv_skb （net/netlink/af_netlink.c：2550） netlink_unicast （net/netlink/af_netlink.c：1318 net/netlink/af_netlink.c：1344） netlink_sendmsg （net/netlink/af_netlink.c：1894） __sock_sendmsg （net/socket.c：787 （discriminator 4） net/socket.c：802 （discriminator 4）） ____sys_sendmsg （net/socket.c：2698） ___sys_sendmsg （net/socket.c：2752） __sys_sendmsg （net/socket.c：2784） do_syscall_64 （arch/x86/entry/syscall_64.c：63 arch/x86/entry/syscall_64.c：94） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） （CVE-2026-63989）

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

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

  - serial：dz：转换为使用平台设备 防止在初始化第一个串行端口时发生崩溃：控制台：切换到彩色帧缓冲设备 160x64 tgafb：检测到 SFB+，rev=0x02 fb0：
    DECstation DZ 串口驱动程序版本 1.04 CPU 0 0x1e000000无法处理虚拟地址 000000bc， epc == 8048b3a4， ra == 80470a78 的数字 ZLX-E1 帧缓冲器设备 000000bc， epc == 8048b3a4， ra == 80470a78 错误[#1]： CPU： 0 UID： 0 PID： 1 通信： swapper/0 未受感染 6.19.0-dirty #35 NONE $ 0 ： 00000000 1000ac00 00000004 804707ac $ 4 ： 00000000 80e20850 80e20858 81000030 $ 8 ： 00000000 8072c81c 00000008 fefefeff $12： 6c616972 00000006 80c5917f 69726420 $16 ： 80e20800 0000000 808f8968 80e20800 $20 ： 00000000 807f5a90 808b0094 808d3bc8 $24 ： 00000018 80479030 $28 ： 80c2e000 80c2fd70 00000069 80470a78 Hi： 00000004 Lo ： 00000000 epc ： 8048b3a4 __dev_fwnode+0x0/0xc RA ： 80470a78 serial_base_ctrl_add+0xa0/0x168 状态： 1000ac04 IEp 原因：
    30000008 （ExcCode 02） BadVA：000000bc PrId：00000220 （R3000） 模块链接于： 进程 swapper/0 （pid：
    1， threadinfo=（ptrval）， task=（ptrval）， tls=00000000） 堆栈： 00400044 00400040 8046f4cc 00000000 808a6148 808a0000 808f8968 8086983c 808e0000 8046fc84 1000ac01 00000028 80e20700 802ba3f8 80e20700 80d34a94 80c1b900 80e20700 80e20 700 80e20700 80e20700 80444650 000000000 00000000 007f5a90 808b0094 80447080 00400040 808e0000 80d34a94 808a6148 80d34a94 00000004 80e20700 00000000 8076974c 80469810 80c2fe3c 1000ac01 ... 调用跟踪：[<8048b3a4>] __dev_fwnode+0x0/0xc [<80470a78>] serial_base_ctrl_add+0xa0/0x168 [<8046fc84>] serial_core_register_port+0x1c8/0x974 [<808c6af0>] dz_init+0x74/0xc8 [<800470e0>] do_one_initcall+0x44/0x2d4 [<808b111c>] kernel_init_freeable+0x258/0x308 [<8072e434>] kernel_init+0x20/0x114 [<80049cd0>] ret_from_kernel_thread 0x1c+0x14/ 代码： 27bd0018 03e00008 2402ffea <8c8200bc> 03e00008 00000000 27bdffc0 afbe0038 afb30024 ---[ end trace 0000000000000000 ]--- --取消引用从空派生的指针指向端口父设备的指针。
    由于没有设备支持旧版探测，并且它不再是发现设备的首选方式，因此请将驱动程序切换为使用平台设备并将其用作端口的父设备。相应地更新资源处理，并且仅请求在插槽内使用的实际地址跨度，通用平台设备代码已经请求其资源。使用 platform_driver_probe（） 不仅因为 DZ 设备是用焊料固定的并且不容易拆卸，而且最重要的是因为相关的 TTY 的主要设备编号与 zs 驱动程序使用的相同，并且第一个声明它的驱动程序将阻止另一个驱动程序使用它。给定系统中将存在一个 DZ 设备或某些 SCC 设备，但绝不会同时存在两个设备，因此我们希望第一个驱动程序声明的主要设备号才能实际成功绑定到其设备，而 platform_driver_probe（） 是实现这一点的一种方式。切换到平台设备的一个不幸后果是，我们现在在启动程序中很久以后才将控制台从 bootconsole 移交。固件控制台处理程序看起来足够好，但可以工作到这么晚，尤其是在启用中断的情况下。
    相反，只有过晚启动控制台端口才能让重置代码充分利用延迟处理程序，因此请从 udelay（） 切换到 fsleep（） 进行发送器耗尽，以避免忙碌等待过多时间。（CVE-2026-63877）

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

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

  - iommu/amd：删除 IOMMU debugfs 中潜在的越界访问 在 iommu_mmio_write（） 和 iommu_capability_write（） 中，变量 dbg_mmio_offset 和 dbg_cap_offset 声明为 int。但是，它们是使用 kstrtou32_from_user（） 填充的。如果用户提供的值足够大，它可变为负整数。在此修补程序之前，AMD IOMMU debugfs 实现已受到不同机制的保护。1. #define OFS_IN_SZ 8 确保用户字符串 <= 8 字节，因此例如，0xffffffff 不是有效输入。if （cnt > OFS_IN_SZ） 返回 -EINVAL;2. iommu_mmio_write（） 中的隐式类型升级，dbg_mmio_offset 是 int，iommu->mmio_phys_end 是 u64，如果 （dbg_mmio_offset > iommu->mmio_phys_end - sizeof（u64）） 返回 -EINVAL;3. show 处理程序当前会捕获负数并拒绝执行读取。将 kstrtou32_from_user（） 替换为 kstrtos32_from_user（） 以解析输入，并检查负值以直接在 iommu_mmio_write（） 和 iommu_capability_write（） 中明确防止越界内存访问。（CVE-2026-64186）

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

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

  - serial：qcom_geni：修复 DMA 完成 IRQ 之前刷新时的 kfifo 下溢 在提供 DMA 完成 IRQ 之前运行 uart_flush_buffer（） 时，可能发生以下争用（所有步骤按 uart_port_lock 序列化）： 1. DMA 启动：tx_remaining = N，kfifo 包含 N 个字节 2.DMA 在硬件中完成;IRQ 待定但尚未交付 3.uart_flush_buffer（） 获取端口锁定并调用 kfifo_reset（），使 kfifo_len（） = 0 而 tx_remaining 仍为 N 4。uart_flush_buffer（） 解除端口锁定 5。DMA IRQ 火灾;handle_tx_dma（） 获取端口锁定并调用空 kfifo uart_xmit_advance（） 上的 uart_xmit_advance（uport， tx_remaining） 递增 kfifo-> tx_remaining。由于 kfifo_reset（） 已将 in 和 out 都设置为 0，因此 out 会过去换行，从而导致 kfifo_len（） 返回 UART_XMIT_SIZE - tx_remaining。然后，下一个 start_tx_dma（） 调用会提交过时缓冲区数据的 DMA 传输。通过在 handle_tx_dma（） 开始时生成快照 kfifo_len（） 并在fifo_len < tx_remaining时跳过 uart_xmit_advance（），来修复此问题，这表明 kfifo 已被先前的刷新重置。（CVE-2026-63883）

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

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

  - ieee802154：6lowpan：仅接受 lowpan_xmit（） 中的 IPv6 数据包 aoe 驱动程序（或类似程序）会生成非 IPv6 数据包（例如 ETH_P_AOE），并将其排队，以便通过 6LoWPAN 接口（由用户或测试用例配置）上的 dev_queue_xmit（） 传输。由于数据包不是 IPv6，因此 6LoWPAN header_ops->create 函数（lowpan_header_create 或 header_create）提早返回，而不会在 skb 余量中初始化lowpan_addr_info结构。在 transmit 函数 （lowpan_xmit） 中，驱动程序调用 lowpan_header （或 setup_header），后者会无条件地从包含未初始化数据的余量中复制和使用lowpan_addr_info。通过丢弃非 IPv6 数据包修复此问题。net/bluetooth/6lowpan.c bt_xmit（） 中需要类似的补丁。（CVE-2026-63870）

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

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

  - hwmon：（pmbus/adm1266） 拒绝 GPIO 访问器中的短块读取响应adm1266_gpio_get（） 和 adm1266_gpio_get_multiple（） 都构成 pin-status 字，pins_status = read_buf[0] + （read_buf[1] << 8）;紧接在 i2c_smbus_read_block_data（） 之后，仅防止错误返回。行为良好的设备会针对 GPIO_STATUS/PDIO_STATUS 返回 2 字节，但帮助程序也会乐意报告 0 或 1 字节响应。如果设备返回 0 字节，则两个read_buf插槽都是未初始化的堆栈内存;如果返回 1 个字节，则 read_buf[1] 为。然后，组成的值经 set_bit（） 流入调用方在 adm1266_gpio_get_multiple（） 中的 *bit，或流入 adm1266_gpio_get（） 的返回值，并通过 gpiolib（sysfs 和 char-dev ioctls）结束在用户空间中。这会在任何固件故障、总线错误或恶意从属设备产生短块读取响应的设备上，每个请求泄漏几位内核堆栈。将缺少的长度检查添加至两个调用站点，并将短响应显示为 -EIO。（CVE-2026-64083）

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

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

  - KVM：SVM：在 Hygon 系列 18h 上禁用 AVIC IPI 虚拟化（勘误表 #1235） Hygon 系列 18h CPU 源自 AMD 系列 17h （Zen1） 芯片并共享相同的勘误表 #1235： 硬件可能在 ICR 写入仿真期间读取过时的 IsRunning=1 位，并且静默地无法在发送的 vCPU 上生成AVIC_IPI_FAILURE_TARGET_NOT_RUNNING VM-Exit。缺少 VM-Exit 会导致 KVM 错过阻断目标 vCPU 的必要唤醒，从而导致 vCPU 挂起和客户机执行中无限延迟。扩展现有的 AMD 系列 17h 勘误表 #1235 变通方案，以涵盖 Hygon 系列 18h。
    禁用 IPI 虚拟化时，KVM 永远不会在物理 ID 表中设置 IsRunning=1，因此每个非自 IPI 都会生成 VM-Exit 并得到正确仿真。（CVE-2026-64172）

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

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

  - net：wwan：iosm：修复 ipc_imem_init（） 中潜在的内存泄漏 ipc_protocol_init（） 中分配的内存未在 ipc_imem_init（） 中随后的错误路径上释放。通过调用错误路径中相应的释放函数 ipc_protocol_deinit（） 来修复此问题。（CVE-2026-64179）

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

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

  - thunderbolt：property：__tb_property_parse_dir（） 中的端点递归深度 DIRECTORY 条目的值字段用作对没有深度计数器的 __tb_property_parse_dir（） 进行递归调用的dir_offset。将 DIRECTORY 条目链接到向后引用循环的构造的对等会驱动解析器，直到内核堆栈耗尽且保护页面触发为止。到达 PROPERTIES_REQUEST 控制平面交换的任何不受信任的 XDomain 对等机（电缆、停靠栏、内联检查器、相邻主机）可在未经认证的情况下触发此漏洞。将深度计数器穿过 tb_property_parse（） 和 __tb_property_parse_dir（），并拒绝超过 TB_PROPERTY_MAX_DEPTH = 8 的块。这比任何观察到的合法 XDomain 布局都要大得多。不需要 XDomain 主机到主机发现的操作员可在内核命令行中通过 thunderbolt.xdomain=0 完全禁用路径。（CVE-2026-63891）

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

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

  - batman-adv：bla：避免双重递减bla.num_requests 无正在进行的request_sent时，bla.num_requests会增加。并在各地减少（收到公告，清除骨干，定期工作）。但是检查 request_sent 是否实际上被设置为特定状态以及 atomic_dec/_inc 不安全，因为它们不是原子性的 （TOCTOU） 并且可以同时运行多个此类代码部分。同时，需要对request_sent（状态）进行修改，并以原子方式bla.num_requests。否则 batadv_bla_send_request（） 可能会将 request_sent 设置为 1 并被中断。
    然后，batadv_handle_announce（） 可以将 request_sent 设置回 0，并在 batadv_bla_send_request（） 递增它之前减少num_requests。因此必须锁定这两个操作。由于状态 （request_sent） 和 wait_periods 只能在此锁内访问，因此可以将它们转换为更简单的数据类型。为避免在 batadv_bla_purge_backbone_gw（） 运行后具有有效 backbone_gw 引用的并行运行上下文接触 bla.num_requests，需要第三个已停止状态以正确表示backbone_gw处于被清理状态。（CVE-2026-64095）

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

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

  - batman-adv：tt：修复报告的 VLAN 的 TOCTOU 争用 基于 TT 的本地 TVLV 通过首先检查具有至少一个 TT 条目的 VLAN 的数量来生成。然后会为 VLAN 分配一个大小正确的新缓冲区。只有这样，才会使用 VLAN 列表填充缓冲区中的 VLAN 条目。在此期间，meshif_vlan_list_lock举行。但是，在此期间，每个VLAN的实际TT条目数量仍可能增加，只是不是列表中的VLAN数量。但是缓冲区大小计算中使用的预过滤器仍可能导致需要存储的 VLAN 数量增加。仅仅是因为 VLAN 在分配前检查中没有条目时，现在可能突然至少有一个条目，然后需要占用未分配的空间。最好在开始时高估缓冲区大小，然后仅用非空的 VLAN 填充缓冲区。（CVE-2026-64091）

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

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

  - USB：serial：mct_u232：修复小端点的内存损坏 该驱动程序会替代特定设备（其 32 字节大量输出端点仅接受 16 字节数据包）的最大传输大小。确保永远不要增加最大传输大小，以便在恶意设备报告的端点最大数据包大小小于预期时防止 slab 损坏。（CVE-2026-63898）

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

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

  - net/sched：修复 ethx：ingress -> ethy：egress -> ethx：ingress mirred 循环 mirred 重定向到入口（从入口或出口）时，数组 dev sched_mirred_dev循环状态丢失，原因在于 1） 数据包延迟到 backlog，以及 2） sched_mirred_dev数组遭到清除。在此类情况下，如果存在循环，我们将不会发现它。下面是一个简单的重现测试：ip a add dev port0 10.10.10.11/24 tc qdisc add dev port0 clsact tc filter add dev port0 egress protocol ip \ prio 10 matchall action mirred ingress redirect dev port1 tc qdisc add dev port1 clsact tc filter add dev port1 ingress protocol ip \ prio 10 matchall action mirred egress redirect dev port0 ping -c 1 -W0.01 10.10.10.10 （CVE-2026-63982）

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

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

  - drm/v3d：修复错误路径上 CPU 作业查询数组的释放后使用 CPU 作业 ioctl 的失败标签在 v3d_job_cleanup（） 之后在cpu_job的时间戳和性能查询数组上调用 kvfree（），从而删除作业的最后引用并释放cpu_job。此时读取cpu_job即为释放后使用。此外，在早期的 v3d_job_init（） 失败路径中，它是空取消引用，因为 v3d_job_deallocate（） 将本地指针清零。在成功路径中，数组从计划程序的.free_job回调中释放，但在错误路径上，它们被手动释放，因为作业从未被推送到计划程序。虽然成功路径正确处理此问题，但失败路径不会。最重要的是，手动 kvfree（） 调用仅释放数组存储;它们不会drm_syncobj_put v3d_timestamp_query_info_free（） 和 v3d_performance_query_info_free（） 在成功路径上释放的按查询 syncobjs。因此，触发释放后使用的同一失败路径也会在每个查询中泄露一个 syncobj 引用。将 CPU 作业拆卸统一到 CPU 作业的 kref 析构函数中，以反映 v3d_render_job_free（）。计划程序的.free_job槽恢复为通用 v3d_sched_job_free（），失败标签会终止手动 kvfree（） 调用，从而留下可从计划程序和 ioctl 错误路径到达的单一拆卸路径。这可按构造删除释放后使用、空指针取消引用和 syncobj 泄露问题。（CVE-2026-64099）

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

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

  - usb：typec：ucsi：ccg：拒绝不含“：”记录标头的固件图像 do_flash（） 使用 p = strnchr（fw->data， fw->size， '：'） 找到第一个 .cyacd 记录;while （p < eof） { s = strnchr（p + 1， eof - p - 1， '：'）; ... }如果固件映像不含“：”字节，strnchr（） 会返回 NULL。NULL 的比较小于有效的内核指针 eof，因此循环正文运行并使用 p + 1 == （void *）1 且长度约为（无符号长）eof 来调用 strnchr（），从而导致精彩的崩溃。do_flash（） 中较早的 not_signed_fw fallthrough 和 ccg_fw_update_needed（） 中的芯片状态分支允许未签名的 blob 到达此循环，因此可在 /lib/firmware 下放置构建的文件并写入 do_flash sysfs 属性的根用户可触发 oops。当初始 strnchr（） 返回 NULL 时使用 -EINVAL 退出。
    (CVE-2026-63964)

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

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

  - drm/amdgpu：修复 AMDGPU_GEM_OP_GET_MAPPING_INFO 中 ENOMEM 的锁定泄漏 调用 kvcalloc（） 之前，amdgpu_gem_op_ioctl（） 的 AMDGPU_GEM_OP_GET_MAPPING_INFO 分支保留三个清理跟踪资源： 来自 drm_gem_object_lookup（） 的 drm_gem_object 引用，通过 drm_exec_lock_obj（） 对已查找的 GEM 的drm_exec锁定， 以及通过 amdgpu_vm_lock_pd（） 对每个进程的 VM 根页面目录进行drm_exec锁定。这三个标签都由此函数中的每个其他错误路径跳转到的out_exec标签发布。kvcalloc（） 失败路径直接返回 -ENOMEM，从而跳过out_exec并泄漏这三者。泄露的各进程虚拟机根 PD dma_resv锁即为承载泄露：相同 VM 上的任何后续操作（进一步的 GEM 操作、命令提交、逐出、TTM shrinker 回调）都会阻断被保留的锁定。DRM_IOCTL_AMDGPU_GEM_OP DRM_AUTH |DRM_RENDER_ALLOW，因此这是针对调用方 GPU 上下文的非特权本地拒绝服务，任何具有 /dev/dri/renderD* 访问权限的进程均可访问此拒绝服务。通过 out_exec 路由故障，使 drm_exec_fini（） 和 drm_gem_object_put（） 运行。现货 7.0.0-10重现，Ryzen 7 5700U / Radeon Vega （Lucienne）：失败的 ioctl 返回 -ENOMEM 和同一 fd 上的第二个GET_MAPPING_INFO，然后在泄露dma_resv上的 drm_exec_lock_obj（） 中阻断。调用程序中的 SIGKILL 不会收获任务;进程退出期间的 fd-release 路径会经过同一锁定上的 amdgpu_gem_object_close（） -> drm_exec_prepare_obj（），使任务处于 D 状态，直到重新启动箱。修补后的内核并未在此硬件上重建和重新测试;修复是机械性的。仅在单个 Lucienne / Vega 盒子上进行测试。Ziyi Guo 发布了针对同一分支中 args->num_entries 的独立INT_MAX边界检查 [1];这两个补丁是互补的，可以按任一顺序登陆。（从提交 b69d3256d79de15f54c322986ff4da68f1d65b0a 中精选出的内容）（CVE-2026-63880）

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

ID	名称	严重性
328298	Linux Distros 未修补的漏洞：CVE-2026-63892	medium
328297	Linux Distros 未修补的漏洞：CVE-2026-63943	medium
328296	Linux Distros 未修补的漏洞：CVE-2026-64030	high
328295	Linux Distros 未修补的漏洞：CVE-2026-64130	medium
328294	Linux Distros 未修补的漏洞：CVE-2026-63090	high
328293	Linux Distros 未修补的漏洞：CVE-2026-63864	high
328292	Linux Distros 未修补的漏洞：CVE-2026-64621	critical
328291	Linux Distros 未修补的漏洞：CVE-2026-63992	critical
328290	Linux Distros 未修补的漏洞：CVE-2026-64094	medium
328289	Linux Distros 未修补的漏洞：CVE-2026-64107	medium
328288	Linux Distros 未修补的漏洞：CVE-2026-63953	medium
328287	Linux Distros 未修补的漏洞：CVE-2026-63906	high
328286	Linux Distros 未修补的漏洞：CVE-2026-63936	medium
328285	Linux Distros 未修补的漏洞：CVE-2026-64031	high
328284	Linux Distros 未修补的漏洞：CVE-2026-63868	medium
328283	Linux Distros 未修补的漏洞：CVE-2026-63935	medium
328282	Linux Distros 未修补的漏洞：CVE-2026-64032	high
328281	Linux Distros 未修补的漏洞：CVE-2026-63944	high
328280	Linux Distros 未修补的漏洞：CVE-2026-63837	medium
328279	Linux Distros 未修补的漏洞：CVE-2026-53373	high
328278	Linux Distros 未修补的漏洞：CVE-2026-64081	high
328277	Linux Distros 未修补的漏洞：CVE-2026-64033	critical
328276	Linux Distros 未修补的漏洞：CVE-2026-63921	high
328275	Linux Distros 未修补的漏洞：CVE-2026-63929	medium
328274	Linux Distros 未修补的漏洞：CVE-2026-63878	medium
328273	Linux Distros 未修补的漏洞：CVE-2026-63912	critical
328272	Linux Distros 未修补的漏洞：CVE-2026-63967	medium
328271	Linux Distros 未修补的漏洞：CVE-2026-63938	critical
328270	Linux Distros 未修补的漏洞：CVE-2026-63903	medium
328269	Linux Distros 未修补的漏洞：CVE-2026-64009	high
328268	Linux Distros 未修补的漏洞：CVE-2026-63873	medium
328267	Linux Distros 未修补的漏洞：CVE-2026-63993	critical
328266	Linux Distros 未修补的漏洞：CVE-2026-63804	medium
328265	Linux Distros 未修补的漏洞：CVE-2026-63984	critical
328264	Linux Distros 未修补的漏洞：CVE-2026-63989	medium
328263	Linux Distros 未修补的漏洞：CVE-2026-63877	medium
328262	Linux Distros 未修补的漏洞：CVE-2026-64186	high
328261	Linux Distros 未修补的漏洞：CVE-2026-63883	high
328260	Linux Distros 未修补的漏洞：CVE-2026-63870	high
328259	Linux Distros 未修补的漏洞：CVE-2026-64083	high
328258	Linux Distros 未修补的漏洞：CVE-2026-64172	high
328257	Linux Distros 未修补的漏洞：CVE-2026-64179	medium
328256	Linux Distros 未修补的漏洞：CVE-2026-63891	medium
328255	Linux Distros 未修补的漏洞：CVE-2026-64095	high
328254	Linux Distros 未修补的漏洞：CVE-2026-64091	critical
328253	Linux Distros 未修补的漏洞：CVE-2026-63898	medium
328252	Linux Distros 未修补的漏洞：CVE-2026-63982	medium
328251	Linux Distros 未修补的漏洞：CVE-2026-64099	high
328250	Linux Distros 未修补的漏洞：CVE-2026-63964	medium
328249	Linux Distros 未修补的漏洞：CVE-2026-63880	medium

检测

Nessus 的 Misc. 系列

medium

medium

high

medium

high

high

critical

critical

medium

medium

medium

high

medium

high

medium

medium

high

high

medium

high

high

critical

high

medium

medium

critical

medium

critical

medium

high

medium

critical

medium

critical

medium

medium

high

high

high

high

high

medium

medium

high

critical

medium

medium

high

medium

medium