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

  - 已修复 Linux 内核中的下列漏洞：iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf() iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes, kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial kref to 1. It then calls dma_resv_add_fence() which takes a second reference (kref=2), and stores a raw pointer in block->fence. On the success path the function returns without calling dma_fence_put() to release the initial reference, so every buffer enqueue permanently leaks one kmalloc-128 allocation. The iio_buffer_cleanup() work item only releases the temporary reference taken during completion signalling by iio_buffer_signal_dmabuf_done();
    the initial reference from dma_fence_init() is never released. With four iio_rwdev instances at 240kHz and 512 samples per buffer, this produces ~1875 kmalloc-128 allocations per second matching the observed slab growth exactly. A test with ftrace confirmed that the dma_fence_destroy event was never triggered. Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring ownership of the fence to the DMA reservation object. The DMA fence then gets properly discarded after being signalled. (CVE-2026-63929)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/amdgpu: check num_entries in GEM_OP GET_MAPPING_INFO kvcalloc(args->num_entries, sizeof(*vm_entries), GFP_KERNEL) at amdgpu_gem.c:1050 uses the user-supplied num_entries directly without any upper bounds check. Since num_entries is a __u32 and sizeof(drm_amdgpu_gem_vm_entry) is 32 bytes, a large num_entries produces an allocation exceeding INT_MAX, triggering WARNING in __kvmalloc_node_noprof(), causing a kernel WARNING, TAINT_WARN, and panic on CONFIG_PANIC_ON_WARN=y systems. Add a size bounds check before we invoke the kvzalloc() to reject oversized num_entries early with -EINVAL. (cherry picked from commit 1fe7bf5457f6efd7be60b17e23163ba54341d73d) (CVE-2026-63878)

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

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

  - xfrm：esp：还原合并的单 frag 长度门控 ESP 就地快速路径会在 esp_output_head（） 中附加 esp_output_tail（） 的尾部，然后再分配目标页面 frag。头侧门目前分别检查 skb->data_len 和尾部，但尾部代码从组合后的拖车 skb->data_len 中分配一个目的地碎片。当组合对齐长度超过页面时，拒绝 page-frag 快速路径。否则，skb_page_frag_refill（） 可能会在目标 sg 仍跨组合 skb->data_len 时回退到单个页面。为 IPv4 和 IPv6 还原此组合长度页面门控。（CVE-2026-63912）

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

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

  - iio：imu： st_lsm6dsx：修复已标记 FIFO 缓冲区中的堆栈泄漏 已标记 FIFO 路径在包含 __aligned（8） 但无初始值设定项的堆栈上声明iio_buff，但是结构中有一个漏洞，随后将随着ST_LSM6DSX_SAMPLE_SIZE字节 （6） 被复制而泄漏到用户空间，但是该漏洞与时间戳之间的空间不会初始化。提交 c14edb4d0bdc （iio：imu：st_lsm6dsx 修复对齐和数据泄漏问题） 将未标记的 FIFO 路径移动到 hw->scan 中的 kzalloc'd 缓冲区，但对于带标记的路径，它仅添加了对齐限定符，而没有添加初始值设定项:(只需对堆栈上的结构进行零初始化即可修复此问题。（CVE-2026-63967）

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: SEV: Check PSC request indices against the actual size of the buffer When processing Page State Change (PSC) requests, validate the PSC buffer against the effective size of the scratch area, which could be less than the maximum size if the guest provided a pointer that isn't exactly at the start of the GHCB shared buffer. (CVE-2026-63938)

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

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

  - USB：serial：belkin_sa：验证中断状态长度 Belkin 中断回调将中断数据视为四字节状态报告，并读取偏移 2 和 3 处的 LSR/MSR 字段。中断输入缓冲区长度派生自端点 wMaxPacketSize，并且短中断传输可能会使用较小的actual_length成功完成。在解析状态字段之前检查已完成的中断数据包长度，以便忽略短中断端点和短的成功数据包，而不是造成越界或过时的状态字节读取。KASAN 报告如下：缺陷：KASAN：大小为 1 的 belkin_sa_read_int_callback（） 读取中的 slab-out-of-bound 调用跟踪：belkin_sa_read_int_callback（） （drivers/usb/serial/belkin_sa.c：202） __usb_hcd_giveback_urb（） （drivers/usb/core/hcd.c：1630） dummy_timer（） （？：？）（CVE-2026-63903）

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

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

  - xfrm：检查 xfrm_state_mtu中的下溢 Leo Lin 报告 esp 组件中的越界写入问题：
    xfrm_state_mtu（） 返回 u32，但在无符号 modulo-2^32 空间中使用从小 MTU 参数中减去的受攻击者影响的 header_len + authsize + net_adj 执行其算术运算。无名用户可安装具有大型认证密钥（XFRMA_ALG_AUTH_TRUNC，如 hmac（sha512）、64 字节密钥、64 字节截干的 IPv4 ESP 隧道 SA）、配置小型接口 MTU（68 字节）并将XFRMA_TFCPAD设为大值。随后通过隧道发送单个 UDP 数据报时，xfrm_state_mtu（） 下溢至接近 2^32 的值，esp_output（） 通过以下方式将其作为签名的 int 使用： padto = min（x->tfcpad， xfrm_state_mtu（x， mtu_cached）） esp.tfclen = padto - skb->len （分配给 int） esp.tfclen 最终变成负值（例如 -207）。当将其传递到 esp_output_fill_trailer（） 内部的 memset（） 时，它被符号扩展为size_t，从而在 skb_tail_pointer（skb） 处产生 ~16 EB 的零写入。KASAN 将其记录为大小为 18446744073709551537 地址的写入 addr ffff888.... 检查下溢并返回 1。这造成 sendmsg 尝试因 ENETUNREACH 而失败。（CVE-2026-64009）

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

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

  - 已修复 Linux 内核中的下列漏洞：accel/amdxdna: Fix mm_struct reference leak in aie2_populate_range() aie2_populate_range() jumps back to the again label without calling mmput(mm), leaking a reference to the mm_struct. Add the missing mmput() before jumping to again.
    (CVE-2026-63873)

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

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

  - vxlan：在 skb_tunnel_check_pmtu（） skb_tunnel_check_pmtu（） 可更改 skb->head 之后不重用缓存的 ip_hdr（） 值。在 skb_tunnel_check_pmtu（） 之后重复使用old_iph可导致 UAF。替代 drivers/net/bareudp.c 和 drivers/net/geneve.c 中所做的 ip_hdr（skb）。由 Sashiko 发现。（CVE-2026-63993）

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

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

  - gfs2：修复 gfs2_qd_dealloc gfs2_qd_dealloc（） 中的释放后使用，作为来自 gfs2_qd_dispose（） 的 RCU 回调调用，释放 qd 后通过 qd->qd_sbd 访问超级块对象 sdp。这样做是为了减少sd_quota_count并唤醒sd_kill_wait。但是，当 RCU 回调运行时，gfs2_put_super（） 可能已经通过 free_sbd（） 释放 sdp。在卸载期间调用 gfs2_quota_cleanup（） 时可能发生这种情况：它通过 call_rcu（） 处置配额对象，然后以 60 秒超时等待sd_kill_wait。如果超时过期，或者如果 gfs2_gl_hash_clear（） 在等待完成后触发其他 qd_put（） 调用来安排更多 RCU 回调，则 gfs2_put_super（） 将继续释放超级块，而引用超级块的 RCU 回调仍在待定中。在 gfs2_put_super（） 中的 free_sbd（） 前添加一个 rcu_barrier（），以确保所有待定的 RCU 回调（包括 gfs2_qd_dealloc）在释放超级块之前完成。（CVE-2026-63804）

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

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

  - ipv6：rpl：修复 ipv6_rpl_srh_decompress（） 中的 hdrlen 溢出 ipv6_rpl_srh_decompress（） 计算：
    outhdr->hdrlen = （（（n + 1） * sizeof（struct in6_addr）） >> 3）;hdrlen __u8。对于 n >= 127，结果超过 255 并静默截断。当 n=127 （cmpri=15， cmpre=15， pad=0， hdrlen=16）： （128 * 16） >> 3 = 256，截断为 0 时__u8 然后，ipv6_rpl_srh_rcv（） 中的调用程序将压缩的标头放在 buf + （（ohdr->hdrlen + 1） << 3）。若 hdrlen=0，则为 buf + 8，但解压缩的区域会占用 buf[0..2055]（8 字节标头加上 128 个完整地址）。压缩的标头与解压缩的数据重叠，ipv6_rpl_srh_compress（） 写入此重叠，从而损坏转发数据包的路由标头。exthdrs.c：546 的现有防护> 255 检查 （n + 1），这可防止 n+1 溢出未签名的字符（segments_left 字段），但无法防止计算的 hdrlen 溢出__u8。
    n=127 通过，因为 128 <= 255，但 hdrlen=256 不适合。将边界收紧到 （n + 1） > 127。这将 n 封装在 126，给出 hdrlen = （127 * 16） >> 3 = 254，这符合 __u8。压缩的标头随后位于 buf + （（254 + 1） << 3） = buf + 2040，正好超过解压缩区域 （buf[0..2039]）。无重叠。
    127 个段远远超出了任何现实的 RPL 部署。（CVE-2026-63984）

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

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

  - 已修复 Linux 内核中的下列漏洞：bridge: Fix sleep in atomic context in netlink path Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 (bridge: bridge port parameters over netlink), br_setport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state). Nowadays, br_setport() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data path.
    Annotations can be added in net-next. * Backup port and NHID: Only require RTNL. Read locklessly by the data path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the three STP related attributes that require it. This is consistent with the multicast attributes where each attribute acquires the multicast lock instead of having one critical section for all relevant attributes. [1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 356, name: bridge preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 2 locks held by bridge/356: #0: ffffffff919473a0 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg (net/core/rtnetlink.c:80 net/core/rtnetlink.c:7002) #1: ffff888115072d58 (&br->lock){+...}-{3:3}, at:
    br_setlink (./include/linux/spinlock.h:348 net/bridge/br_netlink.c:1117) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) br_setport (net/bridge/br_netlink.c:1000) br_setlink (net/bridge/br_netlink.c:1118) rtnl_bridge_setlink (net/core/rtnetlink.c:5572) rtnetlink_rcv_msg (net/core/rtnetlink.c:7005) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1318 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:787 (discriminator 4) net/socket.c:802 (discriminator 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-63989)

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

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

  - serial：dz：转换为使用平台设备 防止在初始化第一个串行端口时发生崩溃：控制台：切换到彩色帧缓冲设备 160x64 tgafb：检测到 SFB+，rev=0x02 fb0：
    DECstation DZ 串口驱动程序版本 1.04 CPU 0 0x1e000000无法处理虚拟地址 000000bc， epc == 8048b3a4， ra == 80470a78 的数字 ZLX-E1 帧缓冲器设备 000000bc， epc == 8048b3a4， ra == 80470a78 错误[#1]： CPU： 0 UID： 0 PID： 1 通信： swapper/0 未受感染 6.19.0-dirty #35 NONE $ 0 ： 00000000 1000ac00 00000004 804707ac $ 4 ： 00000000 80e20850 80e20858 81000030 $ 8 ： 00000000 8072c81c 00000008 fefefeff $12： 6c616972 00000006 80c5917f 69726420 $16 ： 80e20800 0000000 808f8968 80e20800 $20 ： 00000000 807f5a90 808b0094 808d3bc8 $24 ： 00000018 80479030 $28 ： 80c2e000 80c2fd70 00000069 80470a78 Hi： 00000004 Lo ： 00000000 epc ： 8048b3a4 __dev_fwnode+0x0/0xc RA ： 80470a78 serial_base_ctrl_add+0xa0/0x168 状态： 1000ac04 IEp 原因：
    30000008 （ExcCode 02） BadVA：000000bc PrId：00000220 （R3000） 模块链接于： 进程 swapper/0 （pid：
    1， threadinfo=（ptrval）， task=（ptrval）， tls=00000000） 堆栈： 00400044 00400040 8046f4cc 00000000 808a6148 808a0000 808f8968 8086983c 808e0000 8046fc84 1000ac01 00000028 80e20700 802ba3f8 80e20700 80d34a94 80c1b900 80e20700 80e20 700 80e20700 80e20700 80444650 000000000 00000000 007f5a90 808b0094 80447080 00400040 808e0000 80d34a94 808a6148 80d34a94 00000004 80e20700 00000000 8076974c 80469810 80c2fe3c 1000ac01 ... 调用跟踪：[<8048b3a4>] __dev_fwnode+0x0/0xc [<80470a78>] serial_base_ctrl_add+0xa0/0x168 [<8046fc84>] serial_core_register_port+0x1c8/0x974 [<808c6af0>] dz_init+0x74/0xc8 [<800470e0>] do_one_initcall+0x44/0x2d4 [<808b111c>] kernel_init_freeable+0x258/0x308 [<8072e434>] kernel_init+0x20/0x114 [<80049cd0>] ret_from_kernel_thread 0x1c+0x14/ 代码： 27bd0018 03e00008 2402ffea <8c8200bc> 03e00008 00000000 27bdffc0 afbe0038 afb30024 ---[ end trace 0000000000000000 ]--- --取消引用从空派生的指针指向端口父设备的指针。
    由于没有设备支持旧版探测，并且它不再是发现设备的首选方式，因此请将驱动程序切换为使用平台设备并将其用作端口的父设备。相应地更新资源处理，并且仅请求在插槽内使用的实际地址跨度，通用平台设备代码已经请求其资源。使用 platform_driver_probe（） 不仅因为 DZ 设备是用焊料固定的并且不容易拆卸，而且最重要的是因为相关的 TTY 的主要设备编号与 zs 驱动程序使用的相同，并且第一个声明它的驱动程序将阻止另一个驱动程序使用它。给定系统中将存在一个 DZ 设备或某些 SCC 设备，但绝不会同时存在两个设备，因此我们希望第一个驱动程序声明的主要设备号才能实际成功绑定到其设备，而 platform_driver_probe（） 是实现这一点的一种方式。切换到平台设备的一个不幸后果是，我们现在在启动程序中很久以后才将控制台从 bootconsole 移交。固件控制台处理程序看起来足够好，但可以工作到这么晚，尤其是在启用中断的情况下。
    相反，只有过晚启动控制台端口才能让重置代码充分利用延迟处理程序，因此请从 udelay（） 切换到 fsleep（） 进行发送器耗尽，以避免忙碌等待过多时间。（CVE-2026-63877）

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

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

  - 已修复 Linux 内核中的下列漏洞：iommu/amd: Remove latent out-of-bounds access in IOMMU debugfs In iommu_mmio_write() and iommu_capability_write(), the variables dbg_mmio_offset and dbg_cap_offset are declared as int. However, they are populated using kstrtou32_from_user(). If a user provides a sufficiently large value, it can become a negative integer. Prior to this patch, the AMD IOMMU debugfs implementation was already protected by different mechanisms. 1. #define OFS_IN_SZ 8 ensures the user string <= 8 bytes, so e.g. 0xffffffff isn't a valid input. if (cnt > OFS_IN_SZ) return -EINVAL; 2.
    Implicit type promotion in iommu_mmio_write(), dbg_mmio_offset is int and iommu->mmio_phys_end is u64 if (dbg_mmio_offset > iommu->mmio_phys_end - sizeof(u64)) return -EINVAL; 3. The show handlers would currently catch the negative number and refuse to perform the read. Replace kstrtou32_from_user() with kstrtos32_from_user() to parse the input, and check for negative values to explicitly prevent out-of-bounds memory accesses directly in iommu_mmio_write() and iommu_capability_write(). (CVE-2026-64186)

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

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

  - serial：qcom_geni：修复 DMA 完成 IRQ 之前刷新时的 kfifo 下溢 在提供 DMA 完成 IRQ 之前运行 uart_flush_buffer（） 时，可能发生以下争用（所有步骤按 uart_port_lock 序列化）： 1. DMA 启动：tx_remaining = N，kfifo 包含 N 个字节 2.DMA 在硬件中完成;IRQ 待定但尚未交付 3.uart_flush_buffer（） 获取端口锁定并调用 kfifo_reset（），使 kfifo_len（） = 0 而 tx_remaining 仍为 N 4。uart_flush_buffer（） 解除端口锁定 5。DMA IRQ 火灾;handle_tx_dma（） 获取端口锁定并调用空 kfifo uart_xmit_advance（） 上的 uart_xmit_advance（uport， tx_remaining） 递增 kfifo-> tx_remaining。由于 kfifo_reset（） 已将 in 和 out 都设置为 0，因此 out 会过去换行，从而导致 kfifo_len（） 返回 UART_XMIT_SIZE - tx_remaining。然后，下一个 start_tx_dma（） 调用会提交过时缓冲区数据的 DMA 传输。通过在 handle_tx_dma（） 开始时生成快照 kfifo_len（） 并在fifo_len < tx_remaining时跳过 uart_xmit_advance（），来修复此问题，这表明 kfifo 已被先前的刷新重置。（CVE-2026-63883）

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

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

  - ieee802154：6lowpan：仅接受 lowpan_xmit（） 中的 IPv6 数据包 aoe 驱动程序（或类似程序）会生成非 IPv6 数据包（例如 ETH_P_AOE），并将其排队，以便通过 6LoWPAN 接口（由用户或测试用例配置）上的 dev_queue_xmit（） 传输。由于数据包不是 IPv6，因此 6LoWPAN header_ops->create 函数（lowpan_header_create 或 header_create）提早返回，而不会在 skb 余量中初始化lowpan_addr_info结构。在 transmit 函数 （lowpan_xmit） 中，驱动程序调用 lowpan_header （或 setup_header），后者会无条件地从包含未初始化数据的余量中复制和使用lowpan_addr_info。通过丢弃非 IPv6 数据包修复此问题。net/bluetooth/6lowpan.c bt_xmit（） 中需要类似的补丁。（CVE-2026-63870）

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

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

  - 已修复 Linux 内核中的下列漏洞：hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors adm1266_gpio_get() and adm1266_gpio_get_multiple() both compose the pin-status word as pins_status = read_buf[0] + (read_buf[1] << 8); right after i2c_smbus_read_block_data(), guarding only against an error return. A well-behaved device returns 2 bytes for GPIO_STATUS/PDIO_STATUS, but the helper happily reports a 0- or 1-byte response too. If the device returns 0 bytes, both read_buf slots are uninitialized stack memory; if it returns 1 byte, read_buf[1] is.
    The composed value then flows through set_bit() into the caller's *bits in adm1266_gpio_get_multiple(), or into the return value of adm1266_gpio_get(), and ends up in userspace via gpiolib (sysfs and the char-dev ioctls). That leaks a few bits of kernel stack per request on any device whose firmware glitch, bus error, or hostile slave produces a short block-read response. Add the missing length check to both call sites and surface a short response as -EIO. (CVE-2026-64083)

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: SVM: Disable AVIC IPI virtualization on Hygon Family 18h (erratum #1235) Hygon Family 18h CPUs are derived from AMD Family 17h (Zen1) silicon and share the same erratum #1235: hardware may read a stale IsRunning=1 bit during ICR write emulation and silently fail to generate an AVIC_IPI_FAILURE_TARGET_NOT_RUNNING VM-Exit on the sending vCPU. The absence of the VM-Exit causes KVM to miss the required wakeup of blocking target vCPUs, leading to hung vCPUs and unbounded delays in guest execution. Extend the existing AMD Family 17h erratum #1235 workaround to also cover Hygon Family 18h. With IPI virtualization disabled, KVM never sets IsRunning=1 in the Physical ID table, so every non-self IPI generates a VM-Exit and is correctly emulated.
    (CVE-2026-64172)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: wwan: iosm: fix potential memory leaks in ipc_imem_init() The memory allocated in ipc_protocol_init() is not freed on the error paths that follow in ipc_imem_init(). Fix that by calling the corresponding release function ipc_protocol_deinit() in the error path. (CVE-2026-64179)

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

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

  - thunderbolt：property：__tb_property_parse_dir（） 中的端点递归深度 DIRECTORY 条目的值字段用作对没有深度计数器的 __tb_property_parse_dir（） 进行递归调用的dir_offset。将 DIRECTORY 条目链接到向后引用循环的构造的对等会驱动解析器，直到内核堆栈耗尽且保护页面触发为止。到达 PROPERTIES_REQUEST 控制平面交换的任何不受信任的 XDomain 对等机（电缆、停靠栏、内联检查器、相邻主机）可在未经认证的情况下触发此漏洞。将深度计数器穿过 tb_property_parse（） 和 __tb_property_parse_dir（），并拒绝超过 TB_PROPERTY_MAX_DEPTH = 8 的块。这比任何观察到的合法 XDomain 布局都要大得多。不需要 XDomain 主机到主机发现的操作员可在内核命令行中通过 thunderbolt.xdomain=0 完全禁用路径。（CVE-2026-63891）

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

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

  - batman-adv：bla：避免双重递减bla.num_requests 无正在进行的request_sent时，bla.num_requests会增加。并在各地减少（收到公告，清除骨干，定期工作）。但是检查 request_sent 是否实际上被设置为特定状态以及 atomic_dec/_inc 不安全，因为它们不是原子性的 （TOCTOU） 并且可以同时运行多个此类代码部分。同时，需要对request_sent（状态）进行修改，并以原子方式bla.num_requests。否则 batadv_bla_send_request（） 可能会将 request_sent 设置为 1 并被中断。
    然后，batadv_handle_announce（） 可以将 request_sent 设置回 0，并在 batadv_bla_send_request（） 递增它之前减少num_requests。因此必须锁定这两个操作。由于状态 （request_sent） 和 wait_periods 只能在此锁内访问，因此可以将它们转换为更简单的数据类型。为避免在 batadv_bla_purge_backbone_gw（） 运行后具有有效 backbone_gw 引用的并行运行上下文接触 bla.num_requests，需要第三个已停止状态以正确表示backbone_gw处于被清理状态。（CVE-2026-64095）

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

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

  - batman-adv：tt：修复报告的 VLAN 的 TOCTOU 争用 基于 TT 的本地 TVLV 通过首先检查具有至少一个 TT 条目的 VLAN 的数量来生成。然后会为 VLAN 分配一个大小正确的新缓冲区。只有这样，才会使用 VLAN 列表填充缓冲区中的 VLAN 条目。在此期间，meshif_vlan_list_lock举行。但是，在此期间，每个VLAN的实际TT条目数量仍可能增加，只是不是列表中的VLAN数量。但是缓冲区大小计算中使用的预过滤器仍可能导致需要存储的 VLAN 数量增加。仅仅是因为 VLAN 在分配前检查中没有条目时，现在可能突然至少有一个条目，然后需要占用未分配的空间。最好在开始时高估缓冲区大小，然后仅用非空的 VLAN 填充缓冲区。（CVE-2026-64091）

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

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

  - USB：serial：mct_u232：修复小端点的内存损坏 该驱动程序会替代特定设备（其 32 字节大量输出端点仅接受 16 字节数据包）的最大传输大小。确保永远不要增加最大传输大小，以便在恶意设备报告的端点最大数据包大小小于预期时防止 slab 损坏。（CVE-2026-63898）

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

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

  - 已修复 Linux 内核中的下列漏洞：net/sched: Fix ethx:ingress -> ethy:egress -> ethx:ingress mirred loop When mirred redirects to ingress (from either ingress or egress) the loop state from sched_mirred_dev array dev is lost because of 1) the packet deferral into the backlog and 2) the fact the sched_mirred_dev array is cleared. In such cases, if there was a loop we won't discover it. Here's a simple test to reproduce: ip a add dev port0 10.10.10.11/24 tc qdisc add dev port0 clsact tc filter add dev port0 egress protocol ip \ prio 10 matchall action mirred ingress redirect dev port1 tc qdisc add dev port1 clsact tc filter add dev port1 ingress protocol ip \ prio 10 matchall action mirred egress redirect dev port0 ping -c 1 -W0.01 10.10.10.10 (CVE-2026-63982)

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

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

  - drm/v3d：修复错误路径上 CPU 作业查询数组的释放后使用 CPU 作业 ioctl 的失败标签在 v3d_job_cleanup（） 之后在cpu_job的时间戳和性能查询数组上调用 kvfree（），从而删除作业的最后引用并释放cpu_job。此时读取cpu_job即为释放后使用。此外，在早期的 v3d_job_init（） 失败路径中，它是空取消引用，因为 v3d_job_deallocate（） 将本地指针清零。在成功路径中，数组从计划程序的.free_job回调中释放，但在错误路径上，它们被手动释放，因为作业从未被推送到计划程序。虽然成功路径正确处理此问题，但失败路径不会。最重要的是，手动 kvfree（） 调用仅释放数组存储;它们不会drm_syncobj_put v3d_timestamp_query_info_free（） 和 v3d_performance_query_info_free（） 在成功路径上释放的按查询 syncobjs。因此，触发释放后使用的同一失败路径也会在每个查询中泄露一个 syncobj 引用。将 CPU 作业拆卸统一到 CPU 作业的 kref 析构函数中，以反映 v3d_render_job_free（）。计划程序的.free_job槽恢复为通用 v3d_sched_job_free（），失败标签会终止手动 kvfree（） 调用，从而留下可从计划程序和 ioctl 错误路径到达的单一拆卸路径。这可按构造删除释放后使用、空指针取消引用和 syncobj 泄露问题。（CVE-2026-64099）

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

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

  - usb：typec：ucsi：ccg：拒绝不含“：”记录标头的固件图像 do_flash（） 使用 p = strnchr（fw->data， fw->size， '：'） 找到第一个 .cyacd 记录;while （p < eof） { s = strnchr（p + 1， eof - p - 1， '：'）; ... }如果固件映像不含“：”字节，strnchr（） 会返回 NULL。NULL 的比较小于有效的内核指针 eof，因此循环正文运行并使用 p + 1 == （void *）1 且长度约为（无符号长）eof 来调用 strnchr（），从而导致精彩的崩溃。do_flash（） 中较早的 not_signed_fw fallthrough 和 ccg_fw_update_needed（） 中的芯片状态分支允许未签名的 blob 到达此循环，因此可在 /lib/firmware 下放置构建的文件并写入 do_flash sysfs 属性的根用户可触发 oops。当初始 strnchr（） 返回 NULL 时使用 -EINVAL 退出。
    (CVE-2026-63964)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drm_gem_object reference from drm_gem_object_lookup(), the drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and the drm_exec lock on the per-process VM root page directory via amdgpu_vm_lock_pd(). All three are released by the out_exec label that every other error path in this function jumps to. The kvcalloc() failure path returns
    -ENOMEM directly, skipping out_exec and leaking all three. The leaked per-process VM root PD dma_resv lock is the load-bearing leak: any subsequent operation on the same VM (further GEM ops, command-submission, eviction, TTM shrinker callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local denial of service against the caller's GPU context, reachable by any process with /dev/dri/renderD* access. Route the failure through out_exec so drm_exec_fini() and drm_gem_object_put() run. Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega (Lucienne): the failing ioctl returns -ENOMEM and a second GET_MAPPING_INFO on the same fd then blocks in drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the caller does not reap the task; the fd-release path during process exit goes through amdgpu_gem_object_close() -> drm_exec_prepare_obj() on the same lock, leaving the task in D state until the box is rebooted. The patched kernel was not rebuilt and re-tested on this hardware; the fix is mechanical. Tested on a single Lucienne / Vega box only. Ziyi Guo posted an independent INT_MAX-bound check for args->num_entries in the same branch [1]; the two patches are complementary and can land in either order. (cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a) (CVE-2026-63880)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: ti: icssm-prueth: fix eth_ports_node leak in probe The error path on of_property_read_u32() failure inside icssm_prueth_probe() returns without putting eth_ports_node, which was acquired before the for_each_child_of_node() loop. Drop it before returning. (CVE-2026-64161)

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

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

  - batman-adv：mcast：修复 RCU 版本orig_node释放后使用 batadv_mcast_purge_orig（） 从 RCU 保护的 hlists 中删除条目，但不会等待 RCU 宽限期后返回。并发 RCU 读取者可能仍可在删除时访问对这些条目的引用。尝试操作 orig->mcast_want_all_ipv6_node 等条目时受 RCU 保护的阅读器随后将访问已释放的内存。
    通过在 call_rcu（） 调用之前将 batadv_mcast_purge_orig（） 移动到 batadv_orig_node_release（） 来修复此问题。这可确保在回收orig_node内存之前，清除时处于活动状态的 RCU 读取器已经耗尽。（CVE-2026-64096）

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

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

  - 已修复 Linux 内核中的下列漏洞：hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer adm1266_pmbus_block_xfer() sets up the read transaction with .buf = data->read_buf, .len = ADM1266_PMBUS_BLOCK_MAX + 2, but read_buf in struct adm1266_data is declared as u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1]; For a max-length block response (length byte = 255 + up to 1 PEC byte), the i2c controller is told to write 257 bytes into a 256-byte buffer, putting one byte past the end of read_buf. The same response also makes the subsequent PEC compare if (crc != msgs[1].buf[msgs[1].buf[0] + 1]) read a byte beyond the array. Bump the read_buf declaration to ADM1266_PMBUS_BLOCK_MAX + 2 so the buffer can hold the length byte, up to 255 payload bytes, and the PEC byte the i2c_msg length already accounts for. (CVE-2026-64086)

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

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

  - 已修复 Linux 内核中的下列漏洞：spi: ep93xx: fix error pointer deref after DMA setup failure The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. (CVE-2026-64169)

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

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

  - net：tls：修复封装的 sk_msg 环的条目计数sg_chain差一问题 当sk_msg scatterlist 环封装 （sg.end < sg.start） 时，tls_push_record（） 使用 sg_chain（） 将环的末尾部分链接到头部。sg 数组中的一个额外条目为此保留： struct sk_msg_sg { [...] /* 额外的两个元素：* 1） 用于在列表变为 * 分区（如结束<开始）时链接前面和部分。crypto API 需要 * 链接;* 2） 在消息之后链接尾随 SG 条目。*/ 结构 scatterlist data[MAX_MSG_FRAGS + 2];当前代码使用 MAX_SKB_FRAGS + 1 作为环大小：
    sg_chain（&msg_pl->sg.data[msg_pl->sg.start]， MAX_SKB_FRAGS - msg_pl->sg.start + 1， msg_pl->sg.data）;这会将链接指针置于 sg_chain（data[start]， （MAX_SKB_FRAGS - msg_start + 1） .. = &data[start] + （MAX_SKB_FRAGS - msg_start + 1） - 1 = data[start + （MAX_SKB_FRAGS - start + 1） - 1] = data[MAX_SKB_FRAGS] 而不是真正的最后一条。这很可能是由于在接近提交 031097d9e079 的补丁着陆时存在提交争用（bpf：sk_msg，psock down 时的 zap 入口队列） 转换为 ARRAY_SIZE 并终止 data[start] / - start（按照 Sabrina 的建议）。（CVE-2026-64047）

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

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

  - USB：serial：keyspan：修复缺少的 indat 传输健全性检查。添加对 usa49wg indat 传输大小缺少的健全性检查，以避免解析过时或未初始化的 slab 数据。（CVE-2026-63900）

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

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

  - memfd：暗示 SEAL_WRITE 时拒绝可写映射 添加 SEAL_EXEC 时，暗示SEAL_WRITE 造成 W^X。但隐含的密封是在检查后设置的，确保 memfd 不能有任何可写入的映射。这意味着人们可以使用SEAL_EXEC应用SEAL_WRITE同时具有可写入的映射。这破坏了 SEAL_WRITE 提供的合约，并可被攻击者用于传递看似写密封但仍可被任意修改的 memfd。通过在完成对 mapping_deny_writable（） 的调用之前添加隐含密封来修复此问题。（CVE-2026-63952）

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

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

  - USB：serial：cypress_m8：修复小端点的内存损坏 确保中断输出端点数据包大小上限至少为 8 字节，以避免在恶意设备报告较小大小时发生用户控制的 slab 损坏或空指针取消引用。（CVE-2026-63956）

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

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

  - ixgbevf：修复 VEPA 多播源修剪中的释放后使用 ixgbevf_clean_rx_irq（） 通过释放 skb 并继续进行下一个描述符，删除源 MAC 匹配 VF 自有地址的帧（VEPA 多播变通方案）：dev_kfree_skb_irq（skb）;继续;skb 指针在 while 循环之外声明，并且在迭代之间持续存在。由于 continue 会跳过循环底部的 skb = NULL 重置，因此下一个迭代会进入 else if （skb） 路径，并在释放的 skb 上调用 ixgbevf_add_rx_frag（），从而取消引用 skb_shinfo（skb）->nr_frags - NAPI softirq 上下文中的释放后使用。同级驱动程序 iavf 已通过在继续之前将指针为空来正确处理此操作。在这里应用相同的模式。
    我没有 ixgbevf 硬件;该缺陷是通过静态分析发现的（scan_drop_continue_loops.py + semgrep drop_continue_in_loop，扫描中得分最高的多工具佐证）。UAF 通过加载可重现确切代码模式（alloc skb、kfree_skb，然后读取 skb_shinfo（skb）->nr_frags）的测试模块，在 KASAN 下得到确认： 缺陷：KASAN：ixgbevf_uaf_test_init+0x100/0x1000 中的释放后使用 任务 insmod/30 在地址 0000000006163ae78 读取的大小为 8 释放的 208 字节区域 [0000000006163adc0， 000000006163ae90） QEMU 模拟 igb （82576） 但不模拟 ixgbe （82599）， 并且 igbvf VF 驱动程序不包含 VEPA 源修剪路径，因此无法使用仿真硬件进行完整的端到端再现。（CVE-2026-64113）

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

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

  - 已修复 Linux 内核中的下列漏洞：net: devmem: reject dma-buf bind with non-page-aligned size or SG length net_devmem_bind_dmabuf() trusts dmabuf->size and sg_dma_len() to be PAGE_SIZE multiples without checking: - tx_vec is sized dmabuf->size / PAGE_SIZE, and net_devmem_get_niov_at() only bounds-checks virt_addr < dmabuf->size before indexing tx_vec[virt_addr / PAGE_SIZE]. With size = N*PAGE_SIZE + r (1 <= r < PAGE_SIZE), sendmsg() at iov_base = N*PAGE_SIZE passes the bound check and reads tx_vec[N] -- one past. - owner->area.num_niovs = len / PAGE_SIZE while gen_pool_add_owner() covers the full byte len, so a non-page-multiple non-final sg desyncs num_niovs from the gen_pool region for every later sg, on both RX and TX. dma-buf does not require page-aligned sizes, so the bind path has to enforce what its own indexing assumes. Reject both with -EINVAL. The size check is TX-only (only tx_vec is sized off dmabuf->size); the SG-length check covers both directions.
    (CVE-2026-64124)

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

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

  - mm/memory：修复取消映射 device-private/exclusive 页面时的虚假警告 仅匿名作品集支持设备私有和独占条目。使用 folio_test_anon（） 在 __migrate_device_pages（） 和 make_device_exclusive（） 中对此条件进行测试。但是，取消映射路径使用 vma_is_anonymous（） 测试此假设。这是错误的，因为虽然匿名 VMA 只能包含 folio_test_anon（） 为真的作品集，但相反的关系不成立。folio_test_anon（） 为真的对开本并不意味着 vma_is_anonymous（） 为 true。例如，如果作品集是私有文件备份映射的一部分，则可发生此类情况。在这种情况下，由于映射是文件备份，vma_is_anonymous（） 为 false，但 folio_test_anon（） 可能是 true，从而允许设备将作品集迁移到设备私有内存。这可在进程拆卸期间导致以下虚假警告： [ 772.737706] ------------[ cut here]------------ [ 772.739201] WARNING： mm/memory.c：1754 at unmap_page_range.cold+0x26/0x18a， CPU#17： hmm-tests/2041 [ 772.742050] 模块链接： test_hmm nvidia_uvm（O） nvidia（O） [ 772.743959] CPU： 17 UID： 0 PID： 2041 Comm： hmm-tests Tainted： G W O 7.0.0+ #387 PREEMPT（full） [ 772.747104] Tainted： [W]=WARN， [O]=OOT_MODULE [ 772.748509] 硬件名称： QEMU Standard PC （Q35 + ICH9， 2009）， BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 772.752117] RIP：
    0010：unmap_page_range.cold+0x26/0x18a [ 772.753780] 代码： 7e fe ff ff 48 89 4c 24 78 4c 89 44 24 38 e8 f2 ff b1 00 48 8b 4c 24 78 4c 8b 44 24 38 48 8b 44 24 18 48 83 78 48 00 74 04 90 <0f> 0b 90 48 89 ca b8 ff ff 37 00 48 c1 ea 03 48 c1 e0 2a 80 3c 02 [ 772.759602] RSP： 0018：ffff888112607550 EFLAGS： 00010286 [772.761310] RAX： ffff88811bbf4dc0 RBX： dffffc0000000000 RCX： ffffea03e9bfffd8 [ 772.763583] RDX：
    1ffff1102377e9c1 RSI：0000000000000008 RDI：ffff88811bbf4e08 [ 772.765914] RBP：0000000000000006 R08：
    ffff8881059f7448 R09： ffffed10224c0e68 [ 772.768184] R10： ffff888112607347 R11： 0000000000000001 R12：
    0000000000000001 [ 772.770461] R13： ffffea03e9bfffc0 R14： ffff888112607908 R15： ffffea03e9bfffc0 [772.772782] FS： 00007f327caa2780（0000） GS：ffff888427b7d000（0000） knlGS：0000000000000000 [ 772.775328] CS：
    0010 DS：0000 ES：0000 CR0： 0000000080050033 [ 772.777187] CR2： 00007f327ca89000 CR3： 00000001994d5000 CR4： 000000000000006f0 [ 772.779135] 调用跟踪： [ 772.779792] [ <TASK>772.780317] ？ dmirror_interval_invalidate+0x1a3/0x290 [test_hmm] [ 772.781873] ？ vm_normal_page_pud+0x2b0/0x2b0 [772.782992] ？ __rwlock_init+0x150/0x150 [ 772.784006] ？ lock_release+0x216/0x2b0 [ 772.785008] ？
    __mmu_notifier_invalidate_range_start+0x505/0x6e0 [ 772.786522] ？ lock_release+0x216/0x2b0 [ 772.787498] ？ unmap_single_vma+0xb6/0x210 [ 772.788573] unmap_vmas+0x27d/0x520 [ 772.789506] ？ unmap_single_vma+0x210/0x210 [ 772.790607] ？ mas_update_gap.part.0+0x620/0x620 [ 772.791834] unmap_region+0x19e/0x350 [ 772.792769] ？ remove_vma+0x130/0x130 [ 772.793684] ？ mas_alloc_nodes+0x1f2/0x300 [ 772.794730] vms_complete_munmap_vmas+0x8c1/0xe20 [ 772.795926] ？ unmap_region+0x350/0x350 [ 772.796917] do_vmi_align_munmap+0x36a/0x4e0 [ 772.798018] ?lock_release+0x216/0x2b0 [ 772.799024] ？ vma_shrink+0x620/0x620 [ 772.799983] do_vmi_munmap+0x150/0x2c0 [772.800939] __vm_munmap+0x161/0x2c0 [ 772.801872] ？ expand_downwards+0xd60/0xd60 [ 772.802948] ？ clockevents_program_event+0x1ef/0x540 [ 772.804217] ？ lock_release+0x216/0x2b0 [ 772.805158]
    __x64_sys_munmap+0x59/0x80 [ 772.805776] do_syscall_64+0xfc/0x670 [ 772.806336] ？ irqentry_exit+0xda/0x580 [ 772.806976] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 772.807772] RIP： 0033：0x7f327cbb2717 [772.808323] 代码： 73 01 c3 48 8b 0d f9 76 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ---truncated--- （CVE-2026-64131）

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN Commit iommu: return full error code from iommu_map_sg[_atomic]() changed iommu_map_sgtable() to return an ssize_t and negative values in error cases, rather than a size_t and a zero. Store the return value in the appropriate type and in case of error, return it rather than WARNing. Patchwork: https://patchwork.freedesktop.org/patch/719685/ (CVE-2026-64153)

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

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

  - 已修复 Linux 内核中的下列漏洞：ethtool: cmis: require exact CDB reply length Malicious SFP module could respond with rpl_len longer than what cmis_cdb_process_reply() expected, leading to OOB writes. Malicious HW is a bit theoretical but some modules may just be buggy and/or the reads may occasionally get corrupted, so let's protect the kernel. The existing check protects from short replies. We need to protect from long ones, too. All callers that pass a non-zero rpl_exp_len cast the reply payload to a fixed-layout struct and read fields at fixed offsets, with no version negotiation or short-reply handling: - cmis_cdb_validate_password() - cmis_cdb_module_features_get() - cmis_fw_update_fw_mng_features_get() so let's assume that responses longer than expected do not have to be handled gracefully here. Add a warning message to make the debug easier in case my understanding is wrong... Note that page_data->length (argument of kmalloc) comes from last arg to ethtool_cmis_page_init() which is rpl_exp_len. Note2 that AIs also like to point out overflows in args->req.payload itself (which is a fixed-size 120 B buffer, on the stack), but callers should be reading structs defined by the standard, so protecting from requests for more data than max seem like defensive programming.
    (CVE-2026-63996)

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

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

  - 已修复 Linux 内核中的下列漏洞：ethtool: coalesce: cap profile updates at NET_DIM_PARAMS_NUM_PROFILES ethnl_update_profile() walks the ETHTOOL_A_PROFILE_IRQ_MODERATION nest list with an index 'i' and writes new_profile[i++] without bounding i. The destination is kmemdup()'d at NET_DIM_PARAMS_NUM_PROFILES entries (5), but the Netlink nest count is entirely user-controlled. Netlink policies do not have support for constraining the number of nested entries (or number of multi-attr entries). (CVE-2026-63987)

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

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

  - 已修复 Linux 内核中的下列漏洞：iommu: Handle unmap error when iommu_debug is enabled Sashiko noticed a latent bug where the map error flow called iommu_unmap() which calls iommu_debug_unmap_begin()/iommu_debug_unmap_end() however since this is an error path the map flow never actually established the original iommu_debug_map() it will malfunction. Lift the unmap error handling into iommu_map_nosync() and reorder it so the trace_map()/iommu_debug_map() records the partial mapping and then immediately unmaps it. This avoid creating the unbalanced tracking and provides saner tracing instead of a unmap unmatched to any map. (CVE-2026-64152)

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

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

  - net：mana：在拆卸路径中添加空防护以防止附加失败时的错误 当队列分配中途失败时，错误清理将释放 apc->tx_qp 和 apc->rxqs 并产生 NULL 权限。多个拆卸路径，例如 mana_remove（）、mana_change_mtu（） 恢复和 mana_alloc_queues（） 中的内部错误处理，）之后可调用取消引用这些指针的函数，而不需要 NULL 检查： - mana_chn_setxdp（） 取消引用 apc->rxqs[0]，从而造成空指针取消引用错误（CR2：00000000000000000000 at mana_chn_setxdp+0x26）。- mana_destroy_vport（） 在不进行 NULL 检查的情况下迭代 apc->rxqs。- mana_fence_rqs（） 在不进行 NULL 检查的情况下迭代 apc->rxqs。- mana_dealloc_queues（） 在不进行 NULL 检查的情况下迭代 apc->tx_qp。
    为 mana_fence_rqs（）、mana_destroy_vport（） 中和 mana_chn_setxdp（） 调用之前的 apc->rxqs 添加空保护。为 mana_dealloc_queues（） 中的 apc->tx_qp 添加空防护，以在从未分配 TX 队列或尚未释放 TX 队列时跳过 TX 队列耗尽。（CVE-2026-63973）

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

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

  - 低于 1.3.9c 和 1.3.10rc3 的 ProFTPD 在 mod_sftp 模块的 SCP 大小记录解析器中包含有符号的整数溢出漏洞，允许经认证的低权限攻击者通过发送构建的文件大小值 UINT64_MAX 绕过 ASLR，从而导致负的off_t值。攻击者可利用后续转换为 uint32_t，造成大约 4 GB 的请求读取长度，并强制服务器读取超过 SSH 通道数据结尾，并将过度读取的进程内存写入已上传的文件中。在测试的配置中，泄露的数据包含的 libc、libcrypto 和 PIE 指针足以派生其随机基址，从而绕过 ASLR，并能够在同一进程中可靠利用内存损坏漏洞。（CVE-2026-63091）

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

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

  - 已修复 Linux 内核中的下列漏洞：netfs: Fix cancellation of a DIO and single read subrequests When the preparation of a new subrequest for a read fails, if the subrequest has already been added to the stream->subrequests list, it can't simply be put and abandoned as the collector may see it. Also, if it hasn't been queued yet, it has two outstanding refs that both need to be put. Both DIO read and single-read dispatch fail at this; further, both differ in the order they do things to the way buffered read works. Fix cancellation of both DIO-read and single-read subrequests that failed preparation by the following steps: (1) Harmonise all three reads (buffered, dio, single) to queue the subreq before prepping it. (2) Make all three call netfs_queue_read() to do the queuing. (3) Set NETFS_RREQ_ALL_QUEUED independently of the queuing as we don't know the length of the subreq at this point. (4) In all cases, set the error and NETFS_SREQ_FAILED flag on the subreq and then call netfs_read_subreq_terminated() to deal with it. This will pass responsibility off to the collector for dealing with it. (CVE-2026-64069)

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

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

  - 已修复 Linux 内核中的下列漏洞：vfio/pci: Check BAR resources before exporting a DMABUF A DMABUF exports access to BAR resources and, although they are requested at startup time, we need to ensure they really were reserved before exporting. Otherwise, it's possible to access unreserved resources through the export. Add a check to the DMABUF-creation path. (CVE-2026-64042)

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

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

  - nfc：llcp：修复 nfc_llcp_recv_cc（） 中的释放后使用争用 NFC LLCP 连接状态机中存在一个争用条件，其中连接接受数据包 （CC） 可与套接字释放同时处理。这可导致套接字对象释放后使用。当 nfc_llcp_recv_cc（） 将套接字从connecting_sockets列表移动到套接字列表时，它不会保留套接字锁定。
    如果 llcp_sock_release（） 并发执行，可能已经取消套接字链接并丢弃其引用，导致 nfc_llcp_recv_cc（） 将释放的套接字链接到实时列表中。通过在 nfc_llcp_recv_cc（） 中的状态转换和列表移动期间按住 lock_sock（），修复此问题。取得锁定之后，检查套接字是否仍受哈希处理，以确保其尚未被释放路径取消链接及标记为要销毁。这会使锁定模式与 recv_hdlc（） 和 recv_disc（） 保持一致。（CVE-2026-64010）

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

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

  - 已修复 Linux 内核中的下列漏洞：uio: uio_pci_generic_sva: fix double free of devm_kzalloc() memory uio_pci_sva allocates struct uio_pci_sva_dev with devm_kzalloc() in probe(), but then calls kfree(udev) both on the probe() error path (label out_free) and again in remove(). Because devm_kzalloc() allocations are devres-managed and are freed automatically when the device is detached (including after a failing probe() and during driver unbind), the explicit kfree() can lead to a double free. If probe() fails after devm_kzalloc(), the error path frees udev and devres cleanup will free it again when the core unwinds the partially bound device. On normal driver removal, remove() frees udev and devres will free it again when the device is detached. This issue was identified by a static analysis tool I developed and confirmed by manual review. Fix by removing the manual kfree() calls and dropping the now-unused label. (CVE-2026-63907)

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

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

  - net：tls：防止明文中的链后链 SG Sashiko 指出，如果 end = 0 （start ！= 0），当前代码将立即在环绕链接之后创建指向内容类型的链： 这将创建一条链，其中封装链接直接指向另一个链节。scatterlist API sg_next迭代器不会以递归方式解析连续的链链接。这意味着这是对加密货币的非法输入。如果 end = 0，则不需要封装链接。end 是最后一个使用的条目之后的条目，因此 end = 0 表示封装后没有任何推送内容：end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap] 在此情况下跳过封装。如果 end = 0，则 TLS 1.3 可使用封装槽进行链接。这避免了链后链的情况。
    在标记 END 和链接内容类型之前移动封装链，这对我来说感觉更合乎逻辑的顺序，但从功能的角度来看应该无关紧要。（CVE-2026-64046）

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

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

  - 输入：atmel_mxt_ts - 修复mxt_prepare_cfg_mem中的边界检查 配置文件提供的对象大小大于驱动程序的已知mxt_obj_size（对象）时，驱动程序打算丢弃额外的字节。循环使用 for （i = 0; i < size; i++） 进行迭代。在循环中，跳过处理额外字节的条件是：if （i > mxt_obj_size（object）） continue;由于 i 是从 0 开始的索引，因此对象的有效索引为 0 到 mxt_obj_size（对象） - 1。当 i == mxt_obj_size（object） 时，条件的计算结果为 false，代码会处理字节，而不是丢弃它。这会导致代码计算 byte_offset = reg + i - cfg->start_ofs 并将字节写入其中，从而恰好覆盖相邻实例或对象的一个字节。通过使用 >= 更新边界检查以正确地跳过额外字节。（CVE-2026-63908）

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

ID	名称	严重性
328275	Linux Distros 未修补的漏洞：CVE-2026-63929	high
328274	Linux Distros 未修补的漏洞：CVE-2026-63878	medium
328273	Linux Distros 未修补的漏洞：CVE-2026-63912	critical
328272	Linux Distros 未修补的漏洞：CVE-2026-63967	high
328271	Linux Distros 未修补的漏洞：CVE-2026-63938	critical
328270	Linux Distros 未修补的漏洞：CVE-2026-63903	medium
328269	Linux Distros 未修补的漏洞：CVE-2026-64009	high
328268	Linux Distros 未修补的漏洞：CVE-2026-63873	high
328267	Linux Distros 未修补的漏洞：CVE-2026-63993	critical
328266	Linux Distros 未修补的漏洞：CVE-2026-63804	high
328265	Linux Distros 未修补的漏洞：CVE-2026-63984	critical
328264	Linux Distros 未修补的漏洞：CVE-2026-63989	high
328263	Linux Distros 未修补的漏洞：CVE-2026-63877	medium
328262	Linux Distros 未修补的漏洞：CVE-2026-64186	high
328261	Linux Distros 未修补的漏洞：CVE-2026-63883	high
328260	Linux Distros 未修补的漏洞：CVE-2026-63870	high
328259	Linux Distros 未修补的漏洞：CVE-2026-64083	medium
328258	Linux Distros 未修补的漏洞：CVE-2026-64172	high
328257	Linux Distros 未修补的漏洞：CVE-2026-64179	medium
328256	Linux Distros 未修补的漏洞：CVE-2026-63891	medium
328255	Linux Distros 未修补的漏洞：CVE-2026-64095	high
328254	Linux Distros 未修补的漏洞：CVE-2026-64091	critical
328253	Linux Distros 未修补的漏洞：CVE-2026-63898	high
328252	Linux Distros 未修补的漏洞：CVE-2026-63982	medium
328251	Linux Distros 未修补的漏洞：CVE-2026-64099	high
328250	Linux Distros 未修补的漏洞：CVE-2026-63964	medium
328249	Linux Distros 未修补的漏洞：CVE-2026-63880	medium
328248	Linux Distros 未修补的漏洞：CVE-2026-64161	medium
328247	Linux Distros 未修补的漏洞：CVE-2026-64096	high
328246	Linux Distros 未修补的漏洞：CVE-2026-64086	high
328245	Linux Distros 未修补的漏洞：CVE-2026-64169	medium
328244	Linux Distros 未修补的漏洞：CVE-2026-64047	critical
328243	Linux Distros 未修补的漏洞：CVE-2026-63900	high
328242	Linux Distros 未修补的漏洞：CVE-2026-63952	high
328241	Linux Distros 未修补的漏洞：CVE-2026-63956	high
328240	Linux Distros 未修补的漏洞：CVE-2026-64113	critical
328239	Linux Distros 未修补的漏洞：CVE-2026-64124	high
328238	Linux Distros 未修补的漏洞：CVE-2026-64131	medium
328237	Linux Distros 未修补的漏洞：CVE-2026-64153	high
328236	Linux Distros 未修补的漏洞：CVE-2026-63996	high
328235	Linux Distros 未修补的漏洞：CVE-2026-63987	high
328234	Linux Distros 未修补的漏洞：CVE-2026-64152	high
328233	Linux Distros 未修补的漏洞：CVE-2026-63973	medium
328232	Linux Distros 未修补的漏洞：CVE-2026-63091	high
328231	Linux Distros 未修补的漏洞：CVE-2026-64069	critical
328230	Linux Distros 未修补的漏洞：CVE-2026-64042	high
328229	Linux Distros 未修补的漏洞：CVE-2026-64010	high
328228	Linux Distros 未修补的漏洞：CVE-2026-63907	high
328227	Linux Distros 未修补的漏洞：CVE-2026-64046	critical
328226	Linux Distros 未修补的漏洞：CVE-2026-63908	high

检测

Nessus 的 Misc. 系列

high

medium

critical

high

critical

medium

high

high

critical

high

critical

high

medium

high

high

high

medium

high

medium

medium

high

critical

high

medium

high

medium

medium

medium

high

high

medium

critical

high

high

high

critical

high

medium

high

high

high

high

medium

high

critical

high

high

high

critical

high