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

  - ksmbd：以 opener 凭据运行 set info SMB2 SET_INFO处理程序在检查授予 SMB 句柄的访问掩码后，调用基于路径的 VFS 帮助程序。这些帮助程序使用当前 ksmbd 工作线程凭据执行其所有者、inode 权限和 LSM 检查。使用打开句柄时捕获的凭据运行完整的SET_INFO调度。这还删除了单独的安全信息凭据设置，并将所有SET_INFO类保留在一个凭据范围内。使用直接 override_creds（） 是因为它可以与重命名和链接帮助程序已使用的请求凭据替代嵌套。
    (CVE-2026-64393)

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

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

  - net：ipv4：绑定的 TCP 重新排序 sysctl 写入和 MTU 探测大小 在无效的“net.ipv4.tcp_reordering”值达到 TCP 套接字状态之前将其拒绝。sysctl 存储为“int”，但会复制到新套接字的“u32”“tp->reordering”字段中，因此负写入会封装至大值。通过“tcp_mtu_probing=2”，封装值可使“tcp_mtu_probe（）”大小计算溢出并驱动 MTU 探测路径进入越界读取状态。路由“tcp_reordering”通过“proc_dointvec_minmax（）”写入，并要求其至少为 1。还要求“tcp_max_reordering”至少为 1，这样配置的最大值也不会变成负值。当为非初始化网络命名空间注册表时，重新定位指向“init_net.ipv4”的“extra2”指针，使“tcp_reordering”上限跟随该命名空间的“tcp_max_reordering”。通过将“size_needed”计算为“u64”来强化“tcp_mtu_probe（）”本身。这可防止发送队列和窗口检查因已签名的整数溢出而被绕过。（CVE-2026-64422）

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

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

  - USB：serial：digi_acceleport：修复断开连接时的硬锁定 如果提交 OOB 写入 urb 持续失败（例如，如果设备断开连接），驱动程序将在禁用中断的情况下无限循环。发送 OOB 命令时检查 urb 提交错误，以免在 open（）、set_termios（） 或 close（） 等与物理断开连接争用时挂起。这是 Sashiko 在查看与驱动程序的不相关更改时标记的问题。（CVE-2026-64334）

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

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

  - usb：gadget：f_printer：仅为成功打开时采用 kref printer_open（） 在字符设备已经打开时返回 -EBUSY，但无论返回值为何，它都会递增 dev->kref。VFS 不会为打开失败调用 ->release（），因此每拒绝第二次打开，就会永久泄漏一个引用。将 kref_get（） 移动到 successful-open 分支。（CVE-2026-64345）

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

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

  - IIO：gyro：bmg160：带宽/滤波器不在表中时退出 bmg160_get_filter（） 遍历 bmg160_samp_freq_table[] 寻找与从芯片读取的bw_bits值匹配的条目：对于 （i = 0;
    i < ARRAY_SIZE（bmg160_samp_freq_table）;++i） { if （bmg160_samp_freq_table[i].bw_bits == bw_bits） break; }
    *val = bmg160_samp_freq_table[i].filter;如果没有匹配的条目，则 i 最终等于数组大小，下一行读取末尾之外的一个插槽。bmg160_set_filter（） 具有相同的形状，由“val”而不是 bw_bits 驱动。smatch 标记两者：drivers/iio/gyro/bmg160_core.c：204 bmg160_get_filter（） 错误：缓冲区溢出“bmg160_samp_freq_table” 7 <= 7 drivers/iio/gyro/bmg160_core.c：222 bmg160_set_filter（） 错误：缓冲区溢出“bmg160_samp_freq_table” 7 <= 7 当无匹配条目时返回 -EINVAL。可通过 sysfs in_anglvel_filter_low_pass_3db_frequency接口从用户空间访问 set_filter（） 路径，因此用户空间可使用不在 .filter 中的 bmg160_samp_freq_table[]值轻松触发越界读取。
    (CVE-2026-64495)

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG) 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? Refuse to re-try initialization if SNP is not already initialized for SNP_CONFIG. This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options: * do something like symbol_get() for kvm and refuse to initialize if KVM is loaded * check each cpu's HSAVE_PA for non-zero data before re-initializing * once initialization has failed, continue to refuse to initialize until the ccp module is unloaded (CVE-2026-64307)

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

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

  - ksmbd：通过限制无大小写的重试阻止路径遍历 ksmbd_vfs_path_lookup（） 强制LOOKUP_BENEATH限制共享根内的路径解析。当构建的路径尝试使用父目录组件 （“..”） 转义共享边界时，vfs_path_parent_lookup（） 会检测到此情况并立即失败，返回 -EXDEV。但是，在无大小写模式下，__ksmbd_vfs_kern_path（） 中存在一个缺陷。
    该函数无法拦截 -EXDEV 错误并错误地陷入无大小写重试逻辑，该逻辑仅用于真正缺失的文件。在此重试过程中，路径会重建，从而导致非预定的LOOKUP_BENEATH绕过，从而允许可写入的用户在导出的共享外部创建零长度文件或目录。通过确保只有当错误具体为 -ENOENT 时，执行才进行无大小写的查找重试，来修复此问题。任何其他错误，例如
    由于路径遍历尝试，必须立即返回 -EXDEV。（CVE-2026-64400）

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

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

  - xfs：不封装 dqiterate 中的配额 id LOLLM 注意到 q_id 是一个无符号的 32 位变量。如果由于文件系统实际上具有 ID_MAX 的 dquot 而恰好将其设置为 XFS_DQ_ID_MAX，则此加法将截断为零，并且迭代重新开始。通过转换到 u64 修复此问题。（CVE-2026-64256）

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

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

  - usb：xhci：修复 xhci_free_streams（） 中 atomic 上下文中的休眠问题 断开具有活动流端点的 USB 设备时，会从 hub_event 工作队列调用 xhci_free_streams（） 以释放流资源。它会在按住 xhci->lock 并禁用 irqs 的情况下调用 xhci_free_stream_info（）。
    xhci_free_stream_info（） 调用 xhci_free_stream_ctx（），后者会为大型流上下文数组调用 dma_free_coherent（）。dma_free_coherent（） 可休眠（如通过 vunmap），在从 atomic 上下文调用时触发缺陷。调用跟踪：dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c 通过保存stream_info指针和清除锁定下的 ep 引用，然后在允许休眠的锁定外部调用 xhci_free_stream_info（）。
    (CVE-2026-64465)

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

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

  - Bluetooth：L2CAP：通过保持异步运行的 conn ref l2cap_chan_timeout（） 并访问 chan->conn，修复通道超时中的 UAF。若在计时器运行或待定时断开连接，chan->conn 可能会释放，进而在计时器工作线程尝试锁定 conn->lock 时，导致释放后使用：|缺陷：KASAN：
    include/linux/instrumented.h：112 instrument_atomic_read_write中的 slab-use-after-free [内联] |缺陷：
    KASAN：include/linux/atomic/atomic-instrumented.h：4456 中的 slab-after-free atomic_long_try_cmpxchg_acquire释放后使用 [内联] |缺陷：KASAN：__mutex_trylock_fast kernel/locking/mutex.c：161 中的释放后使用板 [inline] |缺陷：KASAN：mutex_lock+0x4f/0xa0 kernel/locking/mutex.c：318 中的 slab-after-free 使用 |任务 kworker/2:1/83 在地址 ffff8881298d9550 处写入大小为 8 | |CPU：2 UID：0 PID：83 通信：kworker/2:1 未受感染 7.1.0-rc6-next-20260601-dirty #6 PREEMPT（full） |硬件名称：QEMU Standard PC （i440FX + PIIX， 1996），BIOS 1.17.0-debian-1.17.0-1 04/01/2014 |工作队列：事件l2cap_chan_timeout |调用跟踪：| <TASK> | instrument_atomic_read_write include/linux/instrumented.h：112 [内联] | atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h：4456 [内联] |
    __mutex_trylock_fast kernel/locking/mutex.c：161 [内联] |mutex_lock+0x4f/0xa0 kernel/locking/mutex.c：318 |l2cap_chan_timeout+0x5d/0x1b0网络/蓝牙/l2cap_core.c：422 |process_one_work kernel/workqueue.c：3326 [内联] |process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c：3409 |worker_thread+0x8a9/0xcf0 kernel/workqueue.c：3490 |kthread+0x346/0x430 kernel/kthread.c：436 |ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c：158 |ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 | </TASK> | |按任务320分配： |l2cap_conn_add+0xa7/0x820网络/蓝牙/l2cap_core.c：7075 |l2cap_connect_cfm+0xdb/0xd70网络/蓝牙/l2cap_core.c：7452 |hci_connect_cfm include/net/bluetooth/hci_core.h：2139 [内联] |hci_remote_features_evt+0x52f/0x9f0网络/蓝牙/hci_event.c：3760 |hci_event_func net/bluetooth/hci_event.c：7796 [内联] |hci_event_packet+0x561/0xa70网络/蓝牙/hci_event.c：7847 |hci_rx_work+0x370/0x890网络/蓝牙/hci_core.c：4040 |process_one_work kernel/workqueue.c：3326 [内联] |process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c：3409 |worker_thread+0x8a9/0xcf0 kernel/workqueue.c：3490 |kthread+0x346/0x430 kernel/kthread.c：436 |ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c：158 |ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 | |由任务 322 释放： |hci_disconn_cfm include/net/bluetooth/hci_core.h：2154 [内联] |hci_conn_hash_flush+0x101/0x1f0网/蓝牙/hci_conn.c：2736 |hci_dev_close_sync+0x889/0xde0网络/蓝牙/hci_sync.c：5405 |hci_dev_do_close net/bluetooth/hci_core.c：502 [内联] |hci_unregister_dev+0x1f7/0x370网络/蓝牙/hci_core.c：2679 |vhci_release+0x12a/0x180 drivers/bluetooth/hci_vhci.c：690 |__fput+0x369/0x890 fs/file_table.c：510 |task_work_run+0x160/0x1d0 kernel/task_work.c：233 |get_signal+0xf5b/0x1120 kernel/signal.c：2810 |arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c：337 |__exit_to_user_mode_loop kernel/entry/common.c：64 [内联] |exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c：98 |do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c：100 |entry_SYSCALL_64_after_hwframe+0x77/0x7f | |有缺陷的地址属于位于 ffff8881298d9400 |属于大小为 512 的缓存 kmalloc-512 |有缺陷的地址位于 |已释放的 512 字节区域 [ffff8881298d9400、ffff8881298d9600） 通过将通道添加到连接时使 chan->conn 保留对 l2cap_conn 的引用（通过 l2cap_conn_get），然后在通道析构函数中释放来修复此问题。这样可以确保只要通道存在，l2cap_conn就会保持活动状态。引入了一个新的 FLAG_DEL 通道标记以指示 ch ---truncated--- （CVE-2026-64434）

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

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

  - usb：dwc3：运行从可休眠暂停上下文断开连接的小工具 dwc3_gadget_suspend（） 采用 dwc->lock 且禁用 IRQ，然后调用 dwc3_disconnect_gadget（）。对于异步回调，该帮助程序仅使用普通 spin_unlock（）/spin_lock（），因此小工具 ->disconnect（） 回调运行时仍会禁用 IRQ，并且任何可休眠的回调跳闸 Lockdep。此问题是我们的静态分析工具发现的，然后对照当前树手动查看。接地的 PoC 保留了 dwc3_gadget_suspend（） -> dwc3_disconnect_gadget（） -> gadget_driver->disconnect（） 链，并且 Lockdep 报告：缺陷：从无效的上下文调用的休眠函数 gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] 将断开连接的回调选择保留在一个通用帮助程序中，但添加一个可休眠的挂起端封装程序，该封装程序在 dwc->lock 下对回调进行快照，然后在 spin_unlock_irqrestore（） 之后运行。常规事件路径仍使用现有 spin_unlock（）/spin_lock（） 窗口。（CVE-2026-64454）

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: chacha20poly1305 - validate poly1305 template argument chachapoly_create() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template argument is always present and immediately passes it to strcmp(). When the argument is missing, crypto_attr_alg_name() returns an error pointer. Check for that before comparing the name so malformed template instantiations fail with an error instead of dereferencing the error pointer in strcmp(). This matches the surrounding Crypto API template pattern where crypto_attr_alg_name() results are validated before string-specific use. (CVE-2026-64314)

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

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

  - crypto：qat - 修复 adf_disable_sriov（） 中的 VF2PF 工作拆卸争用 VF2PF 中断处理程序会将存储原始指针指向 per-VF 状态的 PF 端响应工作排队 （struct adf_accel_vf_info）。目前，adf_disable_sriov（） 会破坏 per-VF 互斥体并释放vf_info，而不会停止新的 VF2PF 工作或等待正在传输的工作线程完成。并发计划或已排队的工作人员随后可取消引用已释放的内存。启用了 KASAN 时，此问题显示为释放后使用：缺陷：KASAN：在 mutex_lock+0x76/0xe0 0000000000000260的地址处有大小为 8 的写入，任务 kworker/24:2/... 工作队列：
    qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] 调用跟踪：kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 添加 PF-local 标记， vf2pf_disabled，这将在拆卸期间阻止工作排队、工作进程处理和中断重新启用。使用 adf_disable_all_vf2pf_interrupts（） 内部的硬件中断掩码以原子方式设置此标记。屏蔽之后，同步 AE 群集 MSI-X 中断并刷新 PF 响应工作队列，然后再解除每个 VF 的锁定和状态，以便在vf_info被破坏之前完成所有正在传输的工作。引入 adf_enable_all_vf2pf_interrupts（） 以在重新启用 SR-IOV 时清除标记并取消屏蔽同一锁定下的所有 VF2PF 中断。这可确保软件标志和硬件状态在启用和禁用路径上以原子方式转换。
    (CVE-2026-64438)

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

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

  - spi：fsl-lpspi：终止 TX 准备失败路径上的 RX 通道 当 TX 通道的 dmaengine_prep_slave_sg（） 失败时，错误路径终止 TX DMA 通道，但使 RX 通道保持运行状态。由于在准备 TX 描述符之前已提交并发出 RX 通道，因此返回 -EINVAL 将导致 SPI 核心取消映射 DMA 缓冲区，而 RX DMA 引擎会继续向其写入，从而导致潜在的内存损坏或释放后使用。在返回 TX 准备失败路径之前终止 RX 通道。（CVE-2026-64303）

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

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

  - ALSA：seq：修复 snd_seq_event_dup（） 中的未初始化堆泄漏 snd_seq_event_dup（） 将传入事件复制到池单元格并清除 memcpy（） 未涵盖的末尾 cell->ump.raw.extra 字。决定是否清除它的警卫将复制的大小与 sizeof（cell->event） 进行比较：memcpy（&cell->ump， event， size）;if （size < sizeof（cell->event）） cell->ump.raw.extra = 0;对于旧的（非 UMP）事件，size == sizeof（struct snd_seq_event） == sizeof（cell->event），因此条件为 false，而额外的字会保留过时的数据。单元池使用 kvmalloc（）（未归零）分配，单元格通过空闲列表重复使用，以便该字保留未初始化的堆或剩余的事件数据。将此类信元传送到设置了 SNDRV_SEQ_FILTER_NO_CONVERT 的 UMP 客户端 （client->midi_version > 0） 时（因此旧事件未转换就到达该信元），snd_seq_read（） 将其读取为较大的 struct snd_seq_ump_event，并将过时字复制到用户空间，即向非特权 /dev/snd/seq 客户端泄漏的 4 字节内核堆信息泄漏。相反，与 sizeof（cell->ump） 进行比较，因此每个比 UMP 单元格短的事件将结尾字归零。（CVE-2026-64479）

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

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

  - Input：goodix - 钳制设备报告的接触计数 goodix_ts_read_input_report（） 将设备报告的接触点数复制到堆栈上的缓冲区 u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];其大小最多可容纳 GOODIX_MAX_CONTACTS （10） 个触点。唯一的运行时检查根据 ts->max_touch_num 限制每个中断计数，但该值是从设备配置块的 4 位字段逐字获取的，并且永远不会被限制：ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] &; 0x0f;半字节可以是 0..15，因此故障、恶意或假冒的控制器（或者篡改 I2C 总线的攻击者）最多可以公告 15 个触点。
    然后，goodix_ts_read_input_report（） 接受最多 15 的touch_num，第二个 goodix_i2c_read（） 将 ts->contact_size * （touch_num - 1） 字节超出 one-contact 标头写入 point_data - 超出 92 字节缓冲区最多 30 字节（9 字节报告格式为 45 字节）：堆栈越界写入。从配置中读取GOODIX_MAX_CONTACTS时，钳位max_touch_num到，即触点 point_data[] 数量的大小。（CVE-2026-64274）

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

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

  - Input：mms114 - 修复 MMS134S 和 MMS136 的触摸索引 MMS134S 和 MMS136 触摸控制器的事件大小为 6 字节，而非 8 字节。当 __mms114_read_reg（） 将触摸数据包从设备读取到触摸缓冲区时，事件将以 6 字节的间隔紧密打包。但是，驱动程序使用标准 C 数组索引 （touch[index]） 循环访问事件，其中每个元素的 sizeof（struct mms114_touch） （8 字节） 相距。因此，超出第一个触摸事件的任何触摸事件都会从不正确的偏移读取，并且解析不当。可根据设备的特定事件大小，显式计算每个触摸事件的字节偏移量，以修复此问题。（CVE-2026-64272）

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

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

  - mfd：cros_ec：延迟 dev_set_drvdata（），直到探测成功 如果 ec_device_probe（） 失败，cros_ec_class_release 会为 cros_ec_dev 结构释放内存。但是，由于已设置 drvdata，像 cros_ec_typec 这样的子驱动程序仍可通过平台设备检索过时指针。
    当cros_ec_typec尝试在已发布的设备上访问 &typec->ec->ec->dev 时，这会导致释放后使用。移动 dev_set_drvdata（） 以确保指针仅在所有初始化步骤都成功后才可用。sysfs：无法创建重复的文件名“/class/chromeos/cros_ec” 调用跟踪：sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... 缺陷：KASAN：__memcpy+0x44/0x230 中的无效访问 任务 kworker/u32：5/125 在地址 f5ffff809e2d33ac 写入 指针标签：[f5]，内存标签：[fe] 受感染：[W]=WARN，[O]=OOT_MODULE 硬件名称： Google Navi 未配置 0x7FFFFFFF/sku0 board/sku3 工作队列：
    events_unbound deferred_probe_work_func 调用跟踪：__memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0 （CVE-2026-64420）

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

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

  - bpf：拒绝 devmap 中的碎片帧 Devmap 广播重定向克隆除最后一个目标以外的所有目标的数据包。对于本机 XDP，该克隆路径仅复制线性xdp_frame数据，而分段帧将skb_shared_info保持在线性区域之外的尾部。克隆此类帧会保留XDP_FLAGS_HAS_FRAGS集，但没有有效的 frag 元数据，而后面的自由路径可能会将未初始化的末尾数据解释为skb_shared_info，从而导致返回帧期间的越界访问。拒绝 dev_map_enqueue_clone（） 中拆分的原生 XDP 帧。对 dev_map_redirect_clone（） 中的通用 XDP 克隆路径添加相同的限制。通用 XDP 将拆分的数据包表示为非线性 skb，在这里拒绝这些数据包可使基于克隆的广播支持在本地和通用 XDP 之间保持一致。
    (CVE-2026-64355)

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

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

  - 已修复 Linux 内核中的下列漏洞：xhci: sideband: fix ring sg table pages leak xhci_ring_to_sgtable() allocates a temporary pages array and uses it to build the returned sg_table with sg_alloc_table_from_pages(). The error paths free the pages array, but the success path returns the sg_table without freeing it. This leaks the temporary array every time a sideband client gets an endpoint or event ring buffer. Free the pages array after sg_alloc_table_from_pages() succeeds. The returned sg_table has its own scatterlist entries and does not depend on the temporary array after construction. (CVE-2026-64464)

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

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

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

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

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

  - crypto：qat - 通过service_lock保护服务表迭代 添加或删除条目时（在 adf_service_add（） 和 adf_service_remove（） 中），service_table列表受到service_lock保护，但有几个函数会在不保持此锁定的情况下迭代该列表。并行 adf_service_register（） 或 adf_service_unregister（） 调用可在遍历期间修改列表，导致列表损坏或释放后使用。通过在 adf_dev_init（）、adf_dev_start（）、adf_dev_stop（）、adf_dev_shutdown（）、adf_dev_restarting_notify（）、adf_dev_restarted_notify） 和 adf_error_notifier（） 中service_table的所有 list_for_each_entry（） 迭代中保持service_lock修复此问题。锁定顺序是安全的：静态帮助程序（adf_dev_up（） 和 adf_dev_down（））的调用者在service_lock之前获取state_lock，并且没有event_hld回调或service_lock持有者以相反的顺序获取state_lock。（CVE-2026-64305）

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

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

  - net：usb：kalmia：kalmia_rx_fixup（） 中的绑定 RX 帧长度 kalmia_rx_fixup（） 计算 usb_packet_length = skb->len - （2 * KALMIA_HEADER_LENGTH） 为 u16，仅由 skb->len 至少为 KALMIA_HEADER_LENGTH（即 6）的预循环检查保护。设备可以提供 skb->len 在 6 到 11 范围内的短批量 IN 帧，或者在以后的循环迭代中留下一个短的尾随余数。任一情况下溢usb_packet_length约 65530。这会绕过usb_packet_length < ether_packet_length截断路径。设备提供的 ether_packet_length（从 header_start[2] 读取的 le16 高达 65535），然后驱动 memcmp（） 以及随后的 skb_trim（） 和 skb_pull（） 经过 rx 缓冲区的末尾。rx 缓冲区为 hard_mtu * 10，即 14000 字节。这是越界读取。在每次循环迭代中，要求在减去开始和结束框架标头之前同时存在它们。（CVE-2026-64351）

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

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

  - media：nxp：imx8-isi：修复删除时的释放后使用 KASAN 报告 中的释放后使用
    imx8_isi的 rmmod 期间的 __media_entity_remove_link（）： 缺陷： KASAN： 中的 slab-use-after-free
    __media_entity_remove_link+0x608/0x650 由任务 rmmod/724 在地址 ffff0000d47cb02a 读取的大小为 2 调用跟踪：__media_entity_remove_link+0x608/0x650 __media_entity_remove_links+0x78/0x144
    __media_device_unregister_entity+0x150/0x280 media_device_unregister_entity+0x48/0x68 v4l2_device_unregister_subdev+0x158/0x300 v4l2_async_unbind_subdev_one+0x22c/0x358 v4l2_async_nf_unbind_all_subdevs+0xfc/0x1c0 v4l2_async_nf_unregister+0x5c/0x14c mxc_isi_remove+0x124/0x2a0 [imx8_isi] 按任务 249 分配：__kmalloc_noprof+0x27c/0x690 mxc_isi_crossbar_init+0x22c/0x560 [imx8_isi] 由任务 724 释放： kfree+0x1e4/0x5b0 mxc_isi_crossbar_cleanup+0x34/0x80 [imx8_isi] mxc_isi_remove+0x11c/0x2a0 [imx8_isi] 问题在于 mxc_isi_remove（） 在调用 mxc_isi_v4l2_cleanup（） 之前先调用 mxc_isi_crossbar_cleanup（）。交叉栏清除将释放媒体实体焊盘，但后续的 v4l2 清理操作仍会尝试删除引用这些焊盘的媒体链接。通过在调用 mxc_isi_crossbar_cleanup（） 之前调用 mxc_isi_v4l2_cleanup（） 来修复此问题，以确保在填充物仍然有效时正确取消注册所有媒体实体。（CVE-2026-64421）

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

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

  - 已修复 Linux 内核中的下列漏洞：ALSA: virtio: Validate control metadata from the device virtio-snd control handling trusts the device-provided control type and value count returned by the device. That metadata is then used directly to index g_v2a_type_map[] in virtsnd_kctl_info(), and to size loops and memcpy() operations in virtsnd_kctl_get() and virtsnd_kctl_put() against fixed-size virtio_snd_ctl_value and snd_ctl_elem_value arrays. A buggy or malicious device can therefore trigger out-of-bounds access by advertising an invalid control type or an oversized value count. Validate control type and count once in virtsnd_kctl_parse_cfg(), before querying enumerated items or exposing the control to ALSA. (CVE-2026-64490)

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

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

  - ALSA：usb-audio：避免在 DualSense 匹配中查找 kobject 路径 DualSense 插孔检测输入处理程序通过为输入设备和 USB 音频设备构建 kobject 路径字符串，然后比较路径前缀，验证匹配的输入设备是否属于同一物理控制器。弱物理连接导致控制器迅速断开和重新连接时会出现此情况。在重复热插拔期间，snd_dualsense_ih_match（） 可在控制器的 USB 设备断开连接时运行。kobject_get_path（） 遍历祖先 kobject 并取消引用它们的名称;如果 USB 设备 kobject 名称不再有效，则 strlen（） 中可能发生错误： RIP：0010：strlen+0x10/0x30 调用跟踪：
    kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] 无需构建 kobject 路径字符串即可进行相同的所有权检查。输入设备是 HID 设备、USB 接口和 USB 设备的父项，因此遍历输入设备的父项链并与混合器 USB 设备进行比较可保留检查，而不会在断开连接期间取消引用 kobject 名称。（CVE-2026-64478）

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

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

  - 已修复 Linux 内核中的下列漏洞：fuse-uring: make a fuse_req on SQE commit only findable after memcpy Bad userspace might try to trick us and send commit SQEs request unique / commit-id of requests that are not even send to fuse-server (io_uring_cmd_done() not called) yet.
    fuse_uring_commit_fetch() ends the fuse request when the ring entry has a wrong state, but that could have caused a use-after-free with the memcpy operations in fuse_uring_send_in_task(). In order to avoid such races the call of fuse_uring_add_to_pq() is moved after the copy operations and just before completing the io-uring request - malicious userspace cannot find the request anymore until all prepration work in fuse-client/kernel is completed. This also moves fuse_uring_add_to_pq() a bit up in the code to avoid a forward declaration. Also not with a preparation commit, to make it easier to back port to older kernels.
    (CVE-2026-64259)

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

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

  - 已修复 Linux 内核中的下列漏洞：fuse-uring: Avoid use-after-free in fuse_uring_async_stop_queues fuse_uring_async_stop_queues() might run when the last reference on ring->queue_refs was already dropped. In order to avoid an early destruction a reference on struct fuse_conn is now taken before starting fuse_uring_async_stop_queues() and that reference is only released when that delayed work queue terminates. (CVE-2026-64261)

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

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

  - iio：accel：bmc150：钳制设备报告的 FIFO 帧计数 __bmc150_accel_fifo_flush（） 将设备在其硬件 FIFO 中报告的样本数复制到堆栈上的缓冲区 u16 缓冲区中 [BMC150_ACCEL_FIFO_LENGTH * 3];其大小最多可容纳 BMC150_ACCEL_FIFO_LENGTH （32） 个样品。
    帧计数从FIFO_STATUS寄存器读取，仅屏蔽到其7个有效位：count = val & 0x7F;所以它可以是 0..127。唯一应用到它的另一个限制是可选的调用方提供的示例预算：if （samples &&; count > samples） count = samples;它不限制 flush-all 路径上的计数 （samples == 0），并且每当样本较大时使其远高于 32。然后将计数样本转移到 buffer[]： bmc150_accel_fifo_transfer（data， （u8 *）buffer， count）;
    bmc150_accel_fifo_transfer（） 通过 regmap 读取计数 * 6 字节，因此报告多达 127 个帧的故障、恶意或假冒的加速计（或篡改 I2C/SPI 总线的攻击者）会向 192 字节缓冲区中写入多达 762 个字节：多达 570 字节的堆栈越界写入会破坏堆栈金丝雀， 保存的寄存器和返回地址。钳制计数为 BMC150_ACCEL_FIFO_LENGTH，则样本 buffer[] 的大小是在传输之前进行的，以反映 bmc150_accel_set_watermark（） 中已经完成的水印钳制。格式良好的刷新最多会报告 BMC150_ACCEL_FIFO_LENGTH 帧，因此合法设备不受影响。（CVE-2026-64504）

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

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

  - 已修复 Linux 内核中的下列漏洞：usb: gadget: f_fs: Fix DMA fence leak In ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc'd, with the underlying dma_fence later initialized by dma_fence_init(), which sets its kref counter to 1. Then, dma_resv_add_fence() gets a second reference, and a pointer to the ffs_dma_fence is passed as the usb_request's context field. The dma-resv mechanism will manage the second reference, but the first reference is never properly released;
    the ffs_dmabuf_cleanup() function decreases the reference count, but only to balance with the reference grab in ffs_dmabuf_signal_done(). The code will then slowly leak memory as more ffs_dma_fence objects are created without being ever freed. Address this issue by transferring ownership of the fence to the DMA reservation object, by calling dma_fence_put() right after dma_resv_add_fence(). The ffs_dma_fence then gets properly discarded after being signalled. (CVE-2026-64328)

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

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

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

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

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

  - io_uring/io-wq：重新检查每个链接工作项提交的IO_WQ_BIT_EXIT 10dc95939817 （io_uring/io-wq：
    检查IO_WQ_BIT_EXIT工作运行循环内部）修复了 io_worker_handle_work（） 在耗尽待定工作前拍摄一个退出位快照，但是补丁过早停止一级的明显情况。
    io_worker_handle_work（） 现在会重新检查其外部工作运行循环中的IO_WQ_BIT_EXIT，但它仍然会在处理整个依赖的链接工作链之前对该位进行一次快照。如果 io_wq_exit_start（） 在第一个链接项启动后设置为 IO_WQ_BIT_EXIT，则其余链接项仍可重复使用过时的 do_kill = false，跳过IO_WQ_WORK_CANCEL，并在退出开始后继续运行。将检查移到更内侧，这样它也涵盖链接的项目。注意：这是一个 syzbot 特别节目，因为它喜欢在像 MSR 这样需要很长时间才能读取并立即关闭环的奇怪设备上设置大量缓慢链接的工作。然后退出需要很长时间。（CVE-2026-64425）

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

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

  - usb：gadget：udc：修复 gadget_match_driver 中的释放后使用 udc 结构充当小工具的管理结构，但它们的生命周期是分离的。存在一个争用条件，其中 usb_del_gadget（） 释放 udc 内存（例如，通过模式切换工作），而 gadget_match_driver（） 同时访问释放的 udc 内存（例如通过 configfs），从而导致释放后使用 （UAF） 缺陷，从而在释放的内存为零时触发空指针取消引用缺陷： [39430.908615][ T1171] 无法在虚拟地址 00000000000000000039430.911397 [][ T1171] pc 处理内核空指针取消引用：
    __pi_strcmp+0x20/0x140 [39430.911441][ T1171] lr：gadget_match_driver+0x34/0x60 ...[39430.911890][T1171] usb_gadget_register_driver_owner+0x50/0xf8 [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140 [39430.931308][ T1171] configfs_write_iter+0xec/0x134 [39430.957058][T1171] 工作队列： events_freezable __dwc3_set_mode [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664 通过确保 udc 结构保持分配状态直到发布小工具来修复此问题。为了实现这一点，在核心中引入一个新的 usb_gadget_release（） 例程。
    添加小工具后，usb_add_gadget（） 将小工具的释放例程存储在 udc 结构中，并获取对 udc 的引用。释放小工具时，usb_gadget_release（） 会删除对 udc 的引用，然后调用小工具的释放例程。（CVE-2026-64346）

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

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

  - mm/damon/ops-common：处理 damon_hot_score（） 中的极端间隔 修复 damon_hot_score（） 中由于错误处理极端（零或过高）监控间隔用户设置而导致的三个问题。当用户设置采样间隔零时，从 damon_hot_score（） 调用的 damon_max_nr_accesses（） 会导致除以零。不用说，这是一个问题。当用户将聚合间隔设置为零时，该函数将返回零。这是错误的，因为设置中的实际最大nr_acceses应该为 1。更糟糕的是，由于调用程序 damon_hot_score（） 使用 damon_max_nr_accesses（） 返回值作为分母，它可导致另一个除零。当用户将聚合间隔设置得非常高时，damon_hot_score（） 可能返回超出 [0， DAMOS_MAX_SCORE] 范围的值。由于返回值用作 regions_score_histogram 数组（大小为 DAMOS_MAX_SCORE+1）的索引，因此会导致越界数组访问。这些问题可以相对容易地重现，如下所示。但需要 sysfs 写入权限。# ./damo 启动 --damos_action lru_prio_quota_space --damos100M \
    --damos_quota_interval 1s # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/monitoring_attrs/intervals/sample_us # echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us # echo commit > state # dmesg [...][ 131.329762] 哎呀：除法错误：0000 [#1] SMP NOPTI [...][131.336089] RIP：0010：damon_hot_score+0x27/0xd0 [...]通过显式处理 damon_max_nr_accesses（） 中的零间隔，修复除以零间隔问题。通过在从 damon_hot_score（） 返回之前应用 [0， DAMOS_MAX_SCORE] 边界修复越界数组访问。此问题由 Sashiko 发现 [1]。（CVE-2026-64458）

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

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

  - usbip：vudc：修复 vep_dequeue（） 中的空取消引用 vep_alloc_request（） 未初始化 vrequest->udc，因此 FunctionFS AIO 路径上的取消在没有有效 UDC 引用的情况下到达vep_dequeue。由于 vrequest->udc 实际上从未在任何地方得到正确使用，因此我们选择将其删除，并更新 vep_dequeue，以便通过与其他vep_ ops 一致的 ep_to_vudc（） 获取 udc 的引用。AFAICT 此缺陷已经存在了 ~10 年。似乎没有人真正强调 usbip 的 vudc 上的 FunctionFS AIO 路径。我在通过 AIO 驱动 FunctionFS 端点的 QEMU aarch64 客户机中测试了此补丁。修复之前，从主机运行“usbip attach”会造成客户机 oops 并进行以下回溯： 调用跟踪：
    vep_dequeue+0x1c/0xe4 （P） usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34
    __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158 （CVE-2026-64331）

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

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

  - bpf：允许从可休眠的 BPF 程序进行 LPM 映射访问 trie_lookup_elem（） 仅使用 rcu_read_lock_bh_held（） 注释其 rcu_dereference_check（） 遍历。因为 rcu_dereference_check（p， c） 解析为 c ||rcu_read_lock_held（），这对于 XDP/NAPI 和经典 RCU 读取器无法，但对于通过 __bpf_prog_enter_sleepable（） 进入且仅保留 rcu_read_lock_trace（） 的可休眠 BPF 程序则失败。
    trie_update_elem（） 和 trie_delete_elem（） 以不同的形式存在相同的问题：它们使用普通 rcu_dereference（） 来行走 trie，后者无条件断言 rcu_read_lock_held（）。可通过 bpf_map_update_elem / bpf_map_delete_elem 帮助程序从可休眠 BPF 程序以及从经典 rcu_read_lock（） 下的 syscall 路径访问这两个版本。在写入器路径中，trie 实际上受到 trie->lock（跨越 walk 的 rqspinlock）的保护;我们从不依赖 RCU 读取端锁定来保持节点活动。最终接触 LPM trie 的可休眠 LSM 挂钩因此会触发调试内核上的 lockdep：
    ============================= 警告：可疑的 RCU 使用情况 7.1.0-... 污染：G E
    ----------------------------- kernel/bpf/lpm_trie.c：249 可疑的 rcu_dereference_check（） 使用情况！1 个由 net_tests/540 持有的锁： #0： （rcu_tasks_trace_srcu_struct）{....}-{0:0}，位于：
    __bpf_prog_enter_sleepable+0x26/0x280 调用跟踪：dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_...security_socket_connect __sys_connect do_syscall_64 这仅限 lockdep -- 没有 UAF，因为任务跟踪 RCU 确实会根据 trie 的回收路径进行序列化 -- 但它会在每个运行接触 LPM trie 的可休眠 BPF LSM 的调试内核上，每个不同的调用站点向控制台发送一次垃圾邮件，而这种情况越来越常见。对于查找路径，将 rcu_dereference_check（） 注释从 rcu_read_lock_bh_held（） 切换到 bpf_rcu_lock_held（），后者接受所有三个上下文（经典、BH、任务跟踪）。其他地图类型已遵循此约定。对于 trie_update_elem（） 和 trie_delete_elem（），请将遍历注释为 rcu_dereference_protected（*p， 1） -- 匹配同一文件中的 trie_free（） -- 因为 trie->lock 是跨遍历的。rqspinlock 没有lockdep_map，因此谓词退化为“1”而不是lockdep_is_held（&trie->lock）;该保护是真实的，但不可通过计算机验证。trie_get_next_key（） 也使用裸rcu_dereference（），但只能从 BPF syscall 访问，后者在分派之前保存了经典 rcu_read_lock（），因此不影响它。(CVE-2026-64352)

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

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

  - 已修复 Linux 内核中的下列漏洞：perf/aux: Fix page UAF in map_range() map_range() reads rb->aux_pages[], rb->aux_nr_pages and rb->aux_pgoff via perf_mmap_to_page() while holding only event->mmap_mutex. Those fields are serialized by rb->aux_mutex, and mmap_mutex is per event.
    Thus, two events sharing one rb via PERF_EVENT_IOC_SET_OUTPUT can race rb_alloc_aux() with map_range(), leading to a page-UAF scenario as follows: CPU 0 CPU 1 ===== ===== rb_alloc_aux() map_range() [1]:
    allocate rb->aux_pages[0] [2]: rb->aux_nr_pages++ [3]: perf_mmap_to_page() returns rb->aux_pages[0] [4]:
    map it as VM_PFNMAP [5]: rb->aux_pgoff = 1 munmap the page [6]: free rb->aux_pages[0] Pages mapped as VM_PFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame. Fix this by taking rb->aux_mutex across the page walk in map_range(). (CVE-2026-64300)

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

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

  - isofs：将 Rock Ridge 符号链接组件绑定到 SL 记录 get_symlink_chunk（） 和 parse_rock_ridge_inode_internal（） 中的 SL 处理遍历 Rock Ridge SL（符号链接）记录的变量长度组件。每个组件都是双字节标头（flags，len），后跟文本的len字节，因此占用slp->len + 2字节。两个循环都读取 slp->len 并前进到下一个组件，get_symlink_chunk（） 另外也会执行 memcpy（rpnt， slp->text， slp->len），但未在取消引用 SL 记录前检查该组件是否在该记录中。因此，构建的 SL 记录（其组件声明运行超过 该记录 （rr->len）的长度，会触发最多 255 个字节的越界读取。当记录位于其后备缓冲区的末尾时（例如，通过 CE 记录到达的小型 kmalloc（）ed 延续块），读取会交叉分配;然后，get_symlink_chunk（） 将越界字节复制到 readlink（） 返回到用户空间的符号链接正文中，从而泄露相邻的内核内存。ISO 9660 镜像通常会从不受信任的可移动媒体挂载 - 桌面环境会在未经CAP_SYS_ADMIN的情况下自动挂载它们（例如通过 udisks2），因此记录内容由攻击者控制。使用前拒绝任何不适合剩余记录字节的组件。在 get_symlink_chunk（） 返回 NULL 时，就像现有的输出缓冲区 （plimit） 检查一样，因此畸形记录会使 readlink（） 因 -EIO 而失败，而不是静默地返回截断的目标;在 parse_rock_ridge_inode_internal（） 中停止 inode-size 遍历。
    (CVE-2026-64317)

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

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

  - tipc：修复广播 Gap ACK 区块中的越界读取 广播 PROTOCOL/STATE_MSG 可在其数据区域中携带 Gap ACK 区块记录。tipc_get_gap_ack_blks（） 仅验证记录的 len 字段是否与其 ugack_cnt/bgack_cnt 计数自一致 （sz == struct_size（p， gacks， ugack_cnt + bgack_cnt））;
    它不检查记录是否确实适合消息数据区域 msg_data_sz（）。单播调用方 tipc_link_proto_rcv（） 对其进行边界 （if （glen > dlen） break;），但广播调用方 tipc_bcast_sync_rcv（） 丢弃返回的大小，因此 tipc_link_advance_transmq（） 使用攻击者控制的计数从接收 skb 复制记录：this_ga = kmemdup（ga， struct_size（ga， gacks， ga->bgack_cnt）， GFP_ATOMIC）;协商TIPC_GAP_ACK_BLOCK的 TIPC 邻居通过一个普通广播STATE_MSG （msg_bc_ack_invalid（） clear） 触发它，大小使其数据区域较短，带有 len = 0x400、bgack_cnt = 0xff 和 ugack_cnt = 0 的 Gap ACK 记录。len 等于 struct_size（p， gacks， 255），因此一致性检查通过并且 ga 为非 NULL;kmemdup（） 从小得多的 skb 中读取 struct_size（ga， gacks， 255） = 1024 字节：缺陷：KASAN：kmemdup_noprof+0x48/0x60 中的 slab-out-of-bound 任务 poc864/69 在地址 ffff0000c7030d38 读取的大小为 1024 调用跟踪：kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 有缺陷的地址属于位于 ffff0000c7030d00 的对象，属于大小为 704 的缓存skbuff_small_head 有缺陷的地址位于分配的 704 字节区域内 56 字节处 [ffff0000c7030d00、ffff0000c7030fc0） 复制的字节随后会作为 gap/ack 值消耗，但无论如何使用它们，读取在 kmemdup（） 处都已越界。单播 STATE 路径会丢弃这样的消息：if （glen > dlen） break;跳过STATE_MSG处理的其余部分，并释放 skb。使广播路径也丢弃它。
    tipc_bcast_sync_rcv（） 现在会针对 msg_data_sz（） 绑定记录，并在记录不适合时通过 tipc_node_bc_sync_rcv（） 将其报告回 tipc_rcv（），这样 skb 就会被丢弃而不是处理。ga 在此路径上未清除：ga == NULL 已表示没有选择性 ACK（明显合法状态）的传统对等机。（CVE-2026-64450）

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

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

  - usb：gadget：function：rndis：添加标头的长度检查 为 rndis_rm_hdr 中的 rndis 标头添加长度检查，以确保在访问 MessageType、MessageLength、DataOffset 和 DataLength 字段之前已存在这些字段。（CVE-2026-64505）

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

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

  - staging：rtl8723bs：修复 issue_assocreq（） 和 join_cmd_hdl（） 的 IE 循环中的 OOB 读取 两个 IE 解析循环在取消引用 pIE->length 之前缺少标头边界检查： - issue_assocreq（） 遍历 pmlmeinfo->network.ies 以构建关联请求。如果存储的 IE 数据以仅一个 element_id字节结尾且没有长度字节，则会在超出缓冲区末尾一个字节处读取 pIE->length。- join_cmd_hdl（） 在基站加入期间遍历 pnetwork->ies，且在相同条件下发生相同问题。
    两个缓冲区都填充自 AP 信标和探测响应帧，因此发送截断的最终 IE 的恶意 AP 可触发该问题。应用 update_beacon_info（） 中建立的双防护模式：1. 如果剩余字节数少于 sizeof（*pIE） 则中断。2. 如果 IE 声明的数据延伸超过缓冲区末尾，则中断。
    (CVE-2026-64442)

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

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

  - NFSv4：在 O_TRUNC 的开放权限掩码中包含MAY_WRITE POSIX 需要写入权限才能截断文件，因此无论O_ACCMODE访问模式如何，都必须授权指定O_TRUNC的 open（） 进行写访问。nfs_open_permission_mask（） 构建传递给 nfs_may_open（） 的访问掩码，（） 是客户端通过 nfs4_try_open_cached（） 中的 can_open_delegated（） 路径从缓存的写入委托提供服务的 OPEN 的本地授权门。掩码仅源自O_ACCMODE，因此 open（O_RDONLY |O_TRUNC） 对于文件，调用程序只能写入请求MAY_READ并通过本地检查。然后在本地满足 OPEN，并通过委派 stateid 将截断作为 SETATTR（size=0） 发出给服务器，服务器在标准写委派语义下接受该委派。POSIX 要求 EACCES 使此打开失败。只要设置O_TRUNC以便本地检查与服务器应强制实施的访问匹配，就将MAY_WRITE包括在掩码中。（CVE-2026-64298）

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

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

  - USB：serial：digi_acceleport：修复节流后损坏的 rx 如果在节流时关闭端口，则永远不会重新提交读取 urb，并且端口将不会再接收任何数据，直到重新连接设备（或驱动程序重新连接）。打开端口时清除节流标记并提交 urb（如果需要）。
    (CVE-2026-64335)

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

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

  - staging：rtl8723bs：修复 rtw_get_sec_ie（）、rtw_get_wapi_ie（） 和 rtw_get_wps_attr（） 中的越界读取 三个 IE/属性解析函数缺少边界检查。rtw_get_sec_ie（） 和 rtw_get_wapi_ie（） 在读取标头字节（标签 + 长度）之前是否在剩余缓冲区内进行迭代原始 IE 缓冲区。此外，rtw_get_sec_ie（） 比较 cnt+2 处的 4 字节 WPA OUI，但未检查至少还剩 6 个字节，rtw_get_wapi_ie（） 比较 cnt+6 处的 4 字节 WAPI OUI，但未检查至少还剩 10 个字节。rtw_get_wps_attr（） 在验证wps_ielen是否足够大以包含 6 字节 WPS IE 标头（element_id + 长度 + 4 字节 OUI）之前，会在输入时无条件读取 wps_ie[0] 和 wps_ie+2。在属性循环内，attr_ptr 和 attr_ptr+2 调用 get_unaligned_be16（），而未检查缓冲区中是否仍有 4 个字节。在 rtw_get_sec_ie（） 和 rtw_get_wapi_ie（） 的每个循环正文前添加 cnt+2 边界检查，利用最小 IE 长度要求保护每个多字节比较，在 rtw_get_wps_attr（） 中添加 wps_ielen < 6 过早返回，并在其内部循环中添加 4 字节边界检查。（CVE-2026-64441）

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

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

  - usb：typec：ucsi：ccg：修复删除时 ucsi 的释放后使用 线程 IRQ 处理程序 ccg_irq_handler（） 调用 ucsi_notify_common（），后者在连接器变更事件时调用 ucsi_connector_change（） 并计划连接器工作。在 ucsi_ccg_remove（） 中，ucsi_destroy（） 会在调用 free_irq（） 之前释放 uc->ucsi （kfree），所以正在运行的处理程序调用可在 ucsi_destroy（） 之后访问释放的对象。CPU 0（删除） |CPU 1（线程 IRQ） ucsi_destroy（uc->ucsi） |ccg_irq_handler（） kfree（ucsi） // 免费 |ucsi_notify_common（uc->ucsi） // USE 将删除路径中的 free_irq（） 移动到 ucsi_destroy（） 之前。它在 ucsi_unregister（） 之后保留：ucsi_unregister（） 取消其处理程序通过 ucsi_send_command_common（） 发出GET_CONNECTOR_STATUS的连接器工作，（） 等待来自 IRQ 处理程序发出的完成信号，因此 IRQ 必须保持活动状态，直到取消该工作。探测错误路径已排序 free_irq（），然后再排序 ucsi_destroy（）。此缺陷是通过静态分析发现的。（CVE-2026-64329）

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

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

  - cpufreq：修复重新启动期间的热插拔暂停争用 在系统重新启动期间，通过 kernel_restart（） -> device_shutdown（） 路径调用 cpufreq_suspend（）。与正常系统挂起路径不同，重新启动路径不会调用 freeze_processes（），因此用户空间进程和内核线程保持活动状态。这允许 CPU 热插拔操作与 cpufreq_suspend（） 并发运行。原始代码没有与 CPU 热插拔同步，导致争用条件，其中 cpufreq_suspend（） 仍在访问热插拔路径时，热插拔路径可释放governor_data，从而导致空指针取消引用：无法处理内核空指针取消引用调用跟踪：do_kernel_fault+0x28/0x3c cpufreq_suspend+0xdc/0x160 device_shutdown+0x18/0x200 kernel_restart+0x40/0x80 arm64_sys_reboot+0x1b0/0x200 通过添加 cpus_read_lock（）/ 来修复此问题cpus_read_unlock（） 到 cpufreq_suspend（） 以在暂停进行中阻止 CPU 热插拔操作。[ rjw： 变更日志编辑 ]（CVE-2026-64373）

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

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

  - net/handshake：提交时采用长期限文件引用 handshake_nl_accept_doit（） 需要文件指针备份 req->hr_sk->sk_socket，以便在 handshake_req_next（） 和后续 FD_PREPARE（） 与 get_file（） 之间的窗口期内留存。提交端的 sock_hold（） 未提供该信息。sk_refcnt使结构 sock 保持活动状态，但结构套接字属于 sock->file：当使用者 fput 最后一个文件引用时，无论sock_hold如何，sock_release（） 都会去除套接字。在 handshake_req_submit（） 期间，向 struct handshake_req 添加hr_file指针并获取对 sock->file 的显式引用。
    handshake_complete（） 和 handshake_req_cancel（） 释放完成位获胜路径上的引用。
    提交错误路径还必须释放文件引用，但在插入 rhashtable 之后，并发 handshake_req_cancel（） 可发现请求并在错误路径中争用。使用已使用的序列化 handshake_complete（） 和 handshake_req_cancel（） 已使用的 test_and_set_bit（HANDSHAKE_F_REQ_COMPLETED） 来控制错误路径清理（sk_destruct还原、fput 和请求销毁）。当 cancel 已经声明了所有权时，提交错误路径会返回，而不会接触请求;套接字拆卸处理最终销毁。尚未重新定位接受端取消引用;该变更将在下一个修补程序中提供。（CVE-2026-64523）

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

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

  - 已修复 Linux 内核中的下列漏洞：mm/swap: add cond_resched() in swap_reclaim_full_clusters to prevent softlockup We hit a real softlockup in an internal stress test environment. The workload was LTP memory/swap stress on a large arm64 machine, with 320 CPUs, about 1TB memory and an 8.6GB swap device. The system was under heavy load and the swap device had a large number of full clusters. The softlockup was triggered during a stress test after about 3 days. So, add periodic cond_resched() calls during large full_clusters reclaim operations to prevent softlockup issues. Detailed call trace as follow: PID: 3817773 TASK: ffff0883bb28b780 CPU: 48 COMMAND: kworker/48:7 #0 [ffff800080183d10] __crash_kexec at ffffa4c1361e5de4 #1 [ffff800080183d90] panic at ffffa4c1360d5e9c #2 [ffff800080183e20] watchdog_timer_fn at ffffa4c136231fa8 ... #16 [ffff8000c4ad3cb0] swap_cache_del_folio at ffffa4c1363e1614 #17 [ffff8000c4ad3ce0] __try_to_reclaim_swap at ffffa4c1363e4bfc #18 [ffff8000c4ad3d40] swap_reclaim_full_clusters at ffffa4c1363e5474 #19 [ffff8000c4ad3da0] swap_reclaim_work at ffffa4c1363e550c #20 [ffff8000c4ad3dc0] process_one_work at ffffa4c136102edc #21 [ffff8000c4ad3e10] worker_thread at ffffa4c136103398 #22 [ffff8000c4ad3e70] kthread at ffffa4c13610d95c (CVE-2026-64415)

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

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

  - nilfs2：拒绝包含超出范围段编号CLEAN_SEGMENTS ioctl Syzbot 报告 nilfs_transaction_begin（） 中存在挂起任务，其中在 nilfs2 挂载上执行 chmod（） 的多个任务阻塞超过 143 秒等待获取 read： INFO： 任务 syz.0 的ns_segctor_sem。17:5918 被屏蔽超过 143 秒。调用跟踪： schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c：221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c：921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 保留 ns_segctor_sem 的写入器是并发的 NILFS_IOCTL_CLEAN_SEGMENTS 调用方， 发出来自 nilfs_sufile_updatev（） 的每个元素警告时卡在 printk 内：__nilfs_msg+0x373/0x450 fs/nilfs2/super.c：78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c：186 nilfs_sufile_freev fs/nilfs2/sufile.h：93 [内联] nilfs_free_segments fs/nilfs2/segment.c：1140 [内联] nilfs_segctor_collect_blocks fs/nilfs2/segment.c：1261 [内联] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c：922[内联] nilfs_ioctl+0x261f/0x2780 根本原因是在 nilfs_clean_segments（） 开始工作之前未验证用户提供的段编号;nilfs_sufile_updatev（） 在调用链深处执行对每个 segnum 的范围检查，从而在仍保留 segctor 锁定和 sufile mi_sem的同时针对每个无效条目发出 nilfs_warn（）。在负载下（在多个挂载中重复调用使全局 printk 路径饱和），累积 printk 延迟保持ns_segctor_sem的时间足以使 hung_task 监视程序跳闸，从而阻止需要ns_segctor_sem进行读取的并发操作，例如 chmod（）。通过 nilfs_transaction_lock（） 获取 ns_segctor_sem 之后立即验证 nilfs_clean_segments（） 中的 kbufs[4] 内容即可修复。按住 ns_segctor_sem 会对 nilfs_ioctl_resize（） 进行序列化检查，后者可修改ns_nsegments，因此验证使用一致的值。在任何段清除工作开始之前，通过 -EINVAL 拒绝超出范围的段编号，因此错误条目永远不会到达 nilfs_sufile_updatev（） 中的每个元素诊断路径。（CVE-2026-64359）

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

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

  - 已修复 Linux 内核中的下列漏洞：bpf: Validate BTF repeated field counts before expansion btf_parse_struct_metas() walks user-supplied BTF during BPF_BTF_LOAD, and btf_repeat_fields() expands repeatable fields from array elements into the fixed BTF_FIELDS_MAX scratch array used by btf_parse_fields(). The remaining-capacity check performs the expanded field count calculation in u32. A malformed BTF can wrap that calculation, causing the check to pass even when the expanded field count exceeds the scratch array capacity. The following memcpy() can then write past the end of the array. Use checked addition and multiplication before copying repeated fields and reject impossible counts. (CVE-2026-64354)

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

ID	名称	严重性
329876	Linux Distros 未修补的漏洞：CVE-2026-64393	critical
329875	Linux Distros 未修补的漏洞：CVE-2026-64422	high
329874	Linux Distros 未修补的漏洞：CVE-2026-64334	medium
329873	Linux Distros 未修补的漏洞：CVE-2026-64345	medium
329872	Linux Distros 未修补的漏洞：CVE-2026-64495	high
329871	Linux Distros 未修补的漏洞：CVE-2026-64307	medium
329870	Linux Distros 未修补的漏洞：CVE-2026-64400	high
329869	Linux Distros 未修补的漏洞：CVE-2026-64256	medium
329868	Linux Distros 未修补的漏洞：CVE-2026-64465	medium
329867	Linux Distros 未修补的漏洞：CVE-2026-64434	high
329866	Linux Distros 未修补的漏洞：CVE-2026-64454	medium
329865	Linux Distros 未修补的漏洞：CVE-2026-64314	medium
329864	Linux Distros 未修补的漏洞：CVE-2026-64438	high
329863	Linux Distros 未修补的漏洞：CVE-2026-64303	critical
329862	Linux Distros 未修补的漏洞：CVE-2026-64479	high
329861	Linux Distros 未修补的漏洞：CVE-2026-64274	high
329860	Linux Distros 未修补的漏洞：CVE-2026-64272	high
329859	Linux Distros 未修补的漏洞：CVE-2026-64420	high
329858	Linux Distros 未修补的漏洞：CVE-2026-64355	critical
329857	Linux Distros 未修补的漏洞：CVE-2026-64464	high
329856	Linux Distros 未修补的漏洞：CVE-2026-64344	high
329855	Linux Distros 未修补的漏洞：CVE-2026-64305	high
329854	Linux Distros 未修补的漏洞：CVE-2026-64351	medium
329853	Linux Distros 未修补的漏洞：CVE-2026-64421	high
329852	Linux Distros 未修补的漏洞：CVE-2026-64490	high
329851	Linux Distros 未修补的漏洞：CVE-2026-64478	medium
329850	Linux Distros 未修补的漏洞：CVE-2026-64259	high
329849	Linux Distros 未修补的漏洞：CVE-2026-64261	high
329848	Linux Distros 未修补的漏洞：CVE-2026-64504	high
329847	Linux Distros 未修补的漏洞：CVE-2026-64328	medium
329846	Linux Distros 未修补的漏洞：CVE-2026-64341	high
329845	Linux Distros 未修补的漏洞：CVE-2026-64425	medium
329844	Linux Distros 未修补的漏洞：CVE-2026-64346	high
329843	Linux Distros 未修补的漏洞：CVE-2026-64458	medium
329842	Linux Distros 未修补的漏洞：CVE-2026-64331	medium
329841	Linux Distros 未修补的漏洞：CVE-2026-64352	high
329840	Linux Distros 未修补的漏洞：CVE-2026-64300	high
329839	Linux Distros 未修补的漏洞：CVE-2026-64317	high
329838	Linux Distros 未修补的漏洞：CVE-2026-64450	critical
329837	Linux Distros 未修补的漏洞：CVE-2026-64505	high
329836	Linux Distros 未修补的漏洞：CVE-2026-64442	high
329835	Linux Distros 未修补的漏洞：CVE-2026-64298	high
329834	Linux Distros 未修补的漏洞：CVE-2026-64335	medium
329833	Linux Distros 未修补的漏洞：CVE-2026-64441	high
329832	Linux Distros 未修补的漏洞：CVE-2026-64329	high
329831	Linux Distros 未修补的漏洞：CVE-2026-64373	medium
329830	Linux Distros 未修补的漏洞：CVE-2026-64523	critical
329829	Linux Distros 未修补的漏洞：CVE-2026-64415	medium
329828	Linux Distros 未修补的漏洞：CVE-2026-64359	medium
329827	Linux Distros 未修补的漏洞：CVE-2026-64354	high

检测

Nessus 的 Misc. 系列

critical

high

medium

medium

high

medium

high

medium

medium

high

medium

medium

high

critical

high

high

high

high

critical

high

high

high

medium

high

high

medium

high

high

high

medium

high

medium

high

medium

medium

high

high

high

critical

high

high

high

medium

high

high

medium

critical

medium

medium

high