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

  - ALSA：firewire：isight：将样本计数绑定到数据包负载 isight_packet（） 从设备 iso 数据包获取帧计数，并仅依据设备声明的 iso 长度进行检查。计数 = be32_to_cpu（有效负载>sample_count）;if （likely（count <= （length - 16） / 4）） isight_samples（isight， payload->samples， count）;length 是 ISO 标头data_length。它可以达到0xffff。因此，该门允许计数到大约 16379。然后，isight_samples（） 将计数帧从 payload->samples 复制到 PCM DMA 缓冲区中。payload->samples 仅包含 2 * MAX_FRAMES_PER_PACKET 个值。该器件每帧多路复用两个样本。超过 MAX_FRAMES_PER_PACKET 的计数读数超过负载。超过缓冲区大小的计数写入过去的运行时>dma_area。最小的 PCM 缓冲区大于 MAX_FRAMES_PER_PACKET。将计数限制为 MAX_FRAMES_PER_PACKET 可使读取和写入保持在范围内。FireWire 总线上的恶意或有缺陷的 Apple iSight 在正常捕获期间会到达此问题。将 MAX_FRAMES_PER_PACKET 绑定到门。（CVE-2026-64483）

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

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

  - RDMA/siw：将读取响应放置到 RREAD 长度 在 drivers/infiniband/sw/siw/siw_qp_rx.c 中，siw_proc_rresp（） 将每个传入读取响应 DDP 段放在 sge->laddr + wqe->processed 处，然后累积 wqe->处理，但它从未针对连续段上的接收缓冲区长度检查运行总计。siw_check_sge（） 仅解析并验证第一个段（if （！*mem） 分支）上的接收内存，siw_rresp_check_ntoh（） 仅在最后一段（！frx->more_ddp_segs 防护）上比较累积长度与 wqe->字节。一个连接的 siw 对等体使用保持 DDP Last 标志清除的读取响应段应答未完成的 RREAD，携带比请求的 RREAD 更多的总负载，驱动 wqe->处理通过验证的接收器缓冲区;下一个 siw_rx_data（） 调用在 sge->laddr + wqe->processed 处写入越界。siw 在普通可路由的 TCP 上运行 iWARP，因此对等机是已建立 RDMA 连接的远程端，不需要任何本地权限。在放置之前绑定每个段，就像 siw_proc_send（） 和 siw_proc_write（） 已经对其标记和未标记的路径所做的那样，并在读取响应使接收器缓冲区溢出时以基本或边界 DDP 错误终止连接。这是此文件的第二个接收路径长度补丁。单独的变更拒绝在标头解码中下溢每片段余数的 MPA FPDU 长度;该保护不涵盖这种情况，因为此处每个单独的段长度都是自一致的，并且只有累积的放置偏移量会溢出缓冲区。（CVE-2026-64268）

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

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

  - 已修复 Linux 内核中的下列漏洞：xfs: fix memory leak in xfs_dqinode_metadir_create() If xfs_metadir_create() fails in xfs_dqinode_metadir_create(), the current code returns directly, leaking the allocated update and transaction state. If the subsequent commit fails, the caller-owned inode reference is left behind. Fix this memory leak by routing the create failure path through xfs_metadir_cancel(). For both create and commit failures, finish and release any inode returned to the caller, mirroring the unwind pattern in xfs_metadir_mkdir(). The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1.
    The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. Runtime validation used kprobe fault injection during `mount -o uquota` on a metadir XFS image. Injecting xfs_metadir_create() reproduced the old active-update path that left mount stuck later in mount setup;
    after this change, the same injection reported cancel_hits=1 and irele_hits=1. Injecting xfs_metadir_commit() exercised the old inode-reference leak path; after this change, it reported irele_hits=1. (CVE-2026-64356)

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

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

  - audit：修复 audit_queue 上 skb_queue_len（） 阅读器的数据争用 多个阅读器可通过 skb_queue_len（） 访问 audit_queue.qlen，而不保留队列锁定或使用 READ_ONCE（），而 kauditd 则通过 skb_dequeue（） __skb_unlink（） 路径写入此字段，WRITE_ONCE（） 受旋转锁保护。这构成数据争用。所有受影响的 skb_queue_len（&audit_queue） 调用站点：- kauditd_thread（） wait_event_freezable（） 条件 - audit_receive_msg（） AUDIT_GET处理程序 （s.backlog 分配） - audit_receive（） backlog 检查 - audit_log_start（） backlog 检查和 pr_warn（） KCSAN 报告以下冲突的访问模式（一个示例）：
    ==================================================================缺陷：KCSAN：audit_log_start / skb_dequeue 中的数据争用通过任务 661 对 4 字节的0xffffffff8512ee20写入（标记）在 CPU 57：
    skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30 通过 CPU 1 上的任务 36586 读取到 4 字节0xffffffff8512ee20：audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0 值已更改：0x00000001 -> 0x00000000 ================================================================== 通过切换到无锁帮助程序 skb_queue_len_lockless（） 解决争用，后者可在内部使用 READ_ONCE（），并与写入器端已有的 WRITE_ONCE（） 写入权限正确配对。[PM：行长度调整]（CVE-2026-64435）

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

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

  - writeback：修复 cgroup_writeback_umount（） 与 inode_switch_wbs（） 之间的争用 容器退出时，有时会触发以下 BUG_ON（）：
    ================================================================== VFS：卸载 sdb （ext4） 后 inode 繁忙 ------------[ cut here ]------------ fs/super.c：695！CPU：3 PID：6 通信：containerd-shim 受感染：G OE K 6.6 #1 pstate：63400009 （nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--） pc：
    generic_shutdown_super+0xf0/0x100 LR：generic_shutdown_super+0xf0/0x100 调用跟踪：
    generic_shutdown_super+0xf0/0x100 kill_block_super+0x20/0x48 ext4_kill_sb+0x28/0x60 deactivate_locked_super+0x54/0x130 deactivate_super+0x84/0xa0 cleanup_mnt+0xa4/0x140
    __cleanup_mnt+0x18/0x28 task_work_run+0x78/0xe0 do_notify_resume+0x204/0x240 ================================================================== 根本原因是 cgroup_writeback_umount（） 和 inode_switch_wbs（）/cleanup_offline_cgwb（） 之间的争用。返回 true 的 inode_prepare_wbs_switch（） 和后续的 wb_queue_isw（） 调用之间存在一个窗口。以下是触发该问题的进程：CPU A（卸载）|CPU B（回写） ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inode_switch_wbs/cleanup_offline_cgwb atomic_inc（&isw_nr_in_flight） inode_prepare_wbs_switch -> 传递SB_ACTIVE检查 __iget（inode） generic_shutdown_super sb->s_flags &= ~SB_ACTIVE cgroup_writeback_umount（sb） smp_mb（） atomic_read（&isw_nr_in_flight） rcu_barrier（） -> 无待定的 RCU 回调 flush_workqueue（isw_wq）
    ->无任何队列，返回 evict_inodes（sb） -> 跳过 Inode，因为 isw 仍保留 ref。 sop->put_super（sb） /* 破坏 percpu 计数器 */ -> VFS： 卸载后 inode 繁忙！wb_queue_isw（） queue_work（isw_wq， ...） /* 工作函数中的后期 */ inode_switch_wbs_work_fn process_inode_switch_wbs iput（） -> 驱逐 percpu_counter_dec（） // UAF！通过将 inode_switch_wbs（） 和 cleanup_offline_cgwb（） 中的 RCU 读取端关键部分扩展到从 inode_prepare_wbs_switch（） 到 wb_queue_isw（） 来修复此问题。由于此窗口中无休眠，因此可以使用 rcu_read_lock（）。然后在现有 rcu_barrier（） 之前的 cgroup_writeback_umount（） 中添加一个 synchronize_rcu（），以便所有通过SB_ACTIVE检查的正在传输的切换器在调用 flush_workqueue（） 之前完成 queue_work（）。有意保留现有 rcu_barrier（），以便可以原样将此补丁向后移植到仍通过 queue_rcu_work（） 排队切换的稳定内核（5.10.y、6.6.y 等）。它在当前干线上是非 op（自提交 e1b849cfa6b6（writeback：避免切换 inode 时对 wb->list_lock 的争用）起），并在后续修补程序中删除。（CVE-2026-64378）

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

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

  - ksmbd：对每个文件的 QUERY_DIRECTORY 请求进行序列化 smb2_query_dir（） 在ksmbd_file readdir_data中存储指向其堆栈分配的私有数据的指针。使用相同文件句柄的并行 QUERY_DIRECTORY 请求可在 iterate_dir（） 回调仍在使用该指针时覆盖此指针，从而导致堆栈释放后使用。添加每个文件互斥体并在访问共享目录枚举状态时保持该互斥体。该锁定涵盖扫描重新启动、点输入状态、readdir_data设置和迭代以及响应构建。这会防止另一个请求在当前请求完成使用之前替换 readdir_data.private，并且会序列化共享文件位置。（CVE-2026-64397）

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

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

  - usb：mtu3：取消映射请求 DMA on queue failure mtu3_gadget_queue（） 会在检查 QMU GPD 环是否可以接受其他传输之前映射请求。如果 mtu3_prepare_transfer（） 失败，在将其链接到端点请求列表之前，将返回请求 -EAGAIN。正常完成和出列路径会取消映射来自 mtu3_req_complete（） 的请求，但此错误路径永远不会到达该辅助函数，因此 DMA 映射会保持活动状态。从失败的队列路径返回请求之前取消映射。（CVE-2026-64337）

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

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

  - wifi：rtw89：修正畸形 AMPDU 帧的终止逻辑 之前提交的内容旨在修复畸形 AMPDU 帧造成的问题。但是，丢弃逻辑无法处理与特定序列号范围配对的第一个 AMPDU 数据包，并导致意外的数据包丢弃。密钥更新过程中存在繁忙流量时更有可能遇到此故障，这可能导致与 AP 断开连接。通过添加初始状态判断和仅在成对密钥更新期间重置状态，来修复此问题。（CVE-2026-64506）

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

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

  - ALSA：cmipci：检查内存分配失败时snd_ctl_new1（） 返回值 snd_ctl_new1（） 可能返回 NULL。snd_cmipci_spdif_controls（） 在取消引用 kctl->id.device 之前未检查返回值，这可导致空指针取消引用。在 snd_ctl_new1（） 调用后添加 NULL 检查并返回
    -ENOMEM（如果有任何失败）。（CVE-2026-64486）

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

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

  - staging：vme_user：将从属读取/写入绑定到kern_buf大小 SLAVE-path 帮助程序 buffer_to_user（） 和 buffer_from_user（） 使用 *ppos 作为偏移量将“count”字节复制到固定大小的kern_buf（size_buf == PCI_BUF_SIZE == 0x20000,128 KiB），而不限制 *ppos + 与size_buf计数。
    vme_user_write（）/vme_user_read（） 仅将计数钳制为 VME 窗口大小 （image_size = vme_get_size（resource）），这是VME_SET_SLAVE从用户提供的 slave.size 设置的 -- 针对 VME 地址空间（最多 VME_A32_MAX = 4 GiB）进行验证，而不是根据 PCI_BUF_SIZE 进行验证。当窗口超过 128 KiB 时，write（）/read（） 会复制超过kern_buf分配。对两个帮助程序中的 size_buf 进行钳制计数，*ppos 处于缓冲区末尾时/之后会提早返回。*ppos 在此为 >= 0（调用程序拒绝负偏移），因此size_buf - *ppos 无法封装。这反映了 MASTER-path 帮助程序 resource_to_user（） / resource_from_user（） 中的现有限制，并符合缓冲区末尾短传输的 read（）/write（） 约定。通过静态分析（CodeQL 感染跟踪 + CBMC 边界模型检查）发现，并在 KASAN 下使用 vme_fake 桥动态确认：缺陷：KASAN：slab-out-of-bound
    _copy_from_user+0x2d/0x80 任务触发器/68 在地址 ffff888004100000 处写入大小262144
    _copy_from_user+0x2d/0x80 vme_user_write+0x13e/0x240 [vme_user] vfs_write+0x1b8/0x7a0 ksys_write+0xb8/0x150 （CVE-2026-64449）

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

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

  - usb：dwc3：修复 dwc3_ulpi_setup（） 中的 dwc3_readl（） 和 dwc3_writel（） 调用 当 dwc3->reg 调用均直接采用 dwc3 结构时，dwc3_ulpi_setup（） 会使用 dwc3-regs 调用寄存器读取和写入调用。
    改变这两个调用以修复以下稀疏警告，并且 dwc3_ulpi_setup（） 代码中可能存在令人讨厌的缺陷： drivers/usb/dwc3/core.c：796：45：warning： incorrect type in argument 1 （different address spaces） drivers/usb/dwc3/core.c：796：45： 预期结构 dwc3 *dwc drivers/usb/dwc3/core.c：796：45：
    已取得 void [noderef] __iomem *regs drivers/usb/dwc3/core.c：798：40：警告：参数 1 中的类型不正确（不同地址空间） drivers/usb/dwc3/core.c：798：40：预期的结构 dwc3 *dwc drivers/usb/dwc3/core.c：798：40：已取得 void [noderef] __iomem *regs （CVE-2026-64349）

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

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

  - 已修复 Linux 内核中的下列漏洞：x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled The architecture updates the cpu_mask in a domain's header to track which online CPUs are associated with the domain. When this mask becomes empty the architecture initiates offline of the domain that includes calling on resctrl fs to offline the domain. If it is a monitoring domain in which LLC occupancy is tracked resctrl fs forces the limbo handler to clear all busy RMID state associated with the domain. The limbo handler always reads the current event value associated with a busy RMID irrespective of it being checked as part of regular is it still busy check or whether it will be forced released anyway. When reading an RMID on a system with SNC enabled the logical RMID is converted to the physical RMID and this conversion requires the NUMA node ID of the resctrl monitoring domain that is in turn determined by querying the NUMA node ID of any CPU belonging to the monitoring domain. When the monitoring domain is going offline its cpu_mask is empty causing the NUMA node ID query via cpu_to_node() to be done with nr_cpu_ids as argument resulting in an out-of-bounds access. Refactor the limbo handler to skip reading the RMID when the RMID will just be forced to no longer be dirty in the domain anyway. Add a safety check to the architecture's RMID reader to protect against this scenario.
    (CVE-2026-64477)

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

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

  - fpga：dfl-afu：验证 afu_dma_map_region（） 中的 DMA 映射长度 afu_ioctl_dma_map（） 在无上限检查的情况下，通过 DFL_FPGA_PORT_DMA_MAP ioctl 接受来自用户空间的 64 位长度。该值传递到 afu_dma_pin_pages（），其中 npages 派生为长度>> PAGE_SHIFT并传递给采用 int nr_pages的 pin_user_pages_fast（），如果长度非常大则造成隐式截断。调用 afu_dma_map_region（） 之前验证 ioctl 入口点的 map.length，拒绝页面计数超过 INT_MAX 的值。
    (CVE-2026-64280)

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

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

  - ksmbd：将打开器凭据用于 ADS I/O 备用数据流存储为 xattrs。因此，与常规文件 I/O 不同的是，其读写路径会调用 VFS xattr 帮助程序，后者使用当前任务凭据重新检查 inode 权限和 LSM 策略。使用打开 SMB 句柄时捕获的凭据运行 ADS I/O。（CVE-2026-64391）

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

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

  - gpio：eic-sprd：在 irq 启动路径中使用raw_spinlock_t sprd_eic_irq_unmask（） 启用 GPIO IRQ，然后通过 sprd_eic_update（） 更新控制器状态，该采用 spin_lock_irqsave（） 进行 sprd_eic->lock 。设置请求的 IRQ 时，可从 irq_startup（） 访问回调。该路径不可休眠，但在PREEMPT_RT，常规spinlock_t会变成睡眠锁。此问题是我们的静态分析工具发现的，然后对照当前树手动查看。接地的 PoC 保留了 request_threaded_irq（） -> __setup_irq（） -> irq_startup（） -> sprd_eic_irq_unmask（） -> sprd_eic_update（） 载波，并使用了原始的 spin_lock_irqsave（&sprd_eic->lock） 边缘。Lockdep 缺陷：
    从无效上下文调用的休眠函数 hardirqs 上次禁用时间为 ... __setup_irq.constprop.0 ...
    [vuln_msv] sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv] sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] 将展讯 EIC 控制器锁定转换为raw_spinlock_t。locked 部分仅序列化 MMIO 寄存器更新，不包含可休眠操作，因此对于 irqchip 回调而言，将其保持为非休眠是合适的。（CVE-2026-64429）

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

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

  - smb：client：解析实时注册中的 SWN tcon cifs_swn_notify（） 按 cifs_swnreg_idr_mutex 下的 id 查找见证注册，删除互斥体，然后使用注册的缓存 tcon 指针。
    该指针不是生命周期引用，一旦 cifs_get_swn_reg（） 允许同一网络/共享名称的多个 tcon 共享一个注册 ID，它就不是稳定的代表。在第一个 tcon 取消注册并释放后，相同共享的第二个挂载可使cifs_swn_reg保持活动。然后，注册仍然指向已释放的第一个 tcon，因此通过 swnreg->tcon 进行tc_lock或递增tc_count只会提前移动释放后使用。在按住 cifs_swnreg_idr_mutex 的同时进行tc_lock也违反了记录的 CIFS 锁定顺序。通过使注册存储仅作为稳定见证身份来修复此问题：
    ID、net 名称、共享名称和通知标记。当通知到达时，将该身份复制到cifs_swnreg_idr_mutex下，放置互斥体，然后找到并固定当前在正常cifs_tcp_ses_lock -> tc_lock 顺序下匹配 net/share 对的实时见证 tcon。通知路径会直接使用该固定的 tcon，并在完成后删除引用。注册和取消注册消息现在使用调用程序传递的实时 tcon，而不是注册中缓存的 tcon。当注册仍受到 cifs_swnreg_idr_mutex 保护时，最终取消注册发送会折叠到 cifs_swn_unregister（） 中。这将删除之前的查找/丢失/重新获取原始指针窗口。释放路径仅删除 idr 条目并释放稳定身份字符串。这保留了预期的 one-registration/many-tcon 行为：注册 ID 表示 net/share 对，并在使用时对选择的实时代表通知处理行为。它还保留了代表性 tcon 的 CLIENT_MOVE 顺序，因为旧 IP 取消注册是在 cifs_swn_register（） 发送新 IP 寄存器之前发送的。（CVE-2026-64401）

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

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

  - ALSA：es1938：当内存分配失败时，检查 snd_ctl_new1（） 返回值 snd_ctl_new1（） 可能返回 NULL。snd_es1938_mixer（） 在取消引用指针之前未检查返回值，这可导致空指针取消引用。在 snd_ctl_new1（） 之后添加空检查，如果失败则返回 -ENOMEM。
    (CVE-2026-64484)

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

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

  - 已修复 Linux 内核中的下列漏洞：fuse-uring: Avoid queue->stopped races and set/read that value under lock There are several readers of queue->stopped that check the value under lock, but fuse_uring_commit_fetch() did not and actually the value was not set under the lock in fuse_uring_abort_end_requests() either. Especially in fuse_uring_commit_fetch it is important to check under a lock, because due to races 'struct fuse_req' might be freed with fuse_request_end, but another thread/cpu might already do teardown work. (CVE-2026-64260)

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

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

  - vfio：阻止阻断的 ARC vfio_mig_get_next_state（） 中的 vfio_mig_get_next_state（） 无限循环，一次遍历 vfio_from_fsm_table[] 一步，循环以跳过设备不支持的可选状态，直到支持 *next_fsm。被阻断的转换编码为 VFIO_DEVICE_STATE_ERROR，尾部返回将其报告为 -EINVAL。跳过循环不考虑 ERROR 哨兵。
    state_flags_table[ERROR] 为 ~0U 且 vfio_from_fsm_table[ERROR][*] 为 ERROR，因此一旦 *next_fsm 变为 ERROR，循环条件将保持 true，*next_fsm 永远不会更改。被阻断的 arc STOP_COPY -> PRE_COPY 和 STOP_COPY -> PRE_COPY_P2P 映射到 ERROR，但仍通过了支持预复制的设备上的支持检查，从而导致循环在保留驱动程序状态互斥体时永久旋转。这可导致软锁定以及softlockup_panic设置的错误。终止 ERROR sentinel 上的跳过循环，以便阻断的转换转向现有返回并报告 -EINVAL。（CVE-2026-64474）

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

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

  - crypto：ecc - 修复 vli 乘法中的进位溢出 进位标记计算在 r01.m_high 饱和 （0xFFFFFFFFFFFFFFFF） 且添加低位溢出时失败。条件 （r01.m_high < product.m_high） 未处理以下情况：r01.m_high == product.m_high 且存在来自低位溢出的额外进位。提交 3c4b23901a0c（crypto：ecdh - 添加 ECDH 软件支持）引入 crypto/ecc.c 时，会将 micro-ecc 库中的 muladd（） 函数拆分为单独的 mul_64_64（） 和 add_128_128（） 辅助函数。支票似乎在翻译中丢失了。通过考虑较低加法的进位，为此边界添加适当的处理。（CVE-2026-64313）

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

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

  - 已修复 Linux 内核中的下列漏洞：iommufd: Use sizeof(*hdr) instead of sizeof(hdr) in veventq read The bound-check in iommufd_veventq_fops_read() for the normal vEVENT path uses sizeof(hdr) where the surrounding code uses sizeof(*hdr): if (!vevent_for_lost_events_header(cur) && sizeof(hdr) + cur->data_len > count - done) { hdr is declared as struct iommufd_vevent_header *, so sizeof(hdr) evaluates to the size of the pointer. Surrounding code uses sizeof(*hdr) consistently: if (done >= count || sizeof(*hdr) > count - done) { ... if (copy_to_user(buf + done, hdr, sizeof(*hdr))) {... done += sizeof(*hdr); struct iommufd_vevent_header is currently 8 bytes (two __u32 fields, flags and sequence), so on 64-bit (sizeof(void *) == 8) the two expressions happen to be equal and the check works as intended. On 32-bit (sizeof(void *) == 4) the check under-counts the header by 4 bytes: a vEVENT whose data_len causes 8 + cur->data_len to exceed count - done while 4 + cur->data_len does not will pass the check, then the loop will copy_to_user 8 bytes of header followed by data_len bytes of payload, writing past the user-supplied buffer. It is also a latent bug for any future expansion of struct iommufd_vevent_header beyond sizeof(void *) on 64-bit; the check should not depend on the type happening to match the host pointer width. Use sizeof(*hdr) to match the rest of the function and the actual amount that will be copied. (CVE-2026-64293)

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

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

  - 已修复 Linux 内核中的下列漏洞：iio: adc: ad_sigma_delta: fix clear_pending_event for registerless devices ad_sigma_delta_clear_pending_event() falls through to the status register read path for devices with has_registers = false and no rdy_gpiod. For such devices, ad_sd_read_reg() skips the address byte entirely and clocks raw MISO bytes with no address phase making it byte-for-byte identical to reading conversion data. If a pending conversion result is present, this partially consumes it and corrupts the data stream for the subsequent ad_sd_read_reg() call in ad_sigma_delta_single_conversion(). Furthermore, with num_resetclks = 0 on these devices, data_read_len evaluates to 0. If the clocked byte has bit 7 clear, pending_event is set and the code attempts memset(data + 2, 0xff, 0 - 1), overflowing to SIZE_MAX and corrupting the heap. Fix by returning 0 immediately when neither rdy_gpiod nor has_registers is set. This is safe for all current registerless devices: ad7191 and ad7780 (with powerdown GPIO) are reset between conversions by CS deassertion, so there is no stale result to drain; ad7780 (without powerdown GPIO) and max11205 are continuously-converting and cycle ~DRDY at the output data rate regardless of whether the previous result was read, so the next falling edge fires naturally. A future registerless device that holds ~DRDY asserted until data is read would be broken by this early return and would require either num_resetclks set or a rdy-gpio. The same heap corruption is reachable on any device with rdy_gpiod set but num_resetclks = 0: if the GPIO indicates a pending event, the drain path executes memset(data + 2, 0xff, 0 - 1) regardless of has_registers. Add an explicit data_read_len == 0 guard after the pending event check; the stale result is then consumed by the first ad_sd_read_reg() call in ad_sigma_delta_single_conversion(). (CVE-2026-64502)

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

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

  - SMB：客户端：将隐含的 bcc[0] 豁免限制为无数据区响应 smb2_check_message（） 有一个由来已久的 quirk，该响应接受计算长度比实际收到的字节大一个字节的响应（由于隐含的 bcc[0]，服务器可多返回一个字节）。引入此方法是为了适应当不存在数据区域时忽略末尾 bcc[0] 重叠字节的服务器。但是，无论命令是否实际带有数据区 （），has_smb2_data_area[]都会无条件地应用豁免。当具有数据区域的响应受到 +1 豁免的制约时，报告的数据可扩展实际收到的字节之外的一个字节，但 smb2_check_message（） 仍然接受它。随后的解码器随后会读取超过接收缓冲区的末端。在会话建立之前，在协商和SESSION_SETUP期间可访问此信息。当针对不合格服务器挂载时，产生的越界读取在 KASAN 下可见;SPNEGO/negTokenInit 和 NTLMSSP 质询解码器均受到影响： 缺陷：KASAN：任务 mount.cifs/81 在地址 ffff8880084d67c0 处的大小为 1 的 asn1_ber_decoder+0x16a7/0x1b00 中的 slab-out-ofbound 读取 CPU：1 UID：0 PID：81 comm：mount.cifs 未受感染 7.1.0-rc6 #1 调用跟踪： <TASK> dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 asn1_ber_decoder+0x16a7/0x1b00 decode_negTokenInit+0x19/0x30 SMB2_negotiate+0x31d9/0x4c90 cifs_negotiate_protocol+0x1f2/0x3f0 cifs_get_smb_ses+0x93f/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 按任务 85 分配： kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 有缺陷的地址位于分配的 448 字节区域右侧 0 字节处 [ffff8880084d6600， ffff8880084d67c0），属于大小为 448 的缓存cifs_small_rq 缺陷：KASAN：
    kmemdup_noprof+0x36/0x50 中的 slab-of-bound 任务 mount.cifs/89 在地址 ffff88800726c678 读取大小为 329 CPU：0 UID：0 PID：89 comm：mount.cifs 受污染：G B 7.1.0-rc6 #1 调用跟踪： <TASK> dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0
    __asan_memcpy+0x23/0x60 kmemdup_noprof+0x36/0x50 decode_ntlmssp_challenge+0x457/0x680 SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0 SMB2_sess_setup+0x219/0x4f0 cifs_setup_session+0x248/0xaf0 cifs_get_smb_ses+0xf79/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 按任务 93 分配：kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 有缺陷的地址位于分配的 448 字节区域内 120 字节处 [ffff88800726c600， ffff88800726c7c0）（属于大小为 448 的缓存cifs_small_rq） 将 +1 豁免限制为无数据区域的响应，使其仍然涵盖其本应针对的 bcc[0] 遗漏。当存在数据区域时，+1 差异意味着报告的数据长度超过
    ---truncated--- (CVE-2026-64448)

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD) Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? The SEV firmware docs for SNP_VLEK_LOAD note: > On SNP_SHUTDOWN, the VLEK is deleted. That is, the initialization/shutdown wrapper here is pointless, because the firmware immediately throws away the key anyway. Instead, refuse to do anything if SNP has not been previously initialized. This is an ABI break: before, this was a no-op and almost certainly a mistake by userspace, and now it returns -ENODEV. ABI compatibility could be maintained here by simply returning 0 in the check instead. (CVE-2026-64308)

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

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

  - 已修复 Linux 内核中的下列漏洞：virtio_pci: fix vq info pointer lookup via wrong index Unbinding a virtio balloon device: echo virtio0 > /sys/bus/virtio/drivers/virtio_balloon/unbind triggers a NULL pointer dereference. The dmesg says: BUG:
    kernel NULL pointer dereference, address: 0000000000000008 [...] RIP:
    0010:__list_del_entry_valid_or_report+0x5/0xf0 Call Trace: <TASK> vp_del_vqs+0x121/0x230 remove_common+0x135/0x150 virtballoon_remove+0xee/0x100 virtio_dev_remove+0x3b/0x80 device_release_driver_internal+0x187/0x2c0 unbind_store+0xb9/0xe0 kernfs_fop_write_iter.llvm.11660790530567441834+0xf6/0x180 vfs_write+0x2a9/0x3b0 ksys_write+0x5c/0xd0 do_syscall_64+0x54/0x230 entry_SYSCALL_64_after_hwframe+0x29/0x31 [...] </TASK> The virtio_balloon device registers 5 queues (inflate, deflate, stats, free_page, reporting) but only the first two are unconditional. The stats, free_page and reporting queues are each conditional on their respective feature bits. When any of these features are absent, the corresponding vqs_info entry has name == NULL, creating holes in the array. The root cause is an indexing mismatch introduced when vq info storage was changed to be passed as an argument. vp_find_vqs_msix() and vp_find_vqs_intx() store the info pointer at vp_dev->vqs[i], where 'i' is the caller's sparse array index. However, the virtqueue itself gets vq->index assigned from queue_idx, a dense index that skips NULL entries. When holes exist, 'i' and queue_idx diverge. Later, vp_del_vqs() looks up info via vp_dev->vqs[vq->index] using the dense index into the sparsely-populated array, and hits NULL. Fix this by storing info at vp_dev->vqs[queue_idx] instead of vp_dev->vqs[i], so the store index matches the lookup index (vq->index). Apply the fix to both the MSIX and INTX paths. (CVE-2026-64457)

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

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

  - 已修复 Linux 内核中的下列漏洞：tracing: Fix NULL pointer dereference in func_set_flag() func_set_flag() dereferences tr->current_trace_flags before verifying that the current tracer is actually the function tracer. When the active tracer has been switched away from function (e.g., to wakeup_rt), tr->current_trace_flags can be NULL, leading to a NULL pointer dereference and kernel crash. The call chain that triggers this is: trace_options_write() -> __set_tracer_option() -> trace->set_flag() /* func_set_flag */ In func_set_flag(), the first operation is: if (!!set == !!(tr->current_trace_flags->val & bit)) This dereferences tr->current_trace_flags unconditionally. The safety check that guards against a non-function tracer: if (tr->current_trace != &function_trace) return 0; is placed *after* the dereference, which is too late. This was observed with the following crash dump:
    BUG: unable to handle page fault at 0000000000000000 RIP: func_set_flag+0xd Call Trace:
    __set_tracer_option+0x27 trace_options_write+0x75 vfs_write+0x12a ksys_write+0x66 do_syscall_64+0x5b RIP:
    ffffffff914c973d RSP: ff67ec88b01dfdf0 RFLAGS: 00010202 RAX: 0000000000000000 RBX: ff3a826e80354580 RCX:
    0000000000000001 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff93918080 The disassembly confirms the fault: func_set_flag+0: mov 0x1f08(%rdi), %rax ; RAX = tr->current_trace_flags = NULL func_set_flag+13: mov (%rax), %eax ; page fault: dereference NULL At the time of the crash:
    tr->current_trace_flags = 0x0 (NULL) tr->current_trace = wakeup_rt_tracer (not function_trace) The scenario is that a process opens a function tracer option file (such as func_stack_trace), then the current tracer is switched to another tracer (e.g., wakeup_rt), which sets current_trace_flags to NULL.
    When the process subsequently writes to the option file, func_set_flag() is invoked and crashes on the NULL dereference. Fix this by moving the current_trace check before the current_trace_flags dereference, so that func_set_flag() returns early when the function tracer is not active. (CVE-2026-64451)

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

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

  - 已修复 Linux 内核中的下列漏洞：x86/mm: Fix freeing of PMD-sized vmemmap pages Commit bf9e4e30f353 (x86/mm: use pagetable_free()), switched from freeing non-boot page tables through __free_pages() to pagetable_free(). However, the function is also called to free vmemmap pages. Given that vmemmap pages are not page tables, already the page_ptdesc(page) is wrong. But worse, pagetable_free() calls: __free_pages(page, compound_order(page)); Since vmemmap pages are not compound pages (see vmemmap_alloc_block()) -- except for HVO, which doesn't apply here -- only first page of a PMD-sized vmemmap page is freed, leaking the other ones. Fix it by properly decoupling pagetable and vmemmap freeing. free_pagetable() no longer has to mess with SECTION_INFO, as only the vmemmap is marked like that in register_page_bootmem_memmap(). The indentation in remove_pmd_table() is messed up. Fix that while touching it. Bootmem info handling will soon be fixed up. For now, handle it similar to free_pagetable(), just avoiding the ifdef. [ dhansen: changelog munging. More imperative voice ] (CVE-2026-64302)

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

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

  - staging：rtl8723bs：修复 rtw_cfg80211_set_wpa_ie（） 中的堆缓冲区溢出supplicant_ie结构security_priv中为 256 字节的数组。WPA 和 WPA2 IE 复制路径使用：
    memcpy（padapter->securitypriv.supplicant_ie， &pwpa[0]， wpa_ielen + 2）;其中 wpa_ielen 是原始 IE 长度字段 （u8， 0-255）。当本地用户通过 nl80211 使用构建的长度为 255 的 WPA IE 提供连接请求时，wpa_ielen + 2 等于 257，这会使 256 字节的缓冲区一个字节溢出到相邻的 last_mic_err_time 字段中。rtw_parse_wpa_ie（） 未阻止此情况：其长度一致性检查会比较
    *（wpa_ie+1） 与 （u8）（wpa_ie_len-2），当 wpa_ie_len = 257 时，即 （u8）（255） == 255，因此检查静默通过。在 memcpy 之前对 WPA 和 WPA2 路径添加明确的边界检查，拒绝总大小 （wpa_ielen + 2） 超过supplicant_ie缓冲区的任何 IE。（CVE-2026-64446）

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: mt76: mt7921/mt7925: fix NULL dereference in CSA beacon This patch is based on a BUG as reported by Bongani Hlope at https://lore.kernel.org/all/20260502125824.425d7159@bongani-mini.home.org.za/ When a channel-switch announcement (CSA) beacon is received, cfg80211 queues a wiphy work item that eventually calls mt7921_channel_switch_rx_beacon(). If the station disconnects (or the channel context is otherwise torn down) between the time the work is queued and the time it runs, the driver's dev->new_ctx pointer can already have been cleared to NULL. mt7921_channel_switch_rx_beacon() then dereferences new_ctx unconditionally, triggering a NULL pointer dereference at address 0x0: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:mt7921_channel_switch_rx_beacon+0x1f/0x100 [mt7921_common] The same missing guard exists in mt7925_channel_switch_rx_beacon(), which shares the same code pattern introduced by the same commit. Add an early-return NULL check for dev->new_ctx in both mt7921_channel_switch_rx_beacon() and mt7925_channel_switch_rx_beacon(). When new_ctx is NULL there is no pending channel switch to process, so returning immediately is the correct and safe action. Oops-Analysis:
    http://oops.fenrus.org/reports/lkml/20260502125824.425d7159@bongani-mini.home.org.za/report.html(CVE-2026-64325)

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

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

  - crypto：caam - 使用 print_hex_dump_devel 保护密钥十六进制转储 当启用CONFIG_DYNAMIC_DEBUG时，使用 print_hex_dump_devel（） 转储 *_setkey（） 和 gen_split_key（） 中的敏感密钥材料，以避免在运行时泄漏机密。（CVE-2026-64316）

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

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

  - iio：light：gp2ap002：修复读取错误时的运行时 PM 泄漏 gp2ap002_read_raw（） 在读取 lux 值之前调用 pm_runtime_get_sync（），但如果 gp2ap002_get_lux（） 失败，它会直接返回。这会跳过 out 标签处的 pm_runtime_put_autosuspend（） 调用，永久泄漏运行时 PM 引用并阻止设备自动暂停。将直接返回替换为 goto out，以确保正确丢弃错误路径中的引用。（CVE-2026-64494）

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

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

  - 已修复 Linux 内核中的下列漏洞：io_uring/nop: fix file reference leak with IOSQE_FIXED_FILE NOP file-acquisition support choses between a fixed (registered) file and a normal fget()'d file based on its own IORING_NOP_FIXED_FILE flag in sqe->nop_flags. However, a request's REQ_F_FIXED_FILE is set independently from the generic IOSQE_FIXED_FILE sqe flag during request init, before the issue handler runs. If a NOP is submitted with IOSQE_FIXED_FILE set (so REQ_F_FIXED_FILE is set) but without IORING_NOP_FIXED_FILE, io_nop() takes the normal path and grabs a real reference via io_file_get_normal(). On completion, io_put_file() only drops the reference when REQ_F_FIXED_FILE is clear, so the fget()'d file is never released and leaks: BUG: memory leak unreferenced object 0xffff88800f42c240 (size 176): kmem_cache_alloc_noprof+0x358/0x440 alloc_empty_file+0x57/0x180 path_openat+0x44/0x1e50 do_file_open+0x121/0x200 do_sys_openat2+0xa7/0x150 __x64_sys_openat+0x82/0xf0 Decide between fixed and normal file acquisition from REQ_F_FIXED_FILE, the same way io_assign_file() does for every other opcode, and fold IORING_NOP_FIXED_FILE into REQ_F_FIXED_FILE at prep time.
    (CVE-2026-64426)

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

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

  - net：af_key：初始化 IPComp 状态的alg_key_len pfkey_msg2xfrm_state（） 通过分配 x->calg 并仅复制算法名称来处理 IPComp （SADB_X_SATYPE_IPCOMP） 情况：x->calg = kmalloc_obj（*x->calg）;if （！x->calg） { err = -ENOMEM; goto out; } strcpy（x->calg->alg_name， a->name）;
    x->props.calgo = sa->sadb_sa_encrypt;与同一函数的认证 （x->aalg） 和加密 （x->ealg） 分支不同，压缩分支从不初始化 calg->alg_key_len。IPComp 不带有密钥，分配仅保留 sizeof（struct xfrm_algo）（即没有密钥空间），因此该字段保留包含未初始化的 slab 数据。当在 XFRM_MSG_MIGRATE 期间克隆 IPComp 状态时，calg->alg_key_len 随后被 xfrm_algo_clone（） 用作长度：xfrm_state_migrate（） xfrm_state_clone_and_setup（） x->calg = xfrm_algo_clone（orig->calg）;kmemdup（orig， xfrm_alg_len（orig））;其中 xfrm_alg_len（） 返回 sizeof（*alg） + （alg_key_len + 7） / 8。使用非零垃圾alg_key_len时，kmemdup（） 会读取超过 68 字节 calg 对象的末尾。通过 PF_KEY 添加 IPComp SA，然后将其迁移会触发（net-next、KASAN、init_on_alloc=0）：缺陷：KASAN：在 kmemdup_noprof+0x44/0x60 中存在 slab-out-of-bound 通过任务 diag2/9287 在地址 ff11000025a74980 读取的大小为 4164 CPU：3 UID：0 PID：9287 Comm：diag2 7.1.0-rc6-g903db046d557 #1 调用跟踪： <TASK> dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 ____sys_sendmsg+0x9f7/0xb90
    ___sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 按任务 9287 分配：kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f 有缺陷的地址属于到属于大小为 96 的缓存 kmalloc-96 的 ff11000025a74980 对象 有缺陷的地址位于分配的 68 字节区域内 0 字节处 [ff11000025a74980、ff11000025a749c4） 根据未初始化的值，同一字段可改为请求过大的 kmemdup（） 分配并导致迁移克隆失败。XFRM netlink 路径不受影响：verify_one_alg（） 拒绝短于 xfrm_alg_len（） 的 XFRMA_ALG_COMP 属性，因此通过 XFRM_MSG_NEWSA 添加的 calg 始终自一致。将 calg->alg_key_len 初始化为 0，以匹配 aalg/ealg 分支。（CVE-2026-64436）

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

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

  - HID：appleir：修复 remove（） 中的待定key_up_timer上的 UAF appleir_remove（） 在 timer_delete_sync（） 之前运行 hid_hw_stop（）。hid_hw_stop（） 通过 hid_disconnect（） -> hidinput_disconnect（） -> input_unregister_device（） 同步取消注册 HID 输入设备，当没有用户空间句柄保持打开时，会终止最后一个引用并释放底层input_dev。key_up_tick（） 读取 appleir->input_dev 并对其调用 input_report_key（） / input_sync（）。定时器由 appleir_raw_event（） 布防，每个按键和按键重复报告都有 HZ/8 （~125 ms） 超时。如果在设备断开连接前不久按下了某个键，则定时器可在 hid_hw_stop（） 释放input_dev之后但在拆卸耗尽它之前触发。简单的重新排序是不够的。将定时器漏放在第一位仍然会留下一个窗口，其中 hid_hw_stop（） 期间运行的 USB URB 完成 （raw_event） 可以调用 mod_timer（） 并重新布防定时器，然后在 hidinput_disconnect（） 释放input_dev后触发。同一个 URB-completion 窗口还允许 raw_event（） 直接访问 key_up（）、key_down（） 和 battery_flat（），所有这些都会取消引用 appleir->input_dev。在由现有自旋锁进行网关的结构 appleir 上引入“removing”标记。
    appleir_remove（） 在锁定下设置标记，然后使用 timer_shutdown_sync（） 关闭定时器，这会耗尽任何正在传输的回调并永久禁用进一步的 mod_timer（） 调用。
    如果设置了该标记，appleir_raw_event（） 和 key_up_tick（） 会提早退出，因此没有任何路径可以在 remove（） 开始拆卸之后布防或运行定时器，或取消引用 appleir->input_dev。之前调用的 appleir_raw_event（） 的 keyrepeat 和 flatbattery 分支没有保持旋转锁而进入输入层;现在就进行，以便明确定义标记检查。这顺便解决了 keyrepeat 分支中 appleir->current_key 上预先存在的读取端争用。此缺陷在结构上是提交 4db2af929279（HID：appletb-kbd：修复 inactivity-timer 清理路径中的 UAF）的同级，自引入该驱动程序以来一直存在。（CVE-2026-64363）

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

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

  - USB：ldusb：修复断开连接争用时的释放后使用 mutex_unlock（） 可在释放锁定后访问互斥体结构，因此无法直接用于管理对象的生命周期（与旋转锁和引用计数不同）。[1][2] 当 release（） 与 disconnect（） 争用时，使用 kref 释放驱动程序数据以避免 mutex_unlock（） 中的释放后使用。[1] a51749ab34d9 （locking/mutex： 记录 mutex_unlock（） 是非原子的） [2] 2b9d9e0a9ba0 （locking/mutex： 阐明 mutex_unlock（） 和大多数其他休眠锁在解锁后仍然可以使用该锁定对象） （CVE-2026-64343）

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

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

  - 已修复 Linux 内核中的下列漏洞：tcp: restore RCU grace period in tcp_ao_destroy_sock Commit 51e547e8c89c (tcp: Free TCP-AO/TCP-MD5 info/keys without RCU) removed the call_rcu() callback from tcp_ao_destroy_sock(), arguing that the destruction of info/keys is delayed until the socket destructor and therefore no one can discover it anymore. That argument does not hold for the call site in tcp_connect() (net/ipv4/tcp_output.c:4327-4332). At that point the socket is in TCP_SYN_SENT, has already been inserted into the inet ehash by inet_hash_connect() in tcp_v4_connect(), and is therefore very much discoverable: any softirq running tcp_v4_rcv() on another CPU can take the socket out of the ehash, walk into tcp_inbound_hash(), and load tp->ao_info via implicit RCU before bh_lock_sock_nested() is taken on the destroying CPU. The reader path then enters __tcp_ao_do_lookup() (net/ipv4/tcp_ao.c:208) which re-loads tp->ao_info via rcu_dereference_check(); the re-load can still observe the (about-to-be-freed) pointer because there is no synchronize_rcu() between rcu_assign_pointer(tp->ao_info, NULL) and tcp_ao_info_free() in tcp_ao_destroy_sock(). The captured pointer is then walked at line 223: hlist_for_each_entry_rcu(key, &ao->head, node, ...) The writer's synchronous kfree() is free to complete between the line 218 re-fetch and the line 223 hlist iteration.
    The slab is reused (or simply LIST_POISON1-stamped if not yet reused) and the iteration walks attacker-controlled or poison memory in softirq context. Reproducer (no debug shim, stock x86_64 v7.1-rc2 SMP+KASAN, QEMU+KVM): an unprivileged uid=1000 process inside CLONE_NEWUSER|CLONE_NEWNET installs TCP_MD5SIG + TCP_AO_ADD_KEY on a TCP socket, sprays forged TCP-AO segments toward its eventual 4-tuple via raw sockets, then calls connect(). The md5-wins reconciliation in tcp_connect() fires tcp_ao_destroy_sock(); the softirq backlog reader on the loopback NAPI path crashes on the freed ao->head.first walk: Oops: general protection fault, probably for non-canonical address 0xfbd59c000000002f KASAN: maybe wild-memory-access in range [0xdead000000000178-0xdead00000000017f] CPU: 0 UID: 1000 PID: 100 Comm: repro_userns RIP: 0010:__tcp_ao_do_lookup+0x107/0x1c0 Call Trace: <IRQ>
    __tcp_ao_do_lookup+0x107/0x1c0 tcp_ao_inbound_lookup.constprop.0+0x12a/0x200 tcp_inbound_ao_hash+0x5ea/0x1520 tcp_inbound_hash+0x7ce/0x1240 tcp_v4_rcv+0x1e7a/0x3e10 ... Restore the RCU grace period: re-add struct rcu_head to tcp_ao_info and replace the synchronous tcp_ao_info_free() with a call_rcu() callback. Readers that captured tp->ao_info before rcu_assign_pointer NULLed it now see the object remain valid until rcu_read_unlock(). With the patch applied the reproducer runs cleanly for 2000 iterations on the same kernel build. (CVE-2026-64459)

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

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

  - ipv4：igmp：设备销毁时从哈希表中删除多播群组 当设备在 RTNL 下销毁时，ip_mc_destroy_dev（） 会迭代多播列表，并对每个成员关系调用 ip_马_put（），从而计划他们进行 RCU 回收。但是，它们不会从设备的多播哈希表 （mc_hash） 解除链接。由于设备会在 ip_mc_destroy_dev（） 完成之前仍会在 dev->ip_ptr 中发布，因此遍历mc_hash的并行 RCU 读取器在减少 refcount 之后仍可定位并访问多播群组。如果在阅读器访问群组时运行 RCU 回调并释放该群组，则会发生释放后使用。通过在计划回收之前使用 ip_mc_hash_remove（） 将多播群组与mc_hash断开链接来修复此问题。缺陷：KASAN：在 ip_check_mc_rcu+0x149/0x3f0 中释放后使用 任务在地址 ffff888009bf1408 处读取大小为 4 调用跟踪： <IRQ> dump_stack_lvl+0x67/0x90 print_report+0x175/0x7c0 kasan_report+0x147/0x180 ip_check_mc_rcu+0x149/0x3f0 udp_v4_early_demux+0x36d/0x12d0 ip_rcv_finish_core+0xb8b/0x1390 ip_rcv_finish+0x54/0x120 NF_HOOK+0x213/0x2b0 __netif_receive_skb+0x126/0x340 process_backlog+0x4f2/0xf00 __napi_poll+0x92/0x2c0 net_rx_action+0x583/0xc60 handle_softirqs+0x236/0x7f0 do_softirq+0x57/0x80 </IRQ> 按任务 2239 分配：
    kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x72/0x90 ____ip_mc_inc_group+0x31a/0xa40
    __ip_mc_join_group+0x334/0x3f0 do_ip_setsockopt+0x16fa/0x2010 ip_setsockopt+0x3f/0x90 do_sock_setsockopt+0x1ad/0x300 由任务 0 释放：kasan_save_track+0x3e/0x80 kasan_save_free_info+0x40/0x50
    __kasan_slab_free+0x3a/0x60 __rcu_free_sheaf_prepare+0xd4/0x220 rcu_free_sheaf+0x36/0x190 rcu_core+0x8d9/0x12f0 handle_softirqs+0x236/0x7f0 （CVE-2026-64423）

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

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

  - 已修复 Linux 内核中的下列漏洞：fuse-uring: end fuse_req on io-uring cancel task work When io_uring delivers task work with tw.cancel set (PF_EXITING, PF_KTHREAD fallback, or percpu_ref_is_dying on the ring context), fuse_uring_send_in_task() takes the cancel branch, assigns
    -ECANCELED, and falls through to fuse_uring_send(). That path only flips the entry to FRRS_USERSPACE and completes the io_uring cmd; it never discharges the ring entry's owning reference to the fuse_req that fuse_uring_add_req_to_ring_ent() handed it at dispatch time. fuse_uring_send_in_task() tw.cancel == true err = -ECANCELED fuse_uring_send(ent, cmd, err, issue_flags) ent->state = FRRS_USERSPACE list_move(&ent->list, &queue->ent_in_userspace) ent->cmd = NULL io_uring_cmd_done(-ECANCELED) /* ent->fuse_req still set, req still hashed */ The fuse_req stays linked on fpq->processing[hash] and fuse_request_end() is never invoked. The originating syscall thread blocks in D-state in request_wait_answer() until fuse_abort_conn() runs, which can be the entire connection lifetime. For FR_BACKGROUND requests fc->num_background is never decremented either, so repeated cancels inflate the counter until max_background is hit and all later background ops stall. tw.cancel does not imply a connection abort (e.g. a single io_uring worker thread exits while the fuse connection stays up), so this cannot be left for fuse_abort_conn() to clean up. Ending the req but still routing the entry through fuse_uring_send() is not enough: that leaves a req-less entry on ent_in_userspace, and ent_list_request_expired() dereferences ent->fuse_req unconditionally on the head of that list, which would then NULL-deref. Fix the cancel branch to release the entry directly. Remove it from the queue, complete the io_uring cmd, end the fuse_req, free the entry, and drop its queue_refs (waking the teardown waiter if it was the last). (CVE-2026-64262)

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

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

  - ALSA：aoa：检查 snd_ctl_new1（） 返回值 snd_ctl_new1（） 可在内存分配失败时返回 NULL。
    在 layout.c 中，函数在取消引用 ctl->id.name 或传递给 aoa_snd_ctl_add（） 之前未检查返回值，这可导致空指针取消引用。在 snd_ctl_new1（） 调用后添加空检查，如果有任何失败并提早返回。（CVE-2026-64488）

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

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

  - NTB：epf：避免从 hardirq 上下文调用 pci_irq_vector（） ntb_epf_vec_isr（） 会调用 hardirq 上下文中的 pci_irq_vector（） 以派生矢量数。pci_irq_vector（） 会调用采用互斥体的 msi_get_virq（），因此可在原子 SPLATS 时触发计划：缺陷：原子时进行计划：
    kworker/u33：0/55/0x00010001 ... 调用跟踪：...计划+0x38/0x110 schedule_preempt_disabled+0x28/0x50
    __mutex_lock.constprop.0+0x848/0x908 __mutex_lock_slowpath+0x18/0x30 mutex_lock+0x4c/0x60 msi_domain_get_virq+0xe8/0x138 pci_irq_vector+0x2c/0x60 ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf]
    __handle_irq_event_percpu+0x70/0x3a8 handle_irq_event+0x48/0x100 handle_edge_irq+0x100/0x1c8 ... 分配矢量时缓存矢量 0 的 Linux IRQ 编号，并将其用作 ISR 中的基础。在线程 IRQ 处理程序中运行 ISR 也可以避免此问题，但此处没有必要。
    (CVE-2026-64430)

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

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

  - 已修复 Linux 内核中的下列漏洞：iommufd: Break the loop on failure in iommufd_fault_fops_read() On a copy_to_user() failure inside the inner list_for_each_entry, only the inner loop breaks; the outer while re-fetches the just-restored fault group and retries the failing copy_to_user() forever, spinning the reader at 100% CPU with fault->mutex held. Check rc after the inner loop and break the outer while as well. (CVE-2026-64290)

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

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

  - 已修复 Linux 内核中的下列漏洞：iio: temperature: tmp006: use devm_iio_trigger_register tmp006_probe() allocates the DRDY trigger with devm_iio_trigger_alloc() but registers it with plain iio_trigger_register(). The driver has no .remove() callback, so on module unload the trigger stays in the global trigger list while its memory is freed by devm, leaving a dangling entry.
    Switch to devm_iio_trigger_register() so the registration is undone in the same devm scope as the allocation. (CVE-2026-64492)

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

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

  - 输入：synaptics-rmi4 - 将键映射绑定 F30 到 GPIO/LED 计数 rmi_f30_map_gpios（） 分配最多 6 个条目的 min（gpioled_count， TRACKSTICK_RANGE_END） == gpioled_key_map，但 rmi_f30_attention（） 迭代完整的 f30->gpioled_count（设备查询寄存器，范围 0..31）和取消引用 gpioled_key_map[i]，并且 input->keycodemax 设置为完整gpioled_count，而 input->keycode 指向 6 个条目分配。因此，报告启用 GPIO 支持的 gpioled_count > 6 的设备会在注意力中断上造成越界读取，以及通过 EVIOCGKEYCODE/EVIOCSKEYCODE ioctls（仅根据 keycodemax 绑定索引）进行越界读取/写入。此缺陷与 F3A 处理程序相同，后者是 F30从 . 调整完整gpioled_count的键映射大小;映射循环仍然仅分配前 min（gpioled_count， TRACKSTICK_RANGE_END） 条目。
    (CVE-2026-64276)

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

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

  - usb：typec：tcpm：验证 svdm_consume_modes（） 中的 SVID 索引 在 svdm_consume_modes（） 中，不经过边界验证，使用 pmdata->svid_index 作为数组索引，从 pmdata->svids 读取 SVID 值：
    paltmode->svid = pmdata->svids[pmdata->svid_index];如果 pmdata->svid_index 的驱动范围超出 SVID_DISCOVERY_MAX （16），会导致越界读取 pmdata->svids 数组。由于 pd_mode_data 嵌入在 struct tcpm_port 内，因此索引过去的 svids 会读取到相邻字段中。特别是：- 在索引 16 处，它读取 altmodes 计数。- 在索引 18 及以上位置，它读入 altmode_desc[]，其中包含合作伙伴提供的 SVDM 发现模式 VDO。通过将选定的 SVID 注入 altmode_desc[0].vdo 并将 svid_index 驱动到 20，伙伴可强制 paltmode->svid 加载伙伴所选的任意 SVID，然后通过 typec_partner_register_altmode（） 注册。通过在访问 svdm_consume_modes（） 中的 pmdata->svids 数组之前验证 pmdata->svid_index 是否为非负且严格小于 pmdata->nsvids，来修复此问题。（CVE-2026-64330）

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

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

  - crypto：caam - 使用 print_hex_dump_devel 保护密钥十六进制转储 在启用CONFIG_DYNAMIC_DEBUG时使用 print_hex_dump_devel（） 转储 *_setkey（） 中的敏感密钥材料以避免在运行时泄漏机密。（CVE-2026-64315）

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: arm64: Don't leak PFN when kvm_translate_vncr() races MMU notifier In the case that kvm_translate_vncr() races with an MMU notifier the early return does not release a reference on the faulted in PFN. Add the necessary call to kvm_release_faultin_page() for the unused PFN. (CVE-2026-64282)

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

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

  - iommufd：设置缓存失效entry_num的上限，entry_len iommufd_hwpt_invalidate（） 采用用户控制的entry_num和entry_len，每个和仅按U32_MAX为边界。超出内核结构大小的entry_len会使复制帮助程序验证额外的字节是否为零，并在一次不间断传递中扫描多余的字节;超过零用户内存的数 GB 值会使软锁定监视程序跳脱。另一半是大entry_num，驱动后端无效循环，无需重新计划。例如，VT-d 嵌套处理程序每次迭代都会复制每个条目并刷新缓存，从而将 CPU 固定在非抢占内核上。在 ioctl 中封装两者。entry_len保持在 PAGE_SIZE 下，高于任何请求结构，entry_num低于 1 << 19，即硬件失效队列的顺序，并且远远超过任何实际批次，限制了每个调用的循环长度。（CVE-2026-64289）

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

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

  - fs/ntfs3：验证 log_replay copy_lcns 中的脏页表容量 在日志重播的 $LogFile 分析过程中，log_replay（） 将每个操作日志记录中的 LCN 复制到现有脏页表 （DPT） 条目，而不限制目标索引边界。具有 DPT 条目 lcns_follow=1 和操作日志记录 lcns_follow=2 的特制 NTFS 图像在装载时产生内核 slab 越界写入：缺陷：
    KASAN：在 log_replay+0x654c/0xdb60 中的 slab-of-bound 通过任务挂载在地址 ffff8880095e1040 处写入大小为 8 两个由攻击者控制的字段可驱动 j+i 越过分配 page_lcns[] 的数组：1.
    DP->lcns_follow（容量）可以小于 LRH->lcns_follow。2. LRH->target_vcn可能比DP->VCN小，使u64减法包装成一个巨大的size_t。根据 DPT 条目容量验证目标 VCN 增量和每条记录的 LCN 计数，通过现有的 out： 清除标签与 -EINVAL 进行验证。这反映了提交 b2bc7c44ed17 中添加的边界检查模式（fs/ntfs3：修复 DeleteIndexEntryRoot 中的 slab-越界读取）和提交 0ca0485e4b2e（fs/ntfs3：验证 rec->用于 journal-replay 文件记录检查）。（CVE-2026-64432）

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

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

  - firmware：arm_ffa：绑定PARTITION_INFO_GET_REGS副本 将分区描述符复制到调用程序缓冲区时，基于寄存器的PARTITION_INFO_GET路径信任固件提供的索引。拒绝不一致的计数或索引数程，这样复制循环就不能写入超过分配的数组。（修复了第一个片段中正好是一个描述符cur_idx）（CVE-2026-64520）

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

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

  - USB：iowarrior：修复断开连接时的释放后使用 提交的写入 URB 未在 close（） 上停止，因此需要在 disconnect（） 上无条件停止以避免完成处理程序中的释放后使用。（CVE-2026-64342）

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

ID	名称	严重性
329926	Linux Distros 未修补的漏洞：CVE-2026-64483	high
329925	Linux Distros 未修补的漏洞：CVE-2026-64268	critical
329924	Linux Distros 未修补的漏洞：CVE-2026-64356	medium
329923	Linux Distros 未修补的漏洞：CVE-2026-64435	high
329922	Linux Distros 未修补的漏洞：CVE-2026-64378	high
329921	Linux Distros 未修补的漏洞：CVE-2026-64397	critical
329920	Linux Distros 未修补的漏洞：CVE-2026-64337	medium
329919	Linux Distros 未修补的漏洞：CVE-2026-64506	medium
329918	Linux Distros 未修补的漏洞：CVE-2026-64486	medium
329917	Linux Distros 未修补的漏洞：CVE-2026-64449	high
329916	Linux Distros 未修补的漏洞：CVE-2026-64349	medium
329915	Linux Distros 未修补的漏洞：CVE-2026-64477	medium
329914	Linux Distros 未修补的漏洞：CVE-2026-64280	high
329913	Linux Distros 未修补的漏洞：CVE-2026-64391	critical
329912	Linux Distros 未修补的漏洞：CVE-2026-64429	medium
329911	Linux Distros 未修补的漏洞：CVE-2026-64401	high
329910	Linux Distros 未修补的漏洞：CVE-2026-64484	medium
329909	Linux Distros 未修补的漏洞：CVE-2026-64260	high
329908	Linux Distros 未修补的漏洞：CVE-2026-64474	medium
329907	Linux Distros 未修补的漏洞：CVE-2026-64313	high
329906	Linux Distros 未修补的漏洞：CVE-2026-64293	high
329905	Linux Distros 未修补的漏洞：CVE-2026-64502	high
329904	Linux Distros 未修补的漏洞：CVE-2026-64448	high
329903	Linux Distros 未修补的漏洞：CVE-2026-64308	medium
329902	Linux Distros 未修补的漏洞：CVE-2026-64457	medium
329901	Linux Distros 未修补的漏洞：CVE-2026-64451	medium
329900	Linux Distros 未修补的漏洞：CVE-2026-64302	medium
329899	Linux Distros 未修补的漏洞：CVE-2026-64446	high
329898	Linux Distros 未修补的漏洞：CVE-2026-64325	medium
329897	Linux Distros 未修补的漏洞：CVE-2026-64316	medium
329896	Linux Distros 未修补的漏洞：CVE-2026-64494	high
329895	Linux Distros 未修补的漏洞：CVE-2026-64426	medium
329894	Linux Distros 未修补的漏洞：CVE-2026-64436	high
329893	Linux Distros 未修补的漏洞：CVE-2026-64363	high
329892	Linux Distros 未修补的漏洞：CVE-2026-64343	high
329891	Linux Distros 未修补的漏洞：CVE-2026-64459	critical
329890	Linux Distros 未修补的漏洞：CVE-2026-64423	high
329889	Linux Distros 未修补的漏洞：CVE-2026-64262	medium
329888	Linux Distros 未修补的漏洞：CVE-2026-64488	medium
329887	Linux Distros 未修补的漏洞：CVE-2026-64430	high
329886	Linux Distros 未修补的漏洞：CVE-2026-64290	medium
329885	Linux Distros 未修补的漏洞：CVE-2026-64492	medium
329884	Linux Distros 未修补的漏洞：CVE-2026-64276	high
329883	Linux Distros 未修补的漏洞：CVE-2026-64330	high
329882	Linux Distros 未修补的漏洞：CVE-2026-64315	high
329881	Linux Distros 未修补的漏洞：CVE-2026-64282	medium
329880	Linux Distros 未修补的漏洞：CVE-2026-64289	medium
329879	Linux Distros 未修补的漏洞：CVE-2026-64432	high
329878	Linux Distros 未修补的漏洞：CVE-2026-64520	high
329877	Linux Distros 未修补的漏洞：CVE-2026-64342	high

检测

Nessus 的 Misc. 系列

high

critical

medium

high

high

critical

medium

medium

medium

high

medium

medium

high

critical

medium

high

medium

high

medium

high

high

high

high

medium

medium

medium

medium

high

medium

medium

high

medium

high

high

high

critical

high

medium

medium

high

medium

medium

high

high

high

medium

medium

high

high

high