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

  - sysfs：更新失败时不删除现有目录 为指定群组调用 sysfs_update_group（） 而 create_files（） 失败（例如 -ENOMEM）时，internal_create_group（） 会在群组目录上调用 kernfs_remove（kn）。在更新路径中，kn 通过 kernfs_find_and_get（） 获取，它指向在此调用之前已存在的目录。将其删除会以静默的方式破坏并非调用程序创建的 sysfs 组。仅自行创建目录时才删除该目录。更新失败时，目录将保持由 create_files（） 内的 remove_files（） 留空，但可以通过重试来重新填充。
    (CVE-2026-64185)

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

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

  - net/handshake：耗尽 net 命名空间退出中的待定请求 handshake_net_exit（） 中 list_splice_init（） 的参数颠倒。该调用会将本地空请求列表移动到 hn->hn_requests 上，使本地列表留空，因此后续的漏循环会运行零迭代。销毁网络命名空间时，尚未接受的待定握手请求不会拆散;每个选项都在套接字文件和handshake_req分配中保留一个引用。按记录的顺序传递源和目标（list_splice_init（list， head） 将列表移动到 head），以便将待定列表传输到本地暂存列表并通过 handshake_complete（） 耗尽。修复 splice 方向会暴露列表损坏争用。在 splice 之后，每个 req->hr_list 仍有非空链接指针，用于串接堆栈本地擦除列表，而不是hn_requests。并行 handshake_req_cancel（） -- 例如，来自未采用 netns 引用的内核套接字上的 sunrpc 的 TLS 超时 -- 通过 rhashtable 查找请求，调用 remove_pending（），并看到 ！list_empty（&req->hr_list）。然后，__remove_pending_locked（） 在漏迭代时从暂存列表中list_del_init（） 一个条目，从而使其损坏。漏循环在条目上运行 list_del（） 之后到达的相同调用会改为命中LIST_POISON。让 remove_pending（） 检查 hn_lock 下的HANDSHAKE_F_NET_DRAINING，并在耗尽正在进行时报告“找不到”。排水管已经拥有所有权;handshake_complete（） 在 HANDSHAKE_F_REQ_COMPLETED 上的现有test_and_set仍然会针对调用使用者hp_done的用户在 drain 和 cancel 之间进行仲裁。在漏中使用 list_del_init（） 而不是 list_del（），这样在漏释放条目之后 req->hr_list 就不会携带LIST_POISON。remove_pending（） 中的 DRAINING 防护使 cancel 返回 false，但 cancel 仍会失败至 HANDSHAKE_F_REQ_COMPLETED 上的 test_and_set_bit 并丢失请求的 hr_file 引用。如果这是最后一个引用，则在没有其他引脚的情况下，sk_destruct释放请求，前提是该请求仍链接在漏循环的本地列表中。在释放列表之前，将每个请求的hr_file固定在hn_lock下，并在循环完成请求后删除该漏引脚。
    (CVE-2026-63978)

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

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

  - ksmbd：smb_check_perm_dacl（） ACE-walk 循环中的 OOB 读取回归 Commit d07b26f39246（ksmbd：要求 smb_check_perm_dacl（） 中的 ACE 大小下限）引入了转置的边界检查：if （offsetof（struct smb_ace， sid） + aces_size < CIFS_SID_BASE_SIZE） Since offsetof（..sid） 为 8，CIFS_SID_BASE_SIZE 为 8，计算结果为“aces_size < 0”。由于“aces_size”始终为非负值，因此此检查会成为死代码并且永远不会中断循环。更糟糕的是，该提交删除了旧的 4 字节保护，这意味着即使“aces_size”为 0-3 字节，循环现在也会读取“ace->size”（偏移 2）。这会在后续SMB2_CREATE操作期间重新打开经过 pntsd 分配的 2 字节堆越界 （OOB） 读取。通过正确转置比较要求至少 16 字节（8 字节偏移 + 8 字节 SID 基本）来修复此问题，并匹配 smb_inherit_dacl（） 中使用的正确形式。（CVE-2026-63909）

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

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

  - 已修复 Linux 内核中的下列漏洞：zram: fix use-after-free in zram_writeback_endio A crash was observed in zram_writeback_endio due to a NULL pointer dereference in wake_up. The root cause is a race condition between the bio completion handler (zram_writeback_endio) and the writeback task. In zram_writeback_endio, wake_up() is called on &wb_ctl->done_wait after releasing wb_ctl->done_lock. This creates a race window where the writeback task can see num_inflight become 0, return, and free wb_ctl before zram_writeback_endio calls wake_up(). CPU 0 (zram_writeback_endio) CPU 1 (writeback_store) ============================ ============================ zram_writeback_slots zram_submit_wb_request zram_submit_wb_request wait_event(wb_ctl->done_wait) spin_lock(&wb_ctl->done_lock);
    list_add(&req->entry, &wb_ctl->done_reqs); spin_unlock(&wb_ctl->done_lock); wake_up(&wb_ctl->done_wait);
    zram_complete_done_reqs spin_lock(&wb_ctl->done_lock); list_add(&req->entry, &wb_ctl->done_reqs);
    spin_unlock(&wb_ctl->done_lock); while (num_inflight) > 0) spin_lock(&wb_ctl->done_lock);
    list_del(&req->entry); spin_unlock(&wb_ctl->done_lock); // num_inflight becomes 0 atomic_dec(num_inflight); // Leave zram_writeback_slots // Free wb_ctl release_wb_ctl(wb_ctl); // UAF crash! wake_up(&wb_ctl->done_wait); This patch fixes this race by using RCU. By protecting wb_ctl with rcu_read_lock() in zram_writeback_endio and using kfree_rcu() to free it, we ensure that wb_ctl remains valid during the execution of zram_writeback_endio. (CVE-2026-63951)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/amdgpu/vcn: set no_user_fence for VCN v5.0.0 enc ring VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 49b1fbbb5a071197ee71e2d70959b1cb29bdc317) (CVE-2026-63850)

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

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

  - btrfs：tracepoints：修复在 btrfs_sync_file（） 中处于原子上下文中的休眠 在原子上下文（所有跟踪事件都是）中调用跟踪事件 btrfs_sync_file（），由于调用 dget_parent（） 而需要对 dput（） 的调用）可休眠，从而触发内核 splat。例如，启用跟踪事件并从 fstests 运行 btrfs/056 可对此重现此情况。dmesg 中显示的崩溃如下：[53.919] BUG：sleeping 函数从 fs/dcache.c：970 的无效上下文中调用 [53.947] in_atomic（）：1， irqs_disabled（）： 0， non_block： 0， PID： 32773，名称：xfs_io [53.988] preempt_count：2，预期：0 [53.967] RCU 嵌套深度：0，预期：0 [53.943] 在以下位置禁用抢占：[53.944] [<0000000000000000>] 0x0 [54.078] CPU：0 UID：0 PID：32773 通信：xfs_io 受感染： G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT（full） [54.070] Tainted： [W]=WARN [54.071] 硬件名称： QEMU Standard PC （i440FX + PIIX， 1996）， BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] 调用跟踪： [54.074] [54.076] <TASK> dump_stack_lvl+0x56/0x80 [54.079] __might_resched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] trace_event_raw_event_btrfs_sync_file+0x75/0x140 [btrfs] [54.089] btrfs_sync_file+0x1ed/0x530 [btrfs] [54.087] ？ __handle_mm_fault+0x8ae/0xed0 [54.089] btrfs_do_write_iter+0x172/0x210 [btrfs] [54.091] vfs_write+0x21f/0x450 [54.094]
    __x64_sys_pwrite64+0x8d/0xc0 [54.096] ？ do_user_addr_fault+0x20c/0x670 [54.099] do_syscall_64+0x60/0xf20 [54.092] ？ clear_bhb_loop+0x60/0xb0 [54.094] entry_SYSCALL_64_after_hwframe+0x76/0x7e 因此请停止使用 dget_parent（） 和 dput（），并以 dentry->d_parent 的形式直接访问父 dentry。这也是 ext4 在其等效跟踪事件 ext4_sync_file_enter（） 中执行的操作。（CVE-2026-64164）

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

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

  - 已修复 Linux 内核中的下列漏洞：ethtool: cmis: validate start_cmd_payload_size from module The CMIS firmware update code reads start_cmd_payload_size from the module's FW Management Features CDB reply and uses it directly as the byte count for memcpy. The destination buffer is 112 bytes (ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8). So a malicious module (or corrupted response) can cause a OOB write later on in cmis_fw_update_start_download(). Let's error out. If modules that expect longer LPL writes actually exist we should revisit. struct cmis_cdb_start_fw_download_pl's definition has to move, no change there. (CVE-2026-63995)

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

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

  - net/handshake：将 spin_lock_bh 用于 hn_lock nvmet_tcp_state_change（），这是一种在 BH 上下文中运行的套接字回调，可通过 nvmet_tcp_schedule_release_queue（） 和 tls_handshake_cancel（） 到达 handshake_req_cancel（）。handshake_req_cancel（） 通过普通 spin_lock（） 获取 hn->hn_lock。如果当 softirq 调用取消路径时，同一 CPU 上的进程上下文线程持有 hn->hn_lock，则锁定尝试会死锁。这是唯一从 BH 上下文中调用 tls_handshake_cancel（） 的调用程序;所有其他使用者都从进程上下文中调用它。延迟取消以处理 NVMe 目标中的上下文并不简单：nvmet_tcp_schedule_release_queue（） 必须以原子方式调用 tls_handshake_cancel（），并将其状态转换为 DISCONNECTING。如果取消被延迟，握手完成回调可在取消运行之前在窗口中触发，观察意外状态并返回而不将其 kref 放在队列中。重做该联锁比强化握手锁更具侵入性。将所有 hn->hn_lock 采集从 spin_lock/spin_unlock 转换为 spin_lock_bh/spin_unlock_bh这样就永远不会在启用 softirqs 的情况下进行锁定。（CVE-2026-63980）

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

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

  - bpf：sockmap：修复 bpf_msg_push_data 中的末尾碎片偏移 当 bpf_msg_push_data（） 在 scatterlist 条目中间插入数据时，会将原始条目拆分为左碎片和右碎片。正确的片段偏移量是页面偏移量，但代码通过“start”推进它，此是消息全局插入点。对于插入到非第一个 SG 条目中，这会过度推进偏移量并使拆分布局不一致。将右侧片段偏移前推进片段本地增量“start - offset”，与从原始条目前面删除的长度匹配。（CVE-2026-63926）

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: ath11k: fix error path leaks in some WMI WOW calls Fix two instances where we used to directly return the result of ath11k_wmi_cmd_send(...). Because we did not check the return value, we also did not free the skb in the error path. (CVE-2026-64155)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/gpusvm: Fix unbalanced unlock in drm_gpusvm_scan_mm() There is a unbalanced lock/unlock to gpusvm notifier lock: [ 931.045868] ===================================== [ 931.046509] WARNING: bad unlock balance detected! [ 931.047149] 6.19.0-rc6+xe-**************** #9 Tainted: G U [ 931.048150] ------------------------------------- [931.048790] kworker/u5:0/51 is trying to release lock (&gpusvm->notifier_lock) at: [ 931.049801] [<ffffffffa090c0d8>] drm_gpusvm_scan_mm+0x188/0x460 [drm_gpusvm_helper] [ 931.050802] but there are no more locks to release! [ 931.051463] The drm_gpusvm_notifier_unlock() sits under err_free label and the first jump to err_free is just before calling the drm_gpusvm_notifier_lock() causing unbalanced unlock.
    (CVE-2026-63863)

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

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

  - drm/i915：修复 TTM 对象清除中潜在的 UAF TLDR：bo->ttm 对象可通过调用 ttm_bo_validate（） 进行更改，稍后将其转换到i915_tt对象以实际获得正确的指针。一位用户报告在大量使用 DG2 时遇到以下缺陷：[26620.095550] 哎呀：一般保护错误，可能针对非规范地址 0xa56b6b6b6b6b6b8b：0000 1 SMP NOPTI [26620.095556] CPU：2 UID：0 PID：
    631 通信：Xorg 未受 6.18.8 #1 污染 PREEMPT（lazy） [26620.095558] 硬件名称：华擎 B850M Steel Legend WiFi/B850M Steel Legend WiFi，BIOS 3.50 09/18/2025 [26620.095559] RIP：0010：i915_ttm_purge+0x84/0x100 [i915] [26620.095604] 代码：00 00 00 48 8d 54 24 10 48 89 e6 48 89 FB E8 83 AA AE FF 85 C0 75 6F 48 83 BB A8 01 00 00 00 74 2C 48 8B 45 78 48 85 C0 74 23 <48> 8B 78 20 48c7 c2 ff ff ff ff 31 f6 e8 7a 73 e3 e0 48 8b 7d 78 [26620.095605] RSP：0018：ffffc90005fd7430 EFLAGS： 00010282 [26620.095607] RAX： a56b6b6b6b6b6b6b6b RBX： ffff8881f46c3dc0 RCX： 0000000000000000 [26620.095608] RDX： 00000000000000000 RSI： 0000000000000246 RDI： 000000000ffffffff [26620.095609] RBP： ffff888289610f00 R08： 0000000000000001 R09： ffff88823b022000 [26620.095609] R10： ffff888103029b28 R11： ffff8881fc7f3800 R12： ffff88810b6150d0 [26620.095609] R13：
    ffff888289610f00 R14：000000000000000 R15：ffff8881f46c3dc0 [26620.095610] FS：00007f1004d86900（0000） GS：ffff88901c858000（0000） knlGS：0000000000000000 [26620.095611] CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 [26620.095611] CR2： 00007f0fdf489000 CR3： 000000035b0c1000 CR4： 0000000000750ef0 [26620.095612] PKRU： 55555554 [26620.095612] 调用跟踪： [26620.095615] []26620.095615<TASK> i915_ttm_move+0x2b9/0x420 [i915] [26620.095642] ？ ttm_tt_init+0x65/0x80 [ttm] [26620.095644] ？ i915_ttm_tt_create+0xc6/0x150 [i915] [26620.095667] ttm_bo_handle_move_mem+0xb6/0x160 [ttm] [26620.095669] ttm_bo_evict+0x100/0x150 [ttm] [26620.095671] ？ preempt_count_add+0x64/0xa0 [26620.095673] ？
    _raw_spin_lock+0xe/0x30 [26620.095675] ？ _raw_spin_unlock+0xd/0x30 [26620.095675] ？ i915_gem_object_evictable+0xb7/0xd0 [i915] [26620.095704] ttm_bo_evict_cb+0x6e/0xd0 [ttm] [26620.095705] ttm_lru_walk_for_evict+0xa6/0x200 [ttm] [26620.095708] ttm_bo_alloc_resource+0x185/0x4f0 [ttm] [26620.095709] ？ init_object+0x62/0xd0 [26620.095712] ttm_bo_validate+0x7a/0x180 [ttm] [26620.095713] ？
    _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095714] __i915_ttm_get_pages+0xb0/0x170 [i915] [26620.095737] i915_ttm_get_pages+0x9f/0x150 [i915] [26620.095759] ？ i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095786] ？ alloc_debug_processing+0xd0/0x100 [26620.095787] ？ _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095788] ？ i915_vma_instance+0xa0/0x4e0 [i915] [26620.095822] __i915_gem_object_get_pages+0x2f/0x40 [i915] [26620.095848] i915_vma_pin_ww+0x706/0x980 [i915] [26620.095875] ？ i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095904] eb_validate_vmas+0x170/0xa00 [i915] [26620.095930] i915_gem_do_execbuffer+0x1201/0x2b40 [i915] [26620.095953] ？ alloc_debug_processing+0xd0/0x100 [26620.095954] ？ _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095955] ？ i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.095977] ？ __wake_up_sync_key+0x32/0x50 [26620.095979] ？ i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.096001] ？ __slab_alloc.isra.0+0x67/0xc0 [26620.096003] i915_gem_execbuffer2_ioctl+0x11a/0x240 [i915] decode_stacktrace.sh指向取消引用 i915 TTM 页面向量容器的文件指针字段的结果，该容器与逐出时要清除的对象相关联。当对象标记为不再需要时，便会采用该路径。代码分析显示，i915 TTM 页面矢量容器可能会在函数仍然忙碌时，换成可清除对象内容的函数内的新实例。该函数通过更改对象放置和缓存策略的更通用的函数间接调用 ---truncated--- （CVE-2026-63884）

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled When the TLC notification disables AMSDU for a TID, the MLD driver sets max_tid_amsdu_len to the sentinel value 1. The TSO segmentation path in iwl_mld_tx_tso_segment() checks for zero but not for this sentinel, allowing it to reach the num_subframes calculation: num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad) = (1 + 2) / (1534 + 2) = 0 This zero propagates to iwl_tx_tso_segment() which sets: gso_size = num_subframes * mss = 0 Calling skb_gso_segment() with gso_size=0 creates over 32000 tiny segments from a single GSO skb. This floods the TX ring with ~1024 micro-frames (the rest are purged), creating a massive burst of TX completion events that can lead to memory corruption and a subsequent use-after-free in TCP's retransmit queue (refcount underflow in tcp_shifted_skb, NULL deref in tcp_rack_detect_loss). The MVM driver is immune because it checks mvmsta->amsdu_enabled before reaching the num_subframes calculation. The MLD driver has no equivalent bitmap check and relies solely on max_tid_amsdu_len, which does not catch the sentinel value.
    Fix this by detecting the sentinel value (max_tid_amsdu_len == 1) at the existing check and falling back to non-AMSDU TSO segmentation. Also add a WARN_ON_ONCE guard after the num_subframes division as defense-in-depth to catch any future code paths that produce zero through a different mechanism. (CVE-2026-64037)

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: SEV: Compute the correct max length of the in-GHCB scratch area When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer. The code was fine when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the *max* size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert). Opportunistically rename @len => @min_len to better reflect its role.
    (CVE-2026-63939)

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

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

  - ipv6：修复 rt6_fill_node（） 中可能的无限循环 Sashiko 报告了此问题 [1]。应用与提交 f8d8ce1b515a 相同的补丁（ipv6：修复 fib6_info_uses_dev（）） 中可能的无限循环）。持有 tb6_lock 的写入器可以在不等待 RCU 读取器的情况下list_del_rcu（&rt->fib6_siblings）;rt->fib6_siblings.next 随后仍指向旧环，而此 softirq-side 遍历器永远不会到达 &rt->fib6_siblings，进而造成 CPU 停止。fib6_del_route（） 始终在 list_del_rcu（） 之前WRITE_ONCE（）的 rt->fib6_nsiblings 到 0，因此内部循环检查是可靠的分离信号。[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev （CVE-2026-63969）

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

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

  - Bluetooth：ISO：序列化带有套接字锁定的 iso_sock_clear_timer iso_sock_close（） 在获取 lock_sock（sk） 之前会调用 iso_sock_clear_timer（）。iso_sock_clear_timer（） 在未保留套接字锁定的情况下读取 iso_pi（sk）->conn 两次：if （！iso_pi（sk）->conn） return;
    cancel_delayed_work（&iso_pi（sk）->conn->timeout_work）;同时，iso_conn_del（） 在 lock_sock（sk） 下执行并调用 iso_chan_del（），这会将 iso_pi（sk）->conn 设置为 NULL，并可能导致对连接的最终引用被丢弃：CPU0 CPU1 ---- ---- iso_sock_clear_timer（） if （conn ！= NULL） ...lock_sock（sk） iso_chan_del（） iso_pi（sk）->conn = NULL cancel_delayed_work（conn） /* NULL 取消引用或 UAF */ iso_pi（sk）->conn 在解锁窗口中不稳定，从而导致空指针取消引用或释放后使用。通过将套接字锁定的 iso_sock_clear_timer（） 移动到 lock_sock（）/release_sock（） 内部对其进行序列化，从而匹配 iso_conn_del（） 和所有其他调用站点中使用的模式。
    (CVE-2026-63945)

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

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

  - net/tcp-ao：修复 del_async 路径中密钥的释放后使用 在 tcp_ao_delete_key（） 中del_async，假设同步路径中存在的current_key和rnext_key有效性检查，假设这些指针在监听套接字上始终为空。但是，如果在套接字处于 CLOSE 状态时添加了 set_current=1/set_rnext=1 的密钥，则在 listen（） 将套接字转换为 LISTEN 之后，current_key 和 rnext_key 将不是 NULL。在 del_async=1 的情况下删除此类密钥时，hlist_del_rcu（） 和 call_rcu（） 会释放密钥，而不清除悬摆指针。在 RCU 宽限期过后，getsockopt（TCP_AO_INFO） 会从已释放的 slab 内存中取消引用 current_key->sndid 和 rnext_key->rcvid。当del_async路径引用正在删除的密钥时清除current_key和rnext_key。（CVE-2026-53389）

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

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

  - 9p：避免将 oldfid 放入 p9_client_walk（） 错误路径 通过将 clone 设置为 false 调用 p9_client_walk（） 时，fid 将别名 oldfid。如果在发送请求后遍历失败，则错误路径会跳至当前无条件调用 p9_fid_put（fid） 的 clunk_fid。这会终止对 oldfid 的引用，即使 oldfid 的所有权仍属于调用者。如果这是最后一个引用，则 oldfid 可能会在调用方仍预期其有效时被 cluk 并销毁。随后对 oldfid 的使用或放置可触发释放后使用或引用计数下溢。通过仅在 fid 没有别名 oldfid 时才将 fid 放入clunk_fid错误路径中来修复此问题，从而匹配以下错误路径中的现有防护。当多组件 walk 拆分为多个 p9_client_walk（） 调用且之后的非克隆 walk 失败时，可触发此漏洞。可根据要求提供重现和引用计数警告日志。（CVE-2026-63795）

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: iwlwifi: mld: stop TX during firmware restart When iwlwifi firmware crashes (e.g., NMI_INTERRUPT_UNKNOWN on Intel BE201/Wi-Fi 7), iwl_mld_nic_error() sets mld->fw_status.in_hw_restart to true. However, iwl_mld_tx_from_txq() does not check this flag before dequeuing frames from mac80211 and pushing them to the transport layer. Since the firmware is dead, iwl_trans_tx() returns -EIO for each frame, which then gets freed immediately. Under high-throughput conditions (e.g., Tailscale UDP traffic or active SSH sessions), this creates a tight dequeue-send-fail-free loop that wastes CPU cycles and generates rapid skb allocation churn, leading to memory pressure from slab fragmentation. The RX path already has this guard (iwl_mld_rx_mpdu checks in_hw_restart at rx.c:1906), and so does the TXQ allocation worker (iwl_mld_add_txqs_wk at tx.c:156). Add the same guard to iwl_mld_tx_from_txq() to stop all TX during firmware restart. Frames left in mac80211's TXQs are naturally drained after restart completes, when queue reallocation triggers iwl_mld_tx_from_txq() via iwl_mld_add_txq_list(), or when new upper-layer traffic invokes wake_tx_queue. Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on kernel 6.19.5 where the firmware crashes approximately every 10-15 minutes under Tailscale traffic. (CVE-2026-64175)

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

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

  - Meshtastic 是一个开源网状网络解决方案。在低于 2.7.21.1370b23 的版本中，Meshtastic GitHub 存储库的main_matrix.yml工作流由pull_request_target触发，多个作业会检出攻击者的 fork 代码，并以存储库密码的访问权限和提升的GITHUB_TOKEN权限执行该代码。不存在审批门。来自具有 author_association： NONE 的外部用户的拉取请求会自动触发 CI 工作流。该工作流会直接执行分支检出中的攻击者控制的文件。此问题可能导致 repo 的供应链受损、自托管运行器受损和/或存储库受管。此问题与 GHSA-6mwm-v2vv-pp96 不同，后者解决了通过github.head_ref在相同工作流程的设置作业中造成的命令注入。该补丁正确地移动到环境变量。但是，尚未解决 check、build 和 build-debian-src 作业中更严重的分支检出漏洞。版本 2.7.21.1370b23 包含针对此问题的补丁。
    (CVE-2026-44359)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/sched: act_mirred: Fix blockcast recursion bypass leading to stack overflow tcf_mirred_act() checks sched_mirred_nest against MIRRED_NEST_LIMIT (4) to prevent deep recursion. However, when the action uses blockcast (tcfm_blockid != 0), the function returns at the tcf_blockcast() call BEFORE reaching the counter increment. As a result, the recursion counter never advances and the limit check is entirely bypassed. When two devices share a TC egress block with a mirred blockcast rule, a packet egressing on device A is mirrored to device B via blockcast; device B's egress TC re-enters tcf_mirred_act() via blockcast and mirrors back to A, creating an unbounded recursion loop: tcf_mirred_act -> tcf_blockcast -> tcf_mirred_to_dev -> dev_queue_xmit -> sch_handle_egress -> tcf_classify -> tcf_mirred_act -> (repeat) This recursion continues until the kernel stack overflows. The bug is reachable from an unprivileged user via unshare(CLONE_NEWUSER | CLONE_NEWNET):
    user namespaces grant CAP_NET_ADMIN in the new network namespace, which is sufficient to create dummy devices, attach clsact qdiscs with shared blocks, and install mirred blockcast filters. BUG: TASK stack guard page was hit at ffffc90000b7fff8 Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 2 UID: 1000 PID: 169 Comm: poc Not tainted 7.0.0-rc7-next-20260410 RIP: 0010:xas_find+0x17/0x480 Call Trace:
    xa_find+0x17b/0x1d0 tcf_mirred_act+0x640/0x1060 tcf_action_exec+0x400/0x530 basic_classify+0x128/0x1d0 tcf_classify+0xd83/0x1150 tc_run+0x328/0x620 __dev_queue_xmit+0x797/0x3100 tcf_mirred_to_dev+0x7b1/0xf70 tcf_mirred_act+0x68a/0x1060 [repeating ~30+ times until stack overflow] Kernel panic - not syncing: Fatal exception in interrupt Fix this by incrementing sched_mirred_nest before calling tcf_blockcast() and decrementing it on return, mirroring the non-blockcast path. This ensures subsequent recursive entries see the updated counter and are correctly limited by MIRRED_NEST_LIMIT. (CVE-2026-63981)

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

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

  - 隧道：在 iptunnel_pmtud_build_icmp[v6]（） 中的 skb_cow（） 之后加载网络标头 Sashiko 发现 iptunnel_pmtud_build_icmp（） 和 iptunnel_pmtud_build_icmpv6（） 在可重新分配 skb->head 的 skb_cow（） 调用之前缓存 ip_hdr（） 和 ipv6_hdr（）。通过在 skb_cow（） 调用后初始化本地变量修复可能的 UAF。删除不需要的 skb_reset_network_header（） 调用。
    (CVE-2026-63994)

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

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

  - 已修复 Linux 内核中的下列漏洞：usb: gadget: f_fs: serialize DMABUF cancel against request completion ffs_epfile_dmabuf_io_complete() calls usb_ep_free_request() on the completed request but leaves priv->req, the back-pointer that ffs_dmabuf_transfer() set on submission, pointing at the freed memory. A later FUNCTIONFS_DMABUF_DETACH ioctl or ffs_epfile_release() on the close path still sees priv->req non-NULL under ffs->eps_lock: if (priv->ep && priv->req) usb_ep_dequeue(priv->ep, priv->req); so usb_ep_dequeue() is called on a freed usb_request. On dummy_hcd the dequeue path only walks a live queue and pointer-compares, so the freed pointer reads without faulting and KASAN requires an explicit check at the FunctionFS call site to surface the use-after-free. On SG-capable in-tree UDCs the dequeue path dereferences the supplied request immediately: * chipidea's ep_dequeue() does container_of(req, struct ci_hw_req, req) and reads hwreq->req.status before acquiring its own lock. * cdnsp's cdnsp_gadget_ep_dequeue() reads request->status first. The narrower option of clearing priv->req via cmpxchg() in the completion does not close the race: the completion runs without eps_lock, so a cancel path holding eps_lock can still observe priv->req non-NULL, race a concurrent completion that clears and frees, and pass the freed pointer to usb_ep_dequeue(). A slightly longer fix that moves the free into the cleanup work is needed. Same class of lifetime race as the recent usbip-vudc timer fix [1]. Take eps_lock in the sole place that mutates priv->req from the callback direction by moving usb_ep_free_request() out of the completion into ffs_dmabuf_cleanup(), the existing work handler scheduled by ffs_dmabuf_signal_done() on ffs->io_completion_wq. Clear priv->req there under eps_lock before freeing, and only clear if priv->req still names our request (a subsequent ffs_dmabuf_transfer() on the same attachment may have queued a new one). This keeps the existing dummy_hcd sync-dequeue invariant:
    the completion callback is still invoked by the UDC without eps_lock held (dummy_hcd drops its own lock before calling the callback), and the callback now takes no f_fs lock at all. Serialization against the cancel path happens in cleanup, which runs from the workqueue with no f_fs lock held on entry. The priv ref count protects the containing ffs_dmabuf_priv: ffs_dmabuf_transfer() takes a ref via ffs_dmabuf_get(), cleanup drops it via ffs_dmabuf_put(), so priv stays live for the cleanup even after the cancel path's list_del + ffs_dmabuf_put. The ffs_dmabuf_transfer() error path no longer frees usb_req inline: fence->req and fence->ep are set before usb_ep_queue(), so ffs_dmabuf_cleanup() (scheduled by the error-path ffs_dmabuf_signal_done()) owns the free regardless of whether the queue succeeded. Reproduced under KASAN on both detach and close paths against dummy_hcd with an observability hook (kasan_check_byte(priv->req) immediately before usb_ep_dequeue) at the two FunctionFS cancel sites to surface the stale-pointer access;
    the hook is not part of this patch. The KASAN allocator / free stacks in the captured splats identify the same request: alloc in dummy_alloc_request, free in dummy_timer, fault reached from ffs_epfile_release (close) and from the FUNCTIONFS_DMABUF_DETACH ioctl (detach). With the patch applied, both paths are silent under the same hook. The bug is reached from the FunctionFS device node, which in real deployments is owned by the privileged gadget daemon (adbd, UMS, composite gadget services, etc.); it is not reachable from unprivileged userspace or from a USB host on the cable. FunctionFS mounts default to GLOBAL_ROOT_UID, but the filesystem supports uid=, gid=, and fmode= delegation to a non-root gadget daemon, so on real deployments the attacker may be a less-privileged service rather than root. (CVE-2026-63894)

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

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

  - 已修复 Linux 内核中的下列漏洞：hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR adm1266_gpio_get_multiple() iterates the PDIO portion of the caller-supplied mask using for_each_set_bit_from(gpio_nr, mask, ADM1266_GPIO_NR + ADM1266_PDIO_STATUS) { ... } where ADM1266_PDIO_STATUS is the PMBus command code (0xE9, i.e. 233), not the number of PDIO pins. The intended upper bound is ADM1266_GPIO_NR + ADM1266_PDIO_NR = 25. gpiolib hands in a mask sized for gc.ngpio (= 25 bits on this chip), so the iteration walks find_next_bit() up to 242, reading up to 217 extra bits (a handful of unsigned-long words: four on 64-bit, seven on 32-bit) of whatever lives past the end of the mask in the caller's stack. Any incidental set bit in that range then drives a set_bit(gpio_nr, bits) call that writes past the end of the caller-supplied bits array too -- both out-of-bounds. Substitute ADM1266_PDIO_NR for the constant so the scan stops at the last real PDIO bit. (CVE-2026-64084)

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

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

  - serial：zs： 转换为使用平台设备 防止在初始化第一个串行端口时发生崩溃： 控制台：切换到 mono 帧缓冲器设备 160x64 fb0： tc0 上的 PMAG-AA 帧缓冲器设备 DECstation Z85C30 串口驱动程序版本 0.10 CPU 0 无法处理虚拟地址 0000002c， epc == 803ab00c， ra == 803aafe0 上的内核分页请求 哎呀[#1]： CPU：0 PID：1 通信：swapper 未受感染 6.4.0-rc3-00031-g84a9582fd203-dirty #57 $ 0 ： 00000000 10012c00 803aaeb0 00000000 $ 4 ： 80e12f60 80e12f50 80e12f58 81000030 $ 8 ： 00000000 805ff37c 000000000 33433538 $12 ： 65732030 00000006 80c2915d 6c616972 $16 ： 80 e12f00 807b7630 000000000 000000000 $20 ： 00000004 00000348 000001a0 807623b8 $24 ： 00000018 00000000 $28 ： 80c24000 80c25d60 8078b148 803aafe0 Hi ： 000000000 Lo ： 00000000 EPC ： 803ab00c serial_base_ctrl_add+0x78/0xf4 RA ： 803aafe0 serial_base_ctrl_add+0x4c/0xf4 状态：10012c03 内核 EXL IE 原因：00000008 （ExcCode 02） BadVA：0000002c PrId：00000440 （R4400SC） 模块链接于： 进程交换器 （pid： 1， threadinfo=（ptrval）， task=（ptrval）， tls=00000000） 堆栈：80760000 00000cc0 00400044 00400040 803aa02c 80d61ab8 00000000 807b7630 8 0760000 807623b8 807b7628 803aa644 80386998 00000000 80e17780 80220f68 80e17780 80d61ab8 80c17d80 80e17780 80e17780 8063c798 80e17780 80383fa0 00000010 80e17780 00000000 80386998 807a000000000000 00400040 8038f848 807623b8 80d61ab8 00000004 80e17780 00000000 803a68e4 80c25e2c 803bb884 ... 调用跟踪： [<803ab00c>] serial_base_ctrl_add+0x78/0xf4 [<803aa644>] serial_core_register_port+0x174/0x69c [<8077e9ac>] zs_init+0xc8/0xfc [<800404d4>] do_one_initcall+0x40/0x2ac [<8076cecc>] kernel_init_freeable+0x1e4/0x270 [<80605bec>] kernel_init+0x20/0x108 [<800431e8>] ret_from_kernel_thread+0x14/0x1c 代码： 2442aeb0 ae120024 ae0200d0 <8c67002c> 50e00001 8c670000 3c06806e 3c05806e afb30010 ---[ end trace 0000000000000000 ]---（在有问题的提交处报告） -- 取消引用源自 null 的指针指向端口父设备的指针。由于没有设备支持旧版探测，并且它不再是发现设备的首选方式，因此请将驱动程序切换为使用平台设备并将其用作端口的父设备。相应地更新资源处理，并且仅请求在插槽内使用的实际地址跨度，通用平台设备代码已经请求其资源。使用 platform_driver_probe（） 不仅因为 SCC 设备是用焊料固定的并且不容易拆卸，而且最重要的是因为相关的 TTY 的主要设备编号与 dz 驱动程序使用的相同，并且第一个声明它的驱动程序将阻止另一个驱动程序使用它。给定系统中将存在一个 DZ 设备或某些 SCC 设备，但绝不会同时存在两个设备，因此我们希望第一个驱动程序声明的主要设备号才能实际成功绑定到其设备，而 platform_driver_probe（） 是实现这一点的一种方式。切换到平台设备的一个不幸后果是，我们现在在启动程序中很久以后才将控制台从 bootconsole 移交。固件控制台处理程序看起来足够好，但可以工作到这么晚，尤其是在启用中断的情况下。由于现在只剩下一种方法可到达 zs_reset（），因此在不再需要时删除端口初始化标记，并且无条件完成通道重置。
    (CVE-2026-63876)

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

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

  - 已修复 Linux 内核中的下列漏洞：igc: fix potential skb leak in igc_fpe_xmit_smd_frame() When igc_fpe_init_tx_descriptor() fails, no one takes care of an allocated skb, leaking it. [1] Use dev_kfree_skb_any() on failure. Tested on an I226 adapter with the following command, while injecting faults in igc_fpe_init_tx_descriptor() to trigger the error path. # ethtool --set-mm $DEV verify-enabled on tx-enabled on pmac-enabled on [1] unreferenced object 0xffff888113c6cdc0 (size 224): ...
    backtrace (crc be3d3fda): kmem_cache_alloc_node_noprof+0x3b1/0x410 __alloc_skb+0xde/0x830 igc_fpe_xmit_smd_frame.isra.0+0xad/0x1b0 igc_fpe_send_mpacket+0x37/0x90 ethtool_mmsv_verify_timer+0x15e/0x300 (CVE-2026-64110)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/amdgpu/jpeg: set no_user_fence for JPEG v5.0.0 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 0f43893d3cd478fa57836697525b338817c9c23d) (CVE-2026-63842)

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

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

  - wifi：rtw88：usb：修复 USB 写入失败时的内存泄漏 当 rtw_usb_write_port（） 无法提交 USB 请求块 （URB）（例如，由于设备断开连接或 ENOMEM）时，从不执行完成回调。
    目前，驱动程序忽略 rtw_usb_write_data（） 和 rtw_usb_tx_agg_skb（） 中 rtw_usb_write_port（） 的返回值。由于这些函数依赖于完成回调来释放套接字缓冲区 （skb） 和事务控制块 （txcb），因此提交失败会导致：1. rtw_usb_write_data（） 中分配的 skb 的内存泄漏。2. rtw_usb_tx_agg_skb（） 中 txcb 结构和所有聚合 skb 的内存泄漏。通过检查 rtw_usb_write_port（） 的返回值修复此问题。如果失败，请在 rtw_usb_write_data（） 中显式释放 skb，然后正确清除 tx_ack_queue 并在 rtw_usb_tx_agg_skb（） 中释放 txcb。在设备断开/重新连接的实际情况以及内存压力条件下发现此问题。通过验证修复后正常的 TX 操作继续进行且无回归来进行测试。（CVE-2026-63821）

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

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

  - scsi：target：iscsi：绑定的 iscsi_encode_text_output（） 附加到 rsp_buf iscsi_encode_text_output（） 将 \0 记录串联 key=value到 login->rsp_buf，即在 iscsit_alloc_login_setup_buffer（） 中分配的 8192 字节 kzalloc（MAX_KEY_VALUE_PAIRS） 缓冲区）。此函数中的三个 sprintf（） 调用站点（v7.1-rc2 中的第 1398、1411、1424 行）从不检查剩余的缓冲区容量：*length += sprintf（output_buf， %s=%s， er->key， er->value）;*长度 += 1;output_buf = textbuf + *length;iscsi_target_check_login_request（） 处的 8192 字节上限限制了 *input* 登录 PDU 负载，但单个 PDU 最多可承载 2048 个最小四字节 a=b\0 对，每个未知密钥通过 iscsi_add_notunderstood_response（） 扩展为 16 字节 a=NotUnderstandod\0 输出记录。2048 * 16 = 32 KiB 的输出进入 8 KiB 缓冲区，从而在 kmalloc-8k slab 中产生 ~24 KiB 堆溢出。该补丁引入静态 iscsi_encode_text_record（） 帮助程序，该帮助程序使用 snprintf（） 对剩余缓冲区进行每次调用的边界检查，并通过 iscsi_encode_text_output（） 线程处理 u32 textbuf_size参数。iscsi_target_handle_csg_zero（） （PHASE_SECURITY） 和 iscsi_target_handle_csg_one（） （PHASE_OPERATIONAL） 中的调用站点都传递MAX_KEY_VALUE_PAIRS。溢出时，编码器记录条件，调用 iscsi_release_extra_responses（） 以删除排队的记录，并返回 -1;两个调用站点现在都会在返回前通过 iscsit_tx_login_rsp（） 发出ISCSI_STATUS_CLS_INITIATOR_ERR/ISCSI_LOGIN_STATUS_INIT_ERR，因此发起程序会看到明确的登录失败响应，而不是静默的连接中断。（在此修补程序之前，仅PHASE_OPERATIONAL调用程序执行此操作;PHASE_SECURITY调用程序已转换为相同的形状。）（CVE-2026-63887）

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

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

  - 已修复 Linux 内核中的下列漏洞：fprobe: Fix unregister_fprobe() to wait for RCU grace period Commit 4346ba1604093 (fprobe: Rewrite fprobe on function-graph tracer) changed fprobe to register struct fprobe to an rcu-hlist, but it forgot to wait for RCU GP. Thus there can be use-after-free if the fprobe is released right after unregistering. This can be happened on fprobe event and sample module code. To fix this issue, add synchronize_rcu() in unregister_fprobe(). Note that BPF is OK because fprobe is used as a part of bpf_kprobe_multi_link. This unregisters its fprobe in bpf_kprobe_multi_link_release() and it is deallocated via bpf_kprobe_multi_link_dealloc(), which is invoked from bpf_link_defer_dealloc_rcu_gp() RCU callback. For BPF, this also introduced unregister_fprobe_async() which does NOT wait for RCU grace priod. (CVE-2026-64075)

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

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

  - net/smc：不重新初始化 smc 哈希表 INIT_HLIST_HEAD（&smc_v*_hashinfo.ht） 在 smc_nl_init）、proto_register（） 和 sock_register（） 之后调用。这可导致即使哈希条目已存在且正在使用 smc_v*_hashinfo.ht 仍会被重置，从而可能导致列表损坏。删除 smc_init（） 中 smc_v*_hashinfo.ht 不必要且危险的重新初始化;无论如何，它会隐式初始化为零。为定义添加HLIST_HEAD_INIT以便理解。（CVE-2026-64005）

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

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

  - 已修复 Linux 内核中的下列漏洞：tracing: Avoid NULL return from hist_field_name() on truncation hist_field_name() returns everywhere except the fully-qualified VAR_REF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL-> guard.
    Callers don't expect NULL: strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758 and the strcmp() in the sort-key match loop at :4804 both deref it. system and event_name are bounded by MAX_EVENT_NAME_LEN, but the field name on a VAR_REF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path. Keep the length check but leave field_name as on overflow. (CVE-2026-64028)

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

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

  - 在 enquirer 中 2.4.1发现一个安全缺陷，直至 。影响的是 Public Package API 组件的 Enquirer.set 函数。参数 question.name 的操纵会导致对对象原型属性的修改受到不当控制。攻击者可远程执行攻击。该漏洞已被公开并可被用于攻击。该项目很早就通过问题报告获悉了该问题。（CVE-2026-15187）

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

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

  - 已修复 Linux 内核中的下列漏洞：iio: chemical: mhz19b: reject oversized serial replies mhz19b_receive_buf() appends each serdev chunk into the fixed MHZ19B_CMD_SIZE receive buffer and advances buf_idx by len without checking that the chunk fits in the remaining space. A large callback can therefore overflow st->buf before the command path validates the reply. Reset the reply state before each command and reject oversized serial replies before copying them into the fixed buffer.
    When an oversized reply is detected, wake the waiter and report -EMSGSIZE instead of overwriting st->buf.
    (CVE-2026-63932)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/msm/snapshot: fix dumping of the unaligned regions The snapshotting code internally aligns data segment to 16 bytes. This works fine for DPU code (where most of the regions are aligned), but fails for snapshotting of the DSI data (because DSI data region is shifted by 4 bytes). Fix the code by removing length alignment and by accurately printing last registers in the region. While reworking the code also fix the 16x memory overallocation in msm_disp_state_dump_regs(). Patchwork: https://patchwork.freedesktop.org/patch/725449/ (CVE-2026-64039)

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

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

  - 已修复 Linux 内核中的下列漏洞：f2fs: fix missing read bio submission on large folio error f2fs_read_data_large_folio() can keep a read bio across multiple readahead folios. If a later folio hits an error before any of its blocks are added to the bio, folio_in_bio is false and the current error path returns immediately after ending that folio. This can leave the bio accumulated for earlier folios unsubmitted. Those folios then never receive read completion, and readers can wait indefinitely on the locked folios. Route errors through the common out path so any pending bio is submitted before returning. Stop consuming more readahead folios once an error is seen, and only wait on and clear the current folio when it was actually added to the bio. (CVE-2026-63820)

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

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

  - 已修复 Linux 内核中的下列漏洞：mm/migrate_device: fix spinlock leak in migrate_vma_insert_huge_pmd_page When check_stable_address_space() fails after the PMD spinlock has been acquired via pmd_lock(), the code jumps directly to the abort label, bypassing the spin_unlock() call in unlock_abort. This causes the PMD spinlock to be permanently held, leading to a deadlock. Change the goto target from abort to unlock_abort to ensure the spinlock is always released on this error path.
    (CVE-2026-64129)

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

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

  - 已修复 Linux 内核中的下列漏洞：igc: set tx buffer type for SMD frames Sashiko pointed out that igc_fpe_init_smd_frame() initializes igc_tx_buffer fields for an SMD skb, but does not set the buffer type: https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jpSince igc_tx_buffer entries are reused, a stale XDP or XSK type can remain and make TX completion use the wrong cleanup path. Set the buffer type to IGC_TX_BUFFER_TYPE_SKB. (CVE-2026-64035)

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

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

  - ipv6：通过计算 put_cmsg（） 长度时信任在线上的 hdrlen 字节 （ptr[1]），复制到 cmsg ip6_datagram_recv_specific_ctl（） 版本 IPV6_cmsg（及其IPV6_2292* 旧版），验证扩展标头长度。仅在解析时验证长度（ipv6_parse_hopopts（） 等）。nftables 负载写入表达式可在解析之后和 skb 到达 recvmsg 之前重写 hdrlen;写入本身为界内，但 put_cmsg（） 随后会从 8 字节标头读取多达 （（HDRLEN+1） << 3） = 2040 字节。可从非特权用户命名空间访问 nftables，因此这是非特权 slab-out-of-bound 读取： 缺陷：KASAN：put_cmsg+0x3ac/0x540 put_cmsg+0x3ac/0x540 udpv6_recvmsg+0xca0/0x1250 sock_recvmsg+0xdf/0x190 ____sys_recvmsg+0x1b1/0x620 中的 slab-out-of-bound 添加 ipv6_get_exthdr_len（），用于在读取 hdrlen 字段之前验证至少两个字节是否可访问， 然后根据 skb_tail_pointer（skb） 检查计算的长度，失败时返回 0。输入时，扩展标头通过 pskb_may_pull（） 保留在线性 skb 区域中，因此 skb_tail_pointer（） 为正确的边界。在所有非 AH 调用站点使用 ipv6_get_exthdr_len（）：五个独立的 cmsg 块（HbH、2292HbH、2292DSTOPTS x2、2292RTHDR）和扩展标头遍历循环中的三种标准情况（DSTOPTS、ROUTING、默认）。AH 保留了内联边界检查，因为其长度公式不同 （（ptr[1]+2）<<2）。walk 循环还会在顶部进行预读取边界检查，以在任何情况下访问 ptr[0] 或 ptr[1] 之前验证 ptr。当 walk 循环检测到损坏的标头时，请从函数返回，而不是继续处理之后的套接字选项。（CVE-2026-63920）

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

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

  - ksmbd：修复 smb_check_perm_dacl（） 中的越界读取 smb_check_perm_dacl（） 中的权限检查 ACE walk 验证 ACE 标头大小并在 SID_MAX_SUB_AUTHORITIES 处sid.num_subauth，但从未在 compare_sids（） 取消引用 ace->size 之前检查 ace-size 是否实际大到足以包含num_subauth子颁发机构。CIFS_SID_BASE_SIZE涵盖数组之前但不包括 sub_auth[] 数组的 SID 标头，而 offsetof（struct smb_ace， sid） 为 ACE 标头，因此现有防护仅保证 8 字节 SID 基础，即零子颁发机构。 然后，compare_sids（） 会读取 i 的 ace->sid.sub_auth[i] < min（local_sid->num_subauth， ace->sid.num_subauth）。本地比较 SID（sid_everyone、sid_unix_NFS_mode 和 id_to_sid（） 结果）始终至少有一个子颁发机构，攻击者可控制 ACE 修订和颁发机构字节（位于界内 SID 库内），因此可以匹配其中一个 SID 并强制进行sub_auth读取。因此，大小 == 16 和 num_subauth >= 1 的特制 ACE 位于安全描述符的末尾，会造成最多超过 pntsd 分配的 SID_MAX_SUB_AUTHORITIES * sizeof（__le32） 字节发生堆越界读取。安全描述符由 ksmbd_vfs_get_sd_xattr（） 加载到与磁盘上数据大小完全匹配的缓冲区（ndr_decode_v4_ntacl（） 中的 kzalloc（sd_size）），因此读取超出分配。畸形描述符可通过 SMB2_SET_INFO 逐字存储（DACL 在写入安全性之前未标准化。NTACL xattr），并且在后续SMB2_CREATE访问检查中触发读取，从而使得使用 ACL xattrs 的共享上的经认证的客户端可以访问此内容。添加缺少的 num_subauth-versus-ace_size 检查，以反映同级解析器 parse_dacl（） 和 smb_inherit_dacl（） 中已存在的相同防护。
    (CVE-2026-53390)

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

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

  - 已修复 Linux 内核中的下列漏洞：hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer adm1266_pmbus_block_xfer() copies the device-supplied block payload into the caller-provided buffer using the device-supplied length: memcpy(data_r, &msgs[1].buf[1], msgs[1].buf[0]); The helper does not know how large data_r is and trusts the device to return at most one record's worth of bytes. adm1266_nvmem_read_blackbox() violates that contract: it advances read_buff inside data->dev_mem in ADM1266_BLACKBOX_SIZE (64-byte) strides while the helper is willing to write up to ADM1266_PMBUS_BLOCK_MAX (255) bytes. A device that returns more than 64 bytes on the trailing record (read_buff offset 1984 in the 2048-byte dev_mem allocation) overflows dev_mem by up to 191 bytes before the post-call if (ret != ADM1266_BLACKBOX_SIZE) return -EIO; can reject the response. Contain the fix in the caller without changing the helper signature: read each record into a 255-byte local bounce buffer that matches the helper's maximum output, validate the returned length, and only then copy exactly ADM1266_BLACKBOX_SIZE bytes into the dev_mem slot. (CVE-2026-64085)

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

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

  - 已修复 Linux 内核中的下列漏洞：l2tp: use refcount_inc_not_zero in l2tp_session_get_by_ifname A reader in l2tp_session_get_by_ifname() can return a pointer to a session whose refcount has reached zero. The getter takes its reference with plain refcount_inc(), but every other session getter in the same file (l2tp_v2_session_get, l2tp_v3_session_get, and the corresponding _get_next variants) uses refcount_inc_not_zero() because the IDR/RCU lookup can race with refcount_dec_and_test() -> l2tp_session_free() -> kfree_rcu(). The ifname getter is the only outlier; the inconsistency was raised on-list after 979c017803c4 (l2tp: use list_del_rcu in l2tp_session_unhash). A reader inside rcu_read_lock_bh() that matches session->ifname can be preempted between the strcmp() and the refcount_inc(). If the last reference drops on another CPU in that window, the reader's refcount_inc() runs on a counter that has reached zero. refcount_t catches the addition-on-zero, prints refcount_t:
    addition on 0; use-after-free, saturates the counter, and returns the saturated pointer to the caller.
    Session memory is held live by the in-flight RCU read section, but the kfree_rcu() callback queued from l2tp_session_free() will free it once the grace period closes; a caller that dereferences the returned session past that point hits a slab-use-after-free. On PREEMPT_RT local_bh_disable() is a per-CPU sleeping lock and the preemption window is real; on stock PREEMPT kernels local_bh_disable() is a preempt_count increment that closes the cross-CPU race in practice (see below). Use refcount_inc_not_zero() and continue the list walk on failure, matching the other session getters in the file. The ifname getter is the only session getter in net/l2tp/ that still uses the bare refcount_inc() pattern; this change restores file-internal consistency. The success path is unchanged. (CVE-2026-63918)

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

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

  - nfc：llcp：修复 llcp_sock_release（） 中的释放后使用 llcp_sock_release（） 会无条件断开套接字与本地套接字列表的链接。但是，如果套接字仍处于连接状态，则它位于连接列表中。通过检查套接字状态并从正确列表中断开链接修复此问题。
    (CVE-2026-64011)

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

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

  - 已修复 Linux 内核中的下列漏洞：selinux: fix avdcache auditing The per-task avdcache was incorrectly saving and reusing the audited vector computed by avc_audit_required() rather than recomputing based on the currently requested permissions and distinguishing the denied versus allowed cases. As a result, some permission checks were not being audited, e.g. directory write checks after a previously cached directory search check. [PM: line wrap tweaks] (CVE-2026-53367)

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

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

  - tracing：如果 elt_alloc（） 失败，不调用 map->ops->elt_free（） 在 tracing_map_elt_alloc（） 无法分配对象的路径中，map->ops->elt_alloc（） 调用从未成功。在这种情况下，不应调用 map->ops->elt_free（）。（CVE-2026-64173）

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

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

  - net： ethernet： cortina： 使 RX SKB 按端口进行 SKB 用于从 gmac_rx（） 中的片段中组装数据包的 SKB 是静态的本地，但 Gemini 有两个以太网端口，这意味着如果设备同时使用这两个端口，则在糟糕的日子里这些端口之间可能存在争用。使 RX SKB 成为每个端口的变量，并在端口结构中的调用之间保留它。在调用 napi_gro_frags（） 时）、出错时（调用 napi_free_frags（） 后）或端口停止时，将指针归零。在某个不是绝对必要的地方将其归零，只是为了强调正在发生的事情。这是 Sashiko 在正常修补程序审查期间发现的。（CVE-2026-64056）

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

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

  - 已修复 Linux 内核中的下列漏洞：bridge: Fix sleep in atomic context in sysfs path Since the start of the git history, brport_store() always acquired the bridge lock. 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 was only used by two STP related attributes (cost and priority). Nowadays, brport_store() 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: Only requires 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 two STP related attributes that require it. Remove the now stale comment from br_switchdev_set_port_flag(). The SWITCHDEV_F_DEFER flag can be removed in net-next. [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: 372, name: bash preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 5 locks held by bash/372: #0: ffff88810c51c3f0 (sb_writers#7){.+.+}-{0:0}, at: ksys_write (fs/read_write.c:740) #1: ffff888115ce9480 (&of->mutex){+.+.}-{4:4}, at: kernfs_fop_write_iter (fs/kernfs/file.c:343) #2: ffff88810b9fd330 (kn->active#37){.+.+}-{0:0}, at: kernfs_fop_write_iter (fs/kernfs/file.c:80 fs/kernfs/file.c:344) #3: ffffffffa59473a0 (rtnl_mutex){+.+.}-{4:4}, at: brport_store (net/bridge/br_sysfs_if.c:326) #4: ffff8881099d2d58 (&br->lock){+...}-{3:3}, at: brport_store (./include/linux/spinlock.h:348 net/bridge/br_sysfs_if.c:345) 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) store_learning (net/bridge/br_sysfs_if.c:79 net/bridge/br_sysfs_if.c:235) brport_store (net/bridge/br_sysfs_if.c:346) kernfs_fop_write_iter (fs/kernfs/file.c:352) new_sync_write (fs/read_write.c:595) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) 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-63988)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/msm/adreno: fix userspace-triggered crash on a2xx-a4xx Before a5xx Adreno driver will not try fetching UBWC params (because those generations didn't support UBWC anyway), however it's still possible to query UBWC-related params from the userspace, triggering possible NULL pointer dereference. Check for UBWC config in adreno_get_param() and return sane defaults if there is none. Patchwork: https://patchwork.freedesktop.org/patch/717778/(CVE-2026-64049)

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

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

  - 已修复 Linux 内核中的下列漏洞：ALSA: pcm: Don't setup bogus iov_iter for silencing At transition to the iov_iter for PCM data transfer, we blindly applied the iov_iter setup also for silencing (i.e. data = NULL), and it leads to a calculation of bogus iov_iter. Fortunately this didn't cause troubles on most of architectures but it goes wrong on RISC-V now, causing a NULL dereference. Handle the NULL data case to treat the silencing in interleaved_copy() for addressing the bug above. noninterleaved_copy() has already the NULL data handling, so it doesn't need changes.
    (CVE-2026-64134)

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

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

  - 已修复 Linux 内核中的下列漏洞：netfs: Fix netfs_invalidate_folio() to clear dirty bit if all changes gone If a streaming write is made, this will leave the relevant modified folio in a not-uptodate, but dirty state with a netfs_folio struct hung off of folio->private indicating the dirty range. Subsequently truncating the file such that the dirty data in the folio is removed, but the first part of the folio theoretically remains will cause the netfs_folio struct to be discarded... but will leave the dirty flag set. If the folio is then read via mmap(), netfs_read_folio() will see that the page is dirty and jump to netfs_read_gaps() to fill in the missing bits. netfs_read_gaps(), however, expects there to be a netfs_folio struct present and can oops because truncate removed it. Fix this by calling folio_cancel_dirty() in netfs_invalidate_folio() in the event that all the dirty data in the folio is erased (as nfs does). Also add some tracepoints to log modifications to a dirty page. This can be reproduced with something like: dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1 umount /xfstest.test mount /xfstest.test xfs_io -c w 0xbbbf 0xf96c \ -c truncate 0xbbbf \ -c mmap -r 0xb000 0x11000 \ -c mr 0xb000 0x11000 \ /xfstest.test/foo with fscaching disabled (otherwise streaming writes are suppressed) and a change to netfs_perform_write() to disallow streaming writes if the fd is open O_RDWR:
    if (//(file->f_mode & FMODE_READ) || <--- comment this out netfs_is_cache_enabled(ctx)) { It should be reproducible even without this change, but if prevents the above trivial xfs_io command from reproducing it. Note that the initial dd is important: the file must start out sufficiently large that the zero-point logic doesn't just clear the gaps because it knows there's nothing in the file to read yet. Unmounting and mounting is needed to clear the pagecache (there are other ways to do that that may also work). This was initially reproduced with the generic/522 xfstest on some patches that remove the FMODE_READ restriction.
    (CVE-2026-64064)

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

ID	名称	严重性
328225	Linux Distros 未修补的漏洞：CVE-2026-64185	medium
328224	Linux Distros 未修补的漏洞：CVE-2026-63978	critical
328223	Linux Distros 未修补的漏洞：CVE-2026-63909	high
328222	Linux Distros 未修补的漏洞：CVE-2026-63951	high
328221	Linux Distros 未修补的漏洞：CVE-2026-63850	high
328220	Linux Distros 未修补的漏洞：CVE-2026-64164	medium
328219	Linux Distros 未修补的漏洞：CVE-2026-63995	high
328218	Linux Distros 未修补的漏洞：CVE-2026-63980	high
328217	Linux Distros 未修补的漏洞：CVE-2026-63926	high
328216	Linux Distros 未修补的漏洞：CVE-2026-64155	medium
328215	Linux Distros 未修补的漏洞：CVE-2026-63863	high
328214	Linux Distros 未修补的漏洞：CVE-2026-63884	high
328213	Linux Distros 未修补的漏洞：CVE-2026-64037	critical
328212	Linux Distros 未修补的漏洞：CVE-2026-63939	critical
328211	Linux Distros 未修补的漏洞：CVE-2026-63969	medium
328210	Linux Distros 未修补的漏洞：CVE-2026-63945	high
328209	Linux Distros 未修补的漏洞：CVE-2026-53389	high
328208	Linux Distros 未修补的漏洞：CVE-2026-63795	critical
328207	Linux Distros 未修补的漏洞：CVE-2026-64175	high
328206	Linux Distros 未修补的漏洞：CVE-2026-44359	critical
328205	Linux Distros 未修补的漏洞：CVE-2026-63981	medium
328204	Linux Distros 未修补的漏洞：CVE-2026-63994	critical
328203	Linux Distros 未修补的漏洞：CVE-2026-63894	high
328202	Linux Distros 未修补的漏洞：CVE-2026-64084	high
328201	Linux Distros 未修补的漏洞：CVE-2026-63876	medium
328200	Linux Distros 未修补的漏洞：CVE-2026-64110	medium
328199	Linux Distros 未修补的漏洞：CVE-2026-63842	high
328198	Linux Distros 未修补的漏洞：CVE-2026-63821	medium
328197	Linux Distros 未修补的漏洞：CVE-2026-63887	critical
328196	Linux Distros 未修补的漏洞：CVE-2026-64075	high
328195	Linux Distros 未修补的漏洞：CVE-2026-64005	high
328194	Linux Distros 未修补的漏洞：CVE-2026-64028	medium
328193	Linux Distros 未修补的漏洞：CVE-2026-15187	medium
328191	Linux Distros 未修补的漏洞：CVE-2026-63932	high
328190	Linux Distros 未修补的漏洞：CVE-2026-64039	high
328189	Linux Distros 未修补的漏洞：CVE-2026-63820	low
328188	Linux Distros 未修补的漏洞：CVE-2026-64129	medium
328187	Linux Distros 未修补的漏洞：CVE-2026-64035	critical
328186	Linux Distros 未修补的漏洞：CVE-2026-63920	high
328185	Linux Distros 未修补的漏洞：CVE-2026-53390	high
328184	Linux Distros 未修补的漏洞：CVE-2026-64085	high
328183	Linux Distros 未修补的漏洞：CVE-2026-63918	high
328182	Linux Distros 未修补的漏洞：CVE-2026-64011	high
328181	Linux Distros 未修补的漏洞：CVE-2026-53367	medium
328180	Linux Distros 未修补的漏洞：CVE-2026-64173	medium
328179	Linux Distros 未修补的漏洞：CVE-2026-64056	critical
328178	Linux Distros 未修补的漏洞：CVE-2026-63988	high
328177	Linux Distros 未修补的漏洞：CVE-2026-64049	medium
328176	Linux Distros 未修补的漏洞：CVE-2026-64134	high
328175	Linux Distros 未修补的漏洞：CVE-2026-64064	medium

检测

Nessus 的 Misc. 系列

medium

critical

high

high

high

medium

high

high

high

medium

high

high

critical

critical

medium

high

high

critical

high

critical

medium

critical

high

high

medium

medium

high

medium

critical

high

high

medium

medium

high

high

low

medium

critical

high

high

high

high

high

medium

medium

critical

high

medium

high

medium