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

  - smb：客户端：修复更改通知重播双重释放 包含响应的尝试可返回可重放的错误并释放其响应缓冲区。如果 SMB2_notify_init（） 在下一次发送之前失败，清理将保留之前的缓冲区类型并再次释放该响应。修复方案是在每次尝试之前重置响应记录信息，以防止这种过期的释放操作。(CVE-2026-64384)

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

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

  - cpufreq：pcc：修复 _OSC 评估中的释放后使用和双重释放 pcc_cpufreq_do_osc（） 针对两阶段_OSC协商调用 acpi_evaluate_object（） 两次。在两次调用之间，它释放了 output.pointer，但 output.length 保持不变。由于 acpi_evaluate_object（） 将具有非空指针的非零长度视为要写入的现有缓冲区，因此第二次调用将写入已释放的内存（释放后使用）。然后，out_free 的后续 kfree（output.pointer） 会再次释放同一指针（双重释放）。释放第一个结果后将 output.pointer 重置为 NULL 并将 output.length 重置为 ACPI_ALLOCATE_BUFFER，以便 ACPICA 为每个阶段独立分配新的缓冲区。（CVE-2026-64372）

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

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

  - usb：typec：tcpci_rt1711h：通过 devres 取消注册 TCPCI 端口 rt1711h_probe（） 在请求中断和启用警报中断前注册 TCPCI 端口。如果后续步骤失败，探测函数返回，而不取消注册 TCPCI 端口。显式取消注册目前仅通过 remove 回调发生。在 tcpci_register_port（） 成功后立即注册 devres 操作，以便在以后的探测失败和驱动程序分离时运行 tcpci_unregister_port（）。终止 remove 回调以避免两次取消注册同一端口。我们在查看内核代码时进行持续的静态分析研究中发现了此问题。（CVE-2026-64463）

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

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

  - ntfs：避免为无效的 post_write_mst_fixup（） 调用 index_block ntfs_icx_ib_sync_write（） 在 ntfs_ib_write（） 返回错误时调用 post_write_mst_fixup（），并打算在写入失败后还原缓冲区。但是，如果 ntfs_ib_write（） 验证失败，pre_write_mst_fixup（） 会立即返回错误。调用程序 ntfs_icx_ib_sync_write（） 将所有错误解释为需要回滚的写入失败。
    它不区分 I/O 错误与验证失败，但还是调用 post_write_mst_fixup（）。由于 post_write_mst_fixup（） 假设index_block内容正确，因此不会执行边界检查，从而导致越界内存访问。攻击者可通过以下命令构建恶意 NTFS 图像：- 大的 index_block.usa_ofs 偏移，指向ntfs_record外部 - index_block.usa_count = 0，导致整数下溢 - 或 index_block.usa_count 大于ntfs_record中的实际扇区数，从而造成越界访问 描述内存损坏的 KASAN 报告：
    ==================================================================缺陷：KASAN：在 post_write_mst_fixup+0x19c/0x1d0 中的 slab-out-of-bound 通过任务 p/9428 在地址 ffff8881586c9018 读取了大小为 2 调用跟踪： <TASK> dump_stack_lvl+0x100/0x190 print_report+0x139/0x4ad ？ post_write_mst_fixup+0x19c/0x1d0 ？
    __virt_addr_valid+0x262/0x500 ？post_write_mst_fixup+0x19c/0x1d0 kasan_report+0xe4/0x1d0 ？post_write_mst_fixup+0x19c/0x1d0 post_write_mst_fixup+0x19c/0x1d0 ntfs_icx_ib_sync_write+0x179/0x220 ntfs_inode_sync_filename+0x83d/0x1080 __ntfs_write_inode+0x1049/0x1480 ntfs_file_fsync+0x131/0x9b0 ================================================================== 缺陷：KASAN：post_write_mst_fixup+0x1aa/0x1d0 中的 slab-out-bound 任务 p/9428 在地址 ffff8881586c91fe 处写入大小为 2 调用跟踪：
    <TASK> dump_stack_lvl+0x100/0x190 print_report+0x139/0x4ad ？post_write_mst_fixup+0x1aa/0x1d0 ？
    __virt_addr_valid+0x262/0x500 ？post_write_mst_fixup+0x1aa/0x1d0 kasan_report+0xe4/0x1d0 ？post_write_mst_fixup+0x1aa/0x1d0 post_write_mst_fixup+0x1aa/0x1d0 ntfs_icx_ib_sync_write+0x179/0x220 ntfs_inode_sync_filename+0x83d/0x1080 __ntfs_write_inode+0x1049/0x1480 ntfs_file_fsync+0x131/0x9b0 ================================================================== 让我们将 post_write_mst_fixup（） 调用移动到 ntfs_ib_write（）。ntfs_ib_write（） 函数在开头调用 pre_write_mst_fixup（）。如果index_block内容无效，则 pre_write_mst_fixup（） 失败且 ntfs_ib_write（） 提早返回，而不会在错误index_block时调用 post_write_mst_fixup（）。（CVE-2026-64431）

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: ccp - Do not initialize SNP for ioctl(SNP_COMMIT) 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 SNP_COMMIT command does not require the firmware to be in any particular state. Skip initializing it if it was previously uninitialized. The SEV-SNP firmware specification doc 56860 does not mention SNP_COMMIT in Table 5 as a command that is allowed in the UNINIT state, but it is in fact allowed and a future documentation update will reflect that. (CVE-2026-64309)

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

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

  - crypto：drbg - 修复在 CTR_DRBG drbg_ctr_generate（） 中失败时返回成功方式有时会在失败时返回成功，从而使输出缓冲区处于未初始化状态。修复它。（CVE-2026-64306）

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

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

  - ksmbd：跟踪拥有字节范围锁定的连接SMB2_LOCK将每个已授予的字节范围锁定添加到处理请求的连接的文件锁定列表和锁定列表。但是，最终的关闭和持久句柄路径会在保留 fp->conn->llist_lock 时删除连接列表条目。使用 SMB3 多通道时，处理 LOCK 请求的连接可以与打开该文件的连接不同。因此，可在与保护其所属列表的旋转锁不同的旋转锁下删除该条目。然后，并发遍历可以访问释放的 struct ksmbd_lock 和 struct file_lock 对象。记录拥有每个锁的 clist 条目的连接，并在链接该条目时保留对该条目的引用。使用该连接及其llist_lock进行解锁、回滚、关闭和持久保留。
    再次发布锁定时，持久重新连接将新连接分配为所有者。
    (CVE-2026-64390)

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

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

  - ALSA：gus：当内存分配失败时，检查 snd_ctl_new1（） 返回值 snd_ctl_new1（） 可能返回 NULL。
    snd_gf1_pcm_volume_control（） 在取消引用 kctl->id.index 之前未检查返回值，这可导致空指针取消引用。在 snd_ctl_new1（） 之后添加空检查，如果失败则返回 -ENOMEM。（CVE-2026-64482）

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

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

  - 已修复 Linux 内核中的下列漏洞：rust: block: fix GenDisk cleanup paths GenDiskBuilder::build() still has fallible work after __blk_mq_alloc_disk(), but its error path only recovers the foreign queue data. That leaks the temporary gendisk and request_queue until later teardown.
    If the caller moved the last Arc<TagSet<T>> into build(), the leaked queue can retain blk-mq state after the tag set is dropped. Fix the pre-registration failure path by dropping the temporary gendisk reference with put_disk() before recovering queue_data, so disk_release() can tear down the owned queue. Also pair GenDisk::drop() with put_disk() after del_gendisk(). Once a Rust GenDisk has been added with device_add_disk(), del_gendisk() only unregisters it; the final gendisk reference still has to be dropped to complete the release path. (CVE-2026-64509)

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

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

  - 已修复 Linux 内核中的下列漏洞：fuse-uring: fix moving cancelled entry to ent_in_userspace list fuse_uring_cancel() moves entries that are available (these have no reqs attached) to the ent_in_userspace list. ent_list_request_expired() checks the first entry on ent_in_userspace and dereferences ent->fuse_req unconditionally, which will crash on a cancelled entry that was moved to this list. Fix this by freeing the entry and dropping queue_refs directly in fuse_uring_cancel(). This is safe because cancel is the cancel handler itself - after io_uring_cmd_done(), no more cancels will be dispatched for this command, and teardown serializes with cancel via queue->lock.
    Since cancel now decrements queue_refs, fuse_uring_abort() must no longer gate fuse_uring_abort_end_requests() on queue_refs > 0, as cancelled entries may have already dropped queue_refs while requests are still queued. Remove the gate so abort always flushes requests and stops queues. (CVE-2026-64263)

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

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

  - s390：恢复对 DCACHE_WORD_ACCESS load_unaligned_zeropad（） 的支持会从未对齐的地址读取八个字节，并且可能跨越页面边界。它处理在从第二页读取导致异常时可能发生的异常。但是，对于出于安全执行目的提供给 Ultravisor 的页面，do_secure_storage_access（） 异常处理程序未正确处理此类异常。这样的异常可能导致永远无法解决的无限异常循环。事实证明，修复此问题 [1] 的尝试是不够的。现在恢复 load_unaligned_zeropad（），直到此问题以正确方式解决。请注意，load_unaligned_zeropad（） 本身的实现是正确的。在安全存储访问异常有完整的补丁发布之前，恢复只是临时变通方案。
    [1] 提交 b00be77302d7（s390/mm：为捐赠的内存添加缺少的安全存储访问修复）（CVE-2026-64369）

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: krb5 - filter out async aead implementations at alloc krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL completion callback and treat any negative return from crypto_aead_{encrypt,decrypt}() as terminal, falling through to kfree_sensitive(buffer). When the encrypt_name resolves to an async AEAD instance the request returns
    -EINPROGRESS, the buffer is freed while the backend's worker still holds a pointer, and the worker dereferences the freed slab on completion. KASAN report under UML+SLUB with a synthetic async aead backend bound to krb5->encrypt_name: BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7 The helpers were written synchronously, so filter the async instances out at allocation time instead of plumbing crypto_wait_req() through every call site. Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and net/ceph/crypto.c on systems with an async AEAD provider bound to the krb5 enctype name. (CVE-2026-64439)

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

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

  - cpufreq：qcom-cpufreq-hw：修复可能的双重释放 qcom_cpufreq。通过 probe（） 中的 devm_kzalloc（） 分配数据作为各域数据的数组。qcom_cpufreq_hw_cpu_init（） 在策略>driver_data中存储指向此数组的一个元素的指针。qcom_cpufreq_hw_cpu_exit（） 目前在策略>driver_data上调用 kfree（）。
    这无效，因为内存由 devm 管理。对于第一个域，这可在 devres 条目仍处于活动状态时释放 devm 管理的分配，导致以后分离平台设备时可能出现双重释放。对于其他域，指针可能引用数组内的元素，而不是分配基础。删除 kfree（data） 调用并让 devres 释放 qcom_cpufreq.data。此问题是由我正在开发的静态分析工具发现的。（CVE-2026-64377）

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

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

  - iio：pressure：mpl115：修复读取错误中的运行时 PM 泄漏 mpl115_read_raw（） 在读取处理过的压力或原始温度之前采用 pm_runtime_get_sync（） 的运行时 PM 引用，但在读取错误路径上它会返回而不调用 pm_runtime_put_autosuspend（）。因此，每次读取失败都会泄露一个运行时 PM 引用，并阻止设备自动暂停。在检查返回值之前删除引用，以平衡成功和错误路径。（CVE-2026-64493）

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

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

  - vfio/pci：每台设备disable_idle_d3锁存 vfio-pci 引入 disable_idle_d3 时，会通过 pci_set_power_state（） 直接操控设备电源状态。没有用于维持或平衡操作的引用计数，我们可以无条件将设备移至 D0，并有条件将其移至 D3hot。
    因此，模块参数设为可写。之后，在提交 c61302aa48f7（vfio/pci：将模块参数移至 vfio_pci.c）中，在 vfio-pci-core 拆分的过程中，模块参数的可写入部分遭到取消。此参数值仍可通过 sysfs 变更，但 vfio-pci 驱动在模块 init 时将该值锁存到 vfio-pci-core 全局变量中。使用非默认值或不同的值加载 vfio-pci 模块，或卸载然后重新加载，可更改相对于绑定至 vfio-pci 变体驱动程序的现有设备的全局。提交 7ab5e10eda02 中引入了运行时 PM（vfio/pci：使用运行时 PM 将未使用的设备移至低功耗状态），这标志着重新计数电源状态的点。PM get 和 put 操作需要取得平衡，但上述相同的模块操作可以更改相对于已绑定至 vfio-pci 变体驱动程序的设备相关的全局变量。这引入了一个 PM 操作现在可变得不平衡的窗口。为了通过较小的稳定向后移植占用空间来解决这个问题，disable_idle_d3 标记在初始化时锁存到vfio_pci_core_device中，以便设备始终以一致的值运行。注意。
    vfio_pci_dev_set_try_reset（） 现在会无条件地提高总线重置前后的运行时 PM 使用计数，以说明disable_idle_d3变成每个设备而非全局标记。设置此标记后，其他 get/put 对无害并允许继续使用共享的 vfio_pci_dev_set_pm_runtime_get（） 辅助函数。（CVE-2026-64476）

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

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

  - block：在 bdev_mark_dead（） 中意外删除时跳过 sync_blockdev（） bdev_mark_dead（） 的 @surprise == true 表示设备已消失。文件系统回调 fs_bdev_mark_dead（） 遵从此并跳过 sync_filesystem（），但是裸块设备路径（no ->mark_dead op）在连接持有者 ->mark_dead 回调时失去其 ！surprise 防护（参见补丁），现在会无条件调用 sync_blockdev（），这可能会永远挂起，等待无法再完成的回写。syzkaller 通过 nvme_reset_work（） 的 I/O 队列丢失路径命中了此问题：nvme_mark_namespaces_dead（） -> blk_mark_disk_dead（） -> bdev_mark_dead（bdev， true） -> sync_blockdev（） 区块在 folio_wait_writeback（） 中，插入重置工作线程及其上等待的每个任务。跳过意外删除时的同步，匹配 fs_bdev_mark_dead（）;
    invalidate_bdev（） 仍在运行。有序删除 （surprise == false） 未更改。由 FuzzNvme（具有 FEMU 模糊框架的 Syzkaller）发现。（CVE-2026-64326）

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

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

  - 已修复 Linux 内核中的下列漏洞：iio: adc: ad_sigma_delta: fix CS held asserted and state leaks In ad_sigma_delta_single_conversion(), set_mode(AD_SD_MODE_IDLE) and disable_one() were called from the out: block while keep_cs_asserted was still true. This caused any SPI transfer issued by those callbacks to carry cs_change=1, leaving CS permanently asserted after the conversion. Fix by moving both calls into the out_unlock: block, after keep_cs_asserted is cleared, matching the pattern already used in ad_sd_calibrate(). In the error path of ad_sd_buffer_postenable(), if an operation fails after set_mode(AD_SD_MODE_CONTINUOUS) has already succeeded (e.g.
    spi_offload_trigger_enable()), the device is left in continuous conversion mode with CS physically asserted. Additionally, bus_locked remaining true after spi_bus_unlock() causes subsequent SPI operations to call spi_sync_locked() without the bus lock actually held, allowing concurrent SPI access. Fix the error path by clearing keep_cs_asserted first, then calling set_mode(AD_SD_MODE_IDLE) to revert the device mode and deassert CS, then clearing bus_locked before releasing the bus. For devices that implement neither set_mode nor disable_one (such as MAX11205, which has no physical CS pin), no SPI transfer is issued during cleanup and the cs_change flag has no effect on any physical line. (CVE-2026-64501)

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

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

  - PCI：mediatek：修复端口无法启用时的 IRQ 域泄漏 当 mtk_pcie_enable_port（） 失败时，mtk_pcie_port_free（） 从 pcie->ports 中删除该端口并释放端口结构。但是，之前由 mtk_pcie_init_irq_domain（） 设置的 IRQ 域永远不会释放。通过将 mtk_pcie_irq_teardown（） 重构为每个端口的辅助函数 mtk_pcie_irq_teardown_port（），并在 mtk_pcie_enable_port（） 失败时从 mtk_pcie_setup（） 调用它来修复此问题。由于 IRQ 拆卸必须仅在探测错误路径中发生（恢复期间，子设备可能具有活动的 MSI 映射，并且 NOIRQ 上下文禁止休眠锁定），因此将 mtk_pcie_enable_port（） 更改为返回错误代码，以便调用方可区分这两种路径并采取相应操作。此问题由 Sashiko 在查看 EcoNet EN7528 SoC 支持系列时报告。（CVE-2026-64461）

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

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

  - 输入：synaptics-rmi4 - 将 F3A keymap 绑定到 GPIO 计数 rmi_f3a_initialize（） 从设备查询寄存器获取 GPIO 计数（f3a->gpio_count = buf &; RMI_F3A_GPIO_COUNT，范围 0..127）。
    然后，rmi_f3a_map_gpios（） 最多分配 6 个条目gpio_key_map min（gpio_count， TRACKSTICK_RANGE_END） == ，但 rmi_f3a_attention（） 迭代完整的gpio_count和取消引用 gpio_key_map[i]，并且 input->keycodemax 设置为完整gpio_count，而 input->keycode 指向 6 个条目分配。因此，报告 gpio_count > 6 的设备会在每次注意力中断时造成越界读取 gpio_key_map[] ，以及通过输入核心的默认 keymap ioctl 进行越界访问：
    由于 input_default_getkeycode（） 和 input_default_setkeycode（） 仅针对 keycodemax 绑定索引，因此 EVIOCGKEYCODE 会针对任何可打开 evdev 节点的进程，读取超过缓冲区（将相邻的 slab 内存泄漏至用户空间），且 EVIOCSKEYCODE 会将调用程序控制的值写过缓冲区。调整完整gpio_count的键映射大小。映射循环保持不变：它仍然只分配第一个 min（gpio_count， TRACKSTICK_RANGE_END） 条目;其余插槽保持KEY_RESERVED（devm_kcalloc零填充）并在报告时跳过。（CVE-2026-64277）

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

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

  - 已修复 Linux 内核中的下列漏洞：mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access The page_ext iteration API does not validate if the PFN still belongs to a valid section while advancing the iterator. When dynamically adding memory in the hotplug path, it can lead to a NULL pointer dereference during page_ext_lookup at the boundary of the last valid section when iterator count equals __pgcount. The for_each_page_ext() macro calls page_ext_iter_next() as its loop increment. for_each_page_ext() does a __page_ext = page_ext_iter_next(&__iter) at the end. This causes page_ext_iter_next() to increment iter->index past
    __pgcount and call page_ext_lookup(start_pfn + __pgcount). During memory hotplug (online), the PFN at start_pfn + __pgcount may belong to a section that has not yet been initialized, causing page_ext_lookup() to trigger a NULL pointer dereference. [ 14.555124][ T846] Call trace: [ 14.555125][ T846] lookup_page_ext+0x6c/0x108 (P) [ 14.555127][ T846] page_ext_lookup+0x30/0x3c [ 14.555129][ T846]
    __reset_page_owner+0x11c/0x260 [ 14.571201][ T846] __free_pages_ok+0x5e8/0x8e0 [ 14.571204][ T846]
    __free_pages_core+0x78/0xf0 [ 14.571206][ T846] generic_online_page+0x14/0x24 [ 14.597782][ T846] online_pages+0x178/0x30c [ 14.597784][ T846] memory_block_change_state+0x284/0x32c [ 14.597787][ T846] memory_subsys_online+0x4c/0x64 [ 14.597789][ T846] device_online+0x88/0xb0 [ 14.597791][ T846] online_memory_block+0x30/0x40 [ 14.597793][ T846] walk_memory_blocks+0xac/0xe8 [ 14.597794][ T846] add_memory_resource+0x280/0x298 [ 14.656161][ T846] add_memory+0x60/0x98 Move the iteration boundary enforcement inside the iterator functions, so callers cannot inadvertently access beyond the requested range. (CVE-2026-64295)

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

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

  - i2c：核心：修复适配器取消注册争用 使用 i2c_get_adapter（） 可以通过其 ID 查找适配器，该 （） 采用嵌入式结构设备的引用。在注销期间（以及注册失败时）拆除适配器之前，请从 IDR 中删除适配器，以确保在释放后不访问其资源（例如设备名称）。（CVE-2026-64279）

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

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

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

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

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

  - bpf：支持针对 JIT 喷洒的强化 BPF JIT 分配器将许多小程序打包成更大的可执行分配，并在加载和释放程序时重用这些分配中的空间。
    当新代码被写入上一个程序占用的空间时，间接跳转到新程序可以重复使用旧程序留下的分支预测。在重用 JIT 内存之前刷新间接分支预测器，以便间接跳转到新编写的程序时不会重用占用相同空间的旧程序的预测。引入bpf_arch_pred_flush_enabled静态密钥和bpf_arch_pred_flush静态调用，以在 JIT 内存重用时刷新分支预测变量。需要刷新的架构可将其更新为预测器刷新函数。默认情况下，它是一个 NOP 并且不发出任何 CALL。此刷新不涵盖大于包的分配。这是安全的，因为 cBPF 程序（非特权攻击面）的边界远小于包大小。如果在刷新处于活动状态时违反了此假设，则发出警告。（CVE-2026-64508）

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

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

  - staging：rtl8723bs：修复 OnAuth（） 中的 WEP 长度下溢和 OOB 读取 OnAuth（） 在共享密钥认证路径中有两个缺陷。设置隐私位时，调用 rtw_wep_decrypt（） 时未验证帧是否足够长以包含有效的 WEP IV 和 ICV。在 rtw_wep_decrypt（） 中，长度的计算公式为：length = len - WLAN_HDR_A3_LEN - iv_len，然后作为 （length - 4） 传递到 crc32_le（）。如果长度小于 WLAN_HDR_A3_LEN + iv_len + icv_len（32 字节），长度 - 4 为负，并且在隐式转换到 size_t 之后，造成 crc32_le（） 读取范围远远超出帧缓冲区。在访问 IV 字段和调用解密路径之前添加最小长度检查。当处理 seq=3 响应时，rtw_get_ie（） 会以 ie_len 存储质询文本 IE 长度，但无论ie_len如何，后续的 memcmp（） 始终读取 128 字节。IEEE 802.11 强制要求刚好为 128 字节的质询文本;拒绝长度字段不同的任何 IE，这与已应用到 OnAuthClient（） 的检查相匹配。（CVE-2026-64445）

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

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

  - sched/rt：将 RT_PUSH_IPI 默认关闭，以PREEMPT_RT积极完成 RT 迁移。当 CPU 为较低优先级的任务计划高优先级的 RT 任务时，它会查看是否有任何 RT 任务正在等待在比此 CPU 要运行的任务更高的另一个 CPU 上运行。如果找到一个，它会将该任务拉到 CPU 并允许它在那里运行。通常，此拉取通过查看 RT 过载掩码 （rto） 来完成，其中包含计划程序域中的所有 CPU，以及由于 CPU 上当前正在运行更高优先级 RT 任务而等待运行的 RT 任务。即将计划优先级较低任务的 CPU 将获取过载 CPU 的 rq 锁定并将 RT 任务从该 CPU 的运行队列移至本地运行队列并计划优先级较高的 RT 任务。当大量 CPU 同时计划优先级较低的任务时，就会造成问题。它们都会尝试通过重载的 RT 任务获取 CPU 的同一个 runqueue 锁定。只有第一个进入的 CPU 才能获得该任务。所有其他人都会等到他们获得 runqueue 锁定，然后看到没有什么可拉的，什么都不做。在具有大量 CPU 的系统上，这会造成超出PREEMPT_RT允许范围的较大延迟（高达 500us）。解决方法是创建一个RT_PUSH_IPI逻辑。当任何 CPU 想要拉取任务时，它会首先向过载 CPU 发送 IPI，而不是抓取过载 CPU 的 runqueue 锁，而该 IPI 处理程序会让具有等待 RT 任务的 CPU 转而执行推送。然后该处理程序会将 IPI 发送到下一个具有过载 RT 任务的 CPU，依此类推。请注意，在第一个 CPU 启动此进程后，如果另一个 CPU 想要执行拉取，它会看到该进程已经开始，并且只会递增一个计数器以使 IPI 再次继续。RT_PUSH_IPI解决了 PREEMPT_RT 的延迟问题，但非PREEMPT_RT可造成新的问题。也就是说，softirqs 在 PREEMPT_RT 上的线程上下文中运行，但它们可以在非 RT 中的中断上下文中运行。如果 IPI 落在刚刚唤醒多个 RT 任务的 CPU 上，而当前 CPU 正在运行非 RT 或低优先级 RT 任务，它将不执行推送，而只是对该 CPU 执行计划。但如果 softirq 也在此 CPU 上执行，则计划将需要等待到 softirq 完成。到那时，CPU 仍会被视为过载，因为仍有 RT 任务等待在其上运行。在大型机器上处理大量网络流量的工作负荷上发生活锁，其中 softirqs 会运行 750us 中的 500us。它还将唤醒 RT 任务，从而导致持续执行 RT pull 逻辑。当 RT 任务已排队但尚未运行的 CPU 上触发 softirq 且其他 CPU 将此 CPU 视为过载时，会向其发送 IPI。CPU 会注意到等待中的 RT 任务的优先级高于当前正在运行的任务，并直接安排该 CPU。但由于 softirq 正在执行，因此在计划之前，它会收到另一个 IPI 以执行相同的操作。IPI 的数量会大大拖慢当前正在运行的 softirq 的速度，以至于在它返回到任务上下文之前，它会执行另一个 softirq，从不允许 CPU 进行计划。这样会活锁该 CPU。创建 RT_PUSH_IPI 的初衷是帮助PREEMPT_RT，因此如果未启用PREEMPT_RT则将其默认关闭。（CVE-2026-64374）

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

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

  - 已修复 Linux 内核中的下列漏洞：fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req When fuse_resend() moves a request from fpq->processing back to fiq->pending, it sets FR_PENDING and clears FR_SENT but does not remove the requests intr_entry from fiq->interrupts. If the request had FR_INTERRUPTED set from a prior signal, intr_entry remains dangling on fiq->interrupts.
    When the requesting task then receives a fatal signal, fuse_remove_pending_req() sees FR_PENDING=1, removes the request from fiq->pending and frees it via the refcount path, also without cleaning intr_entry. The stale intr_entry causes use-after-free when fuse_read_interrupt() iterates fiq->interrupts: - list_del_init(&req->intr_entry) -> UAF write on freed slab - req->in.h.unique -> UAF read, data leaked to userspace Remove intr_entry from fiq->interrupts in fuse_resend() for interrupted requests before they are placed back on fiq->pending. Add a WARN_ON if the intr_entry is not empty on request destruction. (CVE-2026-64265)

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

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

  - ksmbd：修复 SMB2_CLOSE 然后SMB2_CANCEL提交时延迟file_lock的释放后使用 f580d27e8928（ksmbd：修复双重SMB2_CANCEL时的延迟file_lock的释放后使用）使 smb2_cancel（） 跳过状态为 KSMBD_WORK_CANCELLED 的工作，因此无法再次触发其cancel_fn。但是KSMBD_WORK具有三种状态（ACTIVE、CANCELLED、CLOSED），并且 CLOSED 也达到相同的释放生产者路径：
    锁定句柄 -> set_close_state_blocked_works（） 上的SMB2_CLOSE会将延迟工作的状态设置为 KSMBD_WORK_CLOSED 并唤醒 smb2_lock（） 工作线程。工作线程采用非 ACTIVE 提前退出，locks_free_lock（）s file_lock，并且由于状态未KSMBD_WORK_CANCELLED，因此采用带有 goto out2 的 STATUS_RANGE_NOT_LOCKED 分支 -- 与取消的分支一样，跳过 release_async_work（）。工作会停留在 conn->async_requests上，实时 cancel_fn = smb2_remove_blocked_lock 指向已释放的file_lock。随后，针对相同 AsyncId 的后续SMB2_CANCEL会传递仅KSMBD_WORK_CANCELLED保护（其状态为 KSMBD_WORK_CLOSED），因此 smb2_cancel（） 会在释放的file_lock上再次触发 cancel_fn -- 通过 SMB2_CLOSE 而非第一次SMB2_CANCEL修复了相同的释放后使用错误： 缺陷：KASAN：__locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL 中的 slab-use-after-freecancel_fn handle_ksmbd_work 分配者 ...： locks_alloc_lock <- smb2_lock 释放者 ...：
    locks_free_lock <- smb2_lock（非活动提早退出）...大小为 192 的缓存file_lock_cache由经身份验证的 SMB 客户端使用 KASAN 在干线 7.1-rc7（已包含 f580d27e8928）上重现;该内核上的双SMB2_CANCEL控件是静默的，因此 splat 可归因于 CLOSE 触发。
    只有 ACTIVE 延迟工作可触发其cancel_fn：两个终端状态（CANCELLED 和 CLOSED）都到达 smb2_lock（） 提早退出，从而释放file_lock并跳过 release_async_work（）。保护KSMBD_WORK_ACTIVE以便跳过任何非活动工作。（CVE-2026-64437）

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: loongson - Remove broken and unused loongson-rng The loongson-rng rng_alg has several vulnerabilities, including not providing forward security, and a use-after-free bug due to the use of wait_for_completion_interruptible(). Meanwhile, the rng_alg framework doesn't really have any purpose in the first place other than to access the software algorithms crypto/drbg.c and crypto/jitterentropy.c. Hardware-specific rng_algs have no in-kernel user, and unlike hwrng there's no feed into the actual Linux RNG. As such, there's really no point to this code.
    There are of course other rng_alg drivers that are similarly unused, but they're similarly in the process of being phased out, e.g. https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org Given that, there's no point in fixing forward these vulnerabilities, and it makes much more sense to simply roll back the addition of this driver. If this platform provides TRNG (not PRNG) functionality, it could make sense to add a hwrng driver, but it would be quite different. (CVE-2026-64311)

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

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

  - vfio/mlx5：修复 racy 位字段并加强结构布局 位字段操作不是原子操作，它们使用读取-修改-写入模式，因此我们应注意不要将可并发更新的位字段打包到同一个存储单元中。此拆分采用二进制方法：仅在打开/关闭前/之后修改的标记保留位字段，从用户操作修改的标记（包括到达另一台设备的操作（例如重置）使用专用存储单元。注意 mlx5_vhca_page_tracker.status 重定位以填补此拆分暴露的对齐孔。位字段理由： migrate_cap：探测时仅以 mlx5vf_cmd_set_migratable（） 写入 chunk_mode：探测时仅以 mlx5vf_cmd_set_migratable（） 写入 mig_state_cap：探测时仅以 mlx5vf_cmd_set_migratable（） 写入 专用存储单元：mdev_detach：
    运行时在 VF 附加/分离事件通知器 mlx5fv_vf_event（） 中写入 log_active：运行时在 mlx5vf_start_page_tracker（）/ mlx5vf_stop_page_tracker（） 中写入 脏跟踪 deferred_reset：
    在运行时重置处理期间以 mlx5vf_state_mutex_unlock（）/ mlx5vf_pci_aer_reset_done（） 编写 is_err：
    由运行时的跟踪器错误处理和脏日志轮询设置 object_changed：由跟踪器事件处理设置，并由运行时的脏日志轮询清除 （CVE-2026-64472）

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

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

  - vfio/pci：在 register_device（） 失败时释放 VGA 仲裁程序客户端。将以下 Fixes 提交中的重新排序将 vfio_pci_vga_init（） 置换为现在 vfio_pci_core_register_device（） 的最后一个失败点，而未引入 VGA 仲裁程序注册展开。在目前内核中，这大多是良性的，因为 vfio_pci_set_decode（） 仅使用 pci_dev 状态，但原始失败路径会留下带有已释放 vdev cookie 的回调。一旦回调跟随 drvdata 进入 vfio 设备，过时注册也会再次变得不安全。添加所需的 VGA 展开调出。
    (CVE-2026-64475)

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

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

  - tracing：防止 glob 匹配中的越界读取 字符串事件字段不一定以 NUL 结束，因此过滤器谓词函数（filter_pred_string（）、filter_pred_strloc（） 和 filter_pred_strrelloc（））会将字段长度传递给 regex 匹配回调，而长度感知匹配程序会遵从该参数。regex_match_glob（） 例外：它忽略长度并调用 glob_match（），后者会扫描字符串直到它命中 NUL 字节。某些字符串字段不是以 NUL 结尾。例如，复制的 xfs_* 命名空间跟踪点的动态 char 数组时没有结尾 NUL。对于此类字段，glob 匹配读取超出事件字段的末尾，从而导致 glob_match（） 中的 KASAN slab-out-bound 读取，可通过 xfs_lookup 跟踪点的 regex_match_glob（） 和 filter_match_preds（） 到达。添加长度限制的 glob_match_len（） 并从 regex_match_glob（） 中使用，这样 glob 匹配始终在字段边界处停止。匹配循环被分解到共享帮助程序中，因此 glob_match（） 保留其行为。
    (CVE-2026-64299)

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

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

  - netpoll：修复关闭路径中的释放后使用。netpoll 中存在释放后使用错误，KASAN 可以清楚地检测到该错误。缺陷：KASAN：地址处的 _raw_spin_lock_irqsave+0x3b/0x80 读取中存在大小为 1 的 slab-after-free ...按任务 kworker/9:1 工作队列：事件queue_process调用跟踪：skb_dequeue+0x1e/0xb0 queue_process+0x2c/0x600 process_scheduled_works+0x4b6/0x850 worker_thread+0x414/0x5a0 按任务 242 分配：__netpoll_setup+0x201/0x4a0 netpoll_setup+0x249/0x550 enabled_store+0x32f/0x380 由任务 0 释放：
    kfree+0x1b7/0x540 rcu_core+0x3f8/0x7a0 当清理路径并行运行待定的 TX 工作线程时，会发生此问题。这是在 netpoll 关机路径上发生的情况：1） 调用 __netpoll_cleanup（） 2） 将 dev->npinfo 设置为 NULL 3） call_rcu（） 与 rcu_cleanup_netpoll_info（） 3.1） rcu_cleanup_netpoll_info（） 尝试使用 cancel_delayed_work（） 取消所有工作线程，但不等待工作线程完成 4） 和 kfree（npinfo）;因为 ） 并没有真正取消工作，因为 3.1注释说我们无法在此处调用 cancel_delayed_work_sync，因为我们在 softirq 中，TX 工作线程可以在 4） 之后运行。
    TL;DR：queue_process（） 不是 RCU 读取器，它通过 container_of（） 通过工作项到达 npinfo。
    使用 disable_delayed_work_sync（） 确保完全停止工作线程并阻止日后的任何重新布防尝试。npinfo 设置为 NULL 后，发件人将退出并且不会为新工作排队。禁用标记可确保任何正在进行的重新布防尝试也会以静默方式失败。将来，我们可以在此处进行内联清理，而不需要 npinfo->rcu rcu_head，但那是 net-next 材料。（CVE-2026-64424）

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

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

  - gpio：sch：在 irq 启动路径中使用 raw_spinlock_t sch_irq_unmask（） 启用 GPIO IRQ，然后通过 sch_irq_mask_unmask（） 更新控制器状态，其采用 spin_lock_irqsave（） 进行 sch->lock。设置请求的 IRQ 时，可从 irq_startup（） 访问回调。该路径不可休眠，但在PREEMPT_RT，常规spinlock_t会变成睡眠锁。此问题是我们的静态分析工具发现的，然后对照当前树手动查看。接地的 PoC 保留了 request_threaded_irq（） -> __setup_irq（） -> irq_startup（） -> sch_irq_unmask（） -> sch_irq_mask_unmask（） 载波，并使用了原始 spin_lock_irqsave（&sch->lock） 边缘。Lockdep 报告：
    缺陷：从无效上下文调用的休眠函数 hardirqs 上次禁用时间为 ... __setup_irq.constprop.0 ...[vuln_msv] sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] 将 SCH 控制器锁转换为raw_spinlock_t。
    GPIO 方向和值回调也使用相同的锁定，但这些关键部分仅更新 MMIO 支持的 GPIO 寄存器，不包含可休眠操作。因此，将此寄存器锁定保持为非休眠适用于 irqchip 回调，并且不会更改 GPIO 端锁定协定。（CVE-2026-64428）

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

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

  - 已修复 Linux 内核中的下列漏洞：rust_binder: clear freeze listener on node removal Generally userspace is supposed to explicitly clear freeze listeners before they drop the refcount on the node ref to zero, but there's nothing forcing that. Currently, in this scenario the freeze listener remains in the freeze_listeners rbtree and in the remote node's freeze listener list, even though the ref for which the listener is registered is gone. This could potentially lead to a memory leak due to a refcount cycle. Thus, remove the freeze listener in this scenario. (CVE-2026-64466)

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

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

  - 已修复 Linux 内核中的下列漏洞：usb: gadget: f_fs: Initialize epfile->in early to fix endpoint direction checks When parsing endpoint descriptors, ffs_data_got_descs() generates the eps_addrmap which contains the endpoint direction. However, epfile->in was previously only populated in ffs_func_eps_enable() which executes upon USB host connection. As a result, early userspace ioctls like FUNCTIONFS_DMABUF_ATTACH that run before the host connects would see epfile->in as 0, leading to incorrect DMA directions. By moving the initialization to ffs_epfiles_create(), epfile->in is accurate before userspace opens the endpoint files. (CVE-2026-64327)

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

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

  - USB：chaoskey：修复 chaoskey_release（） 中的 slab-after-free（） 释放后使用 chaoskey 驱动程序的发布例程中存在一个释放后使用缺陷。如果用户在拔出 USB 设备后关闭设备文件，则调试日志语句将在释放后尝试访问usb_interface结构：缺陷：
    KASAN：dev_driver_string 中的 slab-use-after-free （drivers/base/core.c：2406） 在地址 ffff888168e8a0b8 处按任务 chaoskey_raw_re/10106 读取大小为 8 硬件名称：QEMU Ubuntu 24.04 PC v2（i440FX + PIIX，arch_caps补丁，1996 年），BIOS 1.16.3-debian-1.16.3-2 04/01/2014 调用跟踪： <TASK> dump_stack_lvl （lib/dump_stack.c：94 lib/dump_stack.c：120） print_report （mm/kasan/report.c：378 mm/kasan/report.c：482） kasan_report （mm/kasan/report.c：595） dev_driver_string （drivers/base/core.c：2406） __dynamic_dev_dbg （lib/dynamic_debug.c：906） chaoskey_release （drivers/usb/misc/chaoskey.c：323） __fput （fs/file_table.c：510） fput_close_sync （fs/file_table.c：615） __x64_sys_close （fs/open.c：1507 fs/open.c：1492 fs/open.c：1492） do_syscall_64 （arch/x86/entry/syscall_64.c：63 arch/x86/entry/syscall_64.c：94） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：121） 驱动程序对接口结构的最后引用在 chaoskey_free（） 例程中丢弃，因此在该例程返回后，代码不得使用该接口，即使是在调试语句中。（例外：如果我们知道在断开连接例程运行时由其他人持有另一个引用，例如设备核心，则没有问题。
    感谢 Johan Hovold 指出此问题。）由于错误访问属于不重要的调试语句的一部分，因此我们只需删除整个语句即可修复问题。（CVE-2026-64455）

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

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

  - ACPI：NFIT：核心：修复提交 9b311b7313d6 后可能的空指针取消引用（ACPI：NFIT：获取 NFIT 表前安装 Notify（） 处理程序），acpi_nfit_probe（） 在检查 NFIT 表是否存在之前为 NFIT 设备安装 ACPI 通知处理程序。如果该表不存在，则在不分配acpi_desc对象和设置 NFIT 设备的驱动程序数据指针的情况下返回 0。如果平台固件此时触发了 NFIT 设备上的NFIT_NOTIFY_UC_MEMORY_ERROR通知，acpi_nfit_uc_error_notify（） 将取消引用空指针。通过向 acpi_nfit_uc_error_notify（） 添加针对 NULL 的acpi_desc检查来防止发生此情况。（CVE-2026-64511）

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

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

  - KVM：arm64：刷新 pKVM hyp vCPU 时清除__hyp_running_vcpu flush_hyp_vcpu（） 在每次运行时将主机 vCPU 上下文复制到 hyp 的私有 vCPU 中。ctxt_to_vcpu（） 预期客户机上下文具有 NULL
    __hyp_running_vcpu，它只会在主机上下文中设置，因此它通过 container_of（） 解析 vCPU。虽然一般情况是这样，但 flush_hyp_vcpu（） 会逐字复制上下文并且不强制执行此操作，因此主机提供的值会在 EL2 取消引用 （host -> EL2）。通过清除修复
    __hyp_running_vcpu复制后。（CVE-2026-64286）

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

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

  - mm/slab：仅启用红色分区时不将归零限制为orig_size 请求对分配进行 init（归零）时，对于 kmalloc（），即使请求了更小的大小，我们通常也必须将整个对象大小归零，以便提供 krealloc（） 的__GFP_ZERO保证。但是如果我们跟踪请求的大小，krealloc（） 会使用该信息来执行正确的操作，因此我们只能将请求的大小归零。启用红色分区时，任何额外的大小都将成为红色区域的一部分，因此不能将其归零，因此我们只能将请求的大小归零。但是，当前检查不精确，并且也会在仅启用SLAB_RED_ZONE而未SLAB_STORE_USER时触发（从而启用跟踪请求的大小）。这意味着单独启用红色分区可能会破坏 krealloc（） 的__GFP_ZERO合约。请改用 slub_debug_orig_size（） 修复此问题，后者可精确检查是否跟踪请求的大小。我们不需要关心是否启用了红色分区。还相应地更新和展开注释。
    (CVE-2026-64368)

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

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

  - binder：修复 binder_free_transaction（） 中的 UAF 在 binder_free_transaction（） 中，在 t->lock 下读取 t->to_proc。但是，一旦放置 t->lock ，to_proc可能会并联死机。当我们之后尝试获取其内部锁定时，这会导致一个释放后使用错误：
    ================================================================== 缺陷：KASAN：中的 slab-use-after-free
    _raw_spin_lock+0xe4/0x1a0 任务 B/672 在地址 ffff00001125da70 处写入大小为 4 CPU：20 UID：0 PID：672 通信：B 未受感染 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT 硬件名称：linux，dummy-virt （DT） 调用跟踪：_raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...]按任务 675 分配：
    __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...]由任务 212 释放：__kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== 若要避免此情况，请固定目标线程 （t->to_thread） 以保证目标进程保持运行中状态。没有目标线程的未交付事务已经是安全的，因为目标进程只能是这些路径中的当前上下文。
    (CVE-2026-64468)

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

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

  - smb：客户端：修复 SMB2_flush（） 重放中的双重释放 SMB2_flush（） 在重放尝试期间保留其响应缓冲区记本。如果接收到可重放的刷新响应，然后在 cifs_send_recv（） 存储替换响应之前重试失败，flush_exit 将再次释放过时的响应指针。在重放循环顶部重新初始化resp_buftype和rsp_iov，以便清除仅针对当前尝试产生的响应状态起作用。这样在不更改对成功请求的重放处理的情况下修复了双重释放。（CVE-2026-64383）

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

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

  - 已修复 Linux 内核中的下列漏洞：iio: adc: ti-ads1119: fix PM reference leak in buffer preenable ads1119_triggered_buffer_preenable() resumes the device with pm_runtime_resume_and_get() before starting a conversion. If i2c_smbus_write_byte() fails, the function returns the error directly and leaves the runtime PM usage counter elevated. The matching postdisable callback is not called when preenable fails, so the reference is leaked and the device may remain runtime-active indefinitely. Store the I2C transfer result in ret and drop the runtime PM reference on failure before returning the error. (CVE-2026-64499)

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

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

  - 已修复 Linux 内核中的下列漏洞：staging: media: ipu7: fix double-free and use-after-free in error paths In both ipu7_isys_init() and ipu7_psys_init(), pdata is allocated and then passed to ipu7_bus_initialize_device(), which stores it in adev->pdata. The ipu7_bus_release() function frees adev->pdata when the device's reference count drops to zero. Two error paths incorrectly call kfree(pdata) after the device teardown has already freed it: 1. When ipu7_mmu_init() fails:
    put_device() is called, which drops the reference count to zero and triggers ipu7_bus_release() -> kfree(pdata). The subsequent kfree(pdata) is a double-free. 2. When ipu7_bus_add_device() fails: it calls auxiliary_device_uninit() internally, which calls put_device() -> ipu7_bus_release() -> kfree(pdata). The subsequent kfree(pdata) is again a double-free. Note that the kfree(pdata) when ipu7_bus_initialize_device() itself fails is correct, because in that case auxiliary_device_init() failed and the release function was never set up, so pdata must be freed manually. Additionally, the error code was not saved before calling put_device(), causing ERR_CAST() to dereference the already-freed adev pointer when constructing the return value. Fix this by saving the error from dev_err_probe() before put_device() and returning ERR_PTR() instead. Remove the redundant kfree(pdata) calls and fix the use-after-free in the return values of the two affected error paths. (CVE-2026-64447)

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

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

  - 已修复 Linux 内核中的下列漏洞：fuse-uring: fix EFAULT clobber in fuse_uring_commit copy_from_user() returns the number of bytes not copied as an unsigned residual on failure (1..sizeof(struct fuse_out_header)). fuse_uring_commit stores that residual in ssize_t err, sets req->out.h.error to -EFAULT, then jumps to out: with err still holding the positive residual. err = copy_from_user(&req->out.h, &ent->headers->in_out, sizeof(req->out.h)); if (err) { req->out.h.error =
    -EFAULT; goto out; /* err is the positive residual */ } ... out: fuse_uring_req_end(ent, req, err);
    fuse_uring_req_end() then runs if (error) req->out.h.error = error; which overwrites the just-assigned
    -EFAULT with the positive residual. FUSE callers such as fuse_simple_request() test err < 0 to detect failure, so the positive value is interpreted as success and the caller proceeds with an uninitialised or partial req->out.args. Fix by assigning err = -EFAULT in the failure branch before jumping to out, so fuse_uring_req_end() receives a negative errno and sets req->out.h.error to -EFAULT. (CVE-2026-64264)

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

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

  - media：mtk-jpeg：仅在为支持的平台发布时取消工作队列 自最近的补丁以来，mtk_jpeg_release 函数会使用cancel_work_sync函数取消驱动程序工作队列中存在的任何待定或正在运行的工作。目前，只有基于多核的变体使用此工作队列，并且它们使用工作队列回调函数初始化了jpeg_worker平台数据字段。对于其他字段，此字段值默认为空。cancel_work_sync 函数会在 mtk_jpeg_release 函数中无条件调用，即使对于不使用工作队列的变量也是如此。此调用在__flush_work中生成WARN_ON打印，因为工作队列回调函数存在性检查在__flush_work函数（由cancel_work_sync使用）中失败。因此，为避免这些警告，请仅在平台数据中定义工作队列回调时调用cancel_work_sync。（CVE-2026-64358）

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

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

  - mm/shrinker：不在 shrinker_debugfs_count_show（） 中保持 RCU 锁定 读取可识别 memcg 的 shrinker 的 debugfs 计数文件可在 RCU 读取端关键部分内休眠：缺陷：从 kernel/cgroup/rstat.c：421 的无效上下文调用休眠函数 RCU 嵌套深度：1，预期：0 css_rstat_flush mem_cgroup_flush_stats zswap_shrinker_count shrinker_debugfs_count_show shrinker_debugfs_count_show（） 调用 rcu_read_lock（） 下的 ->count_objects（） 回调。zswap 回调通过 css_rstat_flush（） 刷新 memcg 统计数据，其可能会休眠，因此不得在 RCU 下运行。此处不需要 RCU 锁定。
    mem_cgroup_iter（） 在内部获取 RCU 并返回一个持有 css 引用的 memcg（在下一次迭代时或由 mem_cgroup_iter_break（）） 丢弃），因此没有它 memcg 也会保持活动状态。打开的 debugfs 文件使 shrinker 保持活动状态：shrinker_free（） 通过 debugfs_remove_recursive（） 删除 debugfs 条目，该条目会等待正在传输的读取器耗尽，然后call_rcu（...， shrinker_free_rcu_cb）。同级扫描处理程序已经调用没有 RCU 部分的休眠 ->scan_objects（） 回调。删除 rcu_read_lock（）/rcu_read_unlock（）。（CVE-2026-64419）

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

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

  - ALSA：had/cs35l41：修复固件加载工作破坏cs35l41_hda创建其专用数据指向cs35l41_hda对象的 ALSA 控件。固件加载控制也可以fw_load_work排队。组件取消绑定时不会删除这些控件，设备删除仅通过 cs35l41_remove_dsp（） 取消fw_load_work。当 halo_initialized 为 false 时，将跳过该辅助函数。禁用firmware_autostart后，可在初始化 DSP 之前请求固件加载。如果在排队的工作运行之前删除组件或设备，则工作线程可以在拆卸和取消引用驱动程序状态后运行，该状态不再有效。跟踪创建的控件并在取消绑定时将其删除，以便没有新的控件回调可以访问驱动程序数据或排队更多工作。然后取消fw_load_work以耗尽已排队的任何请求。此外，在运行时 PM 拆卸之前，在设备删除期间无条件取消工作。
    (CVE-2026-64481)

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

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

  - 已修复 Linux 内核中的下列漏洞：svcrdma: wake sq waiters when the transport closes Threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or sc_send_wait can hang indefinitely in TASK_UNINTERRUPTIBLE state across transport teardown, pinning svc_xprt references and blocking svc_rdma_free(). The close path sets XPT_CLOSE before invoking xpo_detach and both wait_event predicates include an XPT_CLOSE term, but the predicates are re-evaluated only on wakeup.
    sc_sq_ticket_wait has no completion-driven wake path; it is advanced solely by the chained ticket handoff inside svc_rdma_sq_wait() itself. Without an explicit wake at close, parked threads never observe XPT_CLOSE, hold their svc_xprt_get reference forever, and svc_rdma_free() blocks on xpt_ref dropping to zero. Two close entry points reach this transport. Local teardown runs svc_rdma_detach() from svc_handle_xprt() -> svc_delete_xprt() -> xpo_detach() on a worker thread. A remote disconnect arrives at svc_rdma_cma_handler(), which calls svc_xprt_deferred_close(): that sets XPT_CLOSE and enqueues the transport but does not access either RDMA waitqueue, so a worker already parked in svc_rdma_sq_wait() never re-evaluates its predicate. With every worker parked on this transport, no thread is available to run the local teardown either, and the wake site there is unreachable. Introduce svc_rdma_xprt_deferred_close(), a thin svcrdma wrapper that calls svc_xprt_deferred_close() and then wakes both sc_sq_ticket_wait and sc_send_wait. Convert the svcrdma producers that called svc_xprt_deferred_close() directly: svc_rdma_cma_handler(), qp_event_handler(), svc_rdma_post_send_err(), svc_rdma_wc_send(), the sendto drop path, the rw completion error paths, and the recvfrom flush and read-list error paths. Wake both waitqueues from svc_rdma_detach() as well. The synchronous svc_xprt_close() path (backchannel ENOTCONN, device removal via svc_rdma_xprt_done) reaches detach without flowing through svc_xprt_deferred_close() and therefore does not invoke the new helper. [ cel: add svc_rdma_xprt_deferred_close() to complete the fix ] (CVE-2026-64281)

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

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

  - Bluetooth：L2CAP：在读取 conf opt 值之前验证选项长度 l2cap_get_conf_opt（） 从攻击者控制的 opt->len 字段派生选项长度，并在任何调用方确认缓冲区中存在 opt->len 字节之前立即取消引用 opt->val（如 u8、get_unaligned_le16（） 或 get_unaligned_le32（），或默认情况下的原始指针）。调用程序（l2cap_parse_conf_req（）、l2cap_parse_conf_rsp（） 和 l2cap_conf_rfc_get（））仅在之后的运行长度变为负时检测畸形选项，此时已执行越界读取。现有的事后长度检查可防止消耗垃圾值，因此这不是当前控制流中的数据泄漏。它仍然是一个使用后验证排序缺陷：在已知缓冲区包含之前，最多会读取超过 4 个字节，并且它对于调用程序中未来的更改很脆弱。从源头修复。将缓冲区的末尾传递到 l2cap_get_conf_opt（） 中，并拒绝接触 opt->val，除非完整选项（标头 + 值）适合。每个调用程序在循环前计算一次结束指针，并直接检查返回值，而不是从负长度推断错误。（CVE-2026-64403）

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

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

  - USB：ulpi：修复注册失败时的内存泄漏 在早期 ULPI 设备注册失败时，永远不会释放分配的设备名称。通过在注册失败时提前初始化设备结构并释放初始引用来修复此问题。（CVE-2026-64332）

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

ID	名称	严重性
329976	Linux Distros 未修补的漏洞：CVE-2026-64384	critical
329975	Linux Distros 未修补的漏洞：CVE-2026-64372	high
329974	Linux Distros 未修补的漏洞：CVE-2026-64463	high
329973	Linux Distros 未修补的漏洞：CVE-2026-64431	high
329972	Linux Distros 未修补的漏洞：CVE-2026-64309	medium
329971	Linux Distros 未修补的漏洞：CVE-2026-64306	medium
329970	Linux Distros 未修补的漏洞：CVE-2026-64390	high
329969	Linux Distros 未修补的漏洞：CVE-2026-64482	medium
329968	Linux Distros 未修补的漏洞：CVE-2026-64509	medium
329967	Linux Distros 未修补的漏洞：CVE-2026-64263	medium
329966	Linux Distros 未修补的漏洞：CVE-2026-64369	medium
329965	Linux Distros 未修补的漏洞：CVE-2026-64439	critical
329964	Linux Distros 未修补的漏洞：CVE-2026-64377	high
329963	Linux Distros 未修补的漏洞：CVE-2026-64493	medium
329962	Linux Distros 未修补的漏洞：CVE-2026-64476	high
329961	Linux Distros 未修补的漏洞：CVE-2026-64326	medium
329960	Linux Distros 未修补的漏洞：CVE-2026-64501	high
329959	Linux Distros 未修补的漏洞：CVE-2026-64461	high
329958	Linux Distros 未修补的漏洞：CVE-2026-64277	high
329957	Linux Distros 未修补的漏洞：CVE-2026-64295	medium
329956	Linux Distros 未修补的漏洞：CVE-2026-64279	high
329955	Linux Distros 未修补的漏洞：CVE-2026-64340	high
329954	Linux Distros 未修补的漏洞：CVE-2026-64508	high
329953	Linux Distros 未修补的漏洞：CVE-2026-64445	high
329952	Linux Distros 未修补的漏洞：CVE-2026-64374	high
329951	Linux Distros 未修补的漏洞：CVE-2026-64265	high
329950	Linux Distros 未修补的漏洞：CVE-2026-64437	high
329949	Linux Distros 未修补的漏洞：CVE-2026-64311	high
329948	Linux Distros 未修补的漏洞：CVE-2026-64472	high
329947	Linux Distros 未修补的漏洞：CVE-2026-64475	high
329946	Linux Distros 未修补的漏洞：CVE-2026-64299	high
329945	Linux Distros 未修补的漏洞：CVE-2026-64424	high
329944	Linux Distros 未修补的漏洞：CVE-2026-64428	medium
329943	Linux Distros 未修补的漏洞：CVE-2026-64466	medium
329942	Linux Distros 未修补的漏洞：CVE-2026-64327	medium
329941	Linux Distros 未修补的漏洞：CVE-2026-64455	high
329940	Linux Distros 未修补的漏洞：CVE-2026-64511	medium
329939	Linux Distros 未修补的漏洞：CVE-2026-64286	high
329938	Linux Distros 未修补的漏洞：CVE-2026-64368	high
329937	Linux Distros 未修补的漏洞：CVE-2026-64468	high
329936	Linux Distros 未修补的漏洞：CVE-2026-64383	critical
329935	Linux Distros 未修补的漏洞：CVE-2026-64499	high
329934	Linux Distros 未修补的漏洞：CVE-2026-64447	high
329933	Linux Distros 未修补的漏洞：CVE-2026-64264	medium
329932	Linux Distros 未修补的漏洞：CVE-2026-64358	medium
329931	Linux Distros 未修补的漏洞：CVE-2026-64419	medium
329930	Linux Distros 未修补的漏洞：CVE-2026-64481	high
329929	Linux Distros 未修补的漏洞：CVE-2026-64281	high
329928	Linux Distros 未修补的漏洞：CVE-2026-64403	high
329927	Linux Distros 未修补的漏洞：CVE-2026-64332	medium

检测

Nessus 的 Misc. 系列

critical

high

high

high

medium

medium

high

medium

medium

medium

medium

critical

high

medium

high

medium

high

high

high

medium

high

high

high

high

high

high

high

high

high

high

high

high

medium

medium

medium

high

medium

high

high

high

critical

high

high

medium

medium

medium

high

high

high

medium