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

  - io_uring/napi：上限busy_poll_to 10 毫秒 目前，未找到任何事件时 napi 可以轮询的最长时间没有上限，这可导致内核对任务卡住提出投诉，因为该循环内未进行有条件的重新安排。只需将其总计限制在 10 毫秒，这已经远远高于任何可以获得任何好处的合理值，但又足够低，以至于它远未能够触发抢占投诉。（CVE-2026-53321）

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

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

  - wifi：mt76：mt7921：对工作站 AID 设置上限 任何配置有超过 20 个 AID 的电台都会导致固件崩溃。我们在 7922 硬件上使用 AP 接口进行测试时出现此情况，并包含来源于 Mediatek 的 OpenWRT 源的经过修改的 hostapd。在库存 hostapd 中，站台 AID 从 1 开始计数，并且通过关联站的上限阻止此配置。然而，修改后的 hostapd 从 65 开始分配，导致固件崩溃。此补丁不允许这些 AID 正常工作，但会防止固件崩溃。此崩溃只出现在IFTYPE_AP接口上，该补丁似乎不会影响IFTYPE_STATION行为。（CVE-2026-53317）

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

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

  - wifi：cfg80211：强制执行 HE/EHT 端点/操作一致性 Xiang Mei 报告，如果 eht_cap 已设置但未设置eht_oper则 mac80211 可能会崩溃。与其为单个用户修复此问题，不如强制使 HE/EHT 具有一致的元素。（CVE-2026-53257）

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

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

  - Debian Linux - qemu - 无 Ubuntu Linux - [未知描述] （CVE-2026-48915）

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

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

  - NSD 版本 4.13.0 在记录有关 TLS 连接的错误时存在堆释放后使用缺陷，从而导致服务器进程崩溃，可通过 DoT 连接发送 DNS 查询并在未读取响应的情况下关闭连接轻易触发此漏洞。（CVE-2026-12245）

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

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

  - 如果为 provide-xfr 指定了 tls-auth-name，请求传输的辅助服务器应提供具有该名称的客户端证书。但是，当请求通过 TLS 经常规 tls-port（而非 tls-auth-port）传入或通过 TCP 经常规端口传入时，则不需要客户端证书，前提是 provide-xfr 规则的其他条件匹配。（CVE-2026-12490）

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

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

  - libssh2 through 从 1.11.1 publickey-subsystem 响应读取攻击者控制的 32 位属性计数，并在分配num_attrs * sizeof（libssh2_publickey_attribute） 中使用而不进行边界检查，因此在 32 位平台上乘法溢出到缓冲区过小。然后，恶意 SSH 服务器可驱动属性解析循环写入超出分配范围，从而在连接的 libssh2 客户端中造成堆缓冲区溢出。（CVE-2026-58050）

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

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

  - 已修复 Linux 内核中的下列漏洞：ice: fix potential NULL pointer deref in error path of ice_set_ringparam() ice_set_ringparam nullifies tstamp_ring of temporary tx_rings, without clearing ICE_TX_RING_FLAGS_TXTIME bit. When ICE_TX_RING_FLAGS_TXTIME is set and the subsequent ice_setup_tx_ring() call fails, a NULL pointer dereference could happen in the unwinding sequence:
    ice_clean_tx_ring() -> ice_is_txtime_cfg() == true (ICE_TX_RING_FLAGS_TXTIME is set) -> ice_free_tx_tstamp_ring() -> ice_free_tstamp_ring() -> tstamp_ring->desc (NULL deref) Clear ICE_TX_RING_FLAGS_TXTIME bit to avoid the potential issue. Note that this potential issue is found by manual code review. Compile test only since unfortunately I don't have E830 devices. (CVE-2026-53007)

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

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

  - drm/ttm：修复 ttm_bo_swapout（） 在交换失败时无限 LRU 经过 ttm_tt_swapout（） 失败时，当前代码先调用 ttm_resource_add_bulk_move（），接着调用 ttm_resource_move_to_lru_tail（） 以还原资源的 bulk_move 成员身份。但是，ttm_resource_move_to_lru_tail（） 将资源放在 LRU 列表的末尾，相对于遍历光标的挂钩节点（生成资源时紧接在资源之后），将资源放在挂钩的 * 前面。挂钩的下一个 list_for_each_entry_continue（） 再次找到相同的资源，从而造成无限循环。通过仅将del_bulk_move延迟到成功路径来修复。在成功路径上，ttm_tt_swapout（） 刚刚设置了TTM_TT_FLAG_SWAPPED，但仍在bulk_move范围内跟踪资源，因此 ttm_resource_del_bulk_move（） 的 ！ttm_resource_unevictable（） 保护将错误地跳过删除。
    引入绕过该保护的 ttm_resource_del_bulk_move_unevictable（）。（CVE-2026-52965）

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

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

  - FFmpeg 的 RASC 视频解码器（libavcodec/rasc.c 中的 decode_dlta）在 NEXT_LINE 行边界检查之前，在行光标处执行 32 位读取和写入，并以像素而非字节单位验证 DLTA 区域，因此，在 PAL8 帧上运行的 DLTA 可以访问超出行分配的多个字节。使用 RASC FourCC（由 libavcodec 解码）构建的媒体流会触发由比特流控制的越界堆写入和相邻越界读取，导致内存损坏。（CVE-2026-58049）

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

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

  - tcp：将SO_ATTACH_FILTER限制为 priv 用户 此修补程序可将 TCP 套接字上的 SO_ATTACH_FILTER （cBPF） 限制为具有CAP_NET_ADMIN能力的用户。这可阻止潜在的边信道攻击，即非特权应用程序附加过滤器以泄露 TCP 序列/确认号。（CVE-2026-53236）

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

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

  - 已修复 Linux 内核中的下列漏洞：accel/ethosu: fix arithmetic issues in dma_length() dma_length() derives DMA region usage from command stream values and updates region_size[]:
    len = ((len + stride[0]) * size0 + stride[1]) * size1 region_size[region] = max(..., len + dma->offset) Several arithmetic issues can corrupt the derived region size: - signed stride values may underflow when added to len - intermediate multiplications may overflow - len + dma->offset may overflow during region_size updates - dma_length() error returns were not validated by the caller region_size[] is later used by ethosu_job.c to validate command stream accesses against GEM buffer sizes. Arithmetic wraparound can therefore under-report region usage and bypass the bounds validation. Fix by validating signed additions, using overflow helpers for multiplications and offset updates, and propagating dma_length() failures to the caller. (CVE-2026-53171)

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

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

  - i3c：master：renesas：修复 renesas_i3c_i3c_xfers（） 中的内存泄漏 renesas_i3c_alloc_xfer（） 分配的 xfer 结构从未在 renesas_i3c_i3c_xfers（） 函数中得到释放。当变量超出范围时，使用 __free（kfree） cleanup 属性自动释放内存。（CVE-2026-53030）

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

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

  - ipv6：mcast：修复处理 MLD 查询时的释放后使用 当处理 MLD 查询时，最初解析数据包时会检索指向多播群组地址的指针。尽管 skb 标头可能已跟随 pskb_may_pull（） 调用进行重新分配，导致释放后使用 [1]，但随后也会取消引用此指针，而未重新加载。通过在初始解析数据包时复制多播群组地址进行修复。[1] 缺陷：KASAN：__mld_query_work 中的 slab-use-after-free （net/ipv6/mcast.c：1512） 任务 kworker/4:1/118 在地址 ffff8881154b8e90 处读取大小为 8 工作队列：mld mld_query_work 调用跟踪： <TASK> dump_stack_lvl （lib/dump_stack.c：94 lib/dump_stack.c：120） print_address_description.constprop.0 （mm/kasan/report.c：378） print_report （mm/kasan/report.c：482） kasan_report （mm/kasan/report.c：595） __mld_query_work （net/ipv6/mcast.c：1512） mld_query_work （net/ipv6/mcast.c：1563） process_one_work （kernel/workqueue.c：3314） worker_thread （kernel/workqueue.c：3397 kernel/workqueue.c：3478） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：158） ret_from_fork_asm （arch/x86/entry/entry_64.S：245） </TASK> [...]由任务 118 释放：kasan_save_stack （mm/kasan/common.c：57） kasan_save_track （mm/kasan/common.c：78） kasan_save_free_info （mm/kasan/generic.c：584） __kasan_slab_free （mm/kasan/common.c：253 mm/kasan/common.c：285） kfree （./include/linux/kasan.h：235 mm/slub.c：2689 mm/slub.c：6251 mm/slub.c：6566） pskb_expand_head （net/core/skbuff.c：2335） __pskb_pull_tail （net/core/skbuff.c：2878 （discriminator 4）） __mld_query_work （net/ipv6/mcast.c：1495 （discriminator1）） mld_query_work （net/ipv6/mcast.c：1563） process_one_work （kernel/workqueue.c：3314） worker_thread （kernel/workqueue.c：3397 kernel/workqueue.c：3478） kthread （kernel/kthread.c：436） ret_from_fork （arch/x86/kernel/process.c：158） ret_from_fork_asm （arch/x86/entry/entry_64.S：245） （CVE-2026-53275）

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

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

  - nvmem：core：修复错误路径中的释放后使用缺陷 修复我们在其中调用的错误路径的多个实例
    __nvmem_device_put（） - 这最终可能会释放底层内存和其他资源 - 然后继续使用 nvmem 结构。始终将对 nvmem 设备的引用作为返回错误代码之前的最后一步。（CVE-2026-53156）

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

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

  - iommu/vt-d：避免空指针取消引用或引用计数损坏 提交 60f030f7418d（iommu/vt-d：避免在WARN_ON_ONCE后使用 NULL） 在不太可能的情况下部分修复了空指针取消引用。如果在dev_pasids列表中找不到dev_pasid，则它仍然保持 NULL。但是会无条件执行拆卸操作，这会导致空指针取消引用或引用计数损坏。如果域从未附加到此 IOMMU，则 info 将为空，这会在检查 --info->refcnt 时造成立即取消引用。即使 info 不是 NULL，在不删除有效 PASID 的情况下递减 refcount 也可能会使计数不平衡。这可能导致 refcount 过早降至 0，从而可能对共享域的其余活动设备造成释放后使用。如果dev_pasid为 NULL，则通过在执行拆卸操作之前提早返回来修复此问题。问题由 AI 审查发现，并由 Kevin Tian 提出建议。
    https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com (CVE-2026-53281)

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

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

  - 在 QEMU 的 VNC 服务器实现 （ui/vnc.c） 中，set_pixel_format（） 函数未正确验证客户端 sSetPixelFormat 消息中的red_max、green_max和blue_max字段。这些字段作为 16 位值接收，但作为 uint8_t 存储在内部。恶意 VNC 客户端可发送大于 255 的最大值（例如 0x0100），该值通过现有的非零验证检查，但在分配时静默截断为 0，从而导致 Tight PNG 调色板编码路径中的除零。这允许远程攻击者使 QEMU 进程崩溃，从而导致该 QEMU 实例服务的所有客户机拒绝服务。已在 QEMU v11.0.3 和 v10.0.12 中修复。（CVE-2026-15578） 在 QEMU 的 USB 重定向 （usbredir） 实现中，hw/usb/redirect.c 的 usbredir_buffered_bulk_packet（） 函数中存在释放后使用漏洞。处理拆分为 max-packet-size 区块的多片段缓冲批量数据包时，只有最终片段拥有共享的解析器内存分配（通过 free_on_destroy）。如果 bufp_alloc（） 由于队列溢出而丢弃最后一个片段，它会释放后备缓冲区，而已排队的较早片段仍保留内部指针。然后，后续客户机批量输入传输从释放的堆内存中读取。恶意或遭到破坏的 USB 设备（或特制的 usbredir 流）可触发此条件，可能导致堆内存中信息泄露或 QEMU 进程崩溃（拒绝服务）。此漏洞自 QEMU v1.4.0-rc0 起即存在，并已在 v11.0.3 和 v10.0.12 中修复。（CVE-2026-15705） 跟踪工作线程中的有损矩形时，错误计算边界条件将导致越界写入，这可损坏进一步的工作状态，和/或触发 VncWorker 结构之外的任何保护页面。非特权用户在客户机操作系统中仔细选择显示分辨率可触发此漏洞。（CVE-2026-48002） vnc_update_freq 中错误的循环边界导致迭代超过最后一行并超过最后一列 VNC 统计数据数组中的最后一列。
    通过适当选择的维度，这可能是访问嵌入统计数据数组的 VncDisplay 结构之外的内存的 OOB 读取。如果这发生在保护页面上，可能触发客户机崩溃。如果不同步，则将用垃圾更新 VNC 频率统计数据。（CVE-2026-48003） 在 QEMU 的 VNC 服务器实现 （ui/vnc.c） 中，有损平铺刷新期间标记脏位图行时，vnc_refresh_lossy_rect（） 函数包含一个越界写入漏洞。该函数无条件地为每个平铺标记整整 VNC_STAT_RECT （64） 行的脏位图。如果显示高度不是 64 像素的倍数，则最后一个平铺行是部分平铺，并且循环写入超过 vs->dirty[VNC_MAX_HEIGHT] 数组的末尾。例如，对于 2160 像素高的显示器，最后一个统计信息磁贴从 y=2112 开始，并且 64 行循环将行写入行 2112-2175，将 16 行（640 字节）溢出，超过脏位图到后续的 VncState 字段中。恶意 VNC 客户端可能会协商特定的显示分辨率，从而利用此堆缓冲区溢出损坏 QEMU 进程内存，从而导致拒绝服务或可能执行任意代码。已在 QEMU v11.0.3 和 v10.0.12 中修复。（CVE-2026-61475） 在 QEMU 的 USB 重定向 （usbredir） 实现 （hw/usb/redirect.c） 中，恶意的 usbredir 对等机可发送 ep_info 消息，在批量接收已经开始之后将 max_packet_size 重置为 0。这会导致多种可利用的情况：（1） usbredir_buffered_bulk_packet（） 中的无限循环，其中拆分循环递max_packet_size增 （0） 且从未进行，（2） usbredir_buffered_bulk_in_complete_ftdi（） 中的 SIGFPE（浮点异常）来自模数除零运算，以及 （3） usbredir_handle_buffered_bulk_in_data（） 中的 SIGFPE 在计算bytes_per_transfer时来自除零。恶意 USB 重定向对等机可利用此问题导致 QEMU 进程崩溃（拒绝服务）或造成其无限期挂起。已在 QEMU v11.0.3 和 v10.0.12 中修复。（CVE-2026-63319） 在 QEMU 的 9pfs （virtio-9p） 实现中，TXATTRCREATE 和 TXATTRWALK 请求处理程序不会限制同时打开的 xattr FID 的数量。每个 xattr FID 都会为扩展的属性值分配主机内存缓冲区。可直接访问 9p 服务器的恶意特权客户机用户可通过在不关闭 xattr FID 的情况下重复创建 xattr FID，来利用此漏洞，导致无限的主机内存消耗和最终的主机内存耗尽（拒绝服务）。此漏洞自 QEMU v0.14.0-rc0 开始存在，并已在 v11.0.3 和 v10.0.12 中得到修复。（CVE-2026-8348） 在管理程序主机环境（例如 QEMU）中，libslirp v4.9.2 之前版本内的 TCP 紧急数据处理 （sosendoob freedesktop.org 存在越界堆读取和整数下溢，允许特权客户机 VM 攻击者（根或CAP_NET_RAW）通过发送带有操纵的 URG 标志和紧急指针的特制 TCP 段，泄露数 GB 的敏感主机进程堆内存 （ti_urp）。（CVE-2026-9539）CVE-2026-48002 （）

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

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

  - PCI：tegra194：修复由核心开机前的 DBI 访问造成的 CBB 超时 当 PERST# 被取消断言两次 （assert -> deassert -> assert -> deassert） 时，DBI 寄存器偏移0x8bc发生 CBB（控制主干）超时 （PCIE_MISC_CONTROL_1_OFF）。这是因为在 reset_control_deassert（） 打开控制器核心电源之前调用了 pci_epc_deinit_notify（） 和 dw_pcie_ep_cleanup（）。导致超时的调用链：pex_ep_event_pex_rst_deassert（） pci_epc_deinit_notify（） pci_epf_test_epc_deinit（） pci_epf_test_clear_bar（） pci_epc_clear_bar（） dw_pcie_ep_clear_bar（） __dw_pcie_ep_reset_bar（） dw_pcie_dbi_ro_wr_en（） <- 访问 0x8bc DBI 寄存器 reset_control_deassert（pcie->core_rst） <- 核心已打开 HERE DBI 寄存器， 包括 PCIE_MISC_CONTROL_1_OFF （0x8bc） 在内，只能在控制器核心通过 reset_control_deassert （PCIe->core_rst） 通电后才能访问。在此时间点之前访问它们会导致 CBB 超时，因为硬件尚未运行。通过将 pci_epc_deinit_notify（） 和 dw_pcie_ep_cleanup（） 移动到之后 reset_control_deassert（pcie->core_rst） 来修复此问题，确保在任何 DBI 寄存器访问发生之前控制器已完全通电。（CVE-2026-53051）

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

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

  - thunderbolt：将 XDomain 响应数据复制限制为分配大小 tb_xdp_properties_request（） 从响应头派生每个数据包的复制长度，而不检查其是否适合以前分配的数据缓冲区。恶意对等可将其长度字段设置为大于声明的data_length，从而导致 memcpy 写入超过 kcalloc 分配。限制每个数据包的复制长度，使累积偏移量永远不会超过 data_len。（CVE-2026-53148）

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

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

  - 在 QEMU 的 VNC 服务器实现 （ui/vnc.c） 中，set_pixel_format（） 函数未正确验证客户端 sSetPixelFormat 消息中的red_max、green_max和blue_max字段。这些字段作为 16 位值接收，但作为 uint8_t 存储在内部。恶意 VNC 客户端可发送大于 255 的最大值（例如 0x0100），该值通过现有的非零验证检查，但在分配时静默截断为 0，从而导致 Tight PNG 调色板编码路径中的除零。这允许远程攻击者使 QEMU 进程崩溃，从而导致该 QEMU 实例服务的所有客户机拒绝服务。已在 QEMU v11.0.3 和 v10.0.12 中修复。（CVE-2026-15578） 在 QEMU 的 USB 重定向 （usbredir） 实现中，hw/usb/redirect.c 的 usbredir_buffered_bulk_packet（） 函数中存在释放后使用漏洞。处理拆分为 max-packet-size 区块的多片段缓冲批量数据包时，只有最终片段拥有共享的解析器内存分配（通过 free_on_destroy）。如果 bufp_alloc（） 由于队列溢出而丢弃最后一个片段，它会释放后备缓冲区，而已排队的较早片段仍保留内部指针。然后，后续客户机批量输入传输从释放的堆内存中读取。恶意或遭到破坏的 USB 设备（或特制的 usbredir 流）可触发此条件，可能导致堆内存中信息泄露或 QEMU 进程崩溃（拒绝服务）。此漏洞自 QEMU v1.4.0-rc0 起即存在，并已在 v11.0.3 和 v10.0.12 中修复。（CVE-2026-15705） 跟踪工作线程中的有损矩形时，错误计算边界条件将导致越界写入，这可损坏进一步的工作状态，和/或触发 VncWorker 结构之外的任何保护页面。非特权用户在客户机操作系统中仔细选择显示分辨率可触发此漏洞。（CVE-2026-48002） vnc_update_freq 中错误的循环边界导致迭代超过最后一行并超过最后一列 VNC 统计数据数组中的最后一列。
    通过适当选择的维度，这可能是访问嵌入统计数据数组的 VncDisplay 结构之外的内存的 OOB 读取。如果这发生在保护页面上，可能触发客户机崩溃。如果不同步，则将用垃圾更新 VNC 频率统计数据。（CVE-2026-48003） 在 QEMU 的 VNC 服务器实现 （ui/vnc.c） 中，有损平铺刷新期间标记脏位图行时，vnc_refresh_lossy_rect（） 函数包含一个越界写入漏洞。该函数无条件地为每个平铺标记整整 VNC_STAT_RECT （64） 行的脏位图。如果显示高度不是 64 像素的倍数，则最后一个平铺行是部分平铺，并且循环写入超过 vs->dirty[VNC_MAX_HEIGHT] 数组的末尾。例如，对于 2160 像素高的显示器，最后一个统计信息磁贴从 y=2112 开始，并且 64 行循环将行写入行 2112-2175，将 16 行（640 字节）溢出，超过脏位图到后续的 VncState 字段中。恶意 VNC 客户端可能会协商特定的显示分辨率，从而利用此堆缓冲区溢出损坏 QEMU 进程内存，从而导致拒绝服务或可能执行任意代码。已在 QEMU v11.0.3 和 v10.0.12 中修复。（CVE-2026-61475） 在 QEMU 的 USB 重定向 （usbredir） 实现 （hw/usb/redirect.c） 中，恶意的 usbredir 对等机可发送 ep_info 消息，在批量接收已经开始之后将 max_packet_size 重置为 0。这会导致多种可利用的情况：（1） usbredir_buffered_bulk_packet（） 中的无限循环，其中拆分循环递max_packet_size增 （0） 且从未进行，（2） usbredir_buffered_bulk_in_complete_ftdi（） 中的 SIGFPE（浮点异常）来自模数除零运算，以及 （3） usbredir_handle_buffered_bulk_in_data（） 中的 SIGFPE 在计算bytes_per_transfer时来自除零。恶意 USB 重定向对等机可利用此问题导致 QEMU 进程崩溃（拒绝服务）或造成其无限期挂起。已在 QEMU v11.0.3 和 v10.0.12 中修复。（CVE-2026-63319） 在 QEMU 的 9pfs （virtio-9p） 实现中，TXATTRCREATE 和 TXATTRWALK 请求处理程序不会限制同时打开的 xattr FID 的数量。每个 xattr FID 都会为扩展的属性值分配主机内存缓冲区。可直接访问 9p 服务器的恶意特权客户机用户可通过在不关闭 xattr FID 的情况下重复创建 xattr FID，来利用此漏洞，导致无限的主机内存消耗和最终的主机内存耗尽（拒绝服务）。此漏洞自 QEMU v0.14.0-rc0 开始存在，并已在 v11.0.3 和 v10.0.12 中得到修复。（CVE-2026-8348） 在管理程序主机环境（例如 QEMU）中，libslirp v4.9.2 之前版本内的 TCP 紧急数据处理 （sosendoob freedesktop.org 存在越界堆读取和整数下溢，允许特权客户机 VM 攻击者（根或CAP_NET_RAW）通过发送带有操纵的 URG 标志和紧急指针的特制 TCP 段，泄露数 GB 的敏感主机进程堆内存 （ti_urp）。（CVE-2026-9539）CVE-2026-48003 （）

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

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

  - ipv6：修复 cleanup_prefix_route（） 中的潜在 NPD addrconf_get_prefix_route（） 可返回具有空fib6_table指针的fib6_null_entry sentinel 条目。因此，在设置路由的到期时间之前，请检查我们是否没有使用此条目，否则将触发 NPD [1]。
    请注意，addrconf_get_prefix_route（） 的其他调用程序不易受到此缺陷的影响：1.
    addrconf_prefix_rcv（）：请求包含“RTF_ADDRCONF |RTF_PREFIX_RT“标记，这些标记未在fib6_null_entry上设置。2. modify_prefix_route（）：已通过提交 a747e02430df 修复（ipv6：避免 modify_prefix_route（）） 中可能的空取消引用）。3. __ipv6_ifa_notify（）：调用专门检查fib6_null_entry并返回错误的 ip6_del_rt（）。[1] 哎呀：一般保护错误，可能针对非规范地址 0xdffffc0000000006：0000 [#1] SMP KASAN KASAN：范围内的 null-ptr-deref [0x0000000000000030-0x0000000000000037] [...]调用跟踪： <TASK> __kasan_check_byte （mm/kasan/common.c：573） lock_acquire.part.0 （kernel/locking/lockdep.c：5842 （discriminator 1））
    _raw_spin_lock_bh （kernel/locking/spinlock.c：182 （discriminator 1）） cleanup_prefix_route （net/ipv6/addrconf.c：1280） ipv6_del_addr （net/ipv6/addrconf.c：1342） inet6_addr_del.isra.0 （net/ipv6/addrconf.c：3119） inet6_rtm_deladdr （net/ipv6/addrconf.c：4812） rtnetlink_rcv_msg （net/core/rtnetlink.c：6997） netlink_rcv_skb （net/netlink/af_netlink.c：2555） netlink_unicast （net/netlink/af_netlink.c：1344） netlink_sendmsg （net/netlink/af_netlink.c：1899） __sock_sendmsg （net/socket.c：802 （判别器 4）） ____sys_sendmsg （net/socket.c：2698） ___sys_sendmsg （net/socket.c：2752） __sys_sendmsg （net/socket.c：2784） 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） （CVE-2026-53214）

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

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

  - ip6_vti：修复 vti6_tnl_lookup（） 中不正确的隧道匹配 在 vti6_tnl_lookup（） 中，当隧道的完全匹配失败时，代码会回退到搜索通配符隧道： - 与数据包的本地地址匹配的隧道，具有任何远程通配符远程地址）。- 与数据包的远程地址匹配的隧道，具有任何本地地址（本地通配符）。但 vti6 将所有这些不同类型的隧道存储在同一个容易遭受哈希冲突的哈希表 （ip6n->tnls_r_l） 中。缺陷是 vti6_tnl_lookup（） 中的回退搜索循环缺少用于确保候选隧道实际上具有通配符地址的检查。
    (CVE-2026-53221)

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

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

  - md：暂停前唤醒 raid456 reshape 等待程序 在 raid456 reshape 期间，reshape 位置上的直接 IO 可在 raid5_make_request（） 中休眠以等待 reshape 进度，同时仍保留active_io引用。如果用户空间随后冻结 reshape 并写入 md/suspend_lo 或 md/suspend_hi，则 mddev_suspend（） 会终止active_io并等待所有正在传输的 IO 耗尽。这可能会死锁：IO 需要 reshape 进度才能继续，但 reshape 线程已冻结，因此 active_io 引用永远不会丢失，暂停也不会完成。raid5_prepare_suspend（） 已为 dm-raid 唤醒wait_for_reshape。当 reshape 已经中断时，对正常 md 暂停执行相同的操作，因此等待 raid456 IO 可中止、终止其引用并让暂停完成。mdadm 测试 tests/25raid456-reshape-deadlock 重现了挂起情况。
    (CVE-2026-53123)

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

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

  - 已修复 Linux 内核中的下列漏洞：accel/ethosu: fix IFM region index out-of-bounds in command stream parser NPU_SET_IFM_REGION extracts the region index with param & 0x7f, giving a maximum value of 127. However region_size[] and output_region[] in struct ethosu_validated_cmdstream_info are both sized to NPU_BASEP_REGION_MAX (8), giving valid indices [0..7].
    Every other region assignment in the same switch uses param & 0x7: NPU_SET_OFM_REGION: st.ofm.region = param & 0x7; NPU_SET_IFM2_REGION: st.ifm2.region = param & 0x7; NPU_SET_WEIGHT_REGION: st.weight[0].region = param & 0x7; NPU_SET_SCALE_REGION: st.scale[0].region = param & 0x7; The 0x7f mask on IFM is inconsistent and appears to be a typo. feat_matrix_length() and calc_sizes() use the region index directly as an array subscript into the kzalloc'd info struct: info->region_size[fm->region] = max(...); A userspace caller supplying NPU_SET_IFM_REGION with param > 7 causes a write up to 127*8 = 1016 bytes past the start of region_size[], corrupting adjacent kernel heap data. Fix by applying the same & 0x7 mask used by all other region assignments. (CVE-2026-53172)

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

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

  - 如果 NSD 配置为区域的辅助服务器，则该区域的主服务器可通过包含 DNS 消息的 AXFR 造成 NSD 崩溃，其中含有特别构建的 SVCB RR 的 rdata 大小为 65512，这为一个用于分配 RR 封装所需空间的 （uint16_t） 变量（因为总大小> 65535）， 造成堆溢出。攻击者可执行多达 65509 字节的受控（RCE 类）头写入 （CVE-2026-12244）

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

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

  - 对目录区域中存在的 SOA 记录的不完整验证可能导致崩溃。（CVE-2026-42388）

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

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

  - Bluetooth：修复 hci_alloc_dev（） 错误路径中的内存泄漏 Bluetooth HCI 中的早期失败 UART 配置泄漏 SRCU percpu 内存。如果在 hci_register_dev（） 完成之前设备初始化失败，则永远不会设置 HCI_UNREGISTER 标记。因此，当设备引用计数达到零时，bt_host_release（） 会将此标记评估为 false，并回退到直接 kfree（hdev）。由于绕过了 hci_release_dev（），所以 hci_alloc_dev（） 中早期初始化的 SRCU 结构永远不会被清理，从而导致 percpu 内存泄漏。通过在释放设备之前显式调用 bt_host_release（） 的回退（未注册）分支中的 cleanup_srcu_struct（），修复泄漏。（CVE-2026-53252）

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

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

  - ALSA：seq：dummy：修复 UMP 事件堆栈越界读取 虚拟排序器端口通过将传入的 struct snd_seq_event复制到堆栈临时、重写源和目标并将临时分发到订阅者来转发事件。该旧事件存储比结构snd_seq_ump_event小。当 UMP 事件到达虚拟客户端时，副本会保留 UMP 标记集，但仅提供旧大小的堆栈存储。然后，订阅者传送路径使用 snd_seq_event_packet_size（） 并从该堆栈对象复制 UMP 大小的数据包，读取超过临时堆栈的末尾。使用现有 union __snd_seq_event 存储并复制针对传入事件报告的数据包大小，然后再重写通用路由字段。这样可以为 UMP 事件保留完整的 UMP 数据包，同时保持旧事件处理不变。
    (CVE-2026-53241)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: psp: require admin permission for dev-set and key-rotate The dev-set and key-rotate netlink operations modify shared device state (PSP version configuration and cryptographic key material, respectively) but do not require CAP_NET_ADMIN. The only access control is psp_dev_check_access() which merely verifies netns membership. (CVE-2026-52978)

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

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

  - tee：shm：修复 register_shm_helper（） 中的 shm 泄漏 register_shm_helper（） 在调用 iov_iter_npages（） 之前分配 shm。如果 iov_iter_npages（） 返回 0，函数会跳至 err_ctx_put 并泄露 shm。可通过具有长度为 0 的 struct tee_ioctl_shm_register_data TEE_IOC_SHM_REGISTER触发此问题。请跳转到err_free_shm。（CVE-2026-53210）

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

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

  - iommu/dma：不尝试在 swiotlb iommu_dma_iova_link_swiotlb（） 处理在三个部分（头部、中间部和尾部）中未对齐的映射时iommu_map 0 长度区域。如果中间为空，因为没有对齐的页面，它将向下调用大小为 0 的 iommu_map（），iommupt 实现将因非法而失败。然后，它尝试执行错误展开并从错误的位置开始，从而损坏映射，因此最终销毁会触发WARN_ON。检查长度为 0 并避免映射，使用偏移而不是 0 作为取消链接的起点。这通常是通过使用某些类型的 Thunderbolt NVMe 驱动器触发未对齐内存的强制 SWIOTLB 来触发的。NVMe 似乎会针对来自遇到此情况的 smartctl 的传递命令传入奇怪对齐的缓冲区。（CVE-2026-53164）

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

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

  - Debian Linux - qemu - 无 Ubuntu Linux - ui：修复 VNC 扩展剪贴板数据长度 （CVE-2026-8343） 的验证

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

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

  - net：将 pskb_may_pull（） 添加到 skb_gro_receive_list（） skb_gro_receive_list（） 调用 skb_pull（skb， skb_gro_offset（skb）），而不必首先通过 pskb_may_pull（） 确保数据处于线性区域中。当 skb 通过 napi_gro_frags（） 到达时，skb_headlen可以是 0（页面片段中的所有数据），而 skb_gro_offset 则不是零（在 IP+TCP 标头解析之后）。然后 skb_pull（） 会递减 skb->len skb_gro_offset，但 skb->data_len 保持不变，命中 __skb_pull（） 中的 BUG_ON（skb->len < skb->data_len）。UDP fraglist GRO 路径在 udp_offload.c：749 处已包含此防护。将其添加到 skb_gro_receive_list（） 本身可为所有调用程序（TCP、UDP 和任何未来的协议）提供集中保护，并确保在调用 skb_pull（） 之前满足其先决条件。pskb_may_pull（） 失败时，设置 NAPI_GRO_CB（skb）->flush = 1，这样 skb 就不会作为新的 GRO 头保留，而是通过符合 UDP 处理的普通接收路径进行传送。（CVE-2026-53235）

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

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

  - ksmbd：修复双重SMB2_CANCEL上延迟的file_lock释放后使用 延迟的字节范围锁定（阻止的 SMB2_LOCK）通过 setup_async_work（） 在 conn->async_requests 上注册异步工作，其中 cancel_fn = smb2_remove_blocked_lock 且指向结构file_lock cancel_argv[0]。当请求被取消时，工作线程使用 locks_free_lock（） 释放file_lock并采用已取消的提前退出，该退出会转到输出并且永远不会到达 release_async_work（） -- 唯一从连接>async_requests取消工作链接并清除 cancel_fn/cancel_argv 的站点。因此，在async_requests上，工作与指向已释放file_lock的实时cancel_fn保持可匹配，直到连接破坏最终运行 release_async_work（）。smb2_cancel（） 在没有状态防护的情况下无条件触发 cancel_fn，因此到达该窗口的相同 AsyncId 的第二个SMB2_CANCEL将在释放的 file_lock上重新运行 smb2_remove_blocked_lock（） -- slab 释放后使用： 缺陷： KASAN： __locks_delete_block 中的 slab-after-free
    __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 第二次SMB2_CANCEL触发 cancel_fn handle_ksmbd_work 分配者 ...： locks_alloc_lock <- smb2_lock 释放者 ...： locks_free_lock <- smb2_lock（已取消的分支）...大小为 192 的缓存file_lock_cache由经身份验证的 SMB 客户端在干线上使用 KASAN 重现。跳过状态已KSMBD_WORK_CANCELLED的工作，因此无法再次触发其取消回调。（CVE-2026-53198）

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

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

  - macvlan：修复 macvlan_get_size（） 未为 IFLA_MACVLAN_BC_CUTOFF macvlan_get_size（） 预留空间不考虑IFLA_MACVLAN_BC_CUTOFF，但 macvlan_fill_info（） 在 port->bc_cutoff ！= 1 时有条件将其包括在内。当 netlink skb 空间不足时，这会导致 nla_put_s32（） 因 -EMSGSIZE 而失败，从而触发 rtnetlink 中的WARN_ON并阻止转储接口。可通过以下方式重现该缺陷：ip 链接添加 macvlan0 链接 eth0 类型 macvlan 模式桥接 ip 链接设置 macvlan0 类型 macvlan bc_cutoff 0 ip -d 链接显示 macvlan0 # 因 -EMSGSIZE 失败 提交 954d1fa1ac93 中添加了bc_cutoff功能（macvlan：为广播中断添加 netlink 属性），这在 macvlan_fill_info（） 中添加了 nla_put_s32（） 调用，但缺少在 macvlan_get_size（） 中添加相应的 nla_total_size（4）。后续提交 55cef78c244d（macvlan：为 IFLA_MACVLAN_BC_CUTOFF 添加忘记的nla_policy）修复了缺少的 nla_policy 条目，但仍未修复大小计算。（CVE-2026-53013）

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

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

  - ksmbd：修复 durable v2 open ksmbd_lookup_fd_cguid（） 中 ClientGUID 不匹配的持久 fd 泄漏 返回ksmbd_file，其 refcount 通过 ksmbd_fp_get（） 递增。DURABLE_REQ_V2情况下的 parse_durable_handle_context（） 会在 ClientGUID-match 分支的每一个路径上正确释放此引用，方法是调用 ksmbd_put_durable_fd（） 或将所有权转移至 dh_info->fp 以便成功重新连接。但是，当全局文件表中存在具有相同 CreateGuid 但不同 ClientGUID 的条目时，代码只会回到 new-open 路径，而不丢弃从 ksmbd_lookup_fd_cguid（） 获取的引用。根据 MS-SMB2 部分 3.3.5.9.10 （处理SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2创建上下文），服务器必须找到 Open，其 Open.CreateGuid 与请求的 CreateGuid 匹配，并且其 Open.ClientGuid 与接收请求的连接的 ClientGuid 匹配。如果未找到此类打开，服务器必须继续进行正常的打开执行阶段。因此，ClientGUID 不匹配的 CreateGuid 命中就是找不到 Open 的情况：
    继续新的打开是正确的，但绝不能泄漏纯粹作为查找的副作用而获得的引用。重复请求命中此不匹配的 pin 条目global_ft，阻止
    __ksmbd_close_fd（） 从未为相应文件运行，并击败持久清理程序，从而导致长时间的资源泄漏。释放不匹配路径中的引用并清除 dh_info->fp，以便后续逻辑不会将不匹配的查找结果误认为重新连接目标。（CVE-2026-52996）

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

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

  - net/mlx5e：xsk：修复 xmit 失败时的 DMA XDP_TX xdp_frame泄漏 在 mlx5e_xmit_xdp_buff（） 的 XSK 分支中，当 sq->xmit_xdp_frame（） 返回 false（如 XDPSQ 已满）时，该函数在不取消映射 DMA 地址或释放 xdp_convert_zc_to_xdp_frame（） 分配的xdp_frame的情况下返回。xdpi_fifo推送仅在成功时发生，因此完成路径无法恢复这些条目。CONFIG_DMA_API_DEBUG=y 时，驱动程序 unbind 上的泄露浮出水面：DMA-API：pci 0000：08：00.0：从设备释放时，设备驱动程序具有待定的 DMA 分配 [count=1116] 其中一个泄漏的条目详细信息：[device address=0x000000010ffd7028] [size=1534 bytes] [映射为 DMA_TO_DEVICE] [映射为 phy] 警告：
    kernel/dma/debug.c：881 在 dma_debug_device_change+0x127/0x180 ... DMA-API：映射到：
    debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] 添加缺失的取消映射 + xdp_return_frame，以匹配 mlx5e_xdp_xmit（） 中已完成的清理。has_frags在此分支较早阶段遭到拒绝，因此不需要每个 frag 取消映射。
    (CVE-2026-53229)

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

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

  - 已修复 Linux 内核中的下列漏洞：mm/huge_memory: use correct flags for device private PMD entry Commit 65edfda6f3f2 (mm/rmap: extend rmap and migration support device-private entries) updated set_pmd_migration_entry() to use pmdp_huge_get_and_clear() in the softleaf case, but made no further adjustments to the function itself. Therefore this function continues to incorrectly use pmd_write(), pmd_soft_dirty() and pmd_uffd_wp() to determine whether the installed migration entry should be marked writable, softdirty or uffd-wp respectively. Whilst all are incorrect, the most problematic of these is pmd_write(), as this can lead to corrupted rmap state. On x86-64 _PAGE_SWP_SOFT_DIRTY is aliased to _PAGE_RW. So calling pmd_write() on a softleaf will return the softdirty state encoded in the entry, assuming CONFIG_MEM_SOFT_DIRTY was enabled. This was observed when running the hmm.hmm_device_private.anon_write_child selftest: 1. The test faults in a range then migrates it such that a device-private THP range is established. 2. The parent then migrates it to a device-private writable PMD entry whose folio is entirely AnonExclusive with entire_mapcount=1, softdirty set (accidentally correct write state). 3. The parent forks and the PMD entries are set to device-private read only entries, entire_mapcount=2, softdirty still set. 4. [BUG] The child writes to the range then migrates to RAM - intending to install non-writable migration entries - but replacing parent and child PMD mappings with WRITABLE entries due to misinterpreting the softdirty bit. 5. In remove_migration_pmd(), if !softleaf_is_migration_read(entry) we set the RMAP_EXCLUSIVE flag when calling folio_add_anon_rmap_pmd() for both parent and child, which are therefore AnonExclusive. 6. [SPLAT] Child sets migrated folio entire_mapcount=1, parent sets entire_mapcount=2 and we end up with an AnonExclusive folio with entire_mapcount=2! Assert fires in __folio_add_anon_rmap(): VM_WARN_ON_FOLIO(folio_test_large(folio) && folio_entire_mapcount(folio) > 1 && PageAnonExclusive(cur_page), folio) This patch fixes the issue by correctly referencing the softleaf entry fields for writable, softdirty and uffd-wp in set_pmd_migration_entry(). It also only updates A/D flags if the entry is present as these are otherwise not meaningful for a softleaf entry. This patch also flips the if (!present) { ... } else { ... } logic in set_pmd_migration_entry() so it is easier to understand, and adds some comments to make things clearer. I was able to bisect this to commit 775465fd26a3 (lib/test_hmm: add zone device private THP test infrastructure) which first exposes this bug as it was the commit that permitted test_hmm to generate the test. However commit 65edfda6f3f2 (mm/rmap: extend rmap and migration support device-private entries) is the commit that actually enabled this behaviour. (CVE-2026-53155)

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

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

  - drm/virtio：修复 virtio_gpu_dma_fence_wait（） 中出错时dma_fence refcount 泄漏 dma_fence_unwrap_for_each（） 在内部调用 dma_fence_unwrap_first（），其执行 cursor->chain = dma_fence_get（head），并获取额外的引用。正常循环完成时，dma_fence_unwrap_next（） 通过 dma_fence_chain_walk（） -> dma_fence_put（） 释放此循环。当 virtio_gpu_do_fence_wait（） 失败且函数从循环内部提早返回时，永远不会释放游标>链引用。这是整个内核中唯一在dma_fence_unwrap_for_each内部进行提早返回的调用程序。提前返回前添加 dma_fence_put（itr.chain）。（CVE-2026-53190）

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

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

  - padata：将 CPU 离线回调置于 ONLINE 部分以允许失败 syzbot 报告以下警告：
    CPU1 的 DEAD 回调错误 警告：kernel/cpu.c：1463 at _cpu_down+0x759/0x1020 kernel/cpu.c：1463， CPU#0：在提交 4ae12d8bd9a8（合并 git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux 的“kbuild-fixes-7.0-2”标签“kbuild-fixes-7.0-2”）时的 syz.0.1960/14614，tglx 将其跟踪到 padata_cpu_dead（），因为它是唯一返回错误的子CPUHP_TEARDOWN_CPU回调。CPUHP_TEARDOWN_CPU之前，热插拔状态不允许失败，因此将 CPU 离线回调移至可能失败的 ONLINE 部分。（CVE-2026-53314）

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

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

  - gpio：mvebu：修复暂停/恢复中的空指针取消引用 在暂停/恢复期间为所有 GPIO 组调用 mvebu_pwm_suspend（） 和 mvebu_pwm_resume（），但并非所有 bank 都具有 PWM 功能。不含 PWM 的 GPIO bank 将 mvchip->mvpwm 设置为 NULL。尝试访问 mvpwm->blink_select 时，调用 mvpwm == NULL 的 mvebu_pwm_suspend（） 可造成空指针取消引用。写入 [00000020] 时无法处理虚拟地址 00000020 处的内核空指针取消引用 *pgd=00000000 内部错误：哎呀：815 [#1] PREEMPT ARM 模块链接于： CPU：0 UID：0 PID：406 comm：sh 未受感染 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 硬件名称：Marvell Armada 370/XP（设备树） PC 处于 regmap_mmio_read+0x38/0x54 LR 处于 regmap_mmio_read+0x38/0x54 PC： [<c05fd2ac>] lr： [<c05fd2ac>] psr：
    200f0013 SP：f0c11d10 ip：00000000 FP：c100d2f0 r10： c14fb854 r9：00000000 r8：00000000 r7：c1799c00 r6：00000020 r5：00000020 r4：c179c7c0 r3：f0a231a0 r2：00000020 r1：00000020 r0：00000000 标记：
    模式 SVC_32 上 FIQ 上的 nzCv IRQ ISA ARM 段 无 控件：10c5387d 表：135ec059 DAC：00000051 调用跟踪：从 _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read regmap_mmio_read
    _regmap_read+0x60/0x154 _regmap_read 从 regmap_read+0x3c/0x60 regmap_read 从 mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend 从 dpm_run_callback+0x54/0x180 dpm_run_callback 从 device_suspend+0x124/0x630 device_suspend 从 dpm_suspend+0x124/0x270 dpm_suspend 从 dpm_suspend_start+0x64/0x6c dpm_suspend_start 从 suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter 从 pm_suspend+0x2fc/0x308 pm_suspend 从 state_store+从 kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter 0x6c/0xc8 state_store 从 vfs_write+0x270/0x468 vfs_write 从 ksys_write+0x70/0xf0 ksys_write 从 ret_fast_syscall+0x0/0x54 添加 NULL 检查 调用 PWM 暂停/恢复函数之前对 mvchip->mvpwm 添加空检查。（CVE-2026-53237）

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

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

  - xfrm：iptfs：修复 iptfs_destroy_state（） iptfs_destroy_state（） 调用 hrtimer_cancel（） 中的 ABBA 死锁，同时保持定时器回调也获取的旋转锁，从而导致 SMP 系统上的 ABBA 死锁。对于输出定时器 （iptfs_timer）： - iptfs_destroy_state（） 保持 x->lock，调用 hrtimer_cancel（） - iptfs_delay_timer（） 回调采用 x->lock 对于终止定时器 （drop_timer）： - iptfs_destroy_state（） 保持 drop_lock，调用 hrtimer_cancel（） - iptfs_drop_timer（） 回调采用 drop_lock 两个定时器都使用 HRTIMER_MODE_REL_SOFT，因此其回调在 softirq 环境中运行。当针对当前正在另一个 CPU 上执行的软定时器调用 hrtimer_cancel（） 时，hrtimer_cancel_wait_running（） 会在softirq_expiry_lock旋转 -- 由运行回调的 softirq 持有的相同锁定。如果回调在等待 hrtimer_cancel（） 的调用者持有的旋转锁时被阻断，则会形成循环依赖关系： CPU 0：保留 lock_A -> 等待 softirq_expiry_lock CPU 1：保留 softirq_expiry_lock -> 等待 lock_A 在获取相应的锁之前调用 hrtimer_cancel（） 进行修复。hrtimer_cancel（） 无需保持任何锁定即可安全调用，并将等待任何正在进行的回调完成。对于输出定时器，之后仍会获取锁定以耗尽数据包队列。对于丢失定时器，锁定/解锁对将完全删除，因为它仅存在于定时器回调序列化时，而 hrtimer_cancel（） 已经保证了这一点。由源代码审核发现。（CVE-2026-53197）

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

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

  - ublk：在每次提取时重置每个 IO 已取消的标记 如果 ublk 服务器开始恢复设备但在对所有 IO 发出获取命令之前停止运行，则成功发出的提取命令的取消可能无法完成。这是因为每个 IO 已取消标记可保持设置状态，即使在提交该 IO 的提取之后也可保持设置状态 - 只有在提取了队列的所有 IO 之后，队列中所有 IO 的每个 IO 已取消标记才会一起重置。因此，如果在 ublk 服务器终止时获取队列的 IO 的非空正确子集，则该子集中的 IO 将永远不会被成功取消，因为它们已取消的标记仍保持设置状态，这阻止ublk_cancel_cmd实际调用命令上的 io_uring_cmd_done，尽管这些命令已完成。通过在获取每个 IO 时立即重置 per-IO 取消标记而非等待队列的所有 IO（这可能永远不会发生）来修复此问题。（CVE-2026-53124）

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

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

  - vsock/virtio：修复潜在的不受限制的 skb 队列 virtio_transport_inc_rx_pkt（） 检查 vvs->rx_bytes + vvs->buf_alloc >len。virtio_transport_recv_enqueue（） 跳过具有VIRTIO_VSOCK_SEQ_EOM的数据包的合并。如果馈送 len == 0 和 VIRTIO_VSOCK_SEQ_EOM 的数据包，由于 vvs->rx_bytes 保持在 0，因此可能会有大量数据包排队。通过估算 skb 元数据大小修复此问题：（队列中的 skb 数量） * SKB_TRUESIZE（0） （CVE-2026-53132）

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

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

  - audit：修复 CAPSET 记录中由于复制粘贴错误而导致的 CAPSET 记录中不正确的可继承功能__audit_log_capset（） 将有效功能集记录到可继承字段中。因此，每个 CAPSET 审计记录都使用 cap_effective 而不是 cap_inheritable 值报告cap_pi（进程可继承）。这会静默地损坏用于合规性和取证分析的审计数据：如果攻击者修改可继承功能以准备出现权限升级，则会在审计跟踪中屏蔽更改。自 2008 年首次引入 CAPSET 审计记录以来，该缺陷一直存在。
    (CVE-2026-53287)

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

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

  - memcg：在 refill_stock 中使用轮循策略受害者选择 Harry Yoo 报告，在 nmi 上下文中调用 get_random_u32_below（） 并不安全，而且 nmi 上下文中可发生 memcg 电荷耗尽。更具体地说，get_random_u32_below（） 既不可重入也不对 NMI 安全：它通过batched_entropy_u32状态上的 local_lock_irqsave（） 获取每个 cpu 的local_lock。在 ChaCha 批处理状态的 CPU 更新中抵达并递归到随机子系统的 NMI 将会损坏该状态。memcg_stock local_trylock可防止 percpu 库存本身的重新输入，但无法保护不相关的子系统的 per-cpu 锁定。
    将随机选择替换为存储在 memcg_stock_pcp 中并由local_trylock已保护 cached[] 和 nr_pages[]. 无需原子、随机调用、无需额外锁定。（CVE-2026-53162）

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

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

  - netfilter：重新验证桥接端口 ebt_redirect_tg（） 取消引用 br_port_get_rcu（） 返回但未进行 NULL 检查，从而在原始挂钩调用和 NFQUEUE 重新注入之间删除桥接端口时导致内核错误。但是，仅仅进行 NULL 检查是不够的。正如 sashiko review 所指出的，用户空间不仅会从桥接删除端口，还可以将设备放置到其他虚拟设备中，例如 macvlan。如果发生这种情况，我们必须丢弃数据包，无法将其重新注入桥接路径。切换到 _upper API，我们不需要桥接端口结构。此外，此补丁保持另一个缺陷不变：nfnetlink_log和nfnetlink_queue都过于激进地使用CONFIG_BRIDGE_NETFILTER，从而在桥接系列中排队时阻止某些日志记录功能：
    可在旧CONFIG_BRIDGE_NETFILTER cruft 关闭时启用NETFILTER_FAMILY_BRIDGE。修复标签是共同的祖先，但一直被破坏。（CVE-2026-53220）

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

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

  - 已修复 Linux 内核中的下列漏洞：accel/ethosu: reject DMA commands with uninitialized length cmd_state_init() initializes the command state with memset(0xff), leaving dma->len at U64_MAX to signal missing setup. The only setter is NPU_SET_DMA0_LEN; if userspace omits this command and issues NPU_OP_DMA_START, dma->len remains U64_MAX. In dma_length(), a positive stride added to U64_MAX wraps to a small value. With size0 == 1, check_mul_overflow() does not trigger and dma_length() returns 0 instead of U64_MAX. The caller's U64_MAX check then passes, region_size[] stays 0, and the bounds check in ethosu_job.c is bypassed, allowing hardware to execute DMA with stale physical addresses. Fix by checking for U64_MAX at the start of dma_length() before any arithmetic, consistent with the sentinel value used throughout the driver to detect uninitialized fields. (CVE-2026-53170)

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

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

  - 已修复 Linux 内核中的下列漏洞：bpf: Fix abuse of kprobe_write_ctx via freplace uprobe programs are allowed to modify struct pt_regs. Since the actual program type of uprobe is KPROBE, it can be abused to modify struct pt_regs via kprobe+freplace when the kprobe attaches to kernel functions. For example, SEC(?kprobe) int kprobe(struct pt_regs *regs) { return 0; } SEC(?freplace) int freplace_kprobe(struct pt_regs *regs) { regs->di = 0; return 0; } freplace_kprobe prog will attach to kprobe prog. kprobe prog will attach to a kernel function. Without this patch, when the kernel function runs, its first arg will always be set as 0 via the freplace_kprobe prog. To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values. (CVE-2026-53095)

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

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

  - thunderbolt：拒绝验证器中的零长度属性条目 tb_property_entry_valid（） 接受 DIRECTORY、DATA 和 TEXT 类型长度 == 0 的条目。零长度的 TEXT 条目通过验证，但在 null 终止逻辑中造成下溢： property->value.text[property->length * 4 - 1] = '\0';
    当 property->length 为 0 时，相对于分配，这会写入偏移量 -1。在验证器早期拒绝零长度条目，因为其在 XDomain 属性协议中没有有效的表示形式。
    (CVE-2026-53150)

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

ID	名称	严重性
323523	Linux Distros 未修补的漏洞：CVE-2026-53321	medium
323522	Linux Distros 未修补的漏洞：CVE-2026-53317	medium
323521	Linux Distros 未修补的漏洞：CVE-2026-53257	medium
323520	Linux Distros 未修补的漏洞：CVE-2026-48915	low
323519	Linux Distros 未修补的漏洞：CVE-2026-12245	high
323518	Linux Distros 未修补的漏洞：CVE-2026-12490	high
323517	Linux Distros 未修补的漏洞：CVE-2026-58050	high
323516	Linux Distros 未修补的漏洞：CVE-2026-53007	medium
323515	Linux Distros 未修补的漏洞：CVE-2026-52965	medium
323514	Linux Distros 未修补的漏洞：CVE-2026-58049	high
323513	Linux Distros 未修补的漏洞：CVE-2026-53236	medium
323512	Linux Distros 未修补的漏洞：CVE-2026-53171	high
323511	Linux Distros 未修补的漏洞：CVE-2026-53030	medium
323510	Linux Distros 未修补的漏洞：CVE-2026-53275	high
323509	Linux Distros 未修补的漏洞：CVE-2026-53156	high
323508	Linux Distros 未修补的漏洞：CVE-2026-53281	medium
323507	Linux Distros 未修补的漏洞：CVE-2026-48002	critical
323506	Linux Distros 未修补的漏洞：CVE-2026-53051	medium
323505	Linux Distros 未修补的漏洞：CVE-2026-53148	high
323504	Linux Distros 未修补的漏洞：CVE-2026-48003	critical
323503	Linux Distros 未修补的漏洞：CVE-2026-53214	medium
323502	Linux Distros 未修补的漏洞：CVE-2026-53221	critical
323501	Linux Distros 未修补的漏洞：CVE-2026-53123	medium
323500	Linux Distros 未修补的漏洞：CVE-2026-53172	high
323499	Linux Distros 未修补的漏洞：CVE-2026-12244	high
323498	Linux Distros 未修补的漏洞：CVE-2026-42388	medium
323497	Linux Distros 未修补的漏洞：CVE-2026-53252	medium
323496	Linux Distros 未修补的漏洞：CVE-2026-53241	medium
323495	Linux Distros 未修补的漏洞：CVE-2026-52978	medium
323494	Linux Distros 未修补的漏洞：CVE-2026-53210	medium
323493	Linux Distros 未修补的漏洞：CVE-2026-53164	medium
323492	Linux Distros 未修补的漏洞：CVE-2026-8343	critical
323491	Linux Distros 未修补的漏洞：CVE-2026-53235	high
323490	Linux Distros 未修补的漏洞：CVE-2026-53198	high
323489	Linux Distros 未修补的漏洞：CVE-2026-53013	medium
323488	Linux Distros 未修补的漏洞：CVE-2026-52996	medium
323486	Linux Distros 未修补的漏洞：CVE-2026-53229	high
323485	Linux Distros 未修补的漏洞：CVE-2026-53155	medium
323484	Linux Distros 未修补的漏洞：CVE-2026-53190	medium
323483	Linux Distros 未修补的漏洞：CVE-2026-53314	medium
323482	Linux Distros 未修补的漏洞：CVE-2026-53237	medium
323481	Linux Distros 未修补的漏洞：CVE-2026-53197	medium
323480	Linux Distros 未修补的漏洞：CVE-2026-53124	medium
323479	Linux Distros 未修补的漏洞：CVE-2026-53132	high
323478	Linux Distros 未修补的漏洞：CVE-2026-53287	medium
323477	Linux Distros 未修补的漏洞：CVE-2026-53162	high
323476	Linux Distros 未修补的漏洞：CVE-2026-53220	medium
323475	Linux Distros 未修补的漏洞：CVE-2026-53170	high
323474	Linux Distros 未修补的漏洞：CVE-2026-53095	medium
323473	Linux Distros 未修补的漏洞：CVE-2026-53150	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

low

high

high

high

medium

medium

high

medium

high

medium

high

high

medium

critical

medium

high

critical

medium

critical

medium

high

high

medium

medium

medium

medium

medium

medium

critical

high

high

medium

medium

high

medium

medium

medium

medium

medium

medium

high

medium

high

medium

high

medium

medium