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

  - 在 libcupsfilters 和 cups-filters 中发现一个缺陷。PNG 图像读取函数在未安装错误恢复处理程序的情况下创建 libpng 阅读器，从而导致 CUPS 图像过滤器进程在处理畸形 PNG 文件时中止。未经身份验证的攻击者可通过提交特制的 PNG 打印作业来利用此漏洞，导致正在传输的打印作业拒绝服务。（CVE-2026-64612）

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

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

  - scsi：scsi_transport_fc：将 FPIN pname 遍历器计数器加宽至 u32 可将 FPIN ELS 帧传送给 lpfc 或 qla2xxx Linux 发起程序的相邻光纤通道结构执行者可在通用 FC 传输中触发不返回。这并非本地用户空间或 IP 网络路径;攻击者必须能够注入结构流量，例如作为遭入侵的交换机或结构控制器，或作为允许源欺骗的结构上的同区N_Port注入。Link-Integrity 和 Peer-Congestion FPIN 遍历器对 32 位线上pname_count字段使用 u8 循环计数器，并且不pname_count TLV 遍历器已验证的描述符正文约束。因此，pname_count 256 封装计数器并无限期地保持循环条件为 true。将共享 pname_list[] 遍历分解到一个帮助程序中，将计数器加宽为 u32，并在迭代之前根据适合描述符正文的条目钳制pname_count。
    (CVE-2026-63889)

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

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

  - sctp：修复等待关联达到 ESTABLISHED 状态时，sctp_wait_for_connect和剥离之间的争用 sctp_wait_for_connect（） 丢弃和重新获取套接字锁定。在此窗口期间，另一个线程可以通过 getsockopt（SCTP_SOCKOPT_PEELOFF） 解除与新套接字的关联，进而更改 asoc->base.sk。重新获取旧套接字锁后，sctp_wait_for_connect（） 返回成功但不会注意迁移，调用程序随后会访问 sctp_datamsg_from_user（） 中错误锁定下的关联。添加 sctp_wait_for_sndbuf（） 已进行的相同 sk ！= asoc->base.sk 检查，如果在我们睡觉时迁移关联，则会返回错误。（CVE-2026-63971）

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

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

  - ksmbd：修复 proc_show_files（） 中的空指针取消引用 SMB2 客户端打开具有持久 v2 句柄的文件然后发出 SMB2 SESSION_LOGOFF时，session_fd_check（） 清除可重新连接文件指针上的 fp->tcon = NULL，但将 fp 保留在 global_ft.idr 中注册，直到持久清理程序触发（最多 fp->durable_timeout 秒后）。在该窗口期间，对 /proc/fs/ksmbd/files（模式 0400）的任何读取都会造成内核错误，因为 proc_show_files（） global_ft遍历 .idr 并无条件取消引用不含 NULL 保护的 fp->tcon->id。复制程序只需要成功的 SMB2 SESSION_SETUP和配置为“durable handles = yes”的共享。关于干线 70390501d194 的 KASAN 报告：一般保护错误，可能针对非规范地址 0xdffffc0000000000：0000 [#1] SMP KASAN PTI KASA：范围 [0x0000000000000000-0x0000000000000007] 中的 null-ptr-deref RIP：0010：proc_show_files+0x118/0x740 调用跟踪：
    proc_show_files+0x118/0x740 seq_read_iter+0x4ef/0xe10 proc_reg_read_iter+0x1b7/0x280 ... 保护取消引用。持久断开连接的 fp 合法地没有 tcon;报告其树 id 为 0 而不是 oopsing。（CVE-2026-64140）

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

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

  - hwmon：（pmbus/adm1266） 拓宽 blackbox-info 缓冲区以 I2C_SMBUS_BLOCK_MAX adm1266_nvmem_read_blackbox（） 声明一个 5 字节堆栈缓冲区，并将其传递给 i2c_smbus_read_block_data（） 以检索 4 字节BLACKBOX_INFO响应。i2c_smbus_read_block_data（） 未遵从调用程序缓冲区大小 -- 它会从 SMBus 事务 memcpy（） 的 data.block[0] 字节（其中 data.block[0] 是从设备返回的长度字节，最多 I2C_SMBUS_BLOCK_MAX = 32）：memcpy（values， &data.block[1]， data.block[0]）;如果设备返回任何超过 5 的块长度，则调用在调用后 if （ret ！= 4） 返回 -EIO 之前溢出调用者的 5 字节堆栈缓冲区;check 有机会拒绝响应。扩大本地缓冲区以I2C_SMBUS_BLOCK_MAX以便帮助程序为任何格式良好的 SMBus 区块响应提供空间，从而符合此驱动程序中其他 i2c_smbus_read_block_data（） 调用程序使用的约定。（CVE-2026-64135）

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

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

  - 恢复 f2fs：从 move_data_block 中的页面缓存删除非最新的作品集 这会恢复提交 9609dd704725a40cd63d915f2ab6c44248a44598。不断报告内核错误，尤其是当 f2fs 分区几乎已满时。经过调查，我们发现原因是将一个 f2fs 页面释放给 buddy 但未从 LRU 删除，根本原因是此提交注册的 [2] 中发生了争用。这种情况下有 3 个比赛过程，请在下面找到它们的主要活动。move_data_block（） 中更改的代码允许 GC 路径通过 folio_end_dropbehind（） 从页面缓存中逐出尾端作品集。folio_unmap_invalidate（） 从 mapping->i_pages 中删除作品集后，将删除该作品集中所有页面的页面缓存引用。然后，该作品集仅通过临时外部引用保持活动状态，这允许以后的拆分操作子页面不再受页面缓存引用保护的作品集。页面缓存引用消失后，split_folio_to_order（） 可将大作品集拆分为单独的页面，并将生成的子页面放回 LRU 上。对于 EOF 之外的尾页，split 会将其从页面缓存中删除并丢弃其页面缓存引用。然后，尾页可保留在具有PG_lru集的 LRU 上，同时仅保留拆分调用程序的临时引用。当 free_folio_and_swap_cache（） 丢弃该最终引用时，页面将进入最终 folio_put（） 释放路径。同时，folio_isolate_lru（） 可以观察到具有非零引用计数和PG_lru集的同一尾页。它会先清除PG_lru，然后再进行自己的引用。如果这与拆分路径中的最终 folio_put（） 争用，则 __folio_put（） 会看到PG_lru已清除并跳过 lruvec_del_folio（）。然后，当 LRU 列表中仍然存在该页面的 lru 链接时，该页面将释放回分配器。相邻页面上稍后的 LRU 操作会检测到过时链接并报告列表损坏情况。[1] [ 22.486082] list_del损坏。
    next->prev 应为 fffffffec10e0ac8，但已死亡0000000000122。（next=fffffffec10e0a88） [ 22.486130]
    ------------[ cut here ]------------ [ 22.486134] lib/list_debug.c：67 处的内核缺陷！[ 22.486141] 内部错误：错误 - 缺陷：00000000f2000800 [#1] SMP [ 22.488502] 受感染：[W]=WARN，[O]=OOT_MODULE [ 22.488506] 硬件名称：展讯 UMS9230 1H10 SoC （DT） [ 22.488511] pstate：604000c5 （nZCv daIF +PAN -UAO -TCO
    -DIT -SSBS BTYPE=--） [ 22.488517] pc： __list_del_entry_valid_or_report+0x14c/0x154 [ 22.488531] lr：
    __list_del_entry_valid_or_report+0x14c/0x154 [ 22.488539] sp：ffffffc08006b830 [ 22.488542] x29：
    ffffffc08006b868 x28： 0000000000003020 x27： 0000000000000000 [ 22.488553] x26： 0000000000000000 x25：
    0000000000000004 x24： fffffffec10e0ac0 [ 22.488564] x23： 00000000000000e8 x22： 0000000000000024 x21：
    dead0000000000122 [ 22.488574] x20： fffffffec10e0a88 x19： fffffffec10e0ac8 x18： ffffffc080061060 [22.488585] x17： 20747562202c3863 x16： 6130653031636566 x15： 0000000000000058 [ 22.488595] x14：
    0000000000000004 x13： ffffff80f91e0000 x12： 0000000000000003 [ 22.488605] x11： 0000000000000003 x10：
    0000000000000001 x9 ： ffe85721f0e25f00 [ 22.488615] x8 ： ffe85721f0e25f00 x7 ： 000000000000000 x6：
    6c65645f7473696c [ 22.488625] x5 ： ffffffed39b23026 x4 ： 0000000000000000 x3 ： 0000000000000010 [22.488636] x2 ： 0000000000000000 x1 ： 0000000000000000 x0 ： 000000000000006d [ 22.488647] 调用跟踪： [22.488651] __list_del_entry_valid_or_report+0x14c /0x154 （P） [ 22.488661] __folio_put+0x2bc/0x434 [22.488670] folio_put+0x28/0x58 [ 22.488678] do_garbage_collect+0x1a34/0x2584 [ 22.488689] f2fs_gc+0x230/0x9b4 [ 22.488697] f2fs_fallocate+0xb90/0xdf4 [ 22.488706] vfs_fallocate+0x1b4/0x2bc [22.488716] __arm64_sys_fallocate+0x44/0x78 [ 22.488725] invoke_syscall+0x58/0xe4 [ 22.488732] do_el0_svc+0x48/0xdc [ 22.488739] el0 ---truncated--- （CVE-2026-63813）

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

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

  - drm/amdgpu/vcn：设置 VCN v4.0.5 enc 环的no_user_fence VCN 编码器和解码器环不支持 64 位用户隔离写入，拒绝带有用户隔离的 CS 提交。（从提交 084d94ac93707bdda07efb5cee786f632de4219b 中精选出的内容）（CVE-2026-63851）

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

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

  - block：bio-integrity：修复 bio_integrity_map_user（） 中的 null-ptr-deref pin_user_pages_fast（） 可部分成功并返回实际固定的页数。但是，bio_integrity_map_user（） 不会处理此部分固定。这会导致一般保护错误，因为 bvec_from_pages（） 会取消引用未固定的页面地址，即 0。若要修复此问题，请添加检查以验证所有请求的内存是否已固定。如果发生部分固定，请取消固定内存并返回 -EFAULT。Kernel Oops: Oops:
    一般保护错误，可能针对非规范地址 0xdffffc0000000001：0000 [#1] SMP KASAN NOPTI KASAN：范围内的 null-ptr-deref [0x0000000000000008-0x000000000000000f] CPU：0 UID：0 PID：1061 通信：nvme-passthroug 未受感染 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT（lazy） 硬件名称：QEMU Standard PC （i440FX + PIIX，1996），BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 2014 年 4 月 1 日 RIP：
    0010：bio_integrity_map_user.cold+0x1b0/0x9d6 （CVE-2026-64052）

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

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

  - USB：serial：omninet：修复小端点的内存损坏 确保批量输出缓冲区至少与硬编码传输大小一样大，以避免在恶意设备报告端点数据包大小大于预期时造成用户控制的 slab 损坏。（CVE-2026-63928）

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

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

  - scsi：isci：修复设备删除路径中的释放后使用 ISCI 完成 tasklet 在 isci_host_alloc（） （drivers/scsi/isci/init.c：496） 中初始化，并从 MSI-X 和旧中断处理程序 （drivers/scsi/isci/host.c：223,613） 进行计划。isci_host_deinit（） 会停止控制器并等待停止完成，但在继续拆卸之前，它永远不会终止completion_tasklet。功能顶部的 tasklet_kill（） 在这里是不够的：中断仅在 isci_host_stop_complete（） 运行时禁用，因此在 wait_for_stop（） 返回之前，IRQ 处理程序仍然可以重新排队 tasklet。tasklet 回调还会在耗尽完成后重新启用中断，因此在源静默之前终止 tasklet 会使相同的争用处于悬而未决状态。返回 wait_for_stop（） 之后，就不会再发生 IRQ 驱动的计划。终止completion_tasklet，这样 teardown 就不会对在死 ihost 上运行的已排队的 tasklet 争用。在删除或卸载时，过时回调可在主机生命周期结束后取消引用 ihost 并接触 ihost->smu_registers。UML + KASAN 模拟在源静止之前不放置 tasklet_kill（） 和 tasklet_kill（） 的情况下再现故障类，并且在使计划源静默之后发生终止之后保持干净。这镜像提交 f6ab594672d4（scsi：aic94xx：修复设备删除路径中的释放后使用），但 ISCI 需要在 wait_for_stop（） 之后终止。（CVE-2026-64103）

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

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

  - net：hsr：修复监督帧处理中潜在的 OOB 访问 通过将 sizeof（struct hsr_sup_tlv） 添加到 pskb_may_pull s（） 调用，确保在访问前将整个 TLV 标头进行线性化。否则，截断的帧可造成越界访问。（CVE-2026-64000）

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

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

  - drm/amdgpu/jpeg：为 JPEG v4.0.3 环设置no_user_fence JPEG 环不支持 64 位用户屏蔽写入，拒绝带有用户屏蔽的 CS 提交。（从提交 2f6afc97d259d530f4f86c7743efbc573a8da927 中精选出的内容）（CVE-2026-63844）

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

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

  - virt：sev-guest：明确泄漏处于未知状态的页面 当 set_memory_{encrypted，decrypted}（） 失败时，用户无法知道函数在哪一点失败，这意味着从调用者的角度来看，页面将处于未知状态。由于页面可能处于未加密状态，因此不适合一般用途，且无法安全地返回到 buddy 分配器。通过永远不释放页面来避免此问题，然后通过调用 snp_leak_pages（） 进行适当的统计。（CVE-2026-64104）

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

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

  - Wire 为 Android、Kotlin、Swift 和 Java 提供 gRPC 和协议缓冲区。低于 6.3.0 7.0.0-alpha03 的 wire-runtime 中的 ByteArrayProtoReader32.skipGroup（） 和 ProtoReader.skipGroup（） 未在 skip（） 之前验证 LENGTH_DELIMITED 字段长度是否为非负值，从而允许构建的 protobuf varint 编码 -128 作为签名的 Int 使 skip（-128） 将内部位置移为负数并使下一个 readByte（） 抛出 ArrayIndexOutOfBoundsException，而不是记录的 IOException 或 ProtocolException， 其可在不受信任的负载上使用 ProtoAdapter.decode（byte[]） 的服务崩溃。此问题在版本 6.3.0 和 7.0.0-alpha03 中已修复。（CVE-2026-45799）

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

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

  - kho：跳过因崩溃而导致的 KHO 内核 kho_fill_kimage（） 会无条件地使用每个 kexec 镜像类型的 KHO 元数据填充 kimage。当镜像是崩溃内核时，这可能会产生问题，因为崩溃内核可在较小的保留区域中运行，而 KHO 擦除区域可能位于其外部。随后，当崩溃内核尝试对 KHO FDT 地址进行 phys_to_virt（） 时，会在 kho_memory_init（） 期间发生错误：无法处理虚拟地址 xxxxxxxx 的内核分页请求...fdt_offset_ptr+...fdt_check_node_offset_+...
    fdt_first_property_offset+...fdt_get_property_namelen_+...fdt_getprop+...kho_memory_init+...
    mm_core_init+...start_kernel+...kho_locate_mem_hole（） 已跳过 KEXEC_TYPE_CRASH 图像的 KHO 逻辑，但 kho_fill_kimage（） 缺少相同的防护。由于 kho_fill_kimage（） 是填充 image->kho.fdt 和 image->kho.scratch 的单点，因此对于 arm64 和 x86 进行修复已足够，因为当这些字段未设置时，FDT 和 boot_params 路径将退出。（CVE-2026-64167）

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

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

  - nfc：hci：修复了 HCP 标头解析中的越界读取 nfc_hci_recv_from_llc（） 和 nci_hci_data_received_cb（） 在函数条目时从 skb->data 读取 packet->header，而无需首先检查缓冲区是否至少占有一字节。恶意的 NFC 对等机可发送 0 字节的 HCP 帧，该帧会经过 SHDLC 层并到达这些函数，从而导致 packet->header 的越界堆读取。
    如果作为非最终片段排队，同一个 0 字节帧也会造成重组循环下溢msg_len UINT_MAX，进而在写入重组的 skb 时触发 skb_over_panic（）。通过在首次访问 packet->header 之前在每个函数的条目添加 pskb_may_pull（） 检查来修复此问题。重组的 hcp_skb 被转换为结构hcp_packet之前的现有 pskb_may_pull（） 检查保留在原位以保护 2 字节 HCP 消息标头。（CVE-2026-63915）

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

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

  - drm/amdgpu/vcn：设置 VCN v4.0.3 enc 环的no_user_fence VCN 编码器和解码器环不支持 64 位用户隔离写入，拒绝带有用户隔离的 CS 提交。（从提交 ff1a5a125c5a70c328806b9bc01d7d942cf3f9aa 中精选出的内容）（CVE-2026-63852）

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

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

  - KVM：arm64：vgic：分配后 init 失败时释放private_irqs 提交 250f25367b58 的伙伴（KVM：arm64：在创建 vCPU 失败时撤销 vGIC），从而将缺失的 kvm_vgic_vcpu_destroy（） 调用添加到 kvm_arch_vcpu_create（） 中的 kvm_share_hyp（） 失败路径。其正上方的 kvm_vgic_vcpu_init（） 失败路径具有相同的形状，但仍需要相同的清理。当 kvm_vgic_vcpu_init（） 失败时调用 kvm_vgic_vcpu_destroy（），以便在释放失败的 vCPU 之前释放在再分发器 iodev 注册失败之前分配的私有 IRQ。（CVE-2026-64105）

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

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

  - scsi：target：iscsi：修复 iscsit_handle_text_cmd（） 中的 CRC 越界读取和双重释放 文本阶段处理程序中存在两个潜在缺陷，均自提交 e48354ce078c 中的原始 LIO 集成以来出现 （iscsi-target：
    为目标 v4.1 添加 iSCSI 结构支持：1） DataDigest CRC 缓冲区越界读取（4 字节超过text_in）。
    text_in在 ALIGN（payload_length， 4） 上是 kzalloc（） 的。然后，rx_size会通过 ISCSI_CRC_LEN递增，以便为 iovec 中接收的 DataDigest 腾出空间，但是会将相同的（现已升级的）rx_size作为缓冲区长度传递给 iscsit_crc_buf（）：if （conn->conn_ops->DataDigest） { ...rx_size += ISCSI_CRC_LEN;} ...if （conn->conn_ops->DataDigest） { data_crc = iscsit_crc_buf（text_in， rx_size， 0， NULL）; iscsit_crc_buf（） 使用 crc32c（） 遍历 rx_size 个字节的 text_in，因此在协商 DataDigest 时，它会读取超过 text_in 分配结尾的 4 个字节。KASAN 会在未经修补的主线树中直接将此情况再现为从文本 PDU 路径调用的 crc32c（） 中的 slab-out-of-bound。OOB 字节馈送 crc32c（），然后与发起程序提供的校验和进行比较，因此该值不会流回攻击者，但内核会读取 DataDigest=CRC32C 的每个文本 PDU 上的缓冲区。通过传递用于 kzalloc（） 的实际填充负载长度 （ALIGN（payload_length， 4）） 进行修复。2） ERL>0 错误的 DataDigest 终止时过时的 cmd->text_in_ptr 重新释放（双重释放）。当 DataDigest 与 ErrorRecoveryLevel > 0 不匹配时，处理程序静默终止 PDU，让发起程序填补 CmdSN 间隙：kfree（text_in）;返回 0;
    cmd->text_in_ptr仍指向已释放的缓冲区。同一 ITT 上的下一个文本请求会重新输入 iscsit_setup_text_cmd（），这将无条件地执行 kfree（cmd->text_in_ptr）;cmd->text_in_ptr = NULL;
    再次释放同一指针。如果在第二个文本请求到达前断开连接，通过 iscsit_release_cmd（） 进行的会话破坏具有相同的形状并命中相同的双重释放。在未修改的主线树状结构中，bug-1 CRC 越界读取首先会在初始有效文本请求中触发，随后的状态受到干扰，因此 #4 通过构建内核仅应用了此修补程序的 bug-1 hunk，加上三个相关 kfree（） 站点周围的临时 printk（） 可观察性，进行了隔离。可观察性打印不是此修补程序的一部分。在该版本中，登录后的三个 PDU 文本请求序列会产生两个背靠背的 splats：缺陷：KASAN：iscsit_setup_text_cmd+0x 中的双重释放？？缺陷：KASAN：iscsit_release_cmd+0x 中的双重释放？？在 ERL>0 终止路径中再次显示释放的相同指针，然后在 iscsit_setup_text_cmd（） 中（同一 ITT 上的下一个文本请求）中再次显示释放的指针，在 iscsit_release_cmd（） 中再次显示一次（会话拆卸）。在 CONFIG_SLAB_FREELIST_HARDENED=y（默认）的 distro 内核上，双重释放变成远程内核 BUG（）;在非强化内核上，它会损坏 slab 空闲列表。通过清除 ERL>0 终止路径中 kfree（） 之后的 cmd->text_in_ptr 修复。应用 #4 了两个 hunk 之后，在没有可观测性 printk 的情况下直接在库存树上观察到;单独修复 bug-1 将减少（而不是更多）掩盖 #4 ，因此将一起提交 hunk。这两个补丁都是俏皮话。文本 PDU 状态机未更改，线路协议不受影响。（CVE-2026-63888）

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

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

  - arm64：tlb：取消共享 PMD 表时刷新 walk 缓存 调用 huge_pmd_unshare（） 以取消共享 PMD 表时，tlb_unshare_pmd_ptdesc（） 函数将设置 tlb->unshared_tables=true，但是 aarch64 tlb_flush（） 仅检查 tlb->freed_tables 以确定是使用 TLBF_NONE（vae1is，使 walk 缓存无效）还是 TLBF_NOWALKCACHE（vale1is， leaf-only）。这导致过时的 PMD 页表条目在取消共享之后保留在 walk 缓存中，从而可能导致错误的页表 walk。通过在检查中包括 unshared_tables 进行修复，以便在取消共享表时，使用 TLBF_NONE 并正确地使 walk 缓存失效。
    以下是 vae1is 和 vale1is 之间的详细区别： |指令组合 |实际失效范围 | |------------------------ |--------------------------------------------------| |“VAE1IS”+ TTL=“0” |所有级别的所有条目（完全无效）| |'VAE1IS' + TTL='2' （L2） |0/1 层的非叶子 + 2 层的叶子 | |“VALE1IS”+ TTL=“0” |所有级别的叶条目（未清除非叶）| |'VALE1IS' + TTL='2' （L2） |仅限 2 层的叶子入口 |（CVE-2026-63875）

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

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

  - net：shaper：重做 VALID 标记（再次） 最近的提交将语义从 NOT_VALID 更改为 VALID。
    我没有意识到这些标志不是与 XArray 中的条目一起以原子方式存储的。仍然存在争用：读取器观察插槽的 VALID 标记、被中断、写入器将条目替换为不同的条目、读取器继续、获取条目（现在的指针与 VALID 的指针不同）。这样做的最大后果是，由于 net_shaper_rollback（） 假设可在不观察 RCU 的情况下释放不含 VALID 的条目，我们可能会看到 UAF。看起来 XArray 标记目前并没有给我们带来任何好处。让我们将代码转换为显式有效字段。
    smp_load_acquire（） / smp_store_release（） 屏障稍微干净一些。（CVE-2026-64027）

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

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

  - batman-adv：tt：修复负值 tt_buff_len batadv_orig_node：：tt_buff_len 声明为 s16，但该字段从未打算包含负值。当分配大于 32767 的值时，该值将封装为负有符号的整数。在 batadv_send_other_tt_response（） 中，tt_buff_len暂时扩大到 s32。
    不正确的负值 s16 会传播到 s32，造成 batadv_tt_prepare_tvlv_global_data（） 分配完整大小的缓冲区，但收集的变更集仅填充其中的一小部分。所有剩余位保持未初始化。使用 u16 可避免这种类型混淆并确保不会在 batadv_send_other_tt_response（） 中执行任何（负）符号扩展。（CVE-2026-64088）

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

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

  - pds_core：修复 pdsc_devcmd_wait 中的错误处理 修复 pdsc_devcmd_wait（） 从完成寄存器返回过时的成功而非错误的两种情况： 1. 固件崩溃：如果固件停止运行，等待循环将提早中断，并出现 running=false。条件 if （（！done || timeout） &; &; running） 为 false，因此绕过错误处理并返回过时状态。首先检查 ！running 并返回 -ENXIO。2.
    超时：如果某个命令超时，则 err 将设置为 -ETIMEDOUT，但随后被读取过时状态的 pdsc_err_to_errno（status） 覆盖。清除后立即返回 -ETIMEDOUT。这两个错误现在都会传播到 pdsc_devcmd_locked（），后者health_work排队等待恢复。（CVE-2026-64148）

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

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

  - spi：sprd：修复 DMA 设置失败后的错误指针取消引用 如果探测期间 DMA 设置失败，驱动程序会回退到 PIO 模式。在尝试释放 DMA 通道之前，确保检查 dma.enabled 标记，以及发生延迟探测错误时也是如此，以避免取消引用错误指针（或尝试再次释放通道）。Sashiko 在查看 devres 分配转换修补程序时标记了此问题。
    (CVE-2026-64168)

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

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

  - net： ethernet： cortina： 进位碎片计数器 gmac_rx（） NAPI 轮询函数从环形缓冲区将数据包组装到 SKB 中。如果环形缓冲区在轮询周期中完全清空，我们退出 gmac_rx（），但数据包尚未在 SKB 中完全组装，但片段计数器frag_nr在下次调用时重置为零。通过使 RX 片段计数器成为端口结构的一部分并在调用之间继承它来解决此问题。仅在调用 napi_gro_frags（） 后）、出错时（调用 napi_free_frags（） 后）或停止端口时立即重置拆分计数器。在非绝对必要的某个位置将其重置，只是为了强调正在发生的事情。这是 Sashiko 在正常修补程序审查期间发现的。（CVE-2026-64055）

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

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

  - Bluetooth：L2CAP：修复 l2cap_ecred_conn_rsp 上可能发生的崩溃 如果为已分配的目标 CID 接收到 dcid，规范要求同时丢弃两个通道，但调用 l2cap_chan_del 可能会使 list_for_each_entry_safe 创建的 tmp 光标失效，事实上这是错误的过程，因为之前可能已分配 chan->dcid，但实际上需要断开连接。直接调用 l2cap_chan_clone 仍可能导致l2cap_chan_del因此，请改为将延迟为 0 的l2cap_chan_timeout计划为异步关闭通道。（CVE-2026-63975）

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

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

  - media：rzv2h-ivc：修复并发缓冲区列表访问 缓冲区列表 （'rzv2h_ivc：：buffers.queue'） 受旋转锁 （'rzv2h_ivc：：buffers.lock'） 保护。但是，在独立工作队列中运行的“rzv2h_ivc_transfer_buffer（）”中，会在未保持旋转锁的情况下执行“list_del（）”调用，这可能导致列表被同时修改 通过从受锁定保护部分的列表中删除缓冲区来修复此问题。[根据 Barnabas 的报告，在重要部分分配 ivc->buffers.curr]（CVE-2026-53380）

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

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

  - netfilter：synproxy：在 skb_ensure_writable synproxy_tstamp_adjust（） 就地重写 TCP 时间戳选项然后通过调用程序提供的 tcphdr 指针上的 inet_proto_csum_replace4（） 修补 TCP 校验和后，刷新 tcphdr。ipv4_synproxy_hook（） 和 ipv6_synproxy_hook（） 都会在调用之前通过 skb_header_pointer（） 获取该指针，因此它可以直接将 skb->head 别名或指向调用方的堆栈上的_tcph缓冲区。在获取指针和使用它之间，该函数调用 skb_ensure_writable（skb， optend），后者在克隆的或非线性 skb 上调用 pskb_expand_head（） 并释放旧的 skb->head。过后缓存的 th 过时： caller （ipv[46]_synproxy_hook） th = skb_header_pointer（skb， ...， &_tcph） synproxy_tstamp_adjust（skb， protoff， th， ...） skb_ensure_writable（skb， optend） pskb_expand_head（） /* kfree（old skb->head） */ ...
    inet_proto_csum_replace4（&th->check， ...） /* 写入释放的 head，或写入调用程序的堆栈副本，使在线校验和过时 */ 选项字节通过 skb->data 写入，没有问题;只有校验和更新会通过 th，因此会到达错误的位置。结果是写入已释放的 slab 内存或数据包留下与其负载不匹配的校验和。通过在 skb_ensure_writable（） 成功后立即从 skb->data + protoff 重新派生 th 来修复，以便后续校验和更新以线性可写标头为目标。（CVE-2026-64007）

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

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

  - net/mlx5e：修复 mlx5e_safe_reopen_channels（） 拆散并释放通道（及其嵌入式 SQ）后，mlx5e_tx_reporter_timeout_recover mlx5e_tx_reporter_timeout_recover（） 访问 sq->netdev 中的释放后使用。将三个 sq->netdev 引用替换为 priv->netdev，这样是安全的，因为 priv 的寿命比通道拆卸更耐用。因此，netdev_err（） 调用已使用 priv->netdev;使 trylock/unlock 和 health_channel_eq_recover 调用保持一致。这修复了以下 KASAN SPLAT：缺陷：
    KASAN：mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 中的释放后使用 [mlx5_core] 任务 kworker/u113：2/5277 在地址 ffff889860ed0b28 读取大小为 8 调用跟踪：mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core] devlink_health_reporter_recover+0xa2/0x150 devlink_health_report+0x254/0x7c0 mlx5e_reporter_tx_timeout+0x297/0x380 [mlx5_core] mlx5e_tx_timeout_work+0x109/0x170 [mlx5_core] process_one_work+0x677/0xf20 worker_thread+0x51f/0xd90 kthread+0x3a5/0x810 ret_from_fork+0x208/0x400 ret_from_fork_asm+0x1a/0x30 （CVE-2026-64122）

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

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

  - netfilter：nft_inner：重新启用 softirqs 前释放 local_lock 引用 sashiko： 在错误路径中，local_bh_enable（） 在 local_unlock_nested_bh（） 之前调用。（CVE-2026-64150）

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

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

  - net：mana：跳过已分离端口上的冗余分离 mana_per_port_queue_reset_work_handler（） 在前一个分离成功但附加失败后运行时，端口会处于已释放 apc->tx_qp 和 apc->rxqs 的分离状态。再次无条件调用 mana_detach（） 会导致队列拆卸期间的空指针取消引用。当端口已处于分离状态时，在 mana_detach（） 中为非密切呼叫者添加提前退出 （！netif_device_present），使其能够安全地进行幂等调用。这允许队列重置处理程序和其他恢复路径可以简单地重试 mana_attach（），而无需冗余拆卸。（CVE-2026-63972）

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

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

  - RDMA/siw：签名接收匹配之前拒绝 MPA FPDU 长度下溢 恶意连接的 siw 对等机可发送其 MPA 长度字段（c_hdr->mpa_len，16 位大端，对等控制）小于已宣布操作码的固定 DDP/RDMAP 标头的 iWARP FPDU。Soft-iWARP 根据 iwarp_pktinfo[opcode] .hdr_len解析 siw_get_hdr（） 中的完整标头，但从不比较mpa_len与该标头长度。然后，siw_tcp_rx_data（） 派生出 srx->fpdu_part_rem = be16_to_cpu（mpa_len） - fpdu_part_rcvd + MPA_HDR_SIZE;此时fpdu_part_rcvd等于 iwarp_pktinfo[opcode].hdr_len。对于标记的 WRITE （hdr_len 16， MPA_HDR_SIZE 2），线上最小mpa_len 0 会产生 fpdu_part_rem = -14，任何低于 hdr_len - MPA_HDR_SIZE 的mpa_len都会下溢至负 int。然后，有符号的值流入 siw_proc_write（）/siw_proc_rresp（），因为 bytes = min（srx->fpdu_part_rem， srx->skb_new）;作为 int len 传递给 siw_check_mem（）（len 为负时，满足其间隔检查 addr + len > mem->va + mem->len 的有效基数），并达到 siw_rx_data（） -> siw_rx_kva（） / siw_rx_umem（） -> skb_copy_bits（） 作为已签名副本长度。skb_copy_bits（） 中的标头复制分支将其升级为 size_t，从而产生数 GB 的读取。驱动实际内核 TCP 接收路径的 KUnit 线程下的 KASAN -- socketpair AF_INET环回、通过 kernel_sendmsg 写入的畸形 FPDU、sk_data_ready在 softirq 中触发、tcp_read_sock分派到 siw_tcp_rx_data -- 报告： 缺陷：KASAN：地址 ffff888 处大小为 4294967295 的 skb_copy_bits+0x284/0x480 读取中的释放后使用... 调用跟踪：
    skb_copy_bits siw_rx_kva siw_rx_data siw_check_mem siw_proc_write siw_tcp_rx_data __tcp_read_sock siw_qp_llp_data_ready tcp_data_ready tcp_data_queue 在完全组装对等机标头的最早点添加缺少的不变量。iwarp_pktinfo[*].hdr_len - MPA_HDR_SIZE正是 SIW 发送器用作每个操作码的最小mpa_len值 （drivers/infiniband/sw/siw/siw_qp.c：33），因此这与协议契约相匹配。超出范围的 FPDU 终止连接时有 TERM_ERROR_LAYER_LLP / LLP_ETYPE_MPA / LLP_ECODE_FPDU_START -- 这是 RFC 5044 第 8 节错误代码 3（标记和 ULPDU 长度字段对 FPDU 的启动不一致），此不一致的正确帧错误类。
    (CVE-2026-64102)

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

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

  - ovpn：修复删除接口与添加新对等机之间的争用 删除现有 ovpn 接口时，有一个非常窄的窗口，通过 netlink 添加新的对等机可导致网络设备挂起并阻止其取消注册。此问题可能在 ovpn_dellink（） 期间发生，此时所有现有对等机都已释放，设备已排入队列等待注销，但添加新的对等机时出现CMD_PEER_NEW消息，该消息再次引用到 netdev。此时没有办法释放设备，因为我们假设所有对等机都已释放。当已从 netdev 列表中删除 netdevice 时，通过释放 ndo_uninit（） 中的所有对等机来修复争用条件。此外，ovpn_peer_add（） 现在具有一项额外检查，可在设备reg_state未注册时强制函数退出。这样，任何与接口删除例程争用的传入CMD_PEER_NEW都会在添加对等机之前停止。请注意，在按住netdev_lock时会进行上述检查，以防止争用 netdev 状态变更。ovpn_dellink（） 现在为空，可以将其删除。（CVE-2026-64043）

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

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

  - drm/msm/dpu：不混合使用 devm 和 drmm 函数 如果用户空间对 drm 设备保持引用，混合使用 devm 和 drmm 函数将在 msm 驱动程序拆卸时导致释放后使用： WB 连接器数据将因为使用 devm_kzalloc（）） 而遭到破坏，而用户仍然可以尝试与 WB 连接器交互（它使用drmm_函数）。更改 dpu_writeback_init（） 以使用 drmm_。Patchwork：
    https://patchwork.freedesktop.org/patch/722656/ (CVE-2026-64050)

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

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

  - nfsd：修复 nfsd4_create_file nfsd4_create_file（） 中的posix_acl泄漏和忽略的错误在其 ACL 处理中有两个缺陷： 静默地丢弃 nfsd4_acl_to_attr（） 的返回值。当 NFSv4 到 POSIX ACL 转换失败（例如，不受支持的 ACE 类型为 -EINVAL）时，将创建文件而不包含任何 ACL，且客户端会收到NFS4_OK。这违反了 RFC 7530/8881，该规定要求服务器拒绝 CREATE 中不受支持的属性。如果在 attrs 中填充 ACL 属性后（通过 nfsd4_acl_to_attr 或通过 open->op_dpacl/op_pacl 中的所有权转移），start_creating（） 发生故障时，函数会跳至跳过 nfsd_attrs_free（） out_write。posix_acl分配被泄漏。客户端可通过 OPEN（CREATE）、ACL 属性和无效文件名（例如，长度超过 NAME_MAX）重复触发此漏洞。
    通过捕获 nfsd4_acl_to_attr（） 返回值并更改早期错误路径以跳出而非out_write，这两者均进行了修复。将子初始化为 ERR_PTR（-EINVAL），以便即使从未联系过 start_creating（），也可以安全调用 end_creating（）。（CVE-2026-53396）

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

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

  - block：不覆盖 bio_integrity_copy_user（） 中的 bip_vcnt bio_integrity_add_page（） 已将 bounce 段的 bip_vcnt 设置为 1。通过 nr_vecs 中断 bip_vcnt <= bip_max_vcnt 对其进行覆盖（写入时bip_max_vcnt为 1），因此 block/blk.h 读取时的间隙合并检查会经过 flex 数组。bip_vec[] 读取时，读取在界内，但落在已保存用户 bvec 上，而非退回。已为拆分传播添加该行，但 bio_integrity_clone（） 未复制bip_vcnt并且BIP_CLONE_FLAGS排除BIP_COPY_USER。
    (CVE-2026-64053)

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

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

  - platform/x86：uniwill-laptop：即使强制也不启用充电限制 似乎在某些旧型号 （~2020） 上，电池充电限制可能会永久损坏电池。阻止用户通过 force 模块参数启用此功能，以免对此类设备造成永久性硬件损坏。（CVE-2026-64143）

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

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

  - mm/memory_hotplug：修复删除修补程序系列时的内存块引用泄漏 mm：修复内存块泄漏和锁定，v2。该系列修复了 hwpoison 计数器的两个内存块设备引用泄漏和一个锁定问题 per-memory_block 。此修补程序（共 2 个）：remove_memory_blocks_and_altmaps（） 使用 find_memory_block（） 查找每个内存块，（） 可获取对内存块设备的引用。此路径中永远不会丢弃该引用，从而在删除内存块及其 altmap 时导致设备引用泄漏。在删除内存块设备之前，请在检索 mem->altmap 并清除 mem->altmap 之后终止引用。（CVE-2026-64180）

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

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

  - IIO：gyro：adis16260：修复 write_raw 中的除以零 将采样频率值用作除数之前，先对其进行验证检查。用户向sampling_frequency sysfs 属性写入零会在内核中触发除零。（CVE-2026-63933）

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

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

  - drm/msm：修复 shrinker 死锁 在 Snapdragon X1 上PROVE_LOCKING和 VM 回收压力后，我们看到：
    ====================================================== 警告：检测到可能的循环锁定依赖关系 7.0.0-debug+ #43 受感染：G W ------------------------------------------------------ kswapd0/82 正在尝试获取锁定：ffff800080ec3870 （reservation_ww_class_acquire）{+.+.}-{0:0}， at：
    msm_gem_shrinker_scan+0x17c/0x400 [msm] 但任务已保持锁定： ffffc31709b263b8 （fs_reclaim）{+.+.}-{0:0}， at： balance_pgdat+0x88/0x988该锁定已经依赖于新锁定。 现有依赖关系链（顺序相反）为： -> #2 （fs_reclaim）{+.+.}-{0:0}：
    __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 fs_reclaim_acquire+0xd0/0xf0 dma_resv_lockdep+0x224/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20
    -> #1 （reservation_ww_class_mutex）{+.+.}-{4:4}： __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 dma_resv_lockdep+0x1a8/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20 -> #0 （reservation_ww_class_acquire）{+.+.}-{0:0}： check_prev_add+0x114/0x790 validate_chain+0x594/0x6f0
    __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 drm_gem_lru_scan+0x1ac/0x440 msm_gem_shrinker_scan+0x17c/0x400 [msm] do_shrink_slab+0x150/0x4a0 shrink_slab+0x144/0x460 shrink_one+0x9c/0x1b0 shrink_many+0x27c/0x5c0 shrink_node+0x344/0x550 balance_pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret_from_fork+0x10/0x20其他可能有助于我们调试此问题的信息： 链存在：reservation_ww_class_acquire --> reservation_ww_class_mutex --> fs_reclaim 可能的不安全锁定场景：CPU0 CPU1 ---- ---- lock（fs_reclaim）;
    锁（reservation_ww_class_mutex）;lock（fs_reclaim）;lock（reservation_ww_class_acquire）;DEADLOCK ** 由 kswapd0/82 保留的 1 个锁定： #0： ffffc31709b263b8 （fs_reclaim）{+.+.}-{0:0}， at： balance_pgdat+0x88/0x988 堆栈回溯： CPU： 4 UID： 0 PID： 82 通信： kswapd0 受感染： G W 7.0.0-debug+ #43 PREEMPT（full） 受感染：
    [W]=WARN 硬件名称：LENOVO 21BX0016US/21BX0016US，BIOS N3HET94W （1.66 ） 09/15/2025 调用跟踪：
    show_stack+0x20/0x40 （C） dump_stack_lvl+0x9c/0xd0 dump_stack+0x18/0x30 print_circular_bug+0x114/0x120 check_noncircular+0x178/0x198 check_prev_add+0x114/0x790 validate_chain+0x594/0x6f0
    __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 drm_gem_lru_scan+0x1ac/0x440 msm_gem_shrinker_scan+0x17c/0x400 [msm] do_shrink_slab+0x150/0x4a0 shrink_slab+0x144/0x460 shrink_one+0x9c/0x1b0 shrink_many+0x27c/0x5c0 shrink_node+0x344/0x550 balance_pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret_from_fork+0x10/0x20 fs_reclaim kswapd0 会调用 MSM shrinker， 调用dma_resv_lock。这反过来又会获得fs_reclaim。请改用 dma_resv_trylock（） 修复此死锁，并丢弃随后未使用的传递的等待缠绕锁定“票证”。修补程序： https://patchwork.freedesktop.org/patch/723564/ [rob：修复编译错误，将 lockdep 崩溃替换为 somethin ---truncated--- （CVE-2026-64100）

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

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

  - ARM：integrator：修复从提交 bdb249fce9ad4 开始的过早初始化（ARM：integrator：使用 syscon/regmap 的读取计数器），intcp_init_early 会调用 syscon_regmap_lookup_by_compatible，而后者又会调用 of_syscon_register。此函数分配内存。由于此时尚未初始化内存管理代码，因此调用总是失败。它返回 -ENOMEM 或崩溃，如下所示。读取时无法处理虚拟地址 0000000c 的内核空指针取消引用 [0000000c] *pgd=00000000 内部错误：错误：错误：5 [#1] ARM 模块链接：CPU：0 UID：0 PID：0 通信：swapper 未受感染 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT 硬件名称：ARM Integrator/CP（设备树） PC 位于
    __kmalloc_cache_noprof+0xec/0x39c LR 处于 __kmalloc_cache_noprof+0x34/0x39c ... 调用跟踪：
    从 of_syscon_register+0x7c/0x310 of_syscon_register 从 device_node_get_regmap+0xa4/0xb0 device_node_get_regmap 从 intcp_init_early+0xc/0x40 intcp_init_early 从 start_kernel+0x60/0x688 start_kernel 0x0 出现崩溃 出现崩溃的原因是取消引用指针，该指针不应为 NULL，但在内存管理子系统尚未初始化时为 NULL。__kmalloc_cache_noprof 并非所有 gcc 版本都出现崩溃。某些版本（例如 gcc 9.x ）显然不会取消引用指针，这可能是在禁用跟踪的情况下。已通过 gcc 10.x、 11.x和 13.x重现了此问题。无论哪种情况，如果未发现崩溃，对 syscon_regmap_lookup_by_compatible 的调用都会返回
    -ENOMEM，并且从不调用 sched_clock_register。通过将早期初始化代码移动到标准计算机初始化代码中来修复此问题。（CVE-2026-64165）

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

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

  - parport：修复端口与客户端注册之间的争用 parport 子系统在端口设备完全初始化之前对其进行注册，从而导致争用条件，其中客户端驱动程序（如 lp）可连接到未完全初始化甚至被拆散的端口。如果端口和客户端驱动程序构建为模块并在引导期间大约同时加载，这有时会导致崩溃。通过修补 parport_pc 进行失败探测，我能够在具有 PC 样式并行端口的 VM 中可靠地实现这一点：> --- a/drivers/parport/parport_pc.c > +++ b/drivers/parport/parport_pc.c > @@ -2069,7 +2069,7 @@ static struct parport *__parport_pc_probe_port（unsigned long int base， > if （！p） > goto out3; > > - base_res = request_region（base， 3， p->name）;> + base_res = NULL;>如果 （！base_res） > goto out4;>然后运行：while true;执行 modprobe lp 和 modprobe parport_pc等待 rmmod lp parport_pc完成几秒钟。
    从长远来看，我认为应该更改端口注册，以便将对 device_add（） 的调用放入 parport_announce_port（） 中，但由于后者当前不会失败，因此需要更改所有端口驱动程序。现在，添加一个标记以指示是否已公布端口，并且仅在设置该标记时才尝试将客户端驱动程序附加到端口。（CVE-2026-63942）

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

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

  - KVM：x86/mmu：在检查最大映射级别之前确保 hugepage 已按插槽运行。恢复阴影 MMU 中的 hugepage 时，*在*查询指定影子页面 gfn 的最大映射级别之前*，验证目标内存插槽中是否包含影子页面的基本 gfn。未能预先检查 gfn 的有效性，如果客户机创建了延伸到 memslot 边界以下的 hugepage 映射（在其 PTE 中），会导致对插槽lpage_info的越界访问（通常显示为主机 #PF，因为lpage_info为 vmalloc'd）。当客户机的内存中发生错误，并且客户机映射的大小大于 KVM（当前）的最大映射时，KVM 将创建一个直接的阴影页面（直接的原因是没有要遮蔽的 gPTE，因此目标 gfn 是给定影子页面的基础 gfn 的直接计算）。hugepage 恢复流会寻找此类直接阴影页面，例如在脏日志记录生成客户机>主机映射大小案例时强制 4KiB 映射。解除 4KiB 限制后，KVM 就可以将阴影页面替换为大型页面。但是，如果 KVM 最初使用的映射比客户机小，因为客户机 hugepage 覆盖的内存范围超出了 memslot 的边界，则 KVM 会将直接影子页面与用于在内存中发生错误的内存插槽边界之外的 gfn 链接。为叶映射添加的 rmap 条目正确且在界内，但叶 SPTE 父影子页的 gfn 将越界。缺陷：无法处理地址的页面错误：ffffc90000806ffc #PF：内核模式下的监督人读取访问权限 #PF：error_code（0x0000） - 不存在页面 PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops： Oops： 0000 [#1] SMP CPU： 13 UID：
    1000 PID：757 通信：mmu_stress_test 未受感染 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT 硬件名称：QEMU Standard PC （Q35 + ICH9， 2009），BIOS 0.0.0 02/06/2015 RIP：
    0010：kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] 调用跟踪： <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP： 0033：0x7f21c0f1a9bf </TASK> 不必费心预检查潜在 hugepage 的边界，即不要检查 sp->gfn + KVM_PAGES_PER_HPAGE（sp->role.level + 1） 等项是否也在内存插槽内，因为 kvm_mmu_max_mapping_level（） 执行的检查是基本边界检查的超集。也就是说，预先检查整个范围将是一个可疑的微优化。
    (CVE-2026-63807)

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

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

  - ethtool：tsinfo：准备失败时不将ERR_PTR传递给 genlmsg_cancel goto err 标签导致：
    genlmsg_cancel（skb、ehdr）;返回 ret;如果 ethnl_tsinfo_prepare_dump（） 失败，则其尚未启动 genlmsg。不存在可取消的内容，将错误指针传递到 genlmsg_cancel（） 将造成崩溃。
    (CVE-2026-63986)

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

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

  - bpf：从 lsm 可休眠挂钩中丢弃task_to_inode和inet_conn_established bpf_lsm_task_to_inode在 rcu_read_lock（） 下调用，bpf_lsm_inet_conn_established（） 从 softirq 上下文中调用），因此可休眠 LSM 程序无法使用这两个挂钩。（CVE-2026-63865）

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

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

  - scsi：fcoe：拒绝 CVL 遍历器中含零fip_dlen的 FIP 描述符 drivers/scsi/fcoe/fcoe_ctlr.c：：fcoe_ctlr_recv_clr_vlink（） 通过攻击者提供的fip_dlen推进描述符光标，而不需要默认分支中的 dlen >= sizeof（struct fip_desc）。named 描述符案例（FIP_DT_MAC、FIP_DT_NAME FIP_DT_VN_ID）会检查其各类型的最小长度，但FIP_DT_NON_CRITICAL描述符（fip_dtype >= 128，标准要求接收方静默忽略）完全跳过了该检查。通过发出一个单一描述符为 fip_dtype == FIP_DT_NON_CRITICAL 和 fip_dlen == 0 的 FIP CVL 帧，FCoE 控制 VLAN 上未经身份验证的 L2 对等机可无限期挂起 fcoe、qedf 或 bnx2fc 启动程序上的fcoe_ctlr_recv_work：光标每次迭代前进零字节，循环条件 rlen >= sizeof（*desc） 永远保持真， 阻断该控制器上每个后续 FIP 帧。加强外部 dlen 防护，以同时拒绝 sizeof（struct fip_desc） < dlen，以便在切换之前拒绝长度甚至无法覆盖描述符标头的畸形描述符。这与命名案例已应用的下限相同，并且是关闭循环的最小范围。（CVE-2026-63890）

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

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

  - scsi：target：iscsi：在 base64 解码之前验证CHAP_R长度 chap_server_compute_hash（） 将client_digest分配为 kzalloc（chap->digest_size），然后对于编码响应， BASE64chap_r直接传递到 chap_base64_decode（），而不检查输入长度是否可以产生超过 digest_size 字节的输出。 只要有输入要消耗，chap_base64_decode（） 就会无条件写入目的地。将 MAX_RESPONSE_LENGTH 设置为 128 并将 0b 前缀剥离为 extract_param（），解码器最多可有 127 个 base64 字符。127 个字符解码为 95 个字节。对于 SHA-256 （digest_size=32），这会client_digest 63 字节溢出;对于 MD5 （digest_size=16），溢出为 79 个字节。写入发生后触发第 344 行的长度检查。同一 switch 语句中的 HEX 分支已预先验证长度。对分支应用 BASE64 相同的方法：剥离结尾的 base64 填充字符，然后在调用解码器之前拒绝数据长度超过 DIV_ROUND_UP（digest_size * 4， 3） 的任何输入。在比较之前剥离后缀“=”会同时处理填充和未填充编码。chap_base64_decode（） 在“=”上已经提前返回，因此完整的原始字符串仍会以原样传递给解码器。相互 CHAP 路径将CHAP_C解码为 initiatorchg_binhex，即 kzalloc（CHAP_CHALLENGE_STR_LEN）。extract_param（） 将 initiatorchg 封装为 CHAP_CHALLENGE_STR_LEN 个字符，因此最多有 CHAP_CHALLENGE_STR_LEN-1 个 base64 字符到达解码器。最大解码大小 DIV_ROUND_UP（（CHAP_CHALLENGE_STR_LEN-1） * 3， 4） 小于 CHAP_CHALLENGE_STR_LEN，因此不可能发生溢出。在呼叫站点添加注释以记录这一点。（CVE-2026-63886）

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

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

  - 输入：usbtouchscreen - 将 NEXIO data_len/x_len 限制为 URB 缓冲区大小 nexio_read_data（） 从设备中断数据包中打包的 __be16 标头提取data_len和x_len，然后遍历 packet->data[0..x_len） 和 packet->data[x_len.。data_len） 比较每个字节和阈值。两个字段均为线上 16 位（最大 65535）。现有调整最多剃0x100/0x80，因此循环边界仍可达到大约0xfeff。NEXIO 的 URB 传输缓冲区是距 usb_alloc_coherent（） rept_size （1024） 字节，前 7 个字节由打包的标头占用，因此 packet->data[] 有 1017 个有效字节。read_data（） 回调未给定 urb->actual_length，并且没有其他任何限制遍历。与其长度有关的设备可能会通过一致的 DMA 分配获得 ~64 KiB 的越界读取。字节超过 NEXIO_THRESHOLD 的第一个索引位于 begin_x / begin_y 中，并从该处进入报告的触摸坐标，因此相邻的内核内存内容会作为ABS_X / ABS_Y事件泄漏到用户空间。在足够远的地方，读取还可能命中未映射的页面并发生错误。通过data_len限制到缓冲区的 data[] 容量并x_len到data_len，来修复所有这些问题。（CVE-2026-64014）

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

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

  - irq_work：修复 PREEMPT_RT 上 irq_work_single（） 中的释放后使用 在 PREEMPT_RT 上，非 HARD irq_work通过 run_irq_workd（） 在每个 CPU 的 kthreads 中运行，因此 irq_work_sync（） 使用 rcuwait（） 等待 BUSY==0。irq_work_single（） 通过 atomic_cmpxchg（） 清除 BUSY 之后，仍会取消引用 irq_work_is_hard（） 和 rcuwait_wake_up（） 的@work。在清除 BUSY 后进入的其他 CPU 上的 irq_work_sync（） 调用程序可立即观察 BUSY==0，在这些访问完成前返回并释放工作，从而造成释放后使用。
    通过将 run_irq_workd（） 封装在 guard（rcu）（） 中来修复此问题，以便整个 irq_work_single（） 执行都在 RCU 读取端关键部分内。然后在 rcuwait_wait_event（） 之后的 irq_work_sync（） 中添加 synchronize_rcu（），以确保调用程序在返回前会等待 RCU 宽限期，从而防止过早释放。（CVE-2026-64073）

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

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

  - drm/gem：修复 change_handle 和 handle_delete drm_gem_change_handle_ioctl 之间的争用，在 spin_unlock（table_lock） 与最终 spin_lock（table_lock） 之间的时窗期间，IDR 中保留旧句柄。旧句柄上的并发drm_gem_handle_delete在此窗口中成功，将 handle_count 递减为 0，并在新句柄的 IDR 条目仍在引用 GEM 对象时释放该对象。NULL 删除旧句柄的 IDR 条目之前table_lock以便旧句柄上的任何并发GEM_CLOSE都看到 NULL 并返回 -EINVAL。还原 prime-bookkeeping 错误路径中的旧条目。
    (CVE-2026-63885)

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

ID	名称	严重性
328148	Linux Distros 未修补的漏洞：CVE-2026-64612	high
328147	Linux Distros 未修补的漏洞：CVE-2026-63889	high
328146	Linux Distros 未修补的漏洞：CVE-2026-63971	high
328145	Linux Distros 未修补的漏洞：CVE-2026-64140	high
328144	Linux Distros 未修补的漏洞：CVE-2026-64135	medium
328143	Linux Distros 未修补的漏洞：CVE-2026-63813	high
328142	Linux Distros 未修补的漏洞：CVE-2026-63851	high
328141	Linux Distros 未修补的漏洞：CVE-2026-64052	high
328140	Linux Distros 未修补的漏洞：CVE-2026-63928	medium
328139	Linux Distros 未修补的漏洞：CVE-2026-64103	medium
328138	Linux Distros 未修补的漏洞：CVE-2026-64000	critical
328137	Linux Distros 未修补的漏洞：CVE-2026-63844	high
328136	Linux Distros 未修补的漏洞：CVE-2026-64104	high
328135	Linux Distros 未修补的漏洞：CVE-2026-45799	high
328134	Linux Distros 未修补的漏洞：CVE-2026-64167	medium
328133	Linux Distros 未修补的漏洞：CVE-2026-63915	high
328132	Linux Distros 未修补的漏洞：CVE-2026-63852	high
328131	Linux Distros 未修补的漏洞：CVE-2026-64105	medium
328130	Linux Distros 未修补的漏洞：CVE-2026-63888	critical
328129	Linux Distros 未修补的漏洞：CVE-2026-63875	high
328128	Linux Distros 未修补的漏洞：CVE-2026-64027	high
328127	Linux Distros 未修补的漏洞：CVE-2026-64088	high
328126	Linux Distros 未修补的漏洞：CVE-2026-64148	high
328125	Linux Distros 未修补的漏洞：CVE-2026-64168	medium
328124	Linux Distros 未修补的漏洞：CVE-2026-64055	critical
328123	Linux Distros 未修补的漏洞：CVE-2026-63975	high
328122	Linux Distros 未修补的漏洞：CVE-2026-53380	high
328121	Linux Distros 未修补的漏洞：CVE-2026-64007	critical
328120	Linux Distros 未修补的漏洞：CVE-2026-64122	critical
328119	Linux Distros 未修补的漏洞：CVE-2026-64150	critical
328118	Linux Distros 未修补的漏洞：CVE-2026-63972	high
328117	Linux Distros 未修补的漏洞：CVE-2026-64102	critical
328116	Linux Distros 未修补的漏洞：CVE-2026-64043	medium
328115	Linux Distros 未修补的漏洞：CVE-2026-64050	high
328114	Linux Distros 未修补的漏洞：CVE-2026-53396	high
328113	Linux Distros 未修补的漏洞：CVE-2026-64053	high
328112	Linux Distros 未修补的漏洞：CVE-2026-64143	medium
328111	Linux Distros 未修补的漏洞：CVE-2026-64180	medium
328110	Linux Distros 未修补的漏洞：CVE-2026-63933	medium
328109	Linux Distros 未修补的漏洞：CVE-2026-64100	medium
328108	Linux Distros 未修补的漏洞：CVE-2026-64165	medium
328107	Linux Distros 未修补的漏洞：CVE-2026-63942	high
328106	Linux Distros 未修补的漏洞：CVE-2026-63807	high
328105	Linux Distros 未修补的漏洞：CVE-2026-63986	medium
328104	Linux Distros 未修补的漏洞：CVE-2026-63865	high
328103	Linux Distros 未修补的漏洞：CVE-2026-63890	medium
328102	Linux Distros 未修补的漏洞：CVE-2026-63886	critical
328101	Linux Distros 未修补的漏洞：CVE-2026-64014	medium
328100	Linux Distros 未修补的漏洞：CVE-2026-64073	high
328099	Linux Distros 未修补的漏洞：CVE-2026-63885	high

检测

Nessus 的 Misc. 系列

high

high

high

high

medium

high

high

high

medium

medium

critical

high

high

high

medium

high

high

medium

critical

high

high

high

high

medium

critical

high

high

critical

critical

critical

high

critical

medium

high

high

high

medium

medium

medium

medium

medium

high

high

medium

high

medium

critical

medium

high

high