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

  - 已修复 Linux 内核中的下列漏洞：net/mlx5e: Fix use-after-free in mlx5e_tx_reporter_timeout_recover mlx5e_tx_reporter_timeout_recover() accesses sq->netdev after mlx5e_safe_reopen_channels() has torn down and freed the channel (and its embedded SQs). Replace the three sq->netdev references with priv->netdev which is safe because priv outlives channel teardown. The netdev_err() call already used priv->netdev for this reason; make the trylock/unlock and health_channel_eq_recover calls consistent. This fixes the following KASAN splat: BUG: KASAN: use-after-free in mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core] Read of size 8 at addr ffff889860ed0b28 by task kworker/u113:2/5277 Call Trace: mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core] devlink_health_reporter_recover+0xa2/0x150 devlink_health_report+0x254/0x7c0 mlx5e_reporter_tx_timeout+0x297/0x380 [mlx5_core] mlx5e_tx_timeout_work+0x109/0x170 [mlx5_core] process_one_work+0x677/0xf20 worker_thread+0x51f/0xd90 kthread+0x3a5/0x810 ret_from_fork+0x208/0x400 ret_from_fork_asm+0x1a/0x30 (CVE-2026-64122)

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

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

  - 已修复 Linux 内核中的下列漏洞：netfilter: nft_inner: release local_lock before re-enabling softirqs Quoting sashiko: In the error path, local_bh_enable() is called before local_unlock_nested_bh(). (CVE-2026-64150)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: mana: Skip redundant detach on already-detached port When mana_per_port_queue_reset_work_handler() runs after a previous detach succeeded but attach failed, the port is left in a detached state with apc->tx_qp and apc->rxqs already freed.
    Calling mana_detach() again unconditionally leads to NULL pointer dereferences during queue teardown. Add an early exit in mana_detach() when the port is already in detached state (!netif_device_present) for non-close callers, making it safe to call idempotently. This allows the queue reset handler and other recovery paths to simply retry mana_attach() without redundant teardown. (CVE-2026-63972)

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

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

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

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

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

  - 已修复 Linux 内核中的下列漏洞：ovpn: fix race between deleting interface and adding new peer While deleting an existing ovpn interface, there is a very narrow window where adding a new peer via netlink may cause the netdevice to hang and prevent its unregistration. It may happen during ovpn_dellink(), when all existing peers are freed and the device is queued for deregistration, but a CMD_PEER_NEW message comes in adding a new peer that takes again a reference to the netdev. At this point there is no way to release the device because we are under the assumption that all peers were already released. Fix the race condition by releasing all peers in ndo_uninit(), when the netdevice has already been removed from the netdev list. Also ovpn_peer_add() has now an extra check that forces the function to bail out if the device reg_state is not REGISTERED. This way any incoming CMD_PEER_NEW racing with the interface deletion routine will simply stop before adding the peer. Note that the above check happens while holding the netdev_lock to prevent racing netdev state changes.
    ovpn_dellink() is now empty and can be removed. (CVE-2026-64043)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/msm/dpu: don't mix devm and drmm functions Mixing devm and drmm functions will result in a use-after-free on msm driver teardown if userspace keeps a reference on the drm device: The WB connector data will be destroyed because of the use of devm_kzalloc()), while the usersoace still can try interacting with the WB connector (which uses drmm_ functions). Change dpu_writeback_init() to use drmm_. Patchwork:
    https://patchwork.freedesktop.org/patch/722656/ (CVE-2026-64050)

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

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

  - 已修复 Linux 内核中的下列漏洞：nfsd: fix posix_acl leak and ignored error in nfsd4_create_file nfsd4_create_file() has two bugs in its ACL handling: The return value of nfsd4_acl_to_attr() is silently discarded. When the NFSv4-to-POSIX ACL conversion fails (e.g., -EINVAL for unsupported ACE types), the file is created without any ACL and the client receives NFS4_OK. This violates RFC 7530/8881 which require the server to reject unsupported attributes on CREATE. When start_creating() fails after ACL attributes have been populated in attrs (either via nfsd4_acl_to_attr or via ownership transfer from open->op_dpacl/op_pacl), the function jumps to out_write which skips nfsd_attrs_free(). The posix_acl allocations are leaked. A client can trigger this repeatedly with OPEN(CREATE), ACL attributes, and an invalid filename (e.g., longer than NAME_MAX). Fix both by capturing the nfsd4_acl_to_attr() return value and by changing the early error paths to jump to out instead of out_write. Initialize child to ERR_PTR(-EINVAL) so that end_creating() is safe to call even if start_creating() was never reached.
    (CVE-2026-53396)

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

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

  - 已修复 Linux 内核中的下列漏洞：block: don't overwrite bip_vcnt in bio_integrity_copy_user() bio_integrity_add_page() already sets bip_vcnt to 1 for the bounce segment.
    Overwriting it with nr_vecs breaks bip_vcnt <= bip_max_vcnt on WRITE (bip_max_vcnt is 1), so the gap-merge checks in block/blk.h read past the bip_vec[] flex array. On READ the read is in bounds but lands on a saved user bvec instead of the bounce. The line was added for split propagation, but bio_integrity_clone() doesn't copy bip_vcnt and BIP_CLONE_FLAGS excludes BIP_COPY_USER. (CVE-2026-64053)

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

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

  - 已修复 Linux 内核中的下列漏洞：platform/x86: uniwill-laptop: Do not enable the charging limit even when forced It seems that on some older models (~2020) the battery charging limit can permanently damage the battery. Prevent users from enabling this feature thru the force module parameter to avoid causing permanent hardware damage on such devices. (CVE-2026-64143)

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

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

  - 已修复 Linux 内核中的下列漏洞：mm/memory_hotplug: fix memory block reference leak on remove Patch series mm: Fix memory block leaks and locking, v2. This series fixes two memory block device reference leaks and one locking issue around the per-memory_block hwpoison counter.
    This patch (of 2): remove_memory_blocks_and_altmaps() looks up each memory block with find_memory_block(), which acquires a reference to the memory block device. That reference is never dropped on this path, resulting in a leaked device reference when removing memory blocks and their altmaps. Drop the reference after retrieving mem->altmap and clearing mem->altmap, before removing the memory block device.
    (CVE-2026-64180)

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

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

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

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/msm: Fix shrinker deadlock With PROVE_LOCKING on an Snapdragon X1 and VM reclaim pressure, we see:
    ====================================================== WARNING: possible circular locking dependency detected 7.0.0-debug+ #43 Tainted: G W ------------------------------------------------------ kswapd0/82 is trying to acquire lock: ffff800080ec3870 (reservation_ww_class_acquire){+.+.}-{0:0}, at:
    msm_gem_shrinker_scan+0x17c/0x400 [msm] but task is already holding lock: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (fs_reclaim){+.+.}-{0:0}:
    __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 fs_reclaim_acquire+0xd0/0xf0 dma_resv_lockdep+0x224/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20
    -> #1 (reservation_ww_class_mutex){+.+.}-{4:4}: __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 dma_resv_lockdep+0x1a8/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20 -> #0 (reservation_ww_class_acquire){+.+.}-{0:0}: check_prev_add+0x114/0x790 validate_chain+0x594/0x6f0
    __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 drm_gem_lru_scan+0x1ac/0x440 msm_gem_shrinker_scan+0x17c/0x400 [msm] do_shrink_slab+0x150/0x4a0 shrink_slab+0x144/0x460 shrink_one+0x9c/0x1b0 shrink_many+0x27c/0x5c0 shrink_node+0x344/0x550 balance_pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret_from_fork+0x10/0x20 other info that might help us debug this: Chain exists of: reservation_ww_class_acquire --> reservation_ww_class_mutex --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim);
    lock(reservation_ww_class_mutex); lock(fs_reclaim); lock(reservation_ww_class_acquire); *** DEADLOCK *** 1 lock held by kswapd0/82: #0: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988 stack backtrace: CPU: 4 UID: 0 PID: 82 Comm: kswapd0 Tainted: G W 7.0.0-debug+ #43 PREEMPT(full) Tainted:
    [W]=WARN Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET94W (1.66 ) 09/15/2025 Call trace:
    show_stack+0x20/0x40 (C) dump_stack_lvl+0x9c/0xd0 dump_stack+0x18/0x30 print_circular_bug+0x114/0x120 check_noncircular+0x178/0x198 check_prev_add+0x114/0x790 validate_chain+0x594/0x6f0
    __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 drm_gem_lru_scan+0x1ac/0x440 msm_gem_shrinker_scan+0x17c/0x400 [msm] do_shrink_slab+0x150/0x4a0 shrink_slab+0x144/0x460 shrink_one+0x9c/0x1b0 shrink_many+0x27c/0x5c0 shrink_node+0x344/0x550 balance_pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret_from_fork+0x10/0x20 kswapd0 holding fs_reclaim calls the MSM shrinker, which calls dma_resv_lock. This in turn acquires fs_reclaim. Fix this deadlock by using dma_resv_trylock() instead, dropping the subsequently unused passed wait-wound lock 'ticket'. Patchwork: https://patchwork.freedesktop.org/patch/723564/ [rob: fixup compile errors, replace lockdep splat with somethin ---truncated--- (CVE-2026-64100)

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

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

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

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

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

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

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

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

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

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

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

  - 已修复 Linux 内核中的下列漏洞：ethtool: tsinfo: don't pass ERR_PTR to genlmsg_cancel on prepare failure The goto err label leads to: genlmsg_cancel(skb, ehdr); return ret; If ethnl_tsinfo_prepare_dump() failed, it has not started a genlmsg. There's nothing to cancel, and passing an error pointer to genlmsg_cancel() would cause a crash. (CVE-2026-63986)

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

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

  - 已修复 Linux 内核中的下列漏洞：bpf: Drop task_to_inode and inet_conn_established from lsm sleepable hooks bpf_lsm_task_to_inode() is called under rcu_read_lock() and bpf_lsm_inet_conn_established() is called from softirq context, so neither hook can be used by sleepable LSM programs. (CVE-2026-63865)

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

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

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

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

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

  - 已修复 Linux 内核中的下列漏洞：scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the 0b prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this. (CVE-2026-63886)

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

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

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

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

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

  - 已修复 Linux 内核中的下列漏洞：irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0. After irq_work_single() clears BUSY via atomic_cmpxchg(), it still dereferences @work for irq_work_is_hard() and rcuwait_wake_up(). An irq_work_sync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete causing a use-after-free. Fix this by wrapping run_irq_workd() in guard(rcu)() so that the entire irq_work_single() execution is within an RCU read-side critical section. Then add synchronize_rcu() in irq_work_sync() after rcuwait_wait_event() to ensure the caller waits for the RCU grace period before returning, preventing premature frees. (CVE-2026-64073)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/gem: fix race between change_handle and handle_delete drm_gem_change_handle_ioctl leaves the old handle live in the IDR during the window between spin_unlock(table_lock) and the final spin_lock(table_lock). A concurrent drm_gem_handle_delete on the old handle succeeds in this window, decrements handle_count to 0, and frees the GEM object while the new handle's IDR entry still references it. NULL the old handle's IDR entry before dropping table_lock so that any concurrent GEM_CLOSE on the old handle sees NULL and returns
    -EINVAL. Restore the old entry on the prime-bookkeeping error path. (CVE-2026-63885)

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

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

  - f2fs：仅在启用时验证压缩缓存 inode F2FS_COMPRESS_INO（） 使用 NM_I（sbi）->max_nid作为压缩页面缓存 inode 的合成 inode 编号。仅当启用了compress_cache挂载选项时，该 inode 才存在。禁用compress_cache时，max_nid超出了有效的 inode 范围。因此，f2fs_check_nid_range（） 应拒绝指向 ino == max_nid 的损坏目录条目。但 is_meta_ino（） 当前会无条件地将 F2FS_COMPRESS_INO（） 视为元索引节点，因此 f2fs_iget（） 会绕过 do_read_inode（） 及其 nid 范围检查，而是实例化一个假的内部 inode。在匹配 f2fs_init_compress_inode（） 的 COMPRESS_CACHE上保护压缩的缓存 inode 案例。禁用compress_cache后，ino == max_nid 现在会遵循正常的 inode 路径，并因超出范围 nid 而遭到拒绝。（CVE-2026-63817）

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

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

  - keras-team/keras 版本 3.15.0 中的漏洞允许通过公共“keras.layers.TorchModuleWrapper.from_config”方法对攻击者控制的 PyTorch pickle 数据进行不安全的反序列化。此方法调用“torch.load（...， weights_only=False）”而不需要明确的不安全选择加入，例如“safe_mode=False”参数。在“SafeModeScope（True）”上下文之外调用时，缺失环境安全模式状态默认允许不安全的反序列化。如果使用此方法处理不受信任的 Keras 层配置，此问题可导致执行任意代码。产生该漏洞是因为该方法未强制执行安全的反序列化实践，除非 Keras 安全模式明确保护。（CVE-2026-12484）

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: mt76: mt7996: Clear wcid pointer in mt7996_mac_sta_deinit_link() Clear WCID pointer removing the sta link in mt7996_mac_sta_deinit_link routine. (CVE-2026-63866)

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

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

  - Bluetooth：6lowpan：检查 send_mcast_pkt（） 中的 skb_clone（） 返回值 如果内存分配失败，skb_clone（） 函数可能返回 NULL。send_mcast_pkt（） 在未检查返回值的情况下调用 skb_clone（），这样可在取消引用 skb->data 时导致 send_pkt（） 中出现空指针取消引用。在 skb_clone（） 之后添加 NULL 检查，如果克隆失败则跳过对等机。（CVE-2026-63991）

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

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

  - 已修复 Linux 内核中的下列漏洞：drivers/base/memory: fix memory block reference leak in poison accounting memblk_nr_poison_inc() and memblk_nr_poison_sub() look up a memory block via find_memory_block_by_id(), which acquires a reference to the memory block device. Both helpers use the returned memory block without dropping that reference, leaking the device reference on each successful lookup. Drop the reference after updating nr_hwpoison. (CVE-2026-64182)

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

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

  - Bluetooth：ISO：修复 iso_recv_frame iso_recv_frame 中的 UAF 在 iso_conn_lock 下读取 conn->sk，但在使用 sk 之前释放锁定，且未保留任何引用。并发 iso_sock_kill（） 可释放该窗口中的 sk，从而在 sk->sk_state 和 sock_queue_rcv_skb（） 上造成释放后使用。修复方法为将裸指针读取替换为 iso_sock_hold（conn），其会在保留旋转锁时调用 sock_hold（），进而在锁终止前以原子方式提升 refcount。添加 drop_put 标签，以便在保持成功的所有退出路径中调用 sock_put（）。（CVE-2026-63946）

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

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

  - 已修复 Linux 内核中的下列漏洞：perf/x86/intel: Improve validation and configuration of ACR masks Currently there are several issues on the user space ACR mask validation and configuration. - The validation for user space ACR mask (attr.config2) is incomplete, e.g., the ACR mask could include the index which belongs to another ACR events group, but it's not validated. - An early return on an invalid ACR mask caused all subsequent ACR groups to be skipped. - The stale hardware ACR mask (hw.config1) is not cleared before setting new hardware ACR mask. The following changes address all of the above issues. - Figure out the event index group of an ACR group. Any bits in the user-space mask not present in the index group are now dropped. - Instead of an early return on invalid bits, drop only the invalid portions and continue iterating through all ACR events to ensure full configuration. - Explicitly clear the stale hardware ACR mask for each event prior to writing the new configuration.
    Besides, a non-leader event member of ACR group could be disabled in theory. This could cause bit-shifting errors in the acr_mask of remaining group members. But since ACR sampling requires all events to be active, this should not be a big concern in real use case. Add a FIXME comment to notice this risk.
    (CVE-2026-53370)

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

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

  - 已修复 Linux 内核中的下列漏洞：ksmbd: fix durable reconnect error path file lifetime After a durable reconnect succeeds, ksmbd_reopen_durable_fd() republishes the same ksmbd_file into the session volatile-id table. If smb2_open() then takes a later error path, cleanup first calls ksmbd_fd_put(work, fp) and then unconditionally calls ksmbd_put_durable_fd(dh_info.fp). In this case fp and dh_info.fp are the same object. The first put drops the reconnect lookup reference, but the final durable put can run __ksmbd_close_fd(NULL, fp). Because the final close is not session-aware, it can free the file object without removing the volatile-id entry that was just published into the session table. Use the session-aware put for the final reconnect drop when the reconnect had already succeeded and the error path is cleaning up the republished file. Earlier reconnect failures, before fp is assigned to dh_info.fp, keep using the durable-only put path. (CVE-2026-64016)

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

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

  - 已修复 Linux 内核中的下列漏洞：ALSA: seq: Serialize UMP output teardown with event_input seq_ump_process_event() borrows client->out_rfile.output without synchronizing with the first-open and last-close transition in seq_ump_client_open() and seq_ump_client_close(). The last output unuse can therefore drop opened[STR_OUT] to zero and release the rawmidi file while an in-flight event_input callback is still inside snd_rawmidi_kernel_write(). That leaves the rawmidi substream runtime exposed to teardown before the write path has taken its own buffer reference. Add a per-client rwlock for the event_input-visible output file. Publish a newly opened output file under the write side, and hold the read side from the output lookup through snd_rawmidi_kernel_write(). The last output close copies and clears the visible output file under the write side, then drops the lock and releases the saved rawmidi file. Use IRQ-safe rwlock guards because event_input can also be reached from atomic sequencer delivery. The buggy scenario involves two paths, with each column showing the order within that path: path A label: event_input path path B label: last unuse path 1. seq_ump_process_event() reads 1.
    seq_ump_client_close() client->out_rfile.output. drops opened[STR_OUT] to zero. 2.
    snd_rawmidi_kernel_write1() 2. snd_rawmidi_kernel_release() has not yet pinned runtime. closes the output file. 3. The writer continues using 3. close_substream() frees the borrowed substream. substream->runtime.
    This keeps the output substream and runtime alive for the full event_input write while keeping rawmidi release outside the rwlock. KASAN reproduced this as a slab-use-after-free in snd_rawmidi_kernel_write1(), with allocation through seq_ump_use()/snd_seq_port_connect() and free through seq_ump_unuse()/snd_seq_port_disconnect(). Validation reproduced this kernel report: KASAN slab-use-after-free in snd_rawmidi_kernel_write1+0x9d/0x400 RIP: 0033:0x7f5528af837f Read of size 8 Call trace:
    dump_stack_lvl+0x73/0xb0 (?:?) print_report+0xd1/0x650 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?)
    __virt_addr_valid+0x1a7/0x340 (?:?) kasan_complete_mode_report_info+0x64/0x200 (?:?) kasan_report+0xf7/0x130 (?:?) snd_rawmidi_kernel_write1+0x9d/0x400 (?:?) __asan_load8+0x82/0xb0 (?:?) update_stack_state+0x1ef/0x2d0 (?:?) snd_rawmidi_kernel_write+0x1a/0x20 (?:?) seq_ump_process_event+0xd4/0x120 (sound/core/seq/seq_ump_client.c:82)
    __snd_seq_deliver_single_event+0x8a/0xe0 (?:?) snd_seq_deliver_from_ump+0x2b2/0xd60 (?:?) lock_acquire+0x14e/0x2e0 (?:?) find_held_lock+0x31/0x90 (?:?) snd_seq_port_use_ptr+0xa6/0xe0 (?:?)
    __kasan_check_write+0x18/0x20 (?:?) do_raw_read_unlock+0x32/0xa0 (?:?) _raw_read_unlock+0x26/0x50 (?:?) snd_seq_deliver_single_event+0x45c/0x4b0 (?:?) snd_seq_deliver_event+0x10d/0x1b0 (?:?) snd_seq_client_enqueue_event+0x192/0x240 (?:?) snd_seq_write+0x2cd/0x450 (?:?) apparmor_file_permission+0x20/0x30 (?:?) security_file_permission+0x51/0x60 (?:?) vfs_write+0x1ce/0x850 (?:?) __fget_files+0x12b/0x220 (?:?) lock_release+0xc8/0x2a0 (?:?) __rcu_read_unlock+0x74/0x2d0 (?:?)
    __fget_files+0x135/0x220 (?:?) ksys_write+0x15a/0x180 (?:?) rcu_is_watching+0x24/0x60 (?:?)
    __x64_sys_write+0x46/0x60 (?:?) x64_sys_call+0x7d/0x20d0 (?:?) do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) (CVE-2026-64029)

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

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

  - 已修复 Linux 内核中的下列漏洞：ovpn: respect peer refcount in CMD_NEW_PEER error path ovpn_nl_peer_new_doit()'s error path calls ovpn_peer_release() directly rather than ovpn_peer_put(), bypassing the kref. The accompanying comment (peer was not yet hashed, thus it is not used in any context) holds for UDP but not for TCP. For UDP, the ovpn_socket union uses the .ovpn arm and never points back at a peer; UDP encap_recv looks up peers via the not-yet-populated hashtables, so the new peer is unreachable until ovpn_peer_add() publishes it. For TCP, ovpn_socket_new() sets ovpn_sock->peer and ovpn_tcp_socket_attach() publishes ovpn_sock via rcu_assign_sk_user_data(). From that moment until ovpn_socket_release() detaches in the error path, the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll on the fd, as well as the strparser-driven ovpn_tcp_rcv() path, can reach the peer through sk_user_data -> ovpn_sock->peer and bump its refcount via ovpn_peer_hold().
    ovpn_tcp_socket_wait_finish() (called inside ovpn_socket_release()) drains strparser and the tx work, but does not synchronize with userspace syscall callers that already hold a peer reference. If ovpn_nl_peer_modify() or ovpn_peer_add() returns an error while such a caller is in flight - notably an ovpn_tcp_recvmsg() blocked in __skb_recv_datagram() on peer->tcp.user_queue - the direct ovpn_peer_release() destroys the peer while the caller still holds the reference, and the eventual ovpn_peer_put() from that caller operates on freed memory. Replace the direct destructor call with ovpn_peer_put() so the kref correctly defers destruction until the last reference is dropped. In the common case where no concurrent user is present, behaviour is unchanged: the kref hits zero immediately and ovpn_peer_release_kref() runs the same destructor. With this conversion ovpn_peer_release() has no callers outside peer.c - ovpn_peer_release_kref() in the same translation unit is the only remaining user
    - so make it static and drop its declaration from peer.h. (CVE-2026-64044)

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

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

  - 已修复 Linux 内核中的下列漏洞：iio: pressure: bmp280: fix stack leak in bmp580 trigger handler bmp580_trigger_handler() declares its scan buffer on the stack without an initializer and then memcpy()s 3 bytes of 24-bit sensor data into each 4-byte __le32 field. The high byte of comp_temp and comp_press is left uninitialized, and the channel storagebits is 32, so two bytes of stack are pushed to userspace per scan. This is a regression from when the buffer lived in the private data, the move to a stack-local struct dropped the implicit zeroing. bme280_trigger_handler() was fixed up to handle this bug, but this driver was not fixed because there was no padding hole, but rather a short-fill issue. Fix this all by just zero-initializing the structure on the stack. (CVE-2026-63965)

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

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

  - phonet/pep：围绕转发的 sk_receive_skb（） 禁用 BH 网络接收路径通常从 softirq 上下文运行，但采用套接字锁定的协议可能将数据包存储在 backlog 中，然后从进程上下文进行处理。在这种情况下，release_sock（） -> __release_sock（） 会终止具有 spin_unlock_bh（） 的 slock，然后在启用下半部的情况下调用 sk->sk_backlog_rcv（）。典型的 sk_backlog_rcv 处理程序会处理其 backlog 正在被耗尽的套接字，因此条目时的 BH 状态与它们所接触的 slock 无关。pep_do_rcv（） 则不同：当入站 skb 以现有 PEP 管道为目标时，它会通过 sk_receive_skb（） 将该 skb 转发到不同的 *子* 套接字。此帮助程序采用包含 bh_lock_sock_nested（） 的子锁，后者只是 spin_lock_nested（），并假定 BH 已关闭。因此，在 BH 开启（进程路径）和 BH 关闭（softirq 路径）时，都会获取相同的子锁：进程环境 softirq context --------------- --------------- release_sock（listener） __netif_receive_skb（）
    __release_sock（） phonet_rcv（） spin_unlock_bh（） __sk_receive_skb（listener） [BH 已启用] [BH 已禁用] sk_backlog_rcv： sk_backlog_rcv： pep_do_rcv（） pep_do_rcv（） sk_receive_skb（child） sk_receive_skb（child） bh_lock_sock_nested（child） bh_lock_sock_nested（child） => SOFTIRQ-ON-W => IN-SOFTIRQ-W Lockdep 将此标记为不一致的锁定状态， 并且如果同一 CPU 中的 softirq 尝试接收相同的子套接字，而其锁在启用 BH 的路径中保留，则可能变成真正的自死锁：警告：不一致的锁定状态不一致 {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} 使用。
    （slock-AF_PHONET/1）{+.?.}-{3:3}， at： __sk_receive_skb+0x1cf/0x900 __sk_receive_skb net/core/sock.c：563 sk_receive_skb include/net/sock.h：2022 [内联] pep_do_rcv net/phonet/pep.c：675 sk_backlog_rcv include/net/sock.h：1190 __release_sock net/core/sock.c：3216 release_sock net/core/sock.c：3815 pep_sock_accept net/phonet/pep.c：879 将转发的 sk_receive_skb（） 封装在 local_bh_disable（） / local_bh_enable（） 中，以便始终使用BH 关闭。local_bh_disable（） 在 softirq 路径上安全嵌套。通过内部 syzkaller 模糊测试发现;linux-6.1.y syzbot 仪表板上也存在与 extid 44f0626dd6284f02663c 相同的根源。在 KASAN + LOCKDEP + PROVE_LOCKING 下转载，复制品： https://pastebin.com/A3t8xzCR （CVE-2026-64177）

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

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

  - 已修复 Linux 内核中的下列漏洞：ethtool: module: avoid leaking a netdev ref on module flash errors module_flash_fw_schedule() is missing undo for setting the in_progress flag and taking the netdev reference. Delay taking these, the device can't disappear while we are holding rtnl_lock. (CVE-2026-63997)

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

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

  - 已修复 Linux 内核中的下列漏洞：dpll: zl3073x: use
    __dpll_device_change_ntf() and remove change_work The change_work was introduced to send device change notifications from DPLL device callbacks without deadlocking on dpll_lock, since the callbacks are already invoked under that lock. Now that __dpll_device_change_ntf() is exported for callers that already hold dpll_lock, use it directly and remove the change_work infrastructure entirely. This eliminates a race condition where change_work could be re-scheduled after cancel_work_sync() during device teardown, potentially causing the handler to dereference a freed or NULL dpll_dev pointer. (CVE-2026-63977)

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

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

  - RDMA/core：首选 NLA_NUL_STRING 这些属性被评估为 c 字符串（传递到 strcmp），但 NLA_STRING 不会检查是否存在 \0 终止符。这需要切换到 nla_strcmp（） 并需要调整 printf fmt 说明符以不使用普通 %s，或者这需要使用NLA_NUL_STRING。由于代码长期以来一直如此，在我看来，用户空间确实包括终止 nul，甚至到目前为止还没有强制执行，因此NLA_NUL_STRING使用是更简单的解决方案。（CVE-2026-63860）

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

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

  - 已修复 Linux 内核中的下列漏洞：xfrm: iptfs: reset runtime state when cloning SAs iptfs_clone_state() clones the IPTFS mode data with kmemdup(). This copies runtime objects which must not be shared with the original SA, including the embedded sk_buff_head, hrtimers, spinlock, and in-flight reassembly/reorder state. If xfrm_state_migrate() fails after clone_state() but before the later init_state() call has reinitialized those fields, the cloned state can be destroyed by xfrm_state_gc_task() with list and timer state copied from the original SA. With queued packets this lets the clone splice and free skbs owned by the original IPTFS queue, leading to use-after-free and double-free reports in iptfs_destroy_state() and skb release paths. Reinitialize the clone's runtime state before publishing it through x->mode_data. Because clone_state() now publishes a destroyable mode_data object before init_state(), take the mode callback module reference there. Avoid taking it again from
    __iptfs_init_state() for the same object. (CVE-2026-63911)

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

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

  - 已修复 Linux 内核中的下列漏洞：cachefiles: Fix error return when vfs_mkdir() fails When vfs_mkdir() fails, the error code is not extracted from the returned error pointer.
    This causes mkdir_error to be reached with ret=0, which leads to returning ERR_PTR(0) (NULL) instead of a proper error pointer. Fix this by extracting the error code from the error pointer when vfs_mkdir() fails.
    (CVE-2026-64040)

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

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

  - scsi：core：从 scsi_run_host_queues 为所有非SDEV_DEL设备运行队列 SCSI 主机处于恢复状态时，scsi_mq_requeue_cmd（） 不会为将来要踢出的重新排队命令设置重新排队列表。预期调用 scsi_run_host_queues（） 将会在清除恢复状态后驱逐所有 SCSI 设备。但是，scsi_run_host_queues（） 使用会使用 scsi_device_get（） 的 shost_for_each_device（），因此会忽略与 SDEV_CANCEL 类似的部分删除状态的设备。但这些设备也可能有重新排队的请求，导致其请求因不被踢出而卡住，并导致设备删除进程挂起。scsi_run_host_queues（） 需要针对比宏 shost_for_each_device（） 允许的更多的设备运行。不要使用过于严格的 scsi_device_get（） 状态检查，而是只忽略处于SDEV_DEL状态或无法获取引用的设备。尝试在调用 scsi_run_host_queues（） 时为所有其他设备运行队列。（CVE-2026-64003）

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: SEV: Use READ_ONCE() when reading entries/indices from PSC buffer Use READ_ONCE() when reading entries/indices from the guest-accessible Page State Change buffer to defend against TOCTOU bugs. Don't bother with READ_ONCE()/WRITE_ONCE() for cases where KVM is writing (and not consuming the result!), as the guest isn't supposed to touch the buffer while it's being processed. I.e. using READ_ONCE() is all about protecting against misbehaving guests. (CVE-2026-63937)

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

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

  - ethtool：eeprom：为 EEPROM Netlink 回退添加更多安全性 读取模块 EEPROM （fallback_set_params（）） 用于读取模块的 Netlink 回退路径验证该偏移< eeprom_len，但不检查偏移 + 长度是否在eeprom_len范围内。ioctl 等效项（ioctl.c 中的 ethtool_get_any_eeprom（））始终强制实施两个边界：if （eeprom.offset + eeprom.len > total_len） return -EINVAL;这可导致驱动程序和设备 FW 出现意外。向 fallback_set_params（） 添加缺少的偏移 + 长度验证以镜像 ioctl。同样，- 一般的 ethtool 核心，尤其是 ethtool_get_any_eeprom（） 会尝试将传递给驱动程序的所有缓冲区归零初始化，以避免任何额外的清零工作。eeprom_fallback（） 使用普通 kmalloc（），请将其更改为 zalloc。（CVE-2026-63985）

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

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

  - smb：客户端：需要 CIFS SWN netlink 的 net admin CIFS_GENL_CMD_SWN_NOTIFY为用户空间 witness-notify 命令。预期发送者是 cifs.witness 帮助程序，但 generic-netlink 操作当前没有功能标记，因此任何本地进程都可以向内核内见证处理程序发送RESOURCE_CHANGE或CLIENT_MOVE通知。同一系列暴露没有多播群组功能标记的CIFS_GENL_MCGRP_SWN。发送至该群组的注册消息包括见证注册 ID，并且对于经 NTLM 认证的挂载，包括从 CIFS 会话复制的用户名、域和密码属性。本地非特权进程不应能加入该群组并接收这些消息。
    需要CAP_NET_ADMIN才能通过 GENL_ADMIN_PERM 传入 SWN_NOTIFY命令，并需要通过网络命名空间进行CAP_NET_ADMIN才能通过 GENL_MCAST_CAP_NET_ADMIN 加入 SWN 多播群组。cifs.witness 服务以这两种操作所需的权限运行。（CVE-2026-64137）

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

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

  - usb：gadget：composite：修复 WebUSB GET_URL 处理中的整数下溢 composite_setup（） 中的 WebUSB GET_URL 处理程序使用 landing_page_length = w_length - WEBUSB_URL_DESCRIPTOR_HEADER_LENGTH + landing_page_offset; 缩小landing_page_length以适合主机提供的 wLength。如果 wLength 小于 WEBUSB_URL_DESCRIPTOR_HEADER_LENGTH则无符号减法封装，以及后续的 memcpy（url_descriptor->URL、cdev->landing_page + landing_page_offset、landing_page_length - landing_page_offset）;最终会将接近 UINT_MAX 个字节从 cdev->landing_page 复制到 cdev->req->buf 中。
    KASAN 报告 kmalloc-2k gadget_info分配的 composite_setup 中存在越界 slab，并将FORTIFY_SOURCE memcpy 捕获为 4294967293 字节的跨字段写入到 url_descriptor->URL（大小 252）。USB 主机可通过针对任何已配置 webusb/use=1 且已配置 landingPage 的小工具的单个 SETUP 数据包访问此权限。在计算 math： 之前处理 small-wLength 情况：当主机请求的字节数少于 URL 描述符标头时，只有标头有意义，无需复制任何 URL 字节。将 landing_page_length 设置为 landing_page_offset 会使现有 memcpy 成为非 op，并且对所有较大的 wLength 值保持返回主机的描述符不变。（CVE-2026-63896）

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

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

  - Bluetooth：L2CAP：修复 ！conn 的 l2cap_chan_timeout（） 中的 chan ref 泄漏 __set_chan_timer（） 在计划延迟的工作之前，通过 l2cap_chan_hold（） 获取l2cap_chan引用。l2cap_chan_timeout（） 中的正常路径丢弃此引用，结尾为 l2cap_chan_put（），但当 chan->conn 为 NULL 时，提早返回会跳过放置，导致泄露引用。提前返回前添加缺失的 l2cap_chan_put（）。（CVE-2026-63948）

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

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

  - gpio：aggregator：停用聚合器时删除软件节点 停用设备时，使用 configfs 时为聚合器平台设备创建的动态软件节点会泄漏。
    将其作为拆除路径的最后一步将其摧毁。（CVE-2026-64022）

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

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

  - netfilter： conntrack： tcp：不在未检查方向的情况下强制 invalid-seq RST 关闭 TCP conntrack 状态机中的意外行为允许使用具有无效序列号的 RST 数据包强制连接进入 CLOSE 状态。具体而言，在观测到 SYN 数据包后，带有无效 SEQ 的 RST 可将连接跟踪条目转换为 TCP_CONNTRACK_CLOSE，而不管 RST 是否对应于预期的回复方向。相关代码路径假设 RST 是对传出 SYN 的响应，但未验证数据包方向或确保确实是向相反方向发送匹配的 SYN。因此，由 SYN 后接无效序列 RST 所构成的构建数据包序列可提前终止活动的 NAT 条目。这使得连接破坏比预期容易。因此，请加强状态转换逻辑，以确保只有当 RST 是对之前观察到的正确方向上的 SYN 的有效响应时，才会发生 RST 触发的 CLOSE 转换。（CVE-2026-63913）

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

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

  - auxdisplay：line-display：修复零长度 message_store（） 上的 OOB 读取 linedisp_display（） 在检查 count 是否为零之前无条件读取 msg[count - 1]，因此对消息 sysfs 属性的零字节写入会命中 msg[-1]： write（fd， ， 0）;-> message_store（...， buf， count=0） -> linedisp_display（linedisp， buf， count=0） -> msg[count - 1] == '\n' ;越界读取 该存储的 kernfs 写入缓冲区为 1 字节分配（kernfs_fop_write_iter（） 执行 kmalloc（len + 1） 和 len == 0），因此 msg[-1] 是在 slab 对象之前进行 1 字节读取。在启用了 KASAN 的内核上，这会触发越界报告并造成错误;在 stock 内核上，它会静默读取相邻的 slab 数据，如果该字节恰好是 '\n'，则下列 count-- 将 0 ssize_t 封装到 -1，然后传递给 kmemdup_nul（）。 linedisp_display（） 可通过 message_store（） sysfs 回调（drivers/auxdisplay/line-display.c 消息属性，模式 0644）和树内初始消息设置（count == -1， 因此，OOB 路径只能通过零字节写入由用户空间触发;vfs_write（） 在计数 == 0 时不会短路，而无论如何 kernfs_fop_write_iter（） 都会调度存储回调。通过计数检查保护尾部换行符修剪。然后，现有的 if （！count） 块采用不变更的清除显示路径。影响通过 linedisp_register（） / linedisp_attach（） 注册的所有 auxdisplay 驱动程序：ht16k33、max6959、img-ascii-lcd、seg-led-gpio。（CVE-2026-63949）

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

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

  - 已修复 Linux 内核中的下列漏洞：octeontx2-af: validate body pcifunc in rvu_mbox_handler_rep_event_notify rvu_mbox_handler_rep_event_notify() in drivers/net/ethernet/marvell/ octeontx2/af/rvu_rep.c queues a sender-controlled REP_EVENT_NOTIFY request body verbatim, and rvu_rep_up_notify() then forwards event->pcifunc (the nested body field, distinct from the AF-normalised header pcifunc) into rvu_get_pfvf(), rvu_get_pf() and the AF->PF mailbox device index without any bounds check. A VF attached to a PF that has been put into switchdev representor mode reaches this path: the VF mailbox handler otx2_pfvf_mbox_handler() forwards every message id including MBOX_MSG_REP_EVENT_NOTIFY to AF without an allowlist, and the AF dispatcher rewrites only msg->pcifunc, leaving struct rep_event::pcifunc attacker-controlled. The sibling rvu_mbox_handler_esw_cfg() refuses requests whose header pcifunc is not rvu->rep_pcifunc; this handler has no equivalent gate. An out-of-range body pcifunc selects an &rvu->pf[]/&rvu->hwvf[] element past the allocated array and, for RVU_EVENT_MAC_ADDR_CHANGE, turns into a six-byte attacker-chosen OOB ether_addr_copy() target inside the queued worker; KASAN reports a slab-out-of-bounds write in rvu_rep_wq_handler. Reject malformed requests at the handler entry by gating on is_pf_func_valid(), which is already the canonical PF/VF range check in this driver; expose it via rvu.h so callers in rvu_rep.c can use it instead of open-coding the same range arithmetic.
    (CVE-2026-63923)

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

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

  - xfrm： input：在延迟传输重新注入期间保持 netns 传输模式重新注入会将 struct net 指针存储在 skb->cb 中，稍后会从 xfrm_trans_reinject（） 使用。该指针必须保持有效，直到延迟回调运行。在为延迟的再注入工作排队时获取 netns 引用，并在回调完成后将其终止。使用 maybe_get_net（） 以便排队路径不恢复已被拆散的命名空间。这保留了现有工作队列设计，并针对所有 xfrm_trans_queue_net（） 用户修复了特定位置的 netns 生命周期处理。（CVE-2026-63919）

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

ID	名称	严重性
328120	Linux Distros 未修补的漏洞：CVE-2026-64122	critical
328119	Linux Distros 未修补的漏洞：CVE-2026-64150	critical
328118	Linux Distros 未修补的漏洞：CVE-2026-63972	high
328117	Linux Distros 未修补的漏洞：CVE-2026-64102	critical
328116	Linux Distros 未修补的漏洞：CVE-2026-64043	medium
328115	Linux Distros 未修补的漏洞：CVE-2026-64050	high
328114	Linux Distros 未修补的漏洞：CVE-2026-53396	high
328113	Linux Distros 未修补的漏洞：CVE-2026-64053	high
328112	Linux Distros 未修补的漏洞：CVE-2026-64143	medium
328111	Linux Distros 未修补的漏洞：CVE-2026-64180	medium
328110	Linux Distros 未修补的漏洞：CVE-2026-63933	medium
328109	Linux Distros 未修补的漏洞：CVE-2026-64100	medium
328108	Linux Distros 未修补的漏洞：CVE-2026-64165	medium
328107	Linux Distros 未修补的漏洞：CVE-2026-63942	high
328106	Linux Distros 未修补的漏洞：CVE-2026-63807	high
328105	Linux Distros 未修补的漏洞：CVE-2026-63986	medium
328104	Linux Distros 未修补的漏洞：CVE-2026-63865	high
328103	Linux Distros 未修补的漏洞：CVE-2026-63890	medium
328102	Linux Distros 未修补的漏洞：CVE-2026-63886	critical
328101	Linux Distros 未修补的漏洞：CVE-2026-64014	high
328100	Linux Distros 未修补的漏洞：CVE-2026-64073	high
328099	Linux Distros 未修补的漏洞：CVE-2026-63885	high
328098	Linux Distros 未修补的漏洞：CVE-2026-63817	high
328097	Linux Distros 未修补的漏洞：CVE-2026-12484	high
328096	Linux Distros 未修补的漏洞：CVE-2026-63866	high
328095	Linux Distros 未修补的漏洞：CVE-2026-63991	medium
328094	Linux Distros 未修补的漏洞：CVE-2026-64182	medium
328093	Linux Distros 未修补的漏洞：CVE-2026-63946	high
328092	Linux Distros 未修补的漏洞：CVE-2026-53370	medium
328091	Linux Distros 未修补的漏洞：CVE-2026-64016	critical
328090	Linux Distros 未修补的漏洞：CVE-2026-64029	high
328089	Linux Distros 未修补的漏洞：CVE-2026-64044	high
328088	Linux Distros 未修补的漏洞：CVE-2026-63965	high
328087	Linux Distros 未修补的漏洞：CVE-2026-64177	medium
328086	Linux Distros 未修补的漏洞：CVE-2026-63997	medium
328085	Linux Distros 未修补的漏洞：CVE-2026-63977	high
328084	Linux Distros 未修补的漏洞：CVE-2026-63860	high
328083	Linux Distros 未修补的漏洞：CVE-2026-63911	high
328082	Linux Distros 未修补的漏洞：CVE-2026-64040	medium
328081	Linux Distros 未修补的漏洞：CVE-2026-64003	high
328080	Linux Distros 未修补的漏洞：CVE-2026-63937	high
328079	Linux Distros 未修补的漏洞：CVE-2026-63985	high
328078	Linux Distros 未修补的漏洞：CVE-2026-64137	high
328077	Linux Distros 未修补的漏洞：CVE-2026-63896	medium
328076	Linux Distros 未修补的漏洞：CVE-2026-63948	high
328075	Linux Distros 未修补的漏洞：CVE-2026-64022	medium
328074	Linux Distros 未修补的漏洞：CVE-2026-63913	high
328073	Linux Distros 未修补的漏洞：CVE-2026-63949	high
328072	Linux Distros 未修补的漏洞：CVE-2026-63923	high
328071	Linux Distros 未修补的漏洞：CVE-2026-63919	high

检测

Nessus 的 Misc. 系列

critical

critical

high

critical

medium

high

high

high

medium

medium

medium

medium

medium

high

high

medium

high

medium

critical

high

high

high

high

high

high

medium

medium

high

medium

critical

high

high

high

medium

medium

high

high

high

medium

high

high

high

high

medium

high

medium

high

high

high

high