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

  - KVM：x86/mmu：修复供应商模块重新加载时的释放后使用 mmu_destroy_caches（） 会破坏 pte_list_desc_cache 和 mmu_page_header_cache，但两个指针都保持不变。指针位于 kvm.ko 中，因此在 kvm.ko 保持加载状态下卸载供应商模块时仍然存在。如果在后续供应商模块加载过程中未能创建pte_list_desc_cache，则分配将pte_list_desc_cache设置为 NULL，错误路径会调用 mmu_destroy_caches（）。mmu_page_header_cache仍然指向在前面的供应商模块卸载期间所破坏的缓存。将该过时指针传递到 kmem_cache_destroy（） 会导致 slab 释放后使用。在具有 CONFIG_KASAN=y、CONFIG_KASAN_GENERIC=y、CONFIG_KVM=m 和 CONFIG_KVM_INTEL=m 的 v7.1.3 内核上重现该问题。在第二次调用 kvm_mmu_vendor_module_init（） 时，一次性测试挂钩强制 pte_list_desc_cache 为空： 1. 加载 kvm.ko 和 kvm-intel.ko，创建这两个缓存。
    2. 仅kvm_intel卸载，保持 kvm.ko 加载。3. 通过重新加载kvm_intel并强制初始化
    -ENOMEM 路径。KASAN 报告：缺陷：KASAN：kvm_mmu_vendor_module_init+0x5b/0x170 中的释放后使用板 [kvm] ...kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... 按任务 16817 分配：__kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... 由任务 16820 释放：kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] 在销毁缓存后立即清除两个指针，这样存储的状态才能反映缓存的生命周期，并且重复清理是安全的。应用补丁之后，同一注入的供应商模块重新加载会按预期失败并出现 -ENOMEM，并且不会产生任何 KASAN 报告。
    (CVE-2026-68428)

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

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

  - mm/damon/core：禁止 damon_set_regions（） 的重叠输入范围 damon_set_regions（） 假定输入范围已按地址排序且没有重叠。因此，该假设最初需要得到明确验证。但提交 97d482f4592f（mm/damon/sysfs：重用 damon_set_regions（） 用于区域设置）错误地删除了验证。这可使 DAMON 以意想不到的方式运行。充其量，监控结果快照看起来很奇怪，因为会有重叠的区域。DAMOS 也会工作得很奇怪，对重叠的区域多次应用相同的操作，并使 DAMOS 配额变得奇怪。更严重的是，根据设置和区域更新顺序，可以制作负大小的区域。如果内核是以 CONFIG_DAMON_DEBUG_SANITY=y 构建，它将触发 WARN_ONCE（）。
    根据监控结果，负大小区域可进一步触发 damon_merge_two_regions（） 中的除零。请注意，包括 WARN_ONCE（） 和除零在内的一些后果取决于在根本原因提交 97d482f4592f 之后引入的提交（mm/damon/sysfs：
    重用damon_set_regions（） 用于区域设置）。通过检查假设并在输入范围不满足假设时返回错误来修复问题。此问题由 Sashiko 发现 [1]。
    (CVE-2026-68164)

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

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

  - 在 GIMP 的 PSD 文件格式插件中发现一个缺陷。此漏洞是“block_rem”变量中的无符号整数下溢，当用户打开特别构建的“.psd”图像文件时会发生。下溢会导致解析器混淆，使攻击者能够将任意数据作为层资源区块注入。这最终可导致任意代码执行，从而允许攻击者在受害者的系统上运行恶意代码。（CVE-2026-59090）

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

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

  - drm/virtio：响应缓冲区的绑定 EDID 块读取 virtio_get_edid_block（） 仅针对设备提供的 resp->size 字段验证读取偏移，从不针对固定大小的 resp->edid 数组进行验证。
    EDID 块索引由设备提供的扩展计数驱动，因此恶意 virtio-gpu 后端可公告包含高块计数的大尺寸，并远过数组读取到相邻内核内存，然后在解析的 EDID 中显示（越界读取/信息泄漏）。同时拒绝任何末端超过 edid 数组大小的读取。符合要求的 EDID 响应保留在数组内，不受影响。（CVE-2026-68255）

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

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

  - wifi：brcmfmac：在清理前初始化 SDIO 数据工作 brcmf_sdio_probe（） 在分配有序的工作队列之前，将新分配的总线存储在 sdiodev->bus 中。如果该分配失败，函数会跳至失败并调用 brcmf_sdio_remove（）。brcmf_sdio_remove（） 会无条件取消 bus->datawork。在第一个可以到达 brcmf_sdio_remove（） 的失败路径之前初始化工作项，以便清除路径始终观察有效的工作对象。此问题是由我们的静态分析工具发现的，然后通过手动检查探头错误路径和删除时间工作泄漏来确认。问题模式是早期设置失败，它到达清理帮助程序，该帮助程序在初始化程序运行之前取消嵌入的工作项。QEMU PoC 强制 alloc_ordered_workqueue（） 在 brcmf_sdio_probe（） 中的相同时间点发生故障，然后才达到 INIT_WORK（&bus->datawork）。生成的失败路径会调用 brcmf_sdio_remove（），DEBUG_OBJECTS 报告堆栈中有 brcmf_sdio_probe（） 和 brcmf_sdio_remove（） 的无效工作耗尽。
    (CVE-2026-68403)

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

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

  - hwmon：（corsair-cpro） 调用 hid_hw_stop 之前停止设备 IO 调用 hid_hw_stop（） 不会停止设备 IO。这会导致 hid_input_report（） 与驱动程序探测函数中执行 hid_device_io_start（） 紧跟的点之间存在争用条件。如果启动 io 启动后探测操作失败，此争用条件将导致 UAF 漏洞。通过在调用 hid_hw_stop（） 之前先调用 hid_device_io_stop（） 来修复问题。（CVE-2026-68360）

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

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

  - ksmbd：当大小核算溢出时，绑定 DACL 重复数据删除遍历到复制的 ACE set_ntacl_dacl（） 可在消耗完整输入 DACL 之前停止复制 ACE。发生此情况时，num_aces 仅反映实际复制到输出 DACL 中的 ACE，但 set_posix_acl_entries_dacl（） 仍会接收nt_num_aces，并在去重期间使用该 ACE 数组遍历现有 ACE 数组。这样会使 dedup walk 扫描经过复制的 ACE 数组并检查不含有效 ACE 的缓冲区末尾。拆分 NT ACE 计数当前承载的两种含义。传递复制的 NT ACE 数以限制重复数据删除遍历，并单独为“Everyone/default ACL”回退保留原始输入 DACL 具有 NT ACE 状态。这使重复数据删除遍历与重建的 DACL 中实际存在的 ACE 保持一致。（CVE-2026-68098）

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

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

  - wifi：ath6kl：修复连接事件中从固件 IE 长度读取的 OOB 未针对缓冲区长度对 ath6kl_wmi_connect_event_rx（） 中由固件控制的 beacon_ie_len、assoc_req_len 和 assoc_resp_len 字段进行验证。其总和（高达 765）可超过实际的 WMI 事件数据，从而在 IE 解析期间导致越界读取以及 wmi->is_wmm_enabled 的状态损坏。添加总 IE 长度是否适合缓冲区的检查。（CVE-2026-68352）

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

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

  - c-ares 是一种异步解析器库。在版本之前 1.34.7，ares_dns_name_parse（） 强制执行向后 DNS 压缩指针，但未限制总指针跳数或组装的名称长度。恶意 DNS 服务器可发送包含较长的降序指针链和许多 NAME 或 RDATA 字段引用该链的资源记录的响应，从而造成随着消息大小呈二次方增长的反复解压缩工作。单个特制的响应可以终止单线程 c-ares 事件循环并拒绝 DNS 解析，而不会导致内存损坏或信息泄露。此问题已在 1.34.7 版本中修复。(CVE-2026-69184)

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

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

  - firmware：arm_ffa：修复 ffa_setup_and_transmit（） 中的越界写入 Sashiko（本地）报告了 ffa_setup_and_transmit 中的多种越界问题：1） 写入 ep_mem_access->reserved 可对 FFA 版本进行写入越界，< 1.2 因为 ffa_emad_size_get（） 在这种情况下会返回 16 字节，而 reserved 的偏移为 24。memset 结构体不是将字段归零，而是根据 FFA 版本首先将结构设为零。2） 确保有足够的大小来写入成分。同时，转换驱动程序中唯一使用类型而不是变量的 sizeof（）。（CVE-2026-68401）

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

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

  - KVM： SVM：在 CPU 在线时升级asid_generation以避免热插拔之后发生 ASID 冲突 如果 vCPU 保持计划外（或阻断）当上一个运行它的 pCPU 经历热插拔周期（在线->脱机->在线），然后 vCPU 在同一个 pCPU 上恢复执行，则它可能使用现在已分配给其他 vCPU 的 ASID 运行， 导致使用过时的 TLB 转换。svm_enable_virtualization_cpu（） 在每个 CPU 在线事件（包括热插拔周期）上将 asid_generation 重置为 1，并将 next_asid 设置为 max_asid + 1。由于next_asid从池边界之外开始，因此在线事件后对 new_asid（） 的首次调用始终封装池，将 asid_generation 递增为 2 并分配从 min_asid 开始的 ASID。考虑来自不同虚拟机的两个 vCPU，即在热插拔事件之前固定到 CPU-X （保持 asid_generation=2 和 ASID=N）：1. CPU-X 离线并重新在线：asid_generation 重置为 1，next_asid = max_asid + 1。2. 一个或多个 vCPU 迁移到 CPU-X 并调用 new_asid（），封装池并从 min_asid 开始消耗 ASID。最终会为来自不同虚拟机的 vCPU-B 分配 asid_generation=2， ASID=N，即 vCPU-A 在热插拔之前所持有的相同 ASID。3.
    vCPU-A 在 CPU-X 上进入 pre_svm_run（）：current_vmcb->cpu 未更改，因此会跳过迁移分支。
    其保存的 asid_generation=2 与 sd->asid_generation=2 相匹配，因此生成检查静默通过，vCPU-A 继续以 ASID=N（刚刚分配给 vCPU-B 的相同 ASID）运行。来自不同 VM 的两个 vCPU 现在使用相同的 ASID 在 CPU-X 上运行，从而导致它们共享 NPT TLB 条目并产生过时转换。冲突表现为 KVM 内部错误（子错误：1，仿真失败）。NPT 页面错误报告错误 GPA 远超出 VM 的物理内存范围，这是使用过时 TLB 转换的迹象。KVM 回退到指令仿真，这在仿真器未实现的 FPU/XSave 指令（XRSTOR、STMXCSR）上失败。在 svm_enable_virtualization_cpu（） 中递增 asid_generation 而非重置为 1，以修复此问题。在模块加载时，asid_generation从 0 （memset） 开始，递增生成 1，与旧行为相同。在后续的热插拔周期中，生成速度会超出 vCPU 之前在此 CPU 上观察到的任何值，因此在每个热插拔周期之后，pre_svm_run（） 中的生成检查可靠地强制在每个 vCPU 上执行 new_asid（）。（CVE-2026-68093）

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

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

  - ceph：修复 ceph_handle_caps（） 中 snaptrace 上的 pre-auth 越界读取 ceph_handle_caps（） 从 wire-format ceph_mds_caps 标头读取snap_trace_len，并无条件地使用它构建假结束指针 （snaptrace + snaptrace_len），随后在CEPH_CAP_OP_IMPORT情况下传递给 ceph_update_snap_trace（）;snaptrace_len = le32_to_cpu（h->snap_trace_len）;p = 快照跟踪 + snaptrace_len;...案例 CEPH_CAP_OP_IMPORT：if （snaptrace_len） { ...if （ceph_update_snap_trace（MDSC， snaptrace， snaptrace + snaptrace_len， false， &realm）） { ... } ceph_update_snap_trace（） 然后使用 ceph_decode_need（&p， e， sizeof（*ri）， bad） 搭配攻击者提供的假端 e == snaptrace + snaptrace_len，从 snaptrace 解码结构ceph_mds_snap_realm。通过 snaptrace_len == 0xFFFFFFFF，可轻易满足边界检查，ri = p 读取 sizeof（struct ceph_mds_snap_realm） 并通过合法的 msg->front 缓冲区，然后 ri->num_snaps / ri->num_prior_parent_snaps 驱动编码 snap 数组的进一步越界读取。十一msg_version >= 2 ..msg_version >= op 开关上方的 12 个解码器区块通过其 ceph_decode_*_safe（） / ceph_decode_need（） 帮助程序捕获此 OOB，但它们位于 hdr.version-gated if 后面，因此设置为 msg->hdr.version = 1 的恶意或已被破坏的 MDS 到达 IMPORT 路径时没有任何验证过snap_trace_len的版本网关解码器。该形状自引入 ceph_handle_caps（） 以来一直存在。使用规范的 ceph_decode_need（） / ceph_has_room（） 辅助函数，在使用消息前端缓冲区之前，先对其进行验证snap_trace_len。该帮助程序通过减法 （n <= end - p，由 end >= p） 保护，而非指针加法来限制长度，因此对于 p + snap_trace_len 可能溢出地址空间的 32 位版本上受攻击者控制的 u32 长度是封装安全的。这与 ceph 解码路径的其余部分相匹配（例如下面的几行的pool_ns_len检查），并且现有的 goto bad cleanup 已覆盖此退出路径。（CVE-2026-68160）

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

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

  - wifi：ath11k：修复 ath11k_hal_rx_msdu_list_get（） 中潜在的缓冲区下溢 当 msdu_details 中的第一个条目具有零缓冲区地址时，代码会以 i == 0 访问 msdu_details[i - 1]，从而导致缓冲区下溢。通过在主要条件之前添加对 i == 0 的单独检查来阻止越界访问，以与 ath12k_wifi7_hal_rx_msdu_list_get（） 类似进行修复。由 Linux Verification Center (linuxtesting.org) 和 SVACE 发现。(CVE-2026-68355)

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

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

  - sctp：避免在 netns 拆卸期间auth_enable sysctl UAF proc_sctp_do_auth（） 更改 net.sctp.auth_enable 后更新 SCTP 控制套接字。该处理程序从 ctl->data 获取每个网络的 SCTP 状态，因此已经打开的 sysctl 文件在网络命名空间被拆散时仍可以作为该目标。
    SCTP 之前通过 sctp_defaults_init（） 注册其 per-net sysctls，而控制套接字是稍后通过 sctp_ctrlsock_init（） 创建。这暴露了一个初始化窗口，其中 auth_enable 在 net->sctp.ctl_sock 存在之前处于可写状态，以及一个拆卸窗口，其中 auth_enable 在 inet_ctl_sock_destroy（） 释放控制套接字之后仍保持可写。在 sctp_ctl_sock_init（） 成功后将 per-net SCTP sysctl 注册移至 sctp_ctrlsock_init（），并且在破坏 sctp_ctrlsock_exit（） 中的控制套接字前取消注册 sysctl 表。如果创建控制套接字后 sysctl 注册失败，请破坏同一 init 路径中的控制套接字。使 sctp_sysctl_net_unregister（） 容忍缺少的标头并清除已保存的指针，以便 init-error 和 exit 路径可以安全地共享取消注册帮助程序。（CVE-2026-68162）

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

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

  - firewire：net：修复碎片化数据报重组 fwnet_frag_new（） 保留部分数据报的已接收片段的排序列表。当新片段与现有片段相邻时，代码会检查新片段是否也缩小了与下一个或上一个列表条目的差距。这些相邻查找当前假设当前片段始终具有真正的下一个或上一个片段。在列表边缘，下一个或上一个条目是列表标题，而不是结构fwnet_fragment_info。间隙检查还将与当前片段的旧边缘进行比较，而不是与添加新片段后的边缘进行比较。因此，桥接两个现有范围的片段可能使两个相邻范围未合并，因此 fwnet_pd_is_complete（） 可能错过完整的数据报。在查找相邻片段之前检查列表标题，并在决定是否合并所有三个范围时将相邻片段与新片段的远边缘进行比较。此问题由静态分析检查程序发现，并经手动源审查确认。（CVE-2026-68354）

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

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

  - libceph：拒绝 crush_decode CRUSH 存储段类型 0 为设备保留的零存储段类型。映射器依赖于该不变量并使用类型 0 来识别叶设备。如果 crush_decode（） 接受类型为 0 的存储桶，则畸形的 CRUSH 映射可使映射器将负的存储桶 ID 视为设备并将其传递给 is_out（），然后，后者会索引具有负值的 OSD 权重数组。解码 CRUSH 映射时拒绝零存储段类型，这样无效状态就永远不会到达映射器。（CVE-2026-68154）

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

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

  - bnxt_en：在初始化 bnxt_aux_dev_release（） 使用的所有字段之前处理部分初始化的辅助设备 bnxt_aux_devices_init（） 调用 auxiliary_device_init（）。auxiliary_device_init（） 成功后，以后的错误必须使用 auxiliary_device_uninit（） 展开，后者会调用释放回调。释放回调假设填充了 aux_priv->id、aux_priv->edev、edev->net 和 edev->ulp_tbl。如果在 auxiliary_device_init（） 后分配失败，则释放路径可以其他方式取消引用或清除部分初始化状态。在调用 auxiliary_device_init（） 之前，先分配并附加 bnxt_en_dev 和 ULP 表，以便释放回调只看到一个完全初始化的辅助私有对象。如果 auxiliary_device_init（） 本身失败，请直接释放这些分配，因为 device_initialize（） 尚未运行并且不会调用释放回调。此问题由静态分析检查程序发现，并经手动源审查确认。（CVE-2026-68375）

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

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

  - ksmbd：根据 SID 子颁发机构验证 ACE 大小 set_ntacl_dacl（） 会在复制 ACE 之前验证sid.num_subauth，但不验证声明的 ACE 大小是否包含该字段描述的所有子颁发机构。因此，可以复制一个过小的 ACE，然后使 POSIX ACL 重复数据删除遍历检查超出复制的 ACE 边界的数据。现有的初始边界检查也太小。它仅确保在 set_ntacl_dacl（） 进一步读取到输入缓冲区之前sid.num_subauth ACE 大小字段可访问。要求固定 SID 标头有足够的输入，然后才能访问num_subauth，拒绝小于该标头的 ACE，并跳过声明的大小不能包含完整 SID 的 ACE。这会使验证与其他 ACE 遍历路径一致。（CVE-2026-68097）

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

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

  - net/iucv：修复已切断的 iucv_path af_iucv 的释放后使用，将 IUCV->message_q 上尚未收到的消息通知排入队列，每个通知都保留指向连接iucv_path的原始指针。当对等机切断连接时，iucv_sever_path（） 会使用 iucv_path_free（） 释放该路径，但会使通知处于队列状态。之后的 recvmsg（） 通过 iucv_process_message_q（） 耗尽message_q，并将过时路径传递给 message_receive（） -- 释放iucv_path释放后使用。路径被切断时删除排队的通知;一旦路径消失，就无法再接收它们。这还释放了在消息仍处于排队状态下关闭套接字时泄漏的通知。（CVE-2026-68140）

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

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

  - wifi：ipw2100：修复 ipw2100_pci_init_one（） 中潜在的内存泄漏 在 ipw2100_pci_init_one（） 的某些错误路径中未释放 ipw2100_alloc_device（） 函数中分配的内存。通过将直接返回转换为错误路径返回的 goto 来修复此问题。pci_enable_device（） 失败时的错误路径不能跳至失败，因为此时 priv 尚未设置，因此请内联执行错误处理。（CVE-2026-68413）

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

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

  - drm/vc4：hvs/v3d：修复取消绑定中的空取消引用 hvs 和 v3d 驱动程序在其取消绑定函数中使用 dev_get_drvdata（主）。由于 vc4-drm 在其依存驱动程序 （vc4_hvs/vc4_v3d） 之前删除，因此 vc4_hvs_unbind/vc4_v3d_unbind 函数尝试获取其主控端的 drvdata，并因空取消引用错误而失败。直接使用传递到 unbind 函数的数据指针，而不是 dev_get_drvdata（主控）。
    这可避免使用可能释放的内存。（CVE-2026-68303）

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

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

  - drm/amdgpu/gfx9：将 BUG_ON（） 替换为 WARN_ON（） 这些情况下无需造成内核崩溃。
    （从提交 b71604f8685b0eba07866f4e8dc30f93e1931054 中精选出的内容）（CVE-2026-68111）

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

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

  - drm/amdgpu：释放 genpd 前调用 pm_genpd_remove（） 在释放内存前调用 pm_genpd_remove（） 从全局列表中取消注册acp_genpd释放后清除指针。（从提交 cd8650d7a91ee8b768e202354672553faa5cc1f2 中精选出的内容）（CVE-2026-68104）

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

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

  - wifi：mwifiex：修复当 AP 有 HT-cap 但无 HT-oper 时的空取消引用 mwifiex_tdls_add_ht_oper（） 在存在 bss_desc->bcn_ht_cap 时将其跟随 AP 带宽路径bss_desc->bcn_ht_oper：if （ISSUPP_CHANWIDTH40（priv->adapter->hw_dot_11n_dev_cap） &; bss_desc->bcn_ht_cap &; ISALLOWED_CHANWIDTH40（bss_desc->bcn_ht_oper->ht_param）） bcn_ht_cap 和 bcn_ht_在 mwifiex_update_bss_desc_with_ie（） 中解析相关的 AP 信标时，oper 会独立填充：
    通告HT功能元素但无HT操作元素的AP将bcn_ht_cap留为非NULL和bcn_ht_oper NULL。然后，在与此类 AP 关联时设置到对等机的 TDLS 链路会取消引用空bcn_ht_oper并造成内核崩溃。驱动程序中每隔一个其他bcn_ht_oper用户首先对其进行空检查。保护实际取消引用的指针。由 0sec 自动化安全研究工具 （）https://0sec.ai 发现。（CVE-2026-68197）

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

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

  - wifi：carl9170：修复故障转移路径中的缓冲区溢出rx_stream carl9170_rx_stream（） 中的故障转移延续会从第二次 USB 传输复制完整的 tlen，而不是以 rx_failover_missing 字节封锁。当两个传输接近最大大小时，总和将超过 65535 字节故障转移 SKB，从而触发skb_over_panic。将复制大小限制为缺少的字节计数。[修复 checkpatch CHECK：PARENTHESIS_ALIGNMENT]（CVE-2026-68349）

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

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

  - media：cedrus：跳过无效的 H.264 引用列表条目 Cedrus 使用无状态片控件中的 H.264 ref_pic_list0/ref_pic_list1 条目，稍后再使用其索引查询 中的 decode->dpb[]
    _cedrus_write_ref_list（）。拒绝 cedrus_try_ctrl（） 中的此类控件会破坏现有用户空间，因为无状态 H.264 引用列表可合法地为缺失的引用携带超出范围索引。
    而是保护 Cedrus 中的实际 DPB 查找，并跳过其索引不符合固定 V4L2_H264_NUM_DPB_ENTRIES 数组的条目。这可使补丁保留在驱动程序使用站点的本地位置，并避免从畸形或不受支持的引用列表条目进行的越界读取。（CVE-2026-68229）

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

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

  - usb：gadget：f_ncm：验证 ncm_unwrap_ntb（） 中的数据报边界 当解包主机提供的 NTB 时，ncm_unwrap_ntb（） 会根据frame_max检查数据报长度，但不会验证数据报是否适合声明的区块长度。此外，解码来自单个套接字缓冲区的多个 NTB 时，不会针对实际剩余的缓冲区数据检查后续的块长度。由于缺少这些检查，恶意 USB 主机可指定指向区块以外的数据报偏移和长度，或者提供声明长度大于缓冲区的辅助 NTB 标头。然后，skb_put_data（） 将相邻内核内存从 skb_shared_info 复制到网络 skb 中。通过在解析前验证 NTB 标头是否还有足够的缓冲区空间、处理零长度区块声明、确保区块长度从不超过剩余缓冲区空间，以及验证每个数据报负载是否严格停留在区块边界内，来修复此问题。（CVE-2026-68368）

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

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

  - wifi：ath9k：hif_usb：重新布防固件请求后不取消引用 hif_dev 通过 request_firmware_nowait（） 重新布防异步固件加载 ath9k_hif_request_firmware（） 将 hif_dev 作为完成上下文传递，然后仍然取消引用 hif_dev：dev_info（&hif_dev->udev->dev，ath9k_htc：已请求\n固件 %s，hif_dev->fw_name）;重新布防的回调 ath9k_hif_usb_firmware_cb（） 在事件工作队列上运行，当缺少固件时，会将重试链穿进 ath9k_hif_usb_firmware_fail（） -> complete_all（&hif_dev->fw_done）。这会在并发 ath9k_hif_usb_disconnect（） 中释放 wait_for_completion（&hif_dev->fw_done），然后 kfree（） hif_dev。因此，重新布防请求的框架中的尾部 dev_info（） 可读取释放的内存（hif_dev->udev，结构 hif_device_usb 的第一个字段）： BUG： KASAN：大小为 8 的 ath9k_hif_request_firmware 读取中的 slab-use-after-free ...按任务 kworker/...ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c：1247 request_firmware_work_func 分配者 ...： ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c 释放者 ...：
    ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c fw_done屏障仅使断开连接等待固件链 *终止*;它不会保护重新启用请求并在之后继续接触hif_dev的外部 ath9k_hif_request_firmware（） 框架。终止 post-request dev_info（）：这是布防异步请求后唯一使用 hif_dev 的方式，而且它仅提供信息（仅当 request_firmware_nowait（） 未布防回调时才运行失败路径上的 dev_err（），因此 hif_dev 仍处于活动状态）。syzbot 最初将其报告为后来自动弃用的单一非重现崩溃，并由 reFuzz fuzzer 独立重新发现，其产生了 C 重现程序（固件下载失败的 ath9k_htc 设备的 USB 小工具连接/断开连接）。有漏洞的代码未更改，并且仍然存在于 v7.1-rc6 中，其中一旦（亚微秒）争用窗口扩大，slab-after-use-free 就会在 KASAN 下重现。（CVE-2026-68363）

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

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

  - media：vivid：修复 vivid_init（） 中的清理缺陷 当 vivid_init（） 中的 platform_device_register（） 失败时，vivid_pdev 中的嵌入式结构设备已由 device_initialize（） 初始化，但失败路径会跳至free_output_strings，而不会丢弃当前平台设备的设备引用：
    vivid_init（） -> platform_device_register（&vivid_pdev） -> device_initialize（&vivid_pdev.dev） -> setup_pdev_dma_masks（&vivid_pdev） -> platform_device_add（&vivid_pdev） 这会导致 platform_device_register（） 失败时引用泄漏。通过在跳转到通用清理路径之前调用 platform_device_put（） 来修复此问题。此外，unreg_driver标签会错误地调用 platform_driver_register（） 而不是 platform_driver_unregister（），如果驱动程序注册成功后工作队列创建失败，则会中断清理。也请修复该问题。参考泄漏是由我开发的静态分析工具识别的，并通过手动审查确认。在代码检查期间发现不正确的清理调用。
    (CVE-2026-68203)

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

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

  - net/af_iucv：修复 afiucv_hs_callback_syn（） 中的空取消引用 afiucv_hs_callback_syn（） 使用GFP_ATOMIC分配子套接字。如果分配失败，nsk 为 NULL。监听状态检查失败、接受 backlog 已满或 nsk 为空时，将输入 connection-refused 路径。代码会无条件调用该路径中的 iucv_sock_kill（nsk）。iucv_sock_kill（） 不接受空套接字指针并立即通过 sock_flag（sk， SOCK_ZAPPED） 取消引用 sk。当 nsk 为空时，调用 iucv_sock_kill（nsk） 会导致空指针取消引用。成功分配子套接字时仅调用 iucv_sock_kill（）。
    (CVE-2026-68141)

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

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

  - amt：每次拉取后重新读取 skb 标头指针 多个 AMT 接收和传输路径将指针缓存到 skb 标头（ip_hdr（）、ipv6_hdr（）、eth_hdr（） 或 AMT 消息标头），然后调用可在再次使用缓存指针之前重新分配该标头的帮助程序。pskb_may_pull（）、ip_mc_may_pull（）、ipv6_mc_may_pull（）、iptunnel_pull_header（）、ip_mc_check_igmp（） 和 ipv6_mc_check_mld（） 都可以释放旧头并移动数据，因此，在调用之前获取的指针之后悬摆，以后的访问是释放的头的释放后使用。受影响的站点如下：amt_rcv（） 在 amt_parse_type（） 拉取前缓存 ip_hdr（），然后读取 iph->saddr。amt_dev_xmit（） 在 ip_mc_check_igmp（）/ ipv6_mc_check_mld（） 和 pskb_may_pull（） 之前缓存 ip_hdr（）/ipv6_hdr（），然后读取组地址。
    amt_multicast_data_handler（） 在 pskb_may_pull（） 之前缓存 eth_hdr（），然后写入 L2 标头。
    amt_membership_query_handler（） 缓存 AMT 标头、外部和内部 eth_hdr（） 以及 ip_hdr（） 在 iptunnel_pull_header（） 和多次拉取之前，然后读取和写入它们。amt_igmpv3_report_handler（） 和 amt_mldv2_report_handler（） 缓存 ip_hdr（）/ipv6_hdr（） 和当前组记录，并跨 *_mc_may_pull（） 调用从记录循环内的报告标头读取记录计数。
    amt_update_handler（） 在 pskb_may_pull（）、iptunnel_pull_header（）、ip_mc_check_igmp（） 和报告处理程序之前缓存 ip_hdr（） 和 AMT membership-update 标头，然后读取 iph->daddr 和 amtmu->nonce/amtmu->response_mac。修复每个站点的方式是，在第一次拉取运行之前对拉取后使用的标量进行快照，或者在最后一次可移动标头的拉取之后从 skb 重新派生标头指针。对拉取中稳定的值（源和组地址、响应 MAC 和临时信息、记录计数、外部源 MAC）进行快照;通过写入或重复读取的指针会重新派生。（CVE-2026-68302）

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

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

  - wifi：nl80211：在 MBSSID 不匹配时释放 RNR 数据 当 RNR 条目少于 MBSSID 条目时 nl80211_parse_beacon（） 拒绝 EMA RNR 数据。遭拒绝的 RNR 分配尚未附加至信标数据，因此在返回错误前先将其释放。（CVE-2026-68407）

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

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

  - drm/xe/guc：保留设备 ref 直到队列拆卸完成 GuC exec 队列销毁可异步运行。如果最终设备放置来自破坏工作线程，drmm 清理最终可能会耗尽相同的工作队列并死锁。保留队列生命周期的drm_device引用，并在队列拆卸完成后将其终止。这会在异步破坏工作仍待定时阻止 drmm 清理运行。
    将 GuC 破坏工作移至 module-lifetime Xe 工作队列并在 PCI 删除时刷新，这样 hot-unbind/rebind 仍会等待待定的破坏工作。使用队列保持的设备引用时，guc_submit_sw_fini（） 无法使用实时 GuC ID 运行。将 fini wait 替换为断言，并删除未使用的fini_wq。v2： - 衍合 v3： - 切换到队列生命周期 drm_dev_get（）/drm_dev_put（） 模型。（Matt） - 在 system_dfl_wq 而不是 xe->destroy_wq 上排队异步拆卸。（Matt） - 终止单独的延迟drm_dev_put工作线程。- 从 guc_submit_sw_fini（） 删除过时的 drain_workqueue（xe->destroy_wq）。v4： - 用断言替换 guc_submit_sw_fini（） 等待并删除现在未使用的fini_wq。（sashiko） v5： - 将破坏工作移动到模块生命周期 Xe 工作队列，而不是 system_dfl_wq。（Matt） - PCI 删除期间刷新 module-lifetime 破坏工作队列以保留旧的 device-remove 等待语义。v6： - 保留对每设备destroy_wq的 SVM 页图破坏工作，以免使其超过xe_device/drm_device的生存期。（Sashiko） - 将WQ_MEM_RECLAIM用于 xe->destroy_wq，因为 SVM 页面地图破坏工作可从回收路径排队。
    v7： - 终止每设备 xe->destroy_wq，并使用模块级破坏 WQ 来破坏 SVM 页面地图。（Matt） - 将 xe_exec_queue_destroy_wq_*（） 帮助程序重命名为 xe_destroy_wq_*（） 帮助程序，因为 WQ 不再特定于 exec-queue。（Matt） v8： - 衍合。v9： - 保留 SVM 页面地图破坏在每设备WQ_MEM_RECLAIM destroy_wq上工作，因为它可以排队回收并嵌入 devres 拆卸使用的dev_pagemap。（Sashiko） - 保持模块层级破坏 WQ GuC 仅限，并从中丢弃WQ_MEM_RECLAIM。- 更新 module-WQ kdoc 以记录 GuC/SVM 拆分。v10： - 保留每个 cpu 的 xe->destroy_wq，同时添加 WQ_MEM_RECLAIM 以修复工作队列分配警告。v11： - 终止 SVM pagemap 破坏注释，因其针对特定修订。（Thomas） v12： - 衍合。（从提交 da1124abac689cc2b1d8995e5f0a816f8a122edb 中精选出的内容）（CVE-2026-68382）

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

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

  - wifi：mt76：connac：修复 mt76_connac_mcu_uni_bss_he_tlv（） 中可能的空指针取消引用 mt76_connac_get_he_phy_cap例程理论上可返回 NULL，因此在取消引用它之前检查端点指针。（CVE-2026-68309）

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

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

  - sctp： auth：验证 auth_chunk 为 NULL 时的认证要求 sctp_auth_chunk_verify（） 在 chunk->auth_chunk 为 NULL 时无条件返回 true，从而静默跳过认证。在以下情况下，这是不正确的：
    1. skb_clone（） 在 BH 接收路径中失败，auth_chunk NULL。在 sctp_endpoint_bh_rcv（） 中，asoc 对新连接为 NULL，因此早期的 sctp_auth_recv_cid（） 检查无法捕获此问题。2. COOKIE-ECHO 之前没有 AUTH 区块，因此从不调用 skb_clone（），并且 auth_chunk 保持 NULL。当auth_chunk为 NULL 时通过检查 sctp_auth_recv_cid（） 进行修复：如果需要认证，返回 false 以终止区块;否则正常继续。（CVE-2026-68300）

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

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

  - sctp：验证 sctp_process_strreset_inreq（） 中的流计数 当处理来自对等机的RESET_IN_REQUEST时，sctp_process_strreset_inreq（） 从参数长度派生流计数，但不检查生成的RESET_OUT_REQUEST是否超过 SCTP_MAX_CHUNK_LEN。OUT 请求标头（sctp_strreset_outreq，16 字节）比 IN 请求标头（sctp_strreset_inreq，8 字节）大 8 个字节。通常，IP 负载被绑定为 65535 字节，因此流列表不能大到足以触发溢出。然而，在具有 MTU > 65535 的接口上（例如，具有 IPv6 jumbogram 的环回）上，当计算 OUT 请求大小时，符合传入 IN 参数的流列表可在 sctp_make_strreset_req（） 中造成__u16溢出，从而导致 skb 分配过小和内核缺陷：net/core/skbuff.c：207 skb_panic net/core/skbuff.c：2625 skb_put net/sctp/sm_make_chunk.c：1535 sctp_addto_chunk net/sctp/sm_make_chunk.c：3695 sctp_make_strreset_req net/sctp/stream.c：655 sctp_process_strreset_inreq 本地 setsockopt 路径会验证生成的重置请求大小。但是，对于仅传入重置，即使对等机必须生成具有相同流列表的 OUT 请求，它也会考虑较小的 IN 请求。对等机无法成功完成此类请求。拒绝对应 OUT 请求超过 SCTP_MAX_CHUNK_LEN 的对等机 IN 请求。还加强了本地检查，使其不发送需要来自对等机的超大 OUT 请求的 IN 请求。
    (CVE-2026-68315)

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

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

  - drop_monitor：在禁用 IRQ 的部分下执行u64_stats更新 在 net_dm_packet_trace_kfree_skb_hit（） 和 net_dm_hw_trap_packet_probe（） 中，u64_stats_update_begin（） / u64_stats_inc（） / u64_stats_update_end（） 会在 spin_unlock_irqrestore（&...drop_queue.lock， flags），则在已重新启用本地 IRQ 时。跟踪点探测可在 IRQ 或 softirq 上下文中执行。在 32 位架构上，u64_stats_update_begin（） 依赖于 seqcount 写入而禁用优先权但不会中断。如果在 64 位统计信息更新期间同一 CPU 上发生嵌套中断，可重新进入的 seqcount 更新可损坏 seqcount 状态或统计数据值。通过 spin_unlock_irqrestore（） 发布 drop_queue.lock 之前执行 64 位每 CPU 统计信息更新，确保在u64_stats更新期间保持禁用本地中断，从而修复此问题。（CVE-2026-68286）

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

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

  - drm/amdgpu：修复调用驱动程序 fini 例程之前的孔径映射泄漏 amdgpu_pci_remove（） 调用 drm_dev_unplug（）。这可造成 amdgpu_ttm_fini（） 中的 drm_dev_enter（） 始终返回 false，因此 iounmap（aper_base_kaddr） 绝不会在正常驱动程序卸载时运行，进而在 x86 PAT 间隔树中留下一个孤立条目。在 connected_to_cpu 硬件上，孔径通过 ioremap_cache（） 映射回写 （WB）。
    重新加载时，IP 发现会在相同范围内调用 memremap（...， MEMREMAP_WC）。WC 与 WB 冲突造成：0x... 的 ioremap 错误，请求的 0x1,0x0 amdgpu：发现失败：-2 通过切换到 devres 管理的映射进行修复，以便无论 drm_dev_enter（） 状态如何都能保证清除：- connected_to_cpu路径：devm_memremap（MEMREMAP_WB）。对于IORESOURCE_SYSTEM_RAM范围，这会采用 try_ram_remap（） 快捷方式，从现有内核直接映射返回 __va（偏移）。未创建任何新的 ioremap VA 或 PAT 条目，因此没有任何内容可孤立。- dGPU 路径：devm_ioremap_wc（） 将 iounmap（） 注册为 devres 操作，保证在 device_del（） 时完成清理。还从 amdgpu_device_unmap_mmio（） 中删除了 iounmap（aper_base_kaddr），因为该映射现在由 devres 拥有。v2：删除冗余x86_64防护 （Lijo）（从提交 d871e99879cb5fd1fa798b006b4888887e63a17a 中精选出的内容）（CVE-2026-68102）

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

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

  - wifi：mac80211：释放 IRQ 锁定 ieee80211_do_stop（） 之外的 AP_VLAN bc_buf SKB 在禁用 IRQ 的情况下保持 ps->bc_buf.lock 时，从父 AP ps->bc_buf 删除 AP_VLAN 数据包。然后，它会在终止锁定前调用 ieee80211_free_txskb（）。ieee80211_free_txskb（） 不仅仅是一个被动的 SKB 版本。
    对于 TX 状态为 SKB，可通过 cfg80211/nl80211 报告丢弃的帧，且该路径可到达 netlink 分流器传输。这与 ieee80211_do_stop（） 中的待定队列清理已取消队列锁定下的 SKB 链接并在 IRQ 状态恢复后将其释放的原因相同。此错误情况涉及两条路径，每一列显示该路径中的顺序： AP_VLAN 管理 TX：AP_VLAN 停止： 1. 附加 ACK-status 状态 1.清除运行状态 2.将 2 上的多播 SKB 排队。采用 IRQ 父项 ps->bc_buf 的 ps->bc_buf.lock 3.断开AP_VLAN SKB 4 的链接。调用 ieee80211_free_txskb（） 将匹配的 AP_VLAN SKB 从 现有锁定的 ps->bc_buf 中断开链接，但将它们移动到本地空闲队列。终止锁定并还原 IRQ 状态，然后再调用 ieee80211_free_txskb（）。警告：
    kernel/softirq.c：430 在 __local_bh_enable_ip （CVE-2026-68405）

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

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

  - drm/amdgpu：拒绝将预留的门铃映射到新队列 创建用户队列时，用户空间会提供门铃 BO 句柄和 BO 内的偏移量以获取门铃。但是，当前的实现使用 xa_store_irq（） 来存储门铃，这允许使用相同的 BO 和 offset 参数创建的后续队列覆盖现有队列和门铃映射。这可能导致诸如错误路由隔离 IRQ 处理到错误队列之类的问题，并误导一个队列的清理进程擦除另一个队列的映射。此提交通过将 xa_store_irq 替换为 xa_insert_irq 修复了此问题，拒绝将预留的门铃映射到新创建的队列（从提交 6244eae22966350db52faf9c1369d3b2ffc5de4e 中CVE-2026-68103精选出的内容）（）

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

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

  - media：sun4i-csi：start_streaming（） 失败时返回排队的缓冲区 vb2 框架在调用 start_streaming（） 之前通过 buf_queue（） 将缓冲区交给驱动程序。如果 start_streaming（） 返回错误但不首先通过 vb2_buffer_done（） 返回这些缓冲区，则 vb2_start_streaming（） 会触发 WARN_ON（owned_by_drv_count），并且排队的缓冲区会泄漏。当在执行任何设置（暂存缓冲区分配、管道启动）之前找不到匹配的 CSI 格式时，sun4i_csi_start_streaming（） 返回 -EINVAL。其余错误路径已汇聚在调用 csi->qlock 下的 return_all_buffers（...， VB2_BUF_STATE_QUEUED） 的 err_clear_dma_queue 标签上。直接跳转到该标签：中间err_disable_device/err_disable_pipeline/err_free_scratch_buffer标签会被跳过，这是正确的，因为它们尚未发生任何可撤消的事情。这反映了提交 4cf3b6fd54eb 中的 uvcvideo 补丁（media：uvcvideo：start_streaming（） 失败时返回排队的缓冲区）。（CVE-2026-68209）

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

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

  - drm/amdkfd：修复 CWSR 总大小计算中的 32 位溢出 total_cwsr_size在用作 BO/SVM 分配大小时以 32 位计算。通过大ctx_save_restore_area_size和debug_memory_size乘以 XCC 计数，该产品可以进行封装，从而产生一个较小的 CWSR 保存区域，固件稍后会溢出。将 total_cwsr_size 升级到 u64 并在 kfd_queue_acquire_buffers（） 和 kfd_queue_release_buffers（） 中使用 check_add_overflow（）/ check_mul_overflow（）。（从提交 319f7e13423ae3f486b9aea82f9ad2d6af0ee608 中精选出的内容）（CVE-2026-68257）

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

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

  - media：airspy：start_streaming（） 失败时返回已排入队列的缓冲区 vb2 框架在调用 start_streaming（） 之前，通过 buf_queue（） 将缓冲区交给驱动程序。如果 start_streaming（） 返回错误但不首先通过 vb2_buffer_done（） 返回这些缓冲区，则 vb2_start_streaming（） 会触发 WARN_ON（owned_by_drv_count），并且排队的缓冲区会泄漏。airspy_start_streaming（） 在 USB 设备断开连接 （s->udev == NULL） 时提早返回 -ENODEV，而不返回 buf_queue（） 已接受的任何缓冲区。先拿v4l2_lock，跳到现有的err_clear_bit标签，在解锁之前，它已经通过vb2_buffer_done（...， VB2_BUF_STATE_QUEUED）耗尽了 s->queued_bufs。这反映了提交 4cf3b6fd54eb 中的 uvcvideo 补丁（media：uvcvideo：start_streaming（） 失败时返回排队的缓冲区）。（CVE-2026-68231）

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

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

  - 已修复 Linux 内核中的下列漏洞：usb: atm: ueagle-atm: reject descriptors that confuse probe and disconnect uea_probe() distinguishes a pre-firmware device from a post-firmware one using the USB id (UEA_IS_PREFIRM()), and stores a different object as the interface data in each case: a 'struct completion' for a pre-firmware device (to be waited on in .disconnect()), or a 'struct usbatm_data' for a post-firmware one. uea_disconnect() instead tells the two apart by the number of interfaces of the active configuration (a pre-firmware device exposes a single interface, ADI930 has 2 and eagle has 3), and casts the interface data accordingly. Because the two handlers use different criteria, a crafted device that advertises a pre-firmware id together with a multi-interface descriptor (or a post-firmware id with a single interface) makes them disagree: the small 'struct completion' stored by uea_probe() is then passed to usbatm_usb_disconnect(), which casts it to 'struct usbatm_data' and takes instance->serialize, reading past the end of the allocation: BUG: KASAN: slab-out-of-bounds in
    __mutex_lock+0x152a/0x1b80 Read of size 8 at addr ffff8880470e2c60 by task kworker/1:2/982 ...
    __mutex_lock+0x152a/0x1b80 usbatm_usb_disconnect+0x70/0x820 uea_disconnect+0x133/0x2c0 usb_unbind_interface+0x1dd/0x9e0 ... which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes to the right of allocated 96-byte region [ffff8880470e2c00, ffff8880470e2c60) Reject such inconsistent descriptors in uea_probe() so that both handlers always make the same pre/post-firmware decision. (CVE-2026-68344)

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

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

  - drm/amdgpu：修复驱动程序加载失败期间的内核错误 避免驱动程序加载期间 MES init 失败时的内核错误。KIQ 环被错误标记为就绪，因为使用 MES 的 ASIC，KIQ 归 MES 所有。BUG：内核空指针取消引用，地址：0000000000000000 RIP：0010：gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] 调用跟踪：gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280
    __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53（从提交 4623b958dd6da0f4c3026afdf330626a09ecb0f0 中精选出的内容）（CVE-2026-68105）

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

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

  - firmware：arm_ffa：修复端点内存访问描述符偏移计算 使用描述符的“ep_mem_offset”计算端点内存访问数组的起始点，使其符合 FF-A 规范，而非默认为“sizeof（struct ffa_mem_region）”。这需要在设置流中移动“ffa_mem_region_additional_setup（）”。此外，添加健全性检查以确保计算的描述符偏移量不超过“max_fragsize”。（CVE-2026-68400）

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

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

  - drm/amdgpu/gfx10：将 BUG_ON（） 替换为 WARN_ON（） 这些情况下无需造成内核崩溃。
    （从提交 ac6f00beb658239bced4aaed9efbb04a35348d48 中精选出的内容）（CVE-2026-68115）

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

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

  - sched_ext：不就 put_prev_task_scx（） 中的 core-sched 强制空闲发出警告 put_prev_task_scx（） 会在可运行的任务在无SCX_OPS_ENQ_LAST的情况下降至较低sched_class时发出警告，前提是 balance_one（） 会使其保持运行。核心调度打破以下问题：强制空闲 SMT 同级通过 pick_next_task（） 中的core_pick快速路径重新调度，这会跳过 pick_task_scx（） 并因此跳过 balance_one（），因此可运行的任务可在未设置ENQ_LAST的情况下降至空闲状态。在 sched_cpu_cookie_match（） 上发出警告：cookie 不匹配意味着核心计划强制空闲，而匹配（或核心计划关闭）仍捕获真正的漏ENQ_LAST掉。（CVE-2026-68421）

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

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

  - tipc：清除 tipc_sk_create（） 中插入失败路径上的 sock->sk 当 tipc_sk_create（） 未能插入新套接字（tipc_sk_insert（） 返回非零）时，其错误路径将使用 sk_free（） 释放 sk，但使 sock->sk 指向已释放的对象： if （tipc_sk_insert（tsk）） { sk_free（sk）; pr_warn（套接字创建失败;端口号耗尽\n）; return -EINVAL; }这对普通 socket（） 无害：syscall 层在释放之前会清除 sock->ops，因此永远不会调用 tipc_release（）。它在 accept（） 路径上并非无害。tipc_accept（） 使用 tipc_sk_create（net， new_sock， 0， kern） 创建预分配的子套接字;失败时，它会使 new_sock->sk 悬摆，new_sock->ops 为非 NULL，然后 do_accept（） 然后 fput（） 新文件，因此 __sock_release（） -> tipc_release（） 在释放的 sk 上运行 lock_sock（new_sock->sk） -- sk_lock 自旋锁的释放后使用写入。tipc_release（） 已经保护此完全失败的 accept（） 释放预分配的子情况，if （sk == NULL） 返回 0;，但是由于 tipc_sk_create（） 保留 sock->sk 非 NULL（悬摆）而非 NULL，因此绕过了该保护。清除 failed-insert 路径中的 sock->sk，这样才能触发现有的 tipc_release（） NULL 检查并避免释放后使用。当 per-netns 套接字 rhashtable 达到其max_size（tsk_rht_params.max_size = 1048576，~2M 元素）时发生 tipc_sk_insert（） 故障，即一旦 netns 保留 ~2M TIPC 套接字，则每次插入都会返回 -E2BIG。缺陷：KASAN：lock_sock_nested 中的 slab-use-after-free （net/core/sock.c：3839） 在地址 ffff8880047cdc38 处按任务 init/1 写入大小为 8 lock_sock_nested （net/core/sock.c：3839） tipc_release （net/tipc/socket.c：638） __sock_release （net/socket.c：710） sock_close （net/socket.c：1501） __fput （fs/file_table.c：512） 按任务 1 分配：sk_alloc （net/core/sock.c：2308） tipc_sk_create （net/tipc/socket.c：487） tipc_accept （net/tipc/socket.c：2744） do_accept （net/socket.c：2034） 由任务 1 释放：__sk_destruct （net/core/sock.c：2391） tipc_sk_create （net/tipc/socket.c：504） tipc_accept （net/tipc/socket.c：2744） do_accept （net/socket.c：2034） （CVE-2026-68117）

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

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

  - drm/amdgpu/gfx12.1：将 BUG_ON（） 替换为 WARN_ON（） 这些情况下无需造成内核崩溃。
    （从提交 e4d99e04b2e9b13b97d3b17804c735f62689db23 中精选出的内容）（CVE-2026-68114）

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

ID	名称	严重性
334327	Linux Distros 未修补的漏洞：CVE-2026-68428	high
334326	Linux Distros 未修补的漏洞：CVE-2026-68164	medium
334325	Linux Distros 未修补的漏洞：CVE-2026-59090	critical
334324	Linux Distros 未修补的漏洞：CVE-2026-68255	high
334323	Linux Distros 未修补的漏洞：CVE-2026-68403	low
334322	Linux Distros 未修补的漏洞：CVE-2026-68360	critical
334321	Linux Distros 未修补的漏洞：CVE-2026-68098	high
334320	Linux Distros 未修补的漏洞：CVE-2026-68352	high
334319	Linux Distros 未修补的漏洞：CVE-2026-69184	high
334318	Linux Distros 未修补的漏洞：CVE-2026-68401	high
334317	Linux Distros 未修补的漏洞：CVE-2026-68093	medium
334316	Linux Distros 未修补的漏洞：CVE-2026-68160	critical
334315	Linux Distros 未修补的漏洞：CVE-2026-68355	low
334314	Linux Distros 未修补的漏洞：CVE-2026-68162	high
334313	Linux Distros 未修补的漏洞：CVE-2026-68354	high
334312	Linux Distros 未修补的漏洞：CVE-2026-68154	critical
334311	Linux Distros 未修补的漏洞：CVE-2026-68375	medium
334310	Linux Distros 未修补的漏洞：CVE-2026-68097	high
334309	Linux Distros 未修补的漏洞：CVE-2026-68140	high
334308	Linux Distros 未修补的漏洞：CVE-2026-68413	medium
334307	Linux Distros 未修补的漏洞：CVE-2026-68303	medium
334306	Linux Distros 未修补的漏洞：CVE-2026-68111	medium
334305	Linux Distros 未修补的漏洞：CVE-2026-68104	high
334304	Linux Distros 未修补的漏洞：CVE-2026-68197	medium
334303	Linux Distros 未修补的漏洞：CVE-2026-68349	critical
334302	Linux Distros 未修补的漏洞：CVE-2026-68229	high
334301	Linux Distros 未修补的漏洞：CVE-2026-68368	high
334300	Linux Distros 未修补的漏洞：CVE-2026-68363	high
334299	Linux Distros 未修补的漏洞：CVE-2026-68203	medium
334298	Linux Distros 未修补的漏洞：CVE-2026-68141	high
334297	Linux Distros 未修补的漏洞：CVE-2026-68302	critical
334296	Linux Distros 未修补的漏洞：CVE-2026-68407	critical
334295	Linux Distros 未修补的漏洞：CVE-2026-68382	high
334294	Linux Distros 未修补的漏洞：CVE-2026-68309	low
334293	Linux Distros 未修补的漏洞：CVE-2026-68300	critical
334292	Linux Distros 未修补的漏洞：CVE-2026-68315	high
334291	Linux Distros 未修补的漏洞：CVE-2026-68286	high
334290	Linux Distros 未修补的漏洞：CVE-2026-68102	medium
334289	Linux Distros 未修补的漏洞：CVE-2026-68405	medium
334288	Linux Distros 未修补的漏洞：CVE-2026-68103	high
334287	Linux Distros 未修补的漏洞：CVE-2026-68209	high
334286	Linux Distros 未修补的漏洞：CVE-2026-68257	high
334285	Linux Distros 未修补的漏洞：CVE-2026-68231	medium
334284	Linux Distros 未修补的漏洞：CVE-2026-68344	medium
334283	Linux Distros 未修补的漏洞：CVE-2026-68105	medium
334282	Linux Distros 未修补的漏洞：CVE-2026-68400	high
334281	Linux Distros 未修补的漏洞：CVE-2026-68115	medium
334280	Linux Distros 未修补的漏洞：CVE-2026-68421	medium
334279	Linux Distros 未修补的漏洞：CVE-2026-68117	critical
334278	Linux Distros 未修补的漏洞：CVE-2026-68114	medium

检测

Nessus 的 Misc. 系列

high

medium

critical

high

low

critical

high

high

high

high

medium

critical

low

high

high

critical

medium

high

high

medium

medium

medium

high

medium

critical

high

high

high

medium

high

critical

critical

high

low

critical

high

high

medium

medium

high

high

high

medium

medium

medium

high

medium

medium

critical

medium