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

  - KVM：SEV：忽略长度为“0”的端口 I/O 请求 明确忽略长度为“0”（或计数“0”）的端口 I/O 请求，这样设置软件暂存区域（和其他代码）就不必担心长度下溢，并允许在尝试用 len==0 配置暂存区域时发出警告。
    (CVE-2026-63940)

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

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

  - batman-adv：tp_meter：修复接收器关机中的tp_vars引用泄漏 接收器关机定时器处理程序 batadv_tp_receiver_shutdown（） 负责释放它所保留的tp_vars引用。但是，此版本与 batadv_tp_stop_all（） 协调的现有逻辑是有缺陷的。timer_shutdown_sync（） 保证定时器返回后不会再次触发，但仅当定时器在调用时处于待定状态时才返回非零。如果定时器已过期（并且 batadv_tp_stop_all（） 会不成功地尝试重新武装自身），则 batadv_tp_stop_all（） 会跳过其 batadv_tp_vars_put（），并且 batadv_tp_receiver_shutdown（） 也无法放置自己的引用。通过引入接收方设置为 1 的新原子变量修复此问题，在接收方初始化并由先声明它的一方使用 atomic_xchg（） 以原子方式清除接收方时设置为 1。只有观察到 1 到 0 转换的一方负责释放tp_vars定时器参考，从而消除不确定性。（CVE-2026-64092）

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

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

  - net/sched：修复 duplicate on 时 netem 上的数据包循环 netem 复制数据包时，它会将副本重新排入根 qdisc 的队列。如果树中存在另一个 netem，则可重复复制副本，直到耗尽堆栈或内存为止。原始复制防护在重新排队时临时将 q->duplicate 清零，但这并未涵盖所有情况，因为它是跨所有并发排队路径共享的 per-qdisc 状态，如果不额外锁定则不安全。使用较早修补程序中引入的 skb tc_depth字段：- 重新排队前在重复项上递增该值 - 跳过tc_depth已为非零的任何 skb 的重复。这会标记数据包本身，而不是改变 qdisc 状态，因此无论树拓扑或并发如何，它都是安全的。（CVE-2026-63983）

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

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

  - netfs：修复 i_size > remote_i_size 的零点更新 当页面缓存中除发布的作品集之外还有未提交的数据，但服务器上的 EOF（）在此作品集中（即 i_size > remote_i_size）时，修复 netfs_release_folio（） 对零点[*] 的更新。该更新需要将zero_point限制为remote_i_size而不是i_size，因为i_size是一种本地现象，反映了对 pagecache 本地进行的更新，而不是写入服务器的内容。remote_i_size跟踪服务器的i_size。[*]零点是文件位置，我们可以从该位置假设服务器只会返回零，因此我们可以避免生成读取。请注意，netfs_invalidate_folio（） 可能不需要修复，因为应在截断或 fallocate 之后由 setattr 更新zero_point。发现于：fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops，使用以下作为 junk.fsxops：截断0x0 0x1bbae 0x82864写0x3ef2e 0xf9c8 0x1bbae写0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copy_range 0x5d3d 0x10329 0x54fac 0x7495f使用默认缓存选项在 CIFS 上0x64710 0x1c2b 0x7495f写入 mapread 0x64000 0x1000 0x7495f。如果 FMODE_READ 检查在 netfs_perform_write（） 中注释掉，则显示 folio 0x64 中的读取间隙因短读取而失败（即命中 EOF）：if （//（file->f_mode &; FMODE_READ） || netfs_is_cache_enabled（ctx）） { 且无 fscache。这最初是在 generic/522 xfstest 中发现的。（CVE-2026-64159）

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

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

  - KVM：arm64：vgic-its：拒绝以超出范围还原的 DTE num_eventid_bits 用户空间可还原 ITS 设备表条目，其 Size 字段编码的 EventID 位比虚拟 ITS 支持的位数还多。实时 MAPD 路径拒绝该状态，但 vgic_its_restore_dte（） 接受该状态并将超出范围的值存储在 dev->num_eventid_bits 中。分配设备之前拒绝已还原的 num_eventid_bits > VITS_TYPER_IDBITS DTE。这反映了 MAPD 检查，并防止还原的状态达到 vgic_its_restore_itt（），其中未经检查的值可转换为超大的 scan_its_table（） 范围。（CVE-2026-64106）

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

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

  - drm/msm/adreno：修复 a6xx_gpu_init（） 中的引用泄漏 在 a6xx_gpu_init（） 中，节点通过 of_parse_phandle（） 获取。虽然在通用路径的末尾存在手动 of_node_put（），但多个早期的错误返回会绕过此调用，从而导致引用泄漏。通过使用
    __free（device_node） 清除处理程序以在变量超出范围时释放引用。
    拼布： https://patchwork.freedesktop.org/patch/700661/ （CVE-2026-64154）

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

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

  - erofs：修复 inode xattr 初始化提交 bb88e8da0025 中的 metabuf 泄漏（erofs：将元缓冲区用于 xattr 操作） 已将 xattr 操作转换为使用堆栈上的 erofs_buf 实例。
    erofs_init_inode_xattrs（） 在读取内联 xattr 标头和共享 xattr id 数组时使用此类 metabuf。erofs_read_metabuf（） 之后的某些错误路径会在未丢弃 metabuf 的情况下通过out_unlock，因此 folio 引用可能泄漏。在 out_unlock 处合并清理。如果未取得任何作品集，则 erofs_put_metabuf（） 会失败，且如此会保留采取EROFS_I_BL_XATTR_BIT之后的所有路径，由一个清理站点覆盖。（CVE-2026-64146）

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

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

  - netfilter：bridge：eb_tables：关闭模块 init 争用 sashiko 报告不相关的修补程序：ebtables.c 中的核心 ebtables 初始化是否受到类似争用的影响？nf_register_sockopt（） 完成后，sockopts 将全局暴露。sockopt 必须最后注册，就像在 ip/ip6/arptables 中一样。
    (CVE-2026-64076)

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

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

  - net/smc：拒绝与空 ism_dev 插槽相匹配的 CHID-0 ACCEPT 在 SMC-D 客户端上，ini->ism_dev[]/ini->ism_chid[] 的插槽 0 保留给 SMC-Dv1 设备。 smc_find_ism_v2_device_clnt（） 会填充从索引 1 开始的 V2 条目，因此如果未选择 V1 设备，插槽 0 会保留在其 kzalloc（） 的已启用状态，且为 ism_dev[0] == NULL 和 ism_chid[0] == 0。然后，smc_v2_determine_accepted_chid（） 会匹配对等机的单独使用 CHID 对从索引 0 开始的数组的 CHID。恶意对等机回复 smc-dv2-only 提案时 d1.chid == 0 匹配空插槽，ini->ism_selected 变为 0，随后在 offsetof（struct smcd_dev， lgr_lock） == 0000000000000068 0xe0 0x79_raw_spin_lock_bh 0x68 的 smc_conn_create（） 错误中出现 ism_dev[0]->lgr_lock取消引用 _raw_spin_lock_bh smc_conn_create （net/smc/smc_core.c：1997） __smc_connect （net/smc/af_smc.c：1447） smc_connect （net/smc/af_smc.c：1720）
    __sys_connect __x64_sys_connect do_syscall_64 接受 CHID 匹配之前要求 ism_dev[i] 必须为非 NULL。（CVE-2026-64048）

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

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

  - netfilter：x_tables：在互斥体 arp/ip（6）t_register_table（） 下分配挂钩 ops 通过 xt_register_table（） 将表添加到 per-netns 列表，然后再通过 kmemdup_array（） 分配 per-netns 挂钩 ops 副本。
    这会留下一个窗口，其中表在 ops=NULL 的列表中可见。如果 pernet 退出发生并发运行，pre_exit 回调将通过 xt_find_table（） 查找表并将空操作指针传递到 nf_unregister_net_hooks（），从而造成空取消引用： nf_unregister_net_hooks+0xbc/0x150 中的常规保护错误 RIP： nf_unregister_net_hooks （net/netfilter/core.c：613） 调用跟踪：
    ipt_unregister_table_pre_exit iptable_mangle_net_pre_exit ops_pre_exit_list cleanup_net 通过将 ops 分配移动到 xtables 核心进行修复，这样如果没有有效的 ops，则该表永远不会出现在列表中。还要确保该表在错误展开时拆散之前不再处理数据包。nf_register_net_hooks可能至少发布了一个钩子;如果出错，请调用 synchronize_rcu（）。审计日志注册消息会被延迟，直到所有操作都过去，这样就不会在错误展开时需要发出另一个 UREG 消息。基于 Tristan Madani 早期的修补程序。（CVE-2026-64079）

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

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

  - security/keys：修复查找时缺失的 RCU 读取部分 Nicholas Carlini 报告，keyring 代码会在不保持 RCU 读取锁定的情况下调用 find_key_to_update（） 中的 assoc_array_find（），而 assoc_array_gc（） 代码实际上设计为从树中删除节点，然后在 RCU 宽限期后将其释放。常规密钥处理无法看到此问题，因为保留 keyring 信号量会隐藏任何生命周期问题，但持久密钥处理会使用不同的模型。无需延长钥匙圈锁定，只需执行 assoc_array 设计的简单 RCU 锁定即可。（CVE-2026-64015）

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

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

  - net/handshake：将固定文件引用移交给 accept_doit handshake_req_next（） 会在 handshake_nl_accept_doit（） 读取 req->hr_sk->sk_socket 并取消引用 sock->file 之前（在 FD_PREPARE（） 中执行一次，在 get_file（） 中再次引用）之前删除 hn_lock。在该窗口中，先后运行 sockfd_put（） （svc_sock_free） 或 __fput_sync（） （xs_reset_transport） 的 tls_handshake_cancel（） 使用者会释放 sock->file。然后，sock_release（） 运行 sock_orphan（），将sk_socket清零，并释放 struct 套接字。接受端代码通过 sk_socket 读取 NULL 或追逐已释放的内存。
    提交端 sock_hold（） 不会阻止此情况。sk_refcnt保护 struct sock，但 struct 套接字和 sock->file 会通过用户拥有的文件描述符独立引用计数。固定 sk 会使 sock 和 sock->file 处于无保护状态。重新定位在提交时固定的 req->hr_file 的接受端取消引用，而非 req->hr_sk->sk_socket->file。仅靠固定是不够的：在 handshake_req_next（） 返回和到达 FD_PREPARE（） accept_doit之间取消的消费者会获取 handshake_req_cancel（） 中的 ！remove_pending（） 分支，并在接受端获取自己的引用之前删除hr_file。将 handshake_req_next（） 中 hn_lock 下的附加文件引用移交，以便接受端对任何并发 handshake_req_cancel（） 都无法撤消的引用进行操作。FD_PREPARE（） 通过将其转移到 fd_publish（） 中的新 fd 或出错时将其丢弃在清理析构函数中来消耗该移交引用;因此，之前平衡 FD_PREPARE（） 的显式 get_file（） 是多余的，并且消失了。更新 handshake_req_cancel_test2 和 _test3 以使用 fput（） 模拟 FD_PREPARE（） 消耗，这样 kunit 文件计数断言保持平衡。（CVE-2026-63979）

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

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

  - bpf、skmsg：修复判定sk_data_ready与 ktls rx 争用 sk_psock_strp_data_ready（） 已在存在 TLS RX 上下文时检查 tls_sw_has_ctx_rx（） 并推迟到 psock->saved_data_ready，从而避免与 TLS strparser 的接收队列所有权发生冲突（提交 e91de6afa81c，bpf：修复使用 ktls 运行的 sk_skb 程序类型）。sk_psock_verdict_data_ready（） 没有等效保护。在配置 TLS RX 之前将套接字插入 sockmap （BPF_SK_SKB_VERDICT） 时，tls_sw_strparser_arm（） 会将sk_psock_verdict_data_ready保存为 rx_ctx->saved_data_ready。数据到达时：tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready（） = sk_psock_verdict_data_ready（） -> tcp_read_skb（） 在不调用 tcp_eat_skb（） 的情况下通过 __skb_unlink（） 耗尽sk_receive_queue，因此copied_seq未提前处理。然后，tls_strp_msg_load（） 找到 tcp_inq（） >= full_len（过时），在现已为空的队列中调用 tcp_recv_skb（），命中 WARN_ON_ONCE（！first），然后返回指向 psock 拥有（可能已释放）skb 的 rx_ctx->strp.anchor.frag_list。tls_decrypt_sg（） 随后会frag_list释放后使用。
    应用与 sk_psock_strp_data_ready（） 相同的补丁：如果存在 TLS RX 上下文，则调用 psock->saved_data_ready （sock_def_readable） 以唤醒 recv（） 等待程序并立即返回，不影响接收队列。TLS 保留队列的唯一所有权并通过 tls_sw_recvmsg（） 正常解密记录。（CVE-2026-64025）

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

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

  - usb：typec：tcpm/tcpci_maxim：根据RX_BYTE_CNT验证标头 NDO 中断/恶意端口可传输 CRC 有效帧，其标头最多公告七个数据对象，但正文承载的数量少于该参数。
    请检查此错误，并正确拒绝该消息，而不是从未初始化的堆栈内存中读取内容。
    (CVE-2026-63959)

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

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

  - wifi：iwlwifi：mvm：修复旧设备上驱动程序设置的 TX 速率 在 7265D 等旧设备上，速率仍以版本 1 格式编码，该格式不使用 CCK/OFDM 速率索引 （0-3/0-7），而是使用 PLCP 值（例如，10 表示 1 Mbps CCK 速率）。在引入 v3 速率时，我将驱动程序从内部处理 v1 速率并转换为 v2，更改为内部处理 v3 并根据固件转换为 v1 或 v2。因此，我更改了 iwl_mvm_mac80211_idx_to_hwrate（） 中的代码，使不同 API 不再具有不同的值。此情况是正确的。但是，我后来恢复了这部分更改，因为据报告我破坏了信标速率，导致 FW 断言/崩溃。这导致 TX_CMD 速率设置不正确，从而可能在从设备报告为已被使用时造成警告。通过单独处理内嵌在信标模板命令中的TX_CMD中的信标速率，修复此问题（希望现在正确）。还原 iwl_mvm_mac80211_idx_to_hwrate（） 以仅返回速率索引而不返回 PLCP 值，从而修复实TX_CMD。（CVE-2026-64176）

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

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

  - drm/amdkfd：修复 kfd 调试程序 get_queue_ids（） 计算 array_size = num_queues * sizeof（uint32_t） 时整数溢出的漏洞，可在 32 位 size_t 版本中溢出。相反，使用 array_size（），它会饱和到溢出时SIZE_MAX。（从提交 2d57a0475f085c08b49312dfd8edcb461845f285 中精选出的内容）（CVE-2026-63881）

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

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

  - ethtool：module：在模块刷新错误时调用 ethnl_ops_complete（） 当 validate（） 失败时，即使我们调用了 ethnl_ops_begin（），我们仍会跳过 ethnl_ops_complete（）。（CVE-2026-63998）

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

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

  - wifi：mac80211：在 mesh 重用 skb->cb 之前捕获快速 RX 速率 ieee80211_invoke_fast_rx（） 通过 IEEE80211_SKB_RXCB（skb） 读取 RX 状态，其别名为 ieee80211_rx_mesh_data（） 重用为 IEEE80211_TX_INFO 的相同 skb->cb 存储。在单播转发路径中，mesh_data执行以下操作：info = IEEE80211_SKB_CB（fwd_skb）;memset（info， 0， sizeof（*info））;在同一个 skb 上，调用者仍通过 rx->skb 命名，然后将 skb 排队以等待 TX（成功）或 kfree_skb（）的 it（无路由），然后再返回RX_QUEUED。然后，调用方的 RX_QUEUED arm 在已归零（成功路径）或已释放（无路由路径）内存上调用 sta_stats_encode_rate（status）。后者是 ieee80211_prepare_and_rx_handle 的 KASAN slab-after-free-use-later-free。通过在调用 ieee80211_rx_mesh_data（） 之前对状态中的速率进行编码进行修复，以便 RX_QUEUED arm 消耗在状态仍然由有效内存支持时捕获的值。（CVE-2026-64117）

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

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

  - ethtool：rss：修复get_rxfh失败时的 indir_table 和 hkey 泄漏 rss_prepare_get（） 通过 rss_get_data_alloc（） 分配间接表和哈希密钥缓冲区，然后调用 ops->get_rxfh（） 进行填充。如果 get_rxfh（） 失败，该函数将返回错误而不释放分配。（CVE-2026-63999）

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

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

  - batman-adv：tp_meter：在清理时直接关闭定时器 batadv_tp_sender_cleanup（） 调用 timer_delete_sync（），接着调用 timer_delete（），以防止定时器处理程序在两次调用之间自行重新布防。这种双重删除 hack 依靠被设置为 0 的发送状态来禁止重新布防。将两个调用都替换为单个 timer_shutdown_sync（）。此函数既会等待任何运行中的定时器回调完成（如 timer_delete_sync（）），又会永久撤防计时器，使其之后无法重新布防，从而使阻止重新布防成为无条件且自我记录。re-arming 属性也是必需的，否则：1. 上下文 0 （batadv_tp_recv_ack（）） 检查 batadv_tp_reset_sender_timer（） 中是否发送仍为 1 ->则为 2。上下文 1 将 batadv_tp_sender_shutdown（） 发送变为 0，在此过程中强制 kthread 停止 batadv_tp_sender_cleanup（） 3 中的定时器。上下文 0 在 batadv_tp_reset_sender_timer（） 中继续并重新武装计时器
    ->但其引用已消失 （CVE-2026-64093）

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

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

  - lsm：保持 lsm_set_self_attr（） 的cred_guard_mutex，就像 proc_pid_attr_write（） 在调用 LSM 挂钩之前已执行的操作一样。这仅对 SELinux 和 AppArmor 重要，因为 SELinux 和 AppArmor 会检查进程是否正在被追踪，如果是，则检查是否允许转换。（CVE-2026-64111）

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

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

  - drm/amd/display：在迭代之前验证 GPIO 引脚 LUT 表大小 [原因及方式] get_gpio_i2c_info（） 和 bios_parser_get_gpio_pin_info（） 中的 GPIO 引脚表解析器从 VBIOS table_header.structuresize 字段派生元素计数，然后迭代条 gpio_pin[] 目。但是，GET_IMAGE（） 仅验证表标头本身是否适合 BIOS 映像。如果 VBIOS 报告的结构大小大于实际映射的数据，则循环读取时会超出 BIOS 图像的末尾，从而导致越界读取。在两个函数中进入循环之前，调用 bios_get_image（） 验证是否可在 BIOS 映像内访问声明的完整结构大小，以修复此问题。（从提交 ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3 中精选出的内容）（CVE-2026-64097）

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

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

  - drm/amdgpu：修复amdgpu_hmm_range_get_pages 通知程序序列只能读取一次，否则我们可能使用无效页面。同时还修复了编码样式，例如，删除预先初始化的返回值并对 2G 范围使用通用定义。（从提交 c08972f555945cda57b0adb72272a37910153390 中精选出的内容）（CVE-2026-63879）

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

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

  - netfs：修复与重试添加新子请求相关的锁定缺失 修复 netfs_retry_read_subrequests（） 和 netfs_retry_write_stream（） 以在将额外的子请求添加到 stream->subrequest 中时进行适当的锁定。（CVE-2026-64068）

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

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

  - netfs：修复 netfs_write_begin（） 错误处理中的请求泄漏 修复 netfs_write_begin（），以便在收到来自 netfs_wait_for_read（） 错误时不会泄漏请求中的 ref。（CVE-2026-64060）

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

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

  - netfs：修复无锁访问 stream->subrequests 时缺失的屏障 netfs_collect_read_results（） 和 netfs_collect_write_results（） 可以在不带锁的情况下访问 stream->subrequests 附加的子请求列表，然后它们会在从列表中获取 subreq 指针后访问 subreq->flags，而无需使用屏障。相关而言，构造列表的函数在构造列表时不会使用任何类型的写入屏障，以确保在未锁定的情况下将NETFS_SREQ_IN_PROGRESS标记视为首先设置。通过以下方式修复此问题：（1） 添加新的 list_add_tail_release（） 函数，该函数使用释放屏障将指针设置为列表中的新成员。（2） 添加一个新的 list_first_entry_or_null_acquire（） 函数，该函数使用获取屏障来读取指向列表中第一个成员的指针（或返回 NULL）。（3） 将 subreq 添加到 ->subrequests 时使用 list_add_tail_release（）。
    （4） 最初访问列表的前面时使用 list_first_entry_or_null_acquire（） （当删除一个项目时，指向新前面 iterm 的指针在同一锁定下获得）。（CVE-2026-64067）

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

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

  - ALSA：pcm：oss：修复 proc 写入错误上的设置列表 UAF snd_pcm_oss_proc_write（） 在复制任务名称之前将新分配的设置条目链接到 OSS 设置列表中。如果任务名称分配失败，错误路径将释放已链接的条目，并使setup_list指向已释放的内存。之后打开的 OSS 设备可随后遍历 snd_pcm_oss_look_for_setup（） 中的过时列表条目并取消引用已释放的内存。在setup_list上发布条目之前，请分配任务名称并初始化设置条目。
    此外，仅在进行setup_mutex之后才获取初始 proc 读取迭代器，因此所有遍历都遵循相同的列表生命周期规则setup_list。（CVE-2026-64001）

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

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

  - usb：typec：tcpm：验证发现身份 ACK 处理程序中的 VDO 计数 调用 svdm_consume_identity（） 或 svdm_consume_identity_sop_prime（） 时正确验证从设备传递的计数，因为设备控制的值可能会从静态数组索引，从而导致数据泄漏。（CVE-2026-63963）

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

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

  - KVM：arm64：正确封装客户机管理程序提供的ZCR_EL2 ZCR_EL2可由 VHE 客户机管理程序使用 ZCR_EL2（用于陷阱）或 ZCR_EL1（不设陷阱）进行更新。KVM 以不同的方式处理两者：- 在ZCR_EL2陷时，ZCR_EL2。LEN 立即将上限设为 VM 自身的 VL 限制。这有可能破坏依赖完整 LEN 字段实现有状态的现有软件。- 对于ZCR_EL1访问，我们完全不执行任何操作。在还原 L2 客户机的 SVE 上下文时，我们直接将客户机管理程序的ZCR_EL2视图还原到物理ZCR_EL2中。如果使用 ZCR_EL2 访问器更新了客户机的寄存器视图，则该值已被审查（包含上述警告）。但如果客户机使用ZCR_EL1，原始值会写入硬件中，而 L2 客户机现在可以访问本不应访问的 VL。通过将 VL 上限移动到还原点来修复以上所有问题，确保：- 始终使用上限值对硬件进行编程，无论使用何种访问器， - ZCR_EL2。LEN 字段始终是完全有状态的，无论使用何种访问器。此外，ZCR_EL2移动为审查过的寄存器，确保只有 LEN 字段真正有状态。这需要对 RES0 掩码进行一些创造性的构造，因为 sysreg 生成脚本尚未生成 RAZ/WI 字段。[maz：
    已重写提交消息，整理 access_zcr_el2（）] （CVE-2026-63941）

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

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

  - rxrpc：通过将数据复制到 recvmsg 中的缓冲区，修复 DATA 解密与 splice（） 这改进了针对 .CVE-2026-43500 通过去除 I/O 线程中的数据包共享，并无条件地将数据包内容提取到反弹缓冲区（该缓冲区）中进行解密，修复由 splice（） 本地传输的数据包就地解密而造成的页面缓存损坏。recvmsg（）（或内核等效项）然后将数据从 bounce 缓冲区复制到目标缓冲区。然后，sk_buff保持不修改。这还有一个额外的优势，即数据包随后以加密算法直接处理所需的正确对齐方式排列在缓冲区中。加密的性能似乎确实快了一些，而且令人惊讶的是，未加密的性能似乎没有太大变化
    - 可能是因为降低了 I/O 线程的复杂性。另一个优点是 I/O 线程不必复制数据包，这会减慢数据包分发、ACK 生成等速度。缓冲区属于调用，最初以 2K（足够大小容纳整个巨型子数据包）分配，但如果需要，缓冲区的大小将会增加。但是，为了完成这项工作，MSG_PEEK可能会导致将较早的数据包解密到缓冲区中，在这种情况下，较早的数据包将需要为后续的 recvmsg（） 重新解密。请注意，rx_pkt_offset现在可以合法地将 0 视为有效偏移，因此切换为使用 USHRT_MAX 来表示无效偏移。另请注意，我通常更愿意将当前sk_buff的缓冲区替换为大小合适的新 kmalloc'd 缓冲区，放弃旧的数据和碎片，因为这样可以更轻松地处理MSG_PEEK并消除重新解密问题，但这看起来是一件相当复杂的事情。skb_morph（） 看起来符合我想要的一半，但我不想分配新的sk_buff。（CVE-2026-64026）

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

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

  - netfilter：nf_tables：修复同一寄存器操作中的 dst 损坏 对于 lshift 和 rshift，移位操作在 32 位字上循环执行。循环计算移位值并将其写入 dst，然后立即从 src 读取以计算下一次迭代的进位。由于 src 和 dst 可能指向相同的内存位置，因此无法使用新修改的 dst 值而非原始 src 值正确计算进位。添加一个临时本地变量来在写入 dst 之前缓存原始值并将其用于进位计算可解决该问题。此外，所有类型的操作（包括字节顺序）都会拒绝控制平面的部分重叠。这是用下列字节码测试的： 表 test_table ip 标志 0 使用 1 句柄 1 ip test_table test_chain 使用 3 类型筛选器挂钩输入 prio 0 策略接受数据包 0 字节 0 标志 1 ip test_table test_chain 2 [immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = （ reg 1 << 0x08000000 ） ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = （ reg 1 << 0x08000000 ） ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 字节 1917798 ] （CVE-2026-64006）

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

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

  - Bluetooth：HIDP：修复 hidp_input_report（） 中缺少的长度检查 hidp_input_report（） 从 skb 读取键盘和鼠标负载数据，而无需事先验证 skb->len 是否包含足够的数据。
    hidp_recv_intr_frame（） 在调度到 hidp_input_report（） 之前拉取 1 字节的 HIDP 标头。如果已配对设备发送截断的数据包，则处理程序会读取超出有效的 skb 数据，从而导致 skb 数据的越界读取。OOB 字节可被解释为幻影按键或虚假鼠标移动。请用 skb_pull_data（） 调用替换开放代码的长度跟踪和指针算法。
    skb_pull_data（） 如果请求的字节不存在则返回 NULL，因此不需要手动大小变量和单独的 skb->len 保护。（CVE-2026-63947）

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

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

  - usb：gadget：f_fs：仅复制短 ep0 读取上接收到的字节 ffs_ep0_read（） 使用 kmalloc（）（而非 kzalloc）以来自设置数据包的长度值分配其控制 OUT 数据缓冲区，然后将该完整长度复制到用户空间，而不管实际收到的字节数为何：data = kmalloc（len， GFP_KERNEL）;...
    ret = __ffs_ep0_queue_wait（ffs， data， len）;if （（ret > 0） & （copy_to_user（buf， data， len））） ret =
    -EFAULT;__ffs_ep0_queue_wait（） 返回 req->actual，在短控制 OUT 传输中严格小于 len。copy_to_user（） 调用仍然会复制 len 字节，因此在短 OUT 时，kmalloc（） 缓冲区的最后一个 （len - ret） 字节（未初始化的 slab 残余）会传递到 FunctionFS 后台程序。
    短 ep0 OUT 完成是指定的 USB 控制传输行为，由树内 UDC 生成：* dwc2 继续执行 ep0 DATA OUT 的 req->actual < req->length（short-not-ok 是唯一的 ep0-OUT 停止路径）。* aspeed_udc在 ep->ep.maxpacket rx_len <结束 ep0 OUT。* renesas_usbf记录 ep0 短数据包并完成请求。* dwc3 在短 IN 上停止，但在短 OUT 上不会停止。因此，短 ep0 OUT 不是 UDC 损坏的证据;这是f_fs必须应对的正常情况。drivers/usb/gadget/legacy/inode.c 中的同级 gadgetfs 实现已通过 copy_to_user（） 之前的 min（len， dev->req->actual） 正确执行此操作。此修补程序将 f_fs.c 引入相同的安全模式，而不是在防御层进行裁剪。从 FunctionFS 设备节点访问该缺陷，在实际部署中，该节点由特权小工具后台程序（adbd、UMS、复合小工具服务等）拥有;无法从非特权用户空间访问。Linux 主机堆栈通常会在 short-wLength 控制 OUT 到达小工具之前将其拒绝，因此重现此缺陷需要绕过该主机端检查的版本。
    绕过到位后，64 字节安装程序上的 1 字节负载会在后台程序的读取缓冲区中产生 63 字节的非金丝雀碎片残余。通过仅将 ret（实际收到）字节复制到用户空间来修复。
    (CVE-2026-63895)

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

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

  - test_kprobes：在测试运行之间清除 kprobes 运行两次 kprobes 健全测试会使所有测试失败，并最终造成内核崩溃。[root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # 总计：pass：5 fail：0 skip：0 total：5 ok 1 kprobes_test [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # test_kprobe： EXPECTATION FAILED at lib/tests/test_kprobes.c：64 Expected 0 == register_kprobe（&kp），but register_kprobe（&kp） == -22 （0xffffffffffffffea） ... 无法处理内核分页请求... 测试套件将数个 kprobes 和 kretprobes 定义为在测试运行间保留的静态变量。在register_kprobe和unregister_kprobe之后，kprobe 包含一些剩余数据，必须先清除这些数据，然后才能再次注册 kprobe。测试正在设置symbol_name以定义探头位置。必须清除地址和标记。现有代码在后续测试之间清除某些探测，但不会在两次测试运行之间清除。上一次测试运行的剩余数据使注册在下一次测试中失败。将所有 kprobe 的清除移至 kprobes_test_init，此函数会在每次测试（包括测试运行的第一次测试）之前调用。（CVE-2026-64163）

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

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

  - netfilter：ebtables：移至两阶段删除方案 与之前针对 x_tables 的修补程序一样，ebtables 中也遵循相同的模式。我们无法重用 xt 帮助程序：ebt_table struct 布局不兼容。table->ops 分配现在已完成，同时仍保留 ebt 互斥体，以确保永远不会暴露部分填充的表结构。（CVE-2026-64077）

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

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

  - netfilter：x_tables：添加并使用 xtables_unregister_table_exit 之前的变更添加了xtables_unregister_table_pre_exit以将表与数据包路径分离，以及将其与活动表列表断开链接。对于 rmmod，对此表执行 set/getsockopt 的用户空间将无法重新实例化该表：1. 已删除幼虫表 2.现有的实例化表不再位于 XT pernet 表列表中。这添加了第二阶段帮助程序：从濒死列表中取消表的链接，释放挂钩 ops（如果有）并执行审计通知。它替换 xt_unregister_table（）。
    (CVE-2026-64078)

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

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

  - powerpc/hv-gpci：修复 sysfs 显示路径中的 preempt 计数泄漏 hv-gpci 中的四个 sysfs show（） 回调采用 get_cpu_var（hv_gpci_reqb）（调用 preempt_disable（）），但仅在“out：”标签下的错误路径上调用匹配的 put_cpu_var（）。每次成功读取都会泄露一个 preempt_disable（）：
    processor_bus_topology_show（） processor_config_show（） affinity_domain_via_virtual_processor_show（） affinity_domain_via_domain_show（） （affinity_domain_via_partition_show（） 已正确。）在 CONFIG_PREEMPT=y 内核中，反复读取会引发preempt_count，并最终返回仍禁用优先权的用户空间。然后，下一个用户模式页面错误命中 faulthandler_disabled（） == 1，被强制至 SIGSEGV，而生成的 coredump 在 call_usermodehelper_exec -> wait_for_completion_state -> schedule： BUG： scheduling while atomic：
    <task>/<pid>/0x00000004 ... __schedule_bug+0x6c/0x90 __schedule+0x58c/0x13a0 schedule+0x48/0x1a0 schedule_timeout+0x104/0x170 wait_for_completion_state+0x16c/0x330 call_usermodehelper_exec+0x254/0x2d0 vfs_coredump+0x1050/0x2590 get_signal+0xb9c/0xc80 do_notify_resume+0xf8/0x470 添加一个 out_success 标签，该标签在返回字节计数前调用 put_cpu_var（），从而镜像 affinity_domain_via_partition_show（）。
    (CVE-2026-64070)

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

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

  - vsock/virtio：填充 zerocopy skb 前绑定 uarg virtio_transport_send_pkt_info（） 在进入发送循环前分配或重用 zerocopy uarg，但 virtio_transport_alloc_skb（） 在继承该 uarg 之前仍然填充 skb。当固定缓冲区矢量 zerocopy 命中 MAX_SKB_FRAGS 时，io_sg_from_iter（） 可能会部分附加受管 frag 并返回 -EMSGSIZE。回滚路径调用 kfree_skb（） 以释放携带 SKBFL_MANAGED_FRAG_REFS 但不携带 uarg 的 skb，因此 skb_release_data（） 会变成普通的 frag unref。将 uarg 传递到 virtio_transport_alloc_skb（） 并在 virtio_transport_fill_skb（） 之前绑定它。这可以保持控制或无负载 skb，同时确保成功和回滚共享一个生命周期规则。（CVE-2026-63970）

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

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

  - rbd：消除 unmap 上 lock_dwork 耗尽中的争用 鉴于 rbd_lock_add_request（） 和 rbd_img_exclusive_lock（） 的写入方式，lock_dwork 可能（重新）排队的时间超过实际需要的次数：例如，当我们代表另一个 I/O 请求在 rbd_acquire_lock（） 中间时，有一个新的 I/O 请求传入。这是正常情况，且通过 rbd_release_lock（） 抢先取消lock_dwork在正常操作中是安全的。一个更成问题的例子是 maybe_kick_acquire（）： if （have_requests || delayed_work_pending（&rbd_dev->lock_dwork）） { dout（%s rbd_dev %p kicking lock_dwork\n， __func__， rbd_dev）; mod_delayed_work（rbd_dev->task_wq， &rbd_dev->lock_dwork， 0）; }在 delayed_work_pending（） 返回 true 后立即取消 lock_dwork 并让 mod_delayed_work（） 重新排队并非不现实。这是一场经典的 TOCTOU 比赛。在取消映射图像时，隐式假设超过来自 rbd_dev_image_unlock（） 的返回点后没有任何自我启动的排他锁活动，如果碰巧持有锁，则解锁该锁。此解锁被认为是最终的，并且lock_dwork（以及所有其他独占锁定任务，实际上）预计不会再次排队。
    但是，lock_dwork仅在 cancel_tasks_sync（） 中（即取消映射序列的后面）中取消，最重要的是，取消实际上可能被 maybe_kick_acquire（） 无效化。这可能导致 rbd_dev_device_release（） 和 rbd_dev_image_release（） 运行后执行 rbd_acquire_lock（），并释放和/或重置一堆东西。其中一种可能的失败模式是违反rbd_assert（rbd_image_format_valid（rbd_dev->image_format））;在 rbd_dev_header_info（） 中，通过从 rbd_post_acquire_action（） 的 rbd_dev_refresh（） 调用。重做独占锁定任务耗尽，以提供更合理的语义，并尝试满足关于 rbd_dev_image_unlock（） 的假设。（CVE-2026-64112）

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

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

  - netfs：修复 netfs_read_to_pagecache（） 以在子请求失败时暂停 修复 netfs_read_to_pagecache（），以便在已发出的子请求失败时暂停生成新的子请求。（CVE-2026-64066）

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

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

  - blk-mq：弹出缓存的请求（如果可用） 当将 bio 提交到 blk-mq 时，如果任务应该在预览缓存的请求之后休眠，但在弹出之前，插头将刷新并调用blk_mq_free_plug_rqs，从而释放cached_rqs。这造成释放后使用缺陷。如果适合使用，通过在任何可能的阻止调用之前弹出缓存请求来修复此问题。首先弹出此请求会保留队列引用，因此可避免与队列冻结发生任何序列化争用，并可以安全地继续将该请求分派到驱动程序。这可能会增加从驱动程序想要冻结其队列到停止调度请求的计时时段。不过，这种情况不在快速路径上，驱动程序无论如何都需要在冻结请求期间适当处理请求。缺点是，当我们执行生物插头合并时，需要单独释放弹出的元素。以后无论如何都必须释放缓存的请求，但此修补程序在构建插头列表时实现此操作，而不是在刷新它之后。
    (CVE-2026-64017)

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

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

  - netfs：修复 ->remote_i_size 和 ->zero_point 中潜在的撕裂 修复使用
    ->remote_i_size 和 ->zero_point，方法是复制 i_size_read（） 和 i_size_write（），并使用与 i_size 相同的 seqcount。我们需要确保 netfslib 及其使用它的文件系统在更新任何大小时始终保持i_lock，以防止损坏i_size_seqcount。（CVE-2026-64160）

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

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

  - af_unix：修复 unix_stream_data_wait（） 中对 tail->len 的 UAF 读取 unix_stream_data_wait（） 在不保持任何阻止该队列上的 SKB 出列和释放的锁定的情况下执行 skb_peek_tail（&sk->sk_receive_queue）。自提交 79f632c71bea 以来一直如此（unix/stream：修复了使用大于队列中数据的偏移进行的扫视）。这样做的第一个后果是指针比较 'tail ！= last' 可能是假的，即使 'last' 在语义上指的是已经释放的 SKB，而 'tail' 是在同一地址分配的新 SKB;这可导致 unix_stream_data_wait（） 在新数据到达后错误地继续阻断，但仅限于奇怪的情况下，即窥视 recv（） 和同一套接字上的普通 recv（） 正在争用，这可能不是真正的问题。但自从提交 2b514574f7e8（net：af_unix：
    实现 stream af_unix 套接字的 splice），“tail”实际会取消引用，这可在以下争用情况下造成 UAF（其中 test_setup（） 以单线程运行，然后 test_thread1） 和 test_thread2（） 在两个线程中并发运行： ''' static int socks[2]; void test_setup（void） {socketpair（AF_UNIX， SOCK_STREAM， 0， socks）; send（socks[1]， A， 1, 0);int peekoff = 1;
    setsockopt（socks[0]， SOL_SOCKET， SO_PEEK_OFF， &peekoff， sizeof（peekoff））;} void test_thread1（void） { char dummy; recv（socks[0]， &dummy， 1， MSG_PEEK）; } void test_thread2（void） { char dummy; recv（socks[0]， &dummy， 1， 0）; shutdown（socks[1]， SHUT_WR）; } ''' when race： ''' thread1 thread2 unix_stream_read_generic mutex_lock（&u->iolock） skb_peek（&sk->sk_receive_queue） skb_peek_next（skb， &sk->sk_receive_queue） mutex_unlock（&u->iolock） unix_stream_read_generic unix_state_lock（sk） skb_peek（&sk->sk_receive_queue） unix_state_unlock（sk） unix_stream_data_wait unix_state_lock（sk） tail = skb_peek_tail（&sk->sk_receive_queue） spin_lock（&sk->sk_receive_queue.lock） __skb_unlink（skb， &sk->sk_receive_queue） spin_unlock（&sk->sk_receive_queue.lock） consume_skb（skb） [释放 SKB] 'tail ！= last'：false 'tail'：true 'tail->len ！= last_len' ***UAF*** ''' 通过删除 tail->len 的读取修复 UAF;只有当 UNIX 套接字的接收队列中的 SKB 可以增长时（这种情况不再发生），检查 tail->len 才有意义。Kuniyuki 解释道：> 提交 869e7c62486e 时（net：af_unix：实现流 sendpage >支持）添加了 sendpage（） 支持，数据可被附加到接收方队列中的最后一个> skb。> > 这就是为什么我们在 unix_stream_data_wait（） 中等待新数据时，需要检查最后一个 skb 的长度是否>更改。> > 但是，提交 a0dbf5f818f9（af_unix：支持 MSG_SPLICE_PAGES）并>提交 57d44a354a43（unix：将 unix_stream_sendpage（） 转换为使用 > MSG_SPLICE_PAGES） 重构的 sendmsg（），现在数据始终>添加到新的 skb。这表示此补丁之前不适用于内核。 6.5（CVE-2026-64109）

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

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

  - ProFTPD mod_sftp包含基于堆的缓冲区溢出，经认证的 SFTP 用户可访问该溢出。fxp_packet_read（） 函数接受攻击者提供的 32 位 big-endian SFTP 数据包长度，而无需进行最低健全性检查。值为 0 会导致读取路径中其他位置的无符号减法下溢至大约 4 GB。该超大请求到达核心内存分配器，该分配器以 size_t 计算舍入大小，但以 32 位 int 的形式传递给 new_block（）;0x100000000的低 32 位为 0，因此当调用程序被告知其收到 ~4 GB 时，new_block（） 会返回一个小（~512 字节）区块。随后的填充循环会将攻击者控制的字节流式传输到 544 字节分配的末尾之后，进而产生攻击者控制的堆缓冲区溢出。经认证的用户可根据需要使用单个畸形 SFTP 数据包（packet_len=0，后跟大于约 544 字节的正文）使每个连接的 ProFTPD 会话子进程崩溃，从而产生可靠的经认证的远程拒绝服务。根据堆布局和相邻分配，虽然提供的概念证明仅证实拒绝服务，但可能会造成堆元数据损坏和拒绝服务以外的其他后果。
    (CVE-2026-53994)

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

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

  - net：bcmgenet：保持 RBUF EEE/PM 禁用 设置RBUF_EEE_EN |一旦 MAC EEE 变为活动状态，RBUF_ENERGY_CTRL中的RBUF_PM_EN会中断 GENET 硬件上的 RX 路径。当链路保持运行且通常的描述符/RX 错误计数器保持静默时，RX 流量停止流动。在该状态下，MAC 仍接受帧（rbuf_ovflow_cnt持续爬升），但 RBUF 不再将其转发到 DMA，因此rx_packets不再在 netdev 级别递增。在某些板上，损坏最终会通过 LPI 退出上的 bcmgenet_rx_poll 以 skb_release_data 中的分页错误告终。在 Pi 4B （BCM2711 + BCM54213PE） 上复制，并由 Florian Fainelli 在具有相同崩溃签名的内部 Broadcom 4908 系列板上确认。
    RBUF_PM_EN未公开记录。由于 phy_support_eee（） 默认启用 EEE，此问题会更频繁地出现，但一旦通过 ethtool 打开 TX LPI，它也会影响较旧的内核，因此它并不特定于最近的更改。始终清晰RBUF_EEE_EN |RBUF_PM_EN bcmgenet_eee_enable_set，因此位在重置期间保持关闭。UMAC 和 TBUF 设置不会受到影响，因此 TX 端的 EEE 可以继续运行。（CVE-2026-64125）

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

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

  - nvme：修复映射失败时的 bio 泄漏 本地 bio 始终为 NULL，因此如果完整性映射失败，我们将泄漏 bio。只需直接从请求中获取即可。（CVE-2026-64072）

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

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

  - vsock/vmci：修复对等机在握手期间重置连接时的 UAF vmci_transport_recv_connecting_server（） 在其默认交换机 arm 中为对等机 RST 返回 err = 0：err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ？0：-EINVAL;这会使 vmci_transport_recv_listen（） 跳过 vsock_remove_pending（），将待定套接字留在侦听器的 pending_links 上，sk_state = TCP_CLOSE，而 destroy： 仍然丢弃了在 schedule_delayed_work（） 之前的显式引用。一秒钟后，vsock_pending_work（） 观察到 is_pending=true 并执行完全清除：
    vsock_remove_pending（），然后是两个尾随的 sock_put（sk） 调用 -- 第一个到达 refcount 0 且
    __sk_freed套接字，第二个则写入已释放的对象： 缺陷：KASAN：任务 kworker 在地址 ffff88800b1cac80 处的大小为 4 的 refcount_warn_saturate 写入 slab-after-free 工作队列：事件vsock_pending_work 将对等机 RST 视为任何其他意外数据包类型 （err = -EINVAL）。所有 destroy：arm 现在返回 0 <错误，因此 vmci_transport_recv_listen（） 同步从 pending_links 中删除待定项，vsock_pending_work（） 采用 is_pending=false / ！rejected 分支，仅丢弃自己的工作引用。
    这也结束了 Sashiko 在 v2 上报告的多数据包争用：在任何后续数据包找到它之前，挂起的状态就会从列表中删除。Sashiko 还指出，vmci_transport_recv_listen（） 的 err < 0 路径中预先存在的 sk_acceptq_removed（） 间隙并未由此修补程序引入或改变。使用 KASAN 在 lts-6.12.79 上测试：52/100 未修补 -> 0/100 修补。（CVE-2026-64115）

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

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

  - ntfs3：拒绝对保留$LX的直接用户空间写入 * xattrs NTFS3 使用 $LXUID和 作为 $LXGID$LXMOD$LXDEV内部 WSL 权限元数据，并从 ntfs_get_wsl_perm（） 重新加载到 i_uid、i_gid 和 i_mode中。由于空前缀 xattr 处理程序还允许文件所有者直接在这些名称上调用 setxattr（），可写入的 ntfs3 挂载上的非特权写入器可在自己的文件中植入根所有权和S_ISUID，并在 inode 重新加载后获得 euid 0。拒绝直接用户空间写入保留 $LX的 * 名称。内部 ntfs3 元数据更新保持不变，因为 ntfs_save_wsl_perm（） 直接通过 ntfs_set_ea（） 写入。[almaz.alexandrovich@paragon-software.com：为非特权用户添加了额外的检查]（CVE-2026-63833）

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

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

  - hdlc_ppp：释放 hdlc 状态前同步每个原型的定时器 struct ppp 中嵌入的每个 PPP 控制协议 （LCP/IPCP/IPV6CP） 通过 timer_setup（） 注册一个定时器。该结构 ppp 是 hdlc->state 分配，其 detach_hdlc_protocol（） 在 unregister_hdlc_device（） 和 attach_hdlc_protocol（） 内部的重新附加）两个拆卸路径中使用 kfree（） 释放。ppp proto 从未注册 .detach 回调，因此 detach_hdlc_protocol（） 在 kfree（） 之前未执行任何定时器同步。ppp_cp_event（） 中唯一的取消 timer_delete（&proto->timer） 是部分的（它不等待正在运行的回调）并且仅在 ->CLOSED 转换中运行;ppp_stop（）/ppp_close（） 也不同步。已执行中（在 ppp->lock 上阻断）的 ppp_timer 回调在 kfree 中幸存下来，然后在已释放的内存中取消引用 proto->state / ppp->lock，从而导致释放后使用。通过添加一个在每个原型定时器上调用 timer_shutdown_sync（） 的 .detach 辅助函数来修复此问题。detach_hdlc_protocol（） 在 kfree（hdlc->state） 之前调用 proto->detach（dev），因此 timer_shutdown_sync（） 现在在这两个自由路径中运行。使用 timer_shutdown_sync（） 而不是 timer_delete_sync（），因为 keepalive 路径通过 add_timer（）/mod_timer（） 重新布防定时器，并且 shutdown 会在拆卸期间阻止任何重新激活。附加协议时，初始化 ppp_ioctl（） 中的每个协议定时器，并从 ppp_start（） 删除现在冗余的 timer_setup（），以便在附加时初始化定时器一次，并且 ppp_timer_release（） 从不对未初始化的 timer_list 结构进行操作。attach_hdlc_protocol（） 使用 kmalloc（）（不是 kzalloc），因此 struct ppp 的 protos[i].timer 在第一个 timer_setup（） 之前都是未初始化的垃圾;如果没有此 init-at-attach，则附加 PPP 协议而不启动设备，会使 timer_shutdown_sync（） 在 .detach 中的未初始化内存上运行。将 init 从 ppp_start（）（仅在 NETDEV_UP 上运行）移入附加路径将使初始化无条件，并且避免初始化同一timer_list两次。此缺陷是通过静态分析发现的。（CVE-2026-63803）

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

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

  - fbdev：fbcon：修复 fbcon_do_set_font（） err_out中的越界读取 当 fbcon_do_set_font（） 失败时（例如，由于沉重的内存压力下的 vc_resize（） 内部内存分配失败），它会跳至“err_out”标签以回滚控制台状态。但是，当前回滚逻辑忘记了恢复“hi_font”状态，从而导致严重的状态机损坏。在函数的前面，可调用“set_vc_hi_font（）”来更改“vc->vc_hi_font_mask”并改变屏幕缓冲区。如果“vc_resize（）”随后失败，“err_out”路径将还原“vc_font.charcount”，但完全跳过“vc_hi_font_mask”和屏幕缓冲区的回滚。此不匹配使终端处于非同步状态。
    由于保持设置“vc_hi_font_mask”，VT 子系统仍将接受来自用户空间的大于 255 的字符索引，并将其写入屏幕缓冲区。随后的渲染调用（如“fbcon_putcs（）”）随后将使用这些膨胀的索引来访问恢复的 256 个字符的字体数组，从而导致确定性的越界读取并可能泄露内核内存。通过在错误路径中添加“hi_font”掩码和屏幕缓冲区缺少的回滚逻辑来修复此问题。（CVE-2026-53402）

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

ID	名称	严重性
327950	Linux Distros 未修补的漏洞：CVE-2026-63940	critical
327949	Linux Distros 未修补的漏洞：CVE-2026-64092	medium
327948	Linux Distros 未修补的漏洞：CVE-2026-63983	medium
327947	Linux Distros 未修补的漏洞：CVE-2026-64159	high
327946	Linux Distros 未修补的漏洞：CVE-2026-64106	critical
327945	Linux Distros 未修补的漏洞：CVE-2026-64154	high
327944	Linux Distros 未修补的漏洞：CVE-2026-64146	medium
327943	Linux Distros 未修补的漏洞：CVE-2026-64076	high
327942	Linux Distros 未修补的漏洞：CVE-2026-64048	high
327941	Linux Distros 未修补的漏洞：CVE-2026-64079	medium
327940	Linux Distros 未修补的漏洞：CVE-2026-64015	high
327939	Linux Distros 未修补的漏洞：CVE-2026-63979	critical
327938	Linux Distros 未修补的漏洞：CVE-2026-64025	critical
327937	Linux Distros 未修补的漏洞：CVE-2026-63959	medium
327936	Linux Distros 未修补的漏洞：CVE-2026-64176	high
327935	Linux Distros 未修补的漏洞：CVE-2026-63881	high
327934	Linux Distros 未修补的漏洞：CVE-2026-63998	medium
327933	Linux Distros 未修补的漏洞：CVE-2026-64117	high
327932	Linux Distros 未修补的漏洞：CVE-2026-63999	medium
327931	Linux Distros 未修补的漏洞：CVE-2026-64093	high
327930	Linux Distros 未修补的漏洞：CVE-2026-64111	high
327929	Linux Distros 未修补的漏洞：CVE-2026-64097	high
327928	Linux Distros 未修补的漏洞：CVE-2026-63879	high
327927	Linux Distros 未修补的漏洞：CVE-2026-64068	critical
327926	Linux Distros 未修补的漏洞：CVE-2026-64060	medium
327925	Linux Distros 未修补的漏洞：CVE-2026-64067	critical
327924	Linux Distros 未修补的漏洞：CVE-2026-64001	medium
327923	Linux Distros 未修补的漏洞：CVE-2026-63963	high
327922	Linux Distros 未修补的漏洞：CVE-2026-63941	high
327921	Linux Distros 未修补的漏洞：CVE-2026-64026	high
327920	Linux Distros 未修补的漏洞：CVE-2026-64006	high
327919	Linux Distros 未修补的漏洞：CVE-2026-63947	high
327918	Linux Distros 未修补的漏洞：CVE-2026-63895	high
327917	Linux Distros 未修补的漏洞：CVE-2026-64163	medium
327916	Linux Distros 未修补的漏洞：CVE-2026-64077	high
327915	Linux Distros 未修补的漏洞：CVE-2026-64078	high
327914	Linux Distros 未修补的漏洞：CVE-2026-64070	high
327913	Linux Distros 未修补的漏洞：CVE-2026-63970	high
327912	Linux Distros 未修补的漏洞：CVE-2026-64112	high
327911	Linux Distros 未修补的漏洞：CVE-2026-64066	critical
327910	Linux Distros 未修补的漏洞：CVE-2026-64017	high
327909	Linux Distros 未修补的漏洞：CVE-2026-64160	critical
327908	Linux Distros 未修补的漏洞：CVE-2026-64109	high
327905	Linux Distros 未修补的漏洞：CVE-2026-53994	high
327904	Linux Distros 未修补的漏洞：CVE-2026-64125	critical
327903	Linux Distros 未修补的漏洞：CVE-2026-64072	high
327902	Linux Distros 未修补的漏洞：CVE-2026-64115	high
327894	Linux Distros 未修补的漏洞：CVE-2026-63833	high
327893	Linux Distros 未修补的漏洞：CVE-2026-63803	high
327892	Linux Distros 未修补的漏洞：CVE-2026-53402	high

检测

Nessus 的 Misc. 系列

critical

medium

medium

high

critical

high

medium

high

high

medium

high

critical

critical

medium

high

high

medium

high

medium

high

high

high

high

critical

medium

critical

medium

high

high

high

high

high

high

medium

high

high

high

high

high

critical

high

critical

high

high

critical

high

high

high

high

high