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

  - net：tls：修复卸载 RX 设置失败时的 strparser 定位标记 skb 泄漏 当 tls_set_device_offload_rx（） 在 tls_dev_add（） 发生故障时，错误路径将调用 tls_sw_free_resources_rx（） 以清理由 tls_set_sw_offload（） 初始化的 SW 上下文。此函数调用 tls_sw_release_resources_rx（） （通过 tls_strp_stop（） 停止 strparser）和 tls_sw_free_ctx_rx（） （kfree上下文），但从不释放由 tls_strp_init（） 中 alloc_skb（0） 分配的定位标记 skb。请注意，tls_sw_free_resources_rx（） 专门用于此无法启动卸载代码路径，没有其他调用程序。在提交 84c61fe1a75b（tls：rx：不使用标准 strparser）之前不存在泄露，因为标准 strparser 不会尝试预先分配 skb。tls_sk_proto_close（） 中的正常关闭路径会在放置套接字锁后通过调用 tls_sw_strparser_done（）（调用 tls_strp_done（））来处理清理，因为 tls_strp_done（） 会执行 cancel_work_sync（） 并且 strparser 工作处理程序会获取套接字锁。
    (CVE-2026-52974)

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

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

  - pppoe：终止 PFC 帧 RFC 2516 第 7 节指出，不建议将协议字段压缩 （PFC） 用于 PPPoE。实际上，pppd 不支持协商 PPPoE 会话的 PFC，当前 PPPoE 驱动程序假设使用未压缩（2 字节）协议字段。但是，通用 PPP 层函数 ppp_input（） 不知道协商结果，仍然接受 PFC 帧。如果实现中断的对等机或攻击者发送包含压缩（1 字节）协议字段的帧，则后续的 PPP 负载将移动一个字节。这会导致网络标头 4 字节未对齐，从而可能在某些架构上触发未对齐访问异常。要减少攻击面，请丢弃 PPPoE PFC 帧。
    引入要同时在 ppp_generic.c 和 pppoe.c 中使用的 ppp_skb_is_compressed_proto（） 辅助函数以避免开放编码。（CVE-2026-53003）

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

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

  - drm/komeda：修复 AFBC 帧缓冲区大小检查中的整数溢出 AFBC 帧缓冲区大小验证通过将 AFBC 负载大小添加到帧缓冲区偏移量来计算所需的最小缓冲区大小。
    执行此加法时不检查整数溢出。如果加法溢出，大小检查可能未正确完成，并允许用户空间提供过小的drm_gem_object，从而可能导致越界内存访问。添加 check_add_overflow（） 的用法，以安全地计算所需的最小大小并在检测到溢出时拒绝帧缓冲区。这使 AFBC 大小验证针对畸形问题更加完善。由 Linux Verification Center (linuxtesting.org) 和 SVACE 发现。(CVE-2026-53068)

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

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

  - dm log：修复因region_count溢出导致的越界写入 create_log_context（） 中的本地变量 region_count 声明为无符号 int（32 位），但 dm_sector_div_up（） 返回 sector_t（64 位）。当设备映射器目标具有足够大的 ti->len 和较小的region_size时，除法结果可能超过 UINT_MAX。然后将截断值用于计算bitset_size，从而导致分配的clean_bits、sync_bits和recovering_bits远小于实际区域数量所需的小。后续日志操作（log_set_bit、log_clear_bit log_test_bit）会使用来源于完整未截断区域空间的区域索引，从而对 vmalloc 分配的内核堆内存造成越界写入。这可以通过创建region_count溢出 32 位的镜像目标来重现： dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0' 状态输出确认截断（sync_count=1 而不是 4294967297，因为 0x100000001 被截断为 1）： $ dmsetup status mymirror 0 8589934594镜像 2 254:1 254:1 1/4294967297 ... 这会导致 core_in_sync 中的内核崩溃：
    BUG：atomic： （udev-worker）/9150/0x00000000 RIP： 0010：core_in_sync+0x14/0x30 [dm_log] CR2：
    0000000000000008 修复递归错误，但需要重新启动！通过在将值分配给 lc->region_count之前将本地region_count加宽为 sector_t 并添加明确的溢出检查来修复。
    (CVE-2026-53059)

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

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

  - drm/sun4i：backend：修复错误指针取消引用 函数 drm_atomic_get_plane_state（） 可返回错误指针，但不会对其进行检查。添加错误指针检查。由 smatch 检测：
    drivers/gpu/drm/sun4i/sun4i_backend.c：496 sun4i_backend_atomic_check（） 错误：“plane_state”取消引用可能的 ERR_PTR（） （CVE-2026-53066）

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

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

  - sctp：修复 sctp_getsockopt_peer_auth_chunks sctp_getsockopt_peer_auth_chunks（） 中对用户空间的越界写入 检查调用程序的 optval 缓冲区是否足够大，以用于包含 if （len < num_chunks） return -EINVAL 的对等机 AUTH 区块列表;但随后将num_chunks字节写入 p->gauth_chunks，后者位于 optval 内的 offset offsetof（struct sctp_authchunks， gauth_chunks） == 8。检查缺少 sizeof（struct sctp_authchunks） = 8 字节标头。当调用程序提供 len == num_chunks（对于任何num_chunks > 0）时，测试通过但 copy_to_user（） 写入 sizeof（struct sctp_authchunks） = 8 字节超出声明的缓冲区。
    下一行的同级函数 sctp_getsockopt_local_auth_chunks（） 已经进行了正确的检查：
    if （len < sizeof（struct sctp_authchunks） + num_chunks） 返回 -EINVAL;将对等变体与其同级对齐。重现程序在 v7.0-13-generic 上确认：非特权用户空间调用程序在启用 AUTH 的情况下打开环回 SCTP 关联，使用短 optval 查询num_chunks，然后发出真正的 getsockopt len == num_chunks，并且绘制到缓冲区前面的 sentinel 字节会观察那些被对等机的 AUTH 区块类型覆盖的 sentinel 字节。写入的字节在对等机的控制之下，但落在调用者自己的用户空间中;这不是内核内存损坏，而是内核端的契约违规，会静默地损坏相邻的用户空间数据。（CVE-2026-53004）

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

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

  - futex：信号/超时唤醒期间防止 requeue-PI 中锁定 在 wait-requeue-pi（任务 A）和 requeue-PI（任务 B）期间，可能发生以下争用： 任务 A 任务 B futex_wait_requeue_pi（） futex_setup_timer（） futex_do_wait（） futex_requeue（） CLASS（hb， hb1）（&key1）;CLASS（hb， hb2）（&key2）;
    *timeout* futex_requeue_pi_wakeup_sync（） requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic（） futex_requeue_pi_prepare（） Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb（hb1， hb2） *重试* 任务 B 会同时获取 hb 锁定并尝试获取最顶层等待程序的 PI 锁定（任务 B）。由于信号/超时，任务 A 提早离开，并开始将自身从队列中移除。它会更新其requeue_state但无法将其从列表中删除，因为这需要任务 B 拥有的 hb 锁。通常，任务 A 能够在任务 B 解锁后将其扑出。
    但是，如果任务 B 的优先级较高，则任务 A 可能无法在任务 B 再次获得锁定之前及时唤醒并获取锁定。尤其是在从未计划 A 的 UP 系统上。因此，任务 A 会阻断锁定和任务 B 忙碌循环，从而尝试取得进展，但却会活锁系统。
    悲惨的。可通过从列表中删除最上面的等待程序来解决此问题。这允许任务 B 在下一次迭代中抓住下一个顶级等待程序（如果有）并取得进展。如果 futex_requeue_pi_prepare（） 失败，则删除最靠座的等待程序。让等待程序有条件地将自己从 handle_early_requeue_pi_wakeup（） 中的列表中删除。(CVE-2026-52977)

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

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

  - iommu/vt-d： 修复因超出范围访问造成的 oops 终止 QEMU 进程时触发以下 oops： 错误：一般保护错误，可能针对非规范地址 0x7fffffff844eaaa7：0000 [#1] SMP NOPTI 调用跟踪：
    <TASK> do_raw_spin_lock+0xaa/0xc0 _raw_spin_lock_irqsave+0x21/0x40 domain_remove_dev_pasid+0x52/0x160 intel_nested_set_dev_pasid+0x1b9/0x1e0 __iommu_set_group_pasid+0x56/0x120 pci_dev_reset_iommu_done+0xe3/0x180 pcie_flr+0x65/0x160 __pci_reset_function_locked+0x5b/0x120 vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core] vfio_df_close+0x4f/0xa0 vfio_df_unbind_iommufd+0x2d/0x60 vfio_device_fops_release+0x3e/0x40 __fput+0xe5/0x2c0 task_work_run+0x58/0xa0 do_exit+0x2c8/0x600 do_group_exit+0x2f/0xa0 get_signal+0x863/0x8c0 arch_do_signal_or_restart+0x24/0x100 exit_to_user_mode_loop+0x87/0x380 do_syscall_64+0x2ff/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e 全局静态块域是一个没有相应dmar_domain结构的虚拟域， 越过iommu_domain结构访问容易触发 oops。通过像身份域一样在 domain_remove_dev_pasid（） 中提早返回来修复它。（CVE-2026-52953）

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

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

  - 处理具有无效索引的已连接组件构件时，ImageMagick 之前 7.1.2-19 的 ConnectedComponentsImage（） 中包含一个越界访问漏洞。攻击者可通过 CLI 指定畸形的连接组件定义来触发访问冲突，从而造成拒绝服务或可能执行代码。（CVE-2026-56370）

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

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

  - netfilter：conntrack：删除 sprintf 使用情况 将其替换为 scnprintf，缓冲区大小预期足够大以容纳结果，不需要进行 snprintf+溢出检查。同时增大 mangle_content_len（） 中的缓冲区大小。缺陷：KASAN：vsnprintf+0xea5/0x1270 中的堆栈越界 地址处写入大小为 1 [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..]（CVE-2026-53002）

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

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

  - net、bpf：为下机主控端修复 xdp_master_redirect（） 中的 null-ptr-deref syzkaller 报告了 bond_rr_gen_slave_id（） 中通过 xdp_master_redirect（） 到达的内核错误。完整解码的跟踪：
    https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73 bond_rr_gen_slave_id（） 取消引用 bond->rr_tx_counter，这是一种每 CPU 计数器，当模式为轮循策略时，bonding 仅在 bond_open（） 中进行分配。如果从未启动绑定设备，rr_tx_counter 将保持 NULL。XDP 重定向路径仍可访问从未打开的绑定上的该代码：bpf_master_redirect_enabled_key 是全局静态密钥，因此只要任何绑定设备附加了本地 XDP，系统范围内的每个从属设备就会启用 XDP_TX -> xdp_master_redirect（） 拦截。路径 xdp_master_redirect（） -> bond_xdp_get_xmit_slave（） -> bond_xdp_xmit_roundrobin_slave_get（） -> bond_rr_gen_slave_id（） 然后针对没有rr_tx_counter的绑定运行并崩溃。通过在主设备未启动时拒绝调用主控端的 ->ndo_xdp_get_xmit_slave（），在通用 xdp_master_redirect（） 中修复此问题。IFF_UP 只会在
    ->ndo_open（） 已成功返回，因此这可靠地排除了其 XDP 状态尚未完全初始化的主机。丢弃带有XDP_ABORTED的帧，这样异常可通过 trace_xdp_exception（） 可见，而不是静默失败。这并不特定于绑定：任何将 XDP 状态分配延迟至 ->ndo_open（） 的当前或未来主服务器都受到保护。（CVE-2026-53069）

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

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

  - ksmbd：修复来自异步加密的释放后使用 Qualcomm 加密引擎 ksmbd_crypt_message（） 对 AEAD 请求设置空完成回调，并且不处理来自异步硬件加密引擎（如 Qualcomm 加密引擎 （QCE））的 -EINPROGRESS 返回代码。QCE 返回 -EINPROGRESS 时，ksmbd 会将其视为错误，并在硬件 DMA 操作仍在进行中时立即释放请求。然后 DMA 完成回调取消引用释放的内存，从而造成空指针崩溃：pc：
    qce_skcipher_done+0x24/0x174 LR ： vchan_complete+0x230/0x27c ...el1h_64_irq+0x68/0x6c ksmbd_free_work_struct+0x20/0x118 [ksmbd] ksmbd_exit_file_cache+0x694/0xa4c [ksmbd] 使用标准 crypto_wait_req（） 模式和 crypto_req_done（） 作为完成回调，这与 fs/smb/client/smb2ops.c 中 SMB 客户端使用的方法相匹配。这可同时正确处理同步引擎（立即返回）和异步引擎（-EINPROGRESS，后跟回调通知）。（CVE-2026-53046）

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

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

  - net/rds：将每个项目的信息缓冲区交给访问者之前将其清零 rds_for_each_conn_info（） 和 rds_walk_conn_path_info（） 都会将调用方分配的堆栈上 u64 缓冲区交给每个连接的访问者，然后通过 rds_info_copy（） 将完整的 item_len 字节复制回用户空间，而不管访问者实际写入了多少缓冲区。rds_ib_conn_info_visitor（） 和 rds6_ib_conn_info_visitor（） 仅在底层 rds_connection 未处于 RDS_CONN_UP 状态时（src/dst 地址、tos、sl 和两个 GID 通过显式 memsets）时才写入其输出结构的子集。多个 u32 字段（max_send_wr、max_recv_wr、max_send_sge、rdma_mr_max、rdma_mr_size、cache_allocs）以及 sl 和 cache_allocs 之间的 2 字节对齐孔将保留为访问者调用之前的任何堆栈内容，然后memcpy_to_user（）输出到用户空间。struct rds_info_rdma_connection 和 struct rds6_info_rdma_connection 是 include/uapi/linux/rds.h 中仅有的未标记 __attribute__（（packed）） 的 rds_info_* struct，因此它们存在真正的对齐孔。其他信息访问者（rds_conn_info_visitor、rds6_conn_info_visitor、rds_tcp_tc_info...）目前写入其打包输出结构的所有字段，不知道是否容易受影响，但将来添加条件写入路径的访问者将有同样的缺陷。在未构建 CONFIG_INIT_STACK_ALL_ZERO=y 的内核上重现：本地非特权用户打开 AF_RDS，设置 SO_RDS_TRANSPORT=IB，绑定到支持 RDMA 的 netdev 上的本地地址（任何 netdev 上的 rxe soft-RoCE 就足够了），同一子网上的 sendto（） 的任何对等机（完全失败，但在 RDS_CONN_CONNECTING 的全局哈希中安装了一个rds_connection）， 然后调用 getsockopt（SOL_RDS， RDS_INFO_IB_CONNECTIONS）。返回的 68 字节项目包含 26 字节的堆栈垃圾，包括内核文本/数据指针：0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ...gids （memset-zeroed） 40..47 e0 92 a3 81 ff ff ff ff 内核指针 （max_send_wr） 48..55 7f 37 b5 81 ff ff ff ff 内核指针 （rdma_mr_max） 56..59 01 00 08 00 rdma_mr_size（垃圾） 60..61 00 00 tos， sl 62..63 00 00 对齐填充 64..67 18 00 00 00 cache_allocs（垃圾） 通过同时清零 rds_for_each_conn_info（） 和 rds_walk_conn_path_ 中的每项缓冲区进行修复info（），然后再调用访问器。这涵盖了 IPv4/IPv6 IB 访客，并针对同一类缺陷强化了所有当前和未来的访客。对于完全填充其输出的访客，没有功能变更。v2 中的变更： - 在 net 树处重定向（主题前缀 [PATCH net v2]，net/rds：标题中的前缀） - 从 Sharath Srinivasan 和 Allison HendersonCVE-2026-52995 （） 中获取审阅者标签

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

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

  - gfs2：添加一些缺少的日志锁定 函数 gfs2_logd（） 会在不保留 sdp->sd_log_flush_lock 的情况下调用日志刷新函数 gfs2_ail1_start（）、gfs2_ail1_wait（） 和 gfs2_ail1_empty（），但这些函数需要针对并发事务排除。要修复该问题，请添加一个非锁定
    __gfs2_log_flush（） 函数。然后，在 gfs2_logd（） 中，先进行 sdp->sd_log_flush_lock，然后再调用上述日志刷新函数和 __gfs2_log_flush（）。（CVE-2026-53049）

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

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

  - s390/cio：使用通用 driver_override 基础架构 通过 __driver_attach（） 探测驱动程序时，会在未保留设备锁的情况下调用总线的 match（） 回调，因而可在未保留设备锁的情况下访问driver_override字段，这可导致 UAF。通过使用负责内部适当锁定的驱动程序核心driver_override基础架构来修复此问题。请注意，在未保留设备锁定的情况下，从 __driver_attach（） 调用 match（） 是有意为之。[1] （CVE-2026-53117）

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

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

  - concurrent-ruby 是 Ruby 的现代并发工具。在之前版本的 1.3.7Concurrent：：AtomicReference#update 可在当前值为 Float：：NAN 时进入永久忙碌的重试循环。该问题由 AtomicReference#update 之间的交互导致，该交互重试直到 compare_and_set（old_value， new_value） 成功;数字compare_and_set，用于在尝试底层原子交换之前检查旧的 == old_value。;以及 Ruby NaN 语义，其中 Float：：NAN == Float：：NAN 始终为 false。因此，一旦 AtomicReference 包含 Float：：NAN，调用 #update 就会反复评估调用方的区块，并且再也不会返回。在将外部派生的数值存储在 AtomicReference 中的服务中，这可能导致 CPU 耗尽或请求/作业永久挂起。此漏洞已在 1.3.7 中修复。(CVE-2026-54904)

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

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

  - wifi：mt76：mt7925：修复 mt7925_roc_abort_sync roc_abort_sync（） 中可能发生的死锁，roc_work（） 可能与 （） 死锁。roc_work（） 保留 dev->mt76.mutex，而 cancel_work_sync（） 等待 roc_work（） 完成。如果调用方已拥有相同的互斥体，则双方都会阻塞，并且不可能有任何进展。当 mt76_sta_state（） -> mt76_sta_remove（） -> mt7925_mac_sta_remove_link（） -> mt7925_mac_link_sta_remove（） -> mt7925_roc_abort_sync（） 调用 cancel_work_sync（） 而 roc_work（） 仍在运行并保留 dev->mt76.mutex 时，在工作站删除期间会发生此死锁。这可避免互斥体死锁，并保留恰好一次的工作所有权。（CVE-2026-53103）

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

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

  - ceph：修复 __ceph_setxattr（） 中的缓冲区泄漏 __ceph_setxattr（） 中的old_blob可在重试期间存储 ci->i_xattrs.prealloc_blob 值。但是，它永远不会被称为old_blob对象的 ceph_buffer_put（）。此修补程序修复了缓冲区泄漏的问题。（CVE-2026-52962）

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

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

  - bpf：不允许删除 NMI 中的本地存储 目前，通过 NMI 或重新进入中的 kfree_rcu（）、call_rcu（） 或 call_rcu_tasks_trace（） 延迟释放 selem 或本地存储时，本地存储可能会死锁。由于删除 NMI 中的 selem 不太可能使用，因此请在从 NMI 中的 bpf_xxx_storage_delete（） 帮助程序调用时返回错误，以部分缓解此问题。请注意，它仍可以通过重新进入造成死锁。若要完全缓解，必须在 irqs_disabled（） 为 true 时返回错误，但对 bpf_xxx_storage_delete（） 而言过于严厉。长期解决方案需要_nolock版本的 call_rcu。另一种可能的解决方案是延迟 irq_work [0] 的释放，但它会增加 selem 的大小，这并不理想。仅在 helper 和 syscall 使用的 bpf_selem_unlink（） 中才需要此检查。bpf_selem_unlink_nofail（） 没有问题，因为它在映射和所有者拆卸期间被调用，从不在 NMI 或可重入中运行。[0] https://lore.kernel.org/bpf/20260205190233.912-1-alexei.starovoitov@gmail.com/(CVE-2026-53106）

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

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

  - f2fs：修复因错误使用 nat_entry 标记所造成的数据丢失 如果在新创建的文件上执行 fsync（在任何检查点之前）与检查点操作同时执行，则会发生数据丢失。
    情况如下：创建 &; 写入 &; fsync“文件 A”写入检查点 - f2fs_do_sync_file // 内联 inode - f2fs_write_inode // inode 作品集脏 - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_flush_nat_entries - f2fs_fsync_node_pages // 无脏节点 - f2fs_need_inode_block_update // 返回错误的 SPO 和丢失的“文件 A” f2fs_flush_nat_entries（） 设置 IS_CHECKPOINTED 和 HAS_LAST_FSYNC 标记nat_entry，但这并不意味着检查点实际上已成功完成。但是，f2fs_need_inode_block_update（） 检查这些标记并错误地认为检查点已完成。根本原因是只有在检查点写入完全完成后才能保证 IS_CHECKPOINTED 和 HAS_LAST_FSYNC 的语义。此修补程序修改了 f2fs_need_inode_block_update（），使其在读取 nat_entry 标记之前获取 sbi->node_write 锁定，从而确保在观察到设置 IS_CHECKPOINTED 和 HAS_LAST_FSYNC 后，检查点操作已经完成。（CVE-2026-53017）

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

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

  - bpf、sockmap：修复af_unix当 lock_sock_fast（） 采用快速路径并且 iter prog 尝试更新 sockmap 时 iter 死锁 bpf_iter_unix_seq_show（） 可能死锁的问题。其最终会以 sock_map_update_elem（） 的 bh_lock_sock（） 旋转：警告：检测到可能的递归锁定 test_progs/1393 正尝试获取锁定：ffff88811ec25f58 （slock-AF_UNIX）{+...}-{3:3}， at： sock_map_update_elem+0xdb/0x1f0 但任务已保持锁定： ffff88811ec25f58 （slock-AF_UNIX）{+...}-{3:3}， at：
    __lock_sock_fast+0x37/0xe0可能有助于我们调试的其他信息： 可能的不安全锁定情况：
    CPU0 ---- lock（slock-AF_UNIX）;锁（slock-AF_UNIX）;DEADLOCK *** 可能是因为缺少锁定嵌套标记 test_progs/1393 所保留的 4 个锁定： #0：ffff88814b59c790 （&p->lock）{+.+.}-{4:4}， at：
    bpf_seq_read+0x59/0x10d0 #1： ffff88811ec25fd8 （sk_lock-AF_UNIX）{+.+.}-{0:0}， at： bpf_seq_read+0x42c/0x10d0 #2： ffff88811ec25f58 （slock-AF_UNIX）{+...}-{3:3}， at： __lock_sock_fast+0x37/0xe0 #3： ffffffff85a6a7c0 （rcu_read_lock）{....}-{1:3}， at： bpf_iter_run_prog+0x51d/0xb00 调用跟踪： dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0
    _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e （CVE-2026-53035）

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

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

  - quota：修复 dquot_scan_active（） 与配额停用之间的争用 dquot_scan_active（） 可与 quota_release_workfn（） 中的配额停用争用，例如：CPU0 （quota_release_workfn） CPU1 （dquot_scan_active） ============================== ============================== spin_lock（&dq_list_lock）;list_replace_init（&releasing_dquots、&rls_head）;/* dquot X on rls_head，dq_count == 0，DQ_ACTIVE_B仍设置 */ spin_unlock（&dq_list_lock）;synchronize_srcu（&dquot_srcu）;spin_lock（&dq_list_lock）;
    list_for_each_entry（dquot， &inuse_list， dq_inuse） { /* 找到 dquot X */ dquot_active（X） -> true atomic_inc（&X->dq_count）; } spin_unlock（&dq_list_lock）;spin_lock（&dq_list_lock）;dquot = list_first_entry（&rls_head）;WARN_ON_ONCE（atomic_read（&dquot->dq_count））;该问题不仅仅是表面问题，因为在内存压力下，dquot_scan_active（） 的调用程序最终只能处理已释放的 dquot。
    通过确保在获取对 dquot 的引用时将其从发布列表中删除来修复此问题。
    (CVE-2026-53050)

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

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

  - wifi：rtlwifi：pci：修复可能由未完成的irq_prepare_bcn_tasklet造成的释放后使用 irq_prepare_bcn_tasklet在 rtl_pci_init（） 中初始化并计划在硬件触发中断时RTL_IMR_BCNINT 但它从未在 rtl_pci_deinit（） 中被终止。当 rtlwifi 卡探头出现故障或正在被分离时，ieee80211_hw将被释放。但是，irq_prepare_bcn_tasklet可能仍在运行或待定，从而ieee80211_hw导致在
    _rtl_pci_prepare_bcn_tasklet（）。与 irq_tasklet 类似，在 rtl_pci_deinit（） 中添加 tasklet_kill（） 以确保在释放ieee80211_hw前正确终止 irq_prepare_bcn_tasklet。该问题是通过静态分析发现的。（CVE-2026-53112）

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

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

  - netfilter：nf_tables：在提交阶段通过 splice_list_rcu（） 连接挂钩列表 使用 splice_list_rcu（） 将列表中的新挂钩发布到 basechain/flowtable 中，以确保在进行并发规则集更新时通过 rcu 进行 netlink 转储列表遍历是安全的。（CVE-2026-52988）

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

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

  - bpf：修复 pcpu_init_value 中的 OOB 将元素从BPF_MAP_TYPE_CGROUP_STORAGE映射复制到具有相同value_size但未向上舍入为 8 字节的另一个 pcpu 映射时发生越界读取。在以下情况下会发生此问题： 1. 使用未对齐到 8 个字节（例如 4 个字节）的value_size创建CGROUP_STORAGE映射 2.使用相同的value_size创建 pcpu 映射（例如 4 个字节） 3.Update element in 2 in 1 with data in 1 pcpu_init_value 假定所有源都向上舍入为 8 字节，并调用 copy_map_value_long 进行数据复制，但是，由于在某些情况下源可能不会向上舍入到 8 个字节，例如 CGROUP_STORAGE skb->data。校验器会准确验证源声明的大小，而不是内核向上舍入到 8 字节的大小，当源只有 4 个字节而副本大小 （4） 向上舍入为 8 时，会发生 OOB。（CVE-2026-53076）

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

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

  - nexthop：修复引用 IPv4 nexthop 的 IPv6 路由 syzbot 报告错误 [1] [2]。将 IPv6 nexthop 替换为 IPv4 nexthop 时，包含此 nexthop 的所有组的 has_v4 标记不会更新。这是因为只有在将 AF_INET 替换为 AF_INET6 时才会调用 nh_group_v4_update，而缺少相反方向（AF_INET6 到 AF_INET）。这允许过时的 has_v4=false 绕过fib6_check_nexthop，从而导致 IPv6 路由附加到实际上仅包含 AF_INET 个成员的群组。随后路由查找会调用 nexthop_fib6_nh（），为AF_INET成员返回 NULL，导致空指针取消引用。可在系列变更时通过调用 nh_group_v4_update 进行修复，而不仅仅是AF_INET AF_INET6。
    复制商： # AF_INET6 blackhole ip -6 nexthop 添加 id 1 blackhole # 以 has_v4=false ip 分组 nexthop 添加 id 100 group 1 # 替换为 AF_INET（no -6），has_v4保持 false ip nexthop 替换 id 1 blackhole # 传递过时has_v4检查 ip -6 route add 2001：db8：：/64 nhid 100 # panic ping -6 2001：db8：：1 [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3 （CVE-2026-53012）

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

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

  - dm 缓存策略 smq：修复使缓存区块失效时缺少的锁定 在传递模式下，策略invalidate_mapping操作同时从多个工作线程调用，因此应通过锁定进行保护。否则，我们最终可能会在分配的块计数器上出现数据争用，或者在进行并发写入时，内部数据结构甚至出现释放后使用问题。请注意，smq_invalidate_mapping（） 中现有的 FIXME 不会影响传递模式，因为该模式不存在迁移任务，但如果支持在不重新加载目标的情况下通过暂停/恢复快速缩小设备，则需要注意。
    重现步骤：1. 创建一个包含 1024 个缓存条目的缓存设备 dmsetup 创建 cmeta --table 0 8192 linear /dev/sdc 0 dmsetup 创建 cdata --table 0 131072 linear /dev/sdc 8192 dmsetup 创建 corig
    --table 0 262144 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup 创建缓存 --table 0 262144 缓存 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2.填充缓存，并记录缓存区块的数量
    --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, /); 打印 a[1]}'） 3.将缓存重新加载到传递模式 dmsetup 暂停缓存 dmsetup 重新加载缓存 --table 0 262144 缓存 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 传递 smq 0 dmsetup 恢复缓存 4.写入透传缓存。通过设置 I/O 大小等于缓存块大小的多个作业，不同工作线程的缓存块会同时失效。fio --filename=/dev/mapper/cache --name=test
    --rw=randwrite --bs=64k \ --direct=1 --numjobs=2 --randrepeat=0 --size=64m 5.检查降级是否与缓存的区块计数相匹配。这些数字应该匹配，但可能会因数据争用而有所不同。nr_demoted=$(dmsetup status cache | awk '{print $12}') 回声 $nr_cached， $nr_demoted （CVE-2026-53062）

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

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

  - bpf：拒绝 bpf_prog_test_run_skb bpf_prog_test_run_skb（） 调用中的短 IPv4/IPv6 输入 首先 eth_type_trans（），然后使用 skb->protocol 初始化 sk 系列和地址字段以进行测试运行。对于 IPv4 和 IPv6 数据包，即使提供的测试输入仅包含以太网标头，其也可访问 ip_hdr（skb） 或 ipv6_hdr（skb）。如果以太网帧携带 IPv4/IPv6 EtherType，但 L3 标头太短，则提早拒绝输入。将 IPv4/IPv6 标头长度检查包括在现有协议交换机中，并在访问网络标头之前返回 -EINVAL。（CVE-2026-53074）

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

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

  - KVM：s390：pci：通过手动将索引与 sizeof（struct zpci_gaite） 相乘，修复因双倍缩放指针算术 kvm_s390_pci_aif_enable）、kvm_s390_pci_aif_disable（） 和 aen_host_forward（） 而导致的 GAIT 表索引。由于 aift->gait 已经是一个结构zpci_gaite指针，因此这将双倍缩放偏移量，访问元素 aisb*16 而不是 aisb。当 aisb >= 32（ZPCI_NR_DEVICES=512）时，会造成越界访问。通过删除错误的 sizeof 乘法进行修复。（CVE-2026-52968）

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

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

  - net/rds：将 RDS/IB 限制在初始网络命名空间内 阻止在初始命名空间以外的网络命名空间中使用 RDS/IB。现有 RDS/IB 代码将无法在非初始网络命名空间中正常工作。（CVE-2026-53077）

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

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

  - Rclone 是一个命令行程序，用于与不同的云存储提供商同步文件和目录。From 1.46.0 until 1.74.3， rclone rcd --rc-serve 接受针对以下形式的路径的未经认证的 GET 和 HEAD 请求：/[remote：path]/object。从 URL 解析远程值并将其传递到正常后端初始化。内联远程配置可设置在初始化期间执行本地命令的后端选项。因此，单个未经认证的 GET 或 HEAD 请求可以 rclone 进程用户的身份执行命令。此漏洞已在 1.74.3 中修复。(CVE-2026-49980)

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

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

  - dm cache：在传递模式下通过并发写修复 null-deref 在传递模式中，当 dm-cache 开始使缓存条目无效并且 bio prison cell 锁定因并发写入同一缓存块而失败时，mg->cell 仍为空。invalidate_complete（） 中的错误路径尝试无条件解锁和释放信元，从而导致空指针取消引用： KASAN：范围 [0x0000000000000000-0x0000000000000007] 中的 null-ptr-deref CPU：0 UID：0 PID：134 Comm：fio 未受感染 6.19.0-rc7 #3 PREEMPT RIP：0010：dm_cell_unlock_v2+0x3f/0x210 <snip> 调用跟踪：invalidate_complete+0xef/0x430 map_bio+0x130f/0x1a10 cache_map+0x320/0x6b0 __map_bio+0x458/0x510 dm_submit_bio+0x40e/0x16d0
    __submit_bio+0x419/0x870 <snip> 重现步骤：1. 创建缓存设备 dmsetup 创建 cmeta --table 0 8192 linear /dev/sdc 0 dmsetup 创建 cdata --table 0 131072 linear /dev/sdc 8192 dmsetup 创建 corig
    --table 0 262144 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup 创建缓存 --table 0 262144 缓存 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2.将第一个数据块升级到缓存 fio --filename=/dev/mapper/cache
    --name=populate --rw=write --bs=4k \ --direct=1 =64k --size3.将缓存重新加载到传递模式 dmsetup 暂停缓存 dmsetup 重新加载缓存 --table 0 262144 缓存 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 传递 smq 0 dmsetup 恢复缓存 4.同时写入第一个缓存区块 fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0
    --direct=1 --numjobs=2 --size 64k 通过在尝试解锁 mg->cell 是否有效进行修复。
    (CVE-2026-53064)

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

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

  - fs/ntfs3：修复 attr_data_get_block_locked（） 中缺失的 vcn0 运行负载 当压缩或稀疏属性的群集按帧对齐时，vcn 会使用 cmask 向下舍入到帧开头，这会导致 vcn ！= vcn0。在这种情况下，vcn 和 vcn0 可能位于不同的属性段中。此代码通过在分配之前加载 vcn 的运行，来处理 vcn 位于不同段的情况。
    但是，当 vcn0 驻留在与 vcn 不同的段时，无法为 vcn0 加载运行。这导致 run_lookup_entry（） 返回针对 vcn0 的SPARSE_LCN，因为其段从未加载到内存内运行列表，从而触发 WARN_ON（1）。通过在现有 vcn 段检查后添加缺少的 vcn0 检查来修复此问题。如果 vcn0 超出当前段范围 [svcn、evcn1），请在执行运行查找之前查找并加载包含 vcn0 的属性段。以下情况会触发该缺陷：
    attr_data_get_block_locked（） vcn = vcn0 &; cmask <- vcn ！= vcn0 帧对齐加载运行后，对 vcn 段运行 <- vcn0 段未加载！attr_allocate_clusters（） <- 分配成功 run_lookup_entry（vcn0） <- vcn0 not in run -> SPARSE_LCN WARN_ON（1） <- 此处会触发缺陷！（CVE-2026-53027）

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

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

  - fs/adfs：验证 adfs_validate_bblk（） 中的 nzones 在引导块验证期间，在使用光盘记录之前，拒绝区域计数为零的 ADFS 光盘记录。当 nzones 为 0 时，adfs_read_map（） 将其传递给 kmalloc_array（0， ...），后者返回 ZERO_SIZE_PTR，然后 adfs_map_layout（） 写入 dm[-1]，从而在分配的缓冲区之前造成越界写入。adfs_validate_dr0（） 已拒绝旧格式图像的 nzones ！= 1。针对新格式的图像向 adfs_validate_bblk（） 添加对等效检查，以便在探测时拒绝含有 nzones == 0 的特制图像。由 syzkaller 发现。（CVE-2026-52992）

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

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

  - net：usb：rtl8150：修复 rtl8150_start_xmit（） 中的释放后使用 在调用 usb_submit_urb（） 后访问 tx 统计数据的 skb->len 时，syzbot 报告 rtl8150_start_xmit（） 中存在 KASAN slab-use-after-free 读取： 缺陷：KASAN：在 rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c：712 在地址 ffff88810eb7a930 处，任务 kworker/0:4/5226 读取的大小为 4 URB 完成处理程序 write_bulk_callback（） 通过 dev_kfree_skb_irq（dev->tx_ 释放 skbskb）。在提交程序中返回 usb_submit_urb（） 之前，URB 可能会在 softirq 上下文中的另一个 CPU 上完成，因此当提交程序读取 skb->len 时，skb 已排入 per-CPU completion_queue队列，并由 net_tx_action（） 释放： CPU A （xmit） CPU B （USB completion softirq） ------------ ------------------------------ dev->tx_skb = skb;usb_submit_urb（） --+ |-------> write_bulk_callback（） |dev_kfree_skb_irq（dev->tx_skb） |net_tx_action（） |napi_skb_cache_put（） <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read Fix it by caching skb->len 在提交 URB 之前执行长度，并在更新 tx_bytes 计数器时使用缓存值。保留预先存在的tx_bytes语义：计数器跟踪原始帧长度 （skb->len），而不是传递给设备的 ETH_ZLEN/USB 对齐填充计数值。更改该更改将是用户可见的会计更改，此 UAF 补丁的范围。（CVE-2026-52982）

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

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

  - fs/fcntl：修复 fasync 信号中的 SOFTIRQ-unsafe 锁定顺序 当进程组收到信号时，send_sigio（） 和 send_sigurg（） 中可发生 SOFTIRQ-safe 到 SOFTIRQ-unsafe 锁定顺序死锁。为进程组 （PIDTYPE_PGID） 配置 FASYNC 时，这两个函数都使用 read_lock（&tasklist_lock） 遍历任务列表。但是，它们经常从 softirq 上下文中调用：- 通过 input_inject_event -> kill_fasync send_sigio（） - tcp_check_urg -> sk_send_sigurg send_sigurg（） （NET_RX_SOFTIRQ） 死锁是由 rwlock 编写器公平性机制造成：1. CPU 0（进程上下文）在 do_wait（） 中保留 read_lock（&tasklist_lock）。2. CPU 1（进程上下文）尝试在 fork（） 或 exit（） 中write_lock（&tasklist_lock）并旋转，这会阻断所有新阅读器。3. CPU 0 被 softirq 中断（例如，TCP URG 数据包接收）。4. softirq 调用 send_sigurg（） 并尝试获取 read_lock（&tasklist_lock），由于 CPU 1 正在等待而死锁。由于 PID 哈希和 do_each_pid_task（） 遍历已受到 RCU 保护，安全遍历不再严格要求 tasklist_lock 上的 read_lock。通过将 tasklist_lock 替换为 rcu_read_lock（） 来修复此问题，使进程群组信号路径与单 PID 路径保持一致。这也缓解了通过 TCP URG 数据包造成的潜在远程拒绝服务矢量。Lockdep splat：===================================================== 警告：
    SOFTIRQ-safe ->检测到 SOFTIRQ-unsafe 锁定顺序 [...]链存在：&dev->event_lock --> &f_owner->lock --> tasklist_lock 可能的中断不安全锁定情况：CPU0 CPU1 ---- ---- lock（tasklist_lock）;local_irq_disable（）;lock（&dev->event_lock）;lock（&f_owner->lock）; <Interrupt> lock（&dev->event_lock）;死锁 *** （CVE-2026-52946)

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

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

  - drm/msm/dpu：修复功率和频率之间的不匹配 在 DPU 运行时暂停期间，调用 dev_pm_opp_set_rate（dev， 0） 会使 MMCX 轨降至MIN_SVS，而核心时钟频率仍维持其原始（最高）速率。当运行时恢复重新启用时钟时，这可能导致轨电压和时钟速率之间不匹配。例如，在 DPU 绑定路径中，序列可以是：cpu0：
    dev_sync_state -> rpmhpd_sync_state cpu1：dpu_kms_hw_init时间线 0
    ------------------------------------------------> t rpmhpd_sync_state后，电压性能不再保证保持在最高水平。在dpu_kms_hw_init期间，调用 dev_pm_opp_set_rate（dev， 0） 会降低电压，从而导致 MMCX 轨在核心时钟仍处于最大频率时降至MIN_SVS。重新使能电源时，仅使能时钟，导致MMCX轨处于MIN_SVS，但核心时钟处于最高速率。在这种状态下，导轨无法维持时钟速率，可能导致不稳定或系统崩溃。从 dpu_runtime_suspend 中删除对 dev_pm_opp_set_rate（dev， 0） 的调用，以确保在恢复 DPU 时恢复正确的投票。拼布： https://patchwork.freedesktop.org/patch/710077/ （CVE-2026-53056）

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

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

  - i2c：dev：防止 I2C_TIMEOUT ioctl 中的整数溢出 在使用 Syzkaller 进行模糊测试时，观察到持续的“schedule_timeout：错误的超时值”警告，并伴随着 SMBus 控制器状态机损坏。I2C_TIMEOUT ioctl 接受用户提供的超时（单位为 10 毫秒的倍数）。系统会针对 INT_MAX 检查用户参数，但随后会在传递给 msecs_to_jiffies（） 之前将其乘以 10。恶意用户可传递通过“arg > INT_MAX”检查但在乘以 10 时溢出的大值（例如 429496729）。这导致截断的 32 位无符号值绕过“msecs_to_jiffies（）”中的内部“（int）m < 0”检查。然后将截断的值分配给“client->adapter->timeout”（已签名的 32 位 int），后者会将其重新解释为负数。传递到 wait_for_completion_timeout（） 时，此负值将符号扩展为 64 位无符号长整型，从而触发“schedule_timeout”警告并导致过早返回。这会使 SMBus 状态机处于不可恢复的状态，从而构成本地拒绝服务 （DoS）。通过将用户参数限定为“INT_MAX / 10”来修复此问题。[WSA：同时移动注释]（CVE-2026-52948）

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

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

  - net：qrtr：修复 qrtr_port_remove 中的引用计数饱和和潜在 UAF 在 qrtr_port_remove（） 中，从qrtr_ports XArray 中删除端口之前和 RCU 宽限期过去之前，套接字引用计数通过 __sock_put（） 递减。这打破了基本的 RCU 更新范式。它暴露一个争用窗口，其中并行 RCU 读取器（如 qrtr_reset_ports（） 或 qrtr_port_lookup（））可从 XArray 获取套接字的指针并尝试在引用计数已降至零的套接字上调用 sock_hold（）。syzkaller 模糊测试期间会发生确切的争用条件，从而导致以下引用计数饱和警告和潜在的释放后使用：refcount_t：饱和;泄漏内存。警告：CPU：3 PID：1273 at lib/refcount.c：22 refcount_warn_saturate+0xae/0x1d0 链接的模块：qrtr（+） bochs drm_shmem_helper ... 调用跟踪： <TASK> qrtr_reset_ports net/qrtr/af_qrtr.c：768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c：805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c：901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c：3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c：715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c：169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c：1283 ...</TASK> 通过将引用计数递减延迟到 xa_erase（） 和 synchronize_rcu（） 完成之后修复此问题。（注意：此修补程序的 v1 未正确将 __sock_put（） 替换为 sock_put（）。正如 Simon Horman 所指出，qrtr_port_remove（） 的调用程序仍保留对套接字的引用，因此此处释放套接字内存将导致调用程序中的后续 UAF。因此，保留了 __sock_put（），但只是为了结束 RCU 争用而重新定位。（CVE-2026-52947）

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

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

  - erofs：将 lcn 统一为 u64 对于 32 位平台 根据 sashiko 报告 [1]，“lcn”被键入为“unsigned long”（有时或“unsigned int”），这在 32 位平台上仅为 32 位宽，这导致“（lcn << lclusterbits）”在 4 GiB 处被截断。为了整合逻辑，只需在代码库周围一致地使用“u64”即可。[1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com(CVE-2026-53015）

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

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

  - bpf、sockmap：修复 proto 更新 unix_stream_connect（） af_unix在分配对等机 （'unix_peer（sk） = newsk'） 之前，设置sk_state （'WRITE_ONCE（sk->sk_state， TCP_ESTABLISHED）'） 中的 null-ptr-deref。
    sk_state == TCP_ESTABLISHED 使 sock_map_sk_state_allowed（） 相信套接字已正确设置，其中包括拥有已定义的对等机。IOW，有一个窗口期，可以在仍具有 unix_peer（sk） == NULL 的套接字上调用 unix_stream_bpf_update_proto（）。CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE（sk->sk_state， TCP_ESTABLISHED） sock_map_sk_state_allowed（sk） ...sk_pair = unix_peer（sk） sock_hold（sk_pair） sock_hold（newsk） smp_mb__after_atomic（） unix_peer（sk） = newsk 缺陷：内核空指针取消引用，地址：0000000000000080 RIP：0010：unix_stream_bpf_update_proto+0xa0/0x1b0 调用跟踪：
    sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240
    __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e 最初的想法是在 sk_state 更新之前 [1] 移动对等机分配，但这涉及额外的内存屏障，因此更改热路径被拒绝。然后考虑在 unix_stream_bpf_update_proto（） 的原型更新期间进行空检查[2]，但后续讨论[3]侧重于根本原因，即 sockmap 更新采用错误的锁定。或者，更具体地说，缺少 unix_state_lock（）[4]。最后得出的结论是，教授关于af_unix锁定的 sockmap 会不必要地复杂[5]。撇开复杂性不谈，由于允许 BPF_PROG_TYPE_SCHED_CLS 和 BPF_PROG_TYPE_SCHED_ACT 更新 sockmap，因此 sock_map_update_elem（） 采用 unix 锁定（如当前在 unix_state_lock（） 中实现的那样：spin_lock（&unix_sk（s）->lock））将是有问题的。
    unix_state_lock（），然后是尝试采用相同旋转锁的 softirq-context TC BPF 程序 -- 死锁 [6]。这样我们又回到了同伴检查的想法[2]。[1]:
    https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ [2]:
    https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/ [3]:
    https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/ [4]:
    https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/ [5]:
    https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/ [6]:
    https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/ af_unix/stream connect（） 可能争用 sockmap 更新的情况摘要：1. connect（） 与 bpf（BPF_MAP_UPDATE_ELEM），即
    sock_map_update_elem_sys（） 实现的空检查就足够了。一旦分配，套接字对等体将在释放套接字 fd 之前不会释放。这不是问题，因为 sock_map_update_elem_sys（） 会升级 fd refcnf。2. connect（） 与执行更新的 BPF 程序进行更新，按 verifier.c：may_update_sockmap（） 的更新限制为 BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER BPF_PROG_TYPE_SOCK_OPS（仅限 bpf_sock_map_update（）BPF_PROG_TYPE_SOCKET_FILTER BPF_PROG_TYPE_SCHED_CLS BPF_PROG_TYPE_SCHED_ACT BPF_PROG_TYPE_XDP BPF_PROG_TYPE_SK_REUSEPORT BPF_PROG_TYPE_FLOW_DISSECTOR BPF_PROG_TYPE_SK_LOOKUP 另外一个需要考虑的争用： CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE（sk->sk_state， TCP_ESTABLISHED） sock_map_sk_state_allowed（sk） sock_hold（newsk） smp_mb__after_atomic（） ---truncated--- （CVE-2026-53034）

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

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

  - ceph：修复 __ceph_build_xattrs_blob（） 中因过时 blob 大小而造成的BUG_ON generic/642 测试案例可重现内核崩溃：[40243.605254] ------------[ cut here ]------------ [40243.605956] fs/ceph/xattr.c：918！[40243.607142] 哎呀：无效操作码：0000 [#1] SMP PTI [40243.608067] CPU：7 UID：
    0 PID： 498762 Comm： kworker/7:1 未受感染 7.0.0-rc7+ #3 PREEMPT（full） [40243.609700] 硬件名称： QEMU Ubuntu 25.10 PC v2 （i440FX + PIIX， + 10.1 machine， 1996）， BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] 工作队列： ceph-msgr ceph_con_workfn [40243.612715] RIP：
    0010：__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] 代码： 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc <0f> cc 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP： 0018：ffffcc80c4d4b688 EFLAGS：00010287 [40243.617773] RAX：0000000000010026 RBX：0000000000000001 RCX：00000000000000000 [40243.618928] RDX：
    ffff8a773798dee0 RSI：00000000000000000 RDI：00000000000000000 [40243.620158] RBP：ffffcc80c4d4b6a0 R08：
    0000000000000000 ： 0000000000000000 [40243.621573] R10： 00000000000000000 R11： 000000000000000000 R12R09：
    ffff8a75f3b58000 [40243.622907] R13： ffff8a75f3b58000 R14： 0000000000000080 R15： 0000000000000bffd [40243.624054] FS：000000000000000（0000） GS：ffff8a787d1b4000（0000） knlGS：000000000000000 [40243.625331] CS：0010 DS：0000 ES：0000 CR0：0000000080050033 [40243.626269] CR2：000072f390b623c0 CR3：
    000000011c02a003 CR4： 00000000000372ef0 [40243.627408] 调用跟踪： [40243.627839] [40243.628188] <TASK>
    __prep_cap+0x3fd/0x4a0 [40243.628789] ？ do_raw_spin_unlock+0x4e/0xe0 [40243.629474] ceph_check_caps+0x46a/0xc80 [40243.630094] ？ __lock_acquire+0x4a2/0x2650 [40243.630773] ？ find_held_lock+0x31/0x90 [40243.631347] ？ handle_cap_grant+0x79f/0x1060 [40243.632068] ？ lock_release+0xd9/0x300 [40243.632696] ？ __mutex_unlock_slowpath+0x3e/0x340 [40243.633429] ？ lock_release+0xd9/0x300 [40243.634052] handle_cap_grant+0xcf6/0x1060 [40243.634745] ceph_handle_caps+0x122b/0x2110 [40243.635415] mds_dispatch+0x5bd/0x2160 [40243.636034] ？ ceph_con_process_message+0x65/0x190[40243.636828] ？ lock_release+0xd9/0x300 [40243.637431] ceph_con_process_message+0x7a/0x190 [40243.638184] ？ kfree+0x311/0x4f0 [40243.638749] ？ kfree+0x311/0x4f0 [40243.639268] process_message+0x16/0x1a0 [40243.639915] ？ sg_free_table+0x39/0x90 [40243.640572] ceph_con_v2_try_read+0xf58/0x2120 [40243.641255] ？ lock_acquire+0xc8/0x300 [40243.641863] ceph_con_workfn+0x151/0x820 [40243.642493] process_one_work+0x22f/0x630 [40243.643093] ？ process_one_work+0x254/0x630 [40243.643770] worker_thread+0x1e2/0x400 [40243.644332] ？
    __pfx_worker_thread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ？ __pfx_kthread+0x10/0x10 [40243.646125] ret_from_fork+0x3f8/0x480 [40243.646752] ？ __pfx_kthread+0x10/0x10 [40243.647316] ？
    __pfx_kthread+0x10/0x10 [40243.647919] ret_from_fork_asm+0x1a/0x30 [40243.648556] [] </TASK>40243.648902模块链接于： overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate 软盘 i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 00000000000000000 ]--- 提交 d93231a6bc8a（ceph：防止客户端超过 MDS 最大 xattr 大小）将 required_blob_size 计算移到 __build_xattrs（） 调用之前，从而引入争用。 __build_xattrs（） 在执行期间释放和重新获取i_ceph_lock。在该窗口中，handle_cap_grant（） 可能会使用更新的 MDS 提供的 blob 更新 i_xattrs.blob，并升级 i_xattrs.version。当__bui ---truncated--- （CVE-2026-52961）

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

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

  - KVM：拒绝 kvm_reset_dirty_gfn（） 中封装的偏移 kvm_reset_dirty_gfn（） 使用 if （！memslot ||（偏移 + __fls（掩码）） >= memslot->npages） 返回;但偏移量为 u64，并且未选中加法。u64 封装可静默地绕过此检查。在 vcpu fd 的KVM_DIRTY_LOG_PAGE_OFFSET处MAP_SHARED了支持这些条目的脏环，因此 VMM 可在内核推动它们和KVM_RESET_DIRTY_RINGS使用它们之间重写任何条目的槽和偏移字段。重置时，kvm_dirty_ring_reset（） 通过 READ_ONCE（） 重新读取值并将它们直接反馈回此检查;
    仅将标记握手视为切换，插槽/偏移负载以信任方式进行。构建两个条目 entry[i].offset = 0xffffffffffffffc1 entry[i+1].offset = 0 使 kvm_dirty_ring_reset（） 中的合并循环计算 delta = （s64）（0 - 0xffffffffffffffc1） = 63，这落在 [0， BITS_PER_LONG），因此它通过设置位 63 将 entry[i+1] 折叠到现有掩码中。尾随的 kvm_reset_dirty_gfn（） 调用随后会看到 offset = 0xffffffffffffffc1 和 __fls（mask） = 63;u64 中的总和为 0，边界检查通过。该偏移会原封不动地传播到 kvm_arch_mmu_enable_log_dirty_pt_masked（）。在旧的 MMU 路径（kvm_memslots_have_rmaps（） == true（即阴影分页、任何分配了影子根的 VM 或写入跟踪槽）上，它会到达 gfn_to_rmap（），后者会索引具有接近U64_MAX gfn 的 slot->arch.rmap[0][]。这是kvm_rmap_head的越界加载，然后是加载指针所指向的任何内容中的条件清除PT_WRITABLE_MASK。可从任何保留 /dev/kvm 的进程访问该路径。首先对其本身进行范围检查偏移，因此加法不能换行。
    memslot->npages 的边界远低于 U64_MAX，因此一旦 npages <偏移成立，偏移 + __fls（掩码）（使用
    __fls（掩码） < BITS_PER_LONG） 保持在范围内。（CVE-2026-52969）

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

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

  - af_unix：终止 SOCKMAP 的所有 SCM 属性。SOCKMAP 可隐藏 AF_UNIX GC 的 inflight fd。当 SOCKMAP 中的套接字接收到具有 inflight fd 的 skb 时，sk_psock_verdict_data_ready（） 会查找映射的套接字并将 skb 排队到其 psock->ingress_skb。由于新旧 GC 都无法检查 psock 队列，因此隐藏的 skb 会泄露飞行套接字。请注意，这无法通过 kmemleak 检测，因为飞行套接字链接到全局列表。此外，SOCKMAP 重定向打破了基于 Tarjan 的 GC 的假设，即 unix_edge.successor 始终处于活动状态，这一假设在重定向 skb 后就不再成立，导致下面的释放后使用。[0] 此外，SOCKMAP 不会正确调用 scm_stat_del（），因此 unix_show_fdinfo（） 可能报告不正确的 fd 计数。sk_msg_recvmsg（） 首先不支持任何 SCM 属性。让我们在将 skb 传递到 SOCKMAP 层之前删除所有 SCM 属性。[0]：缺陷：KASAN：unix_del_edges 中的 slab-use-after-free （net/unix/garbage.c：118 net/unix/garbage.c：181 net/unix/garbage.c：251） 在 addr ffff888125362670 处按任务 kworker/56:1/496 读取大小为 8 CPU：56 UID：0 PID：496 Comm：kworker/56:1 未受感染 7.0.0-rc7-00263-gb9d8b856689d #3 PREEMPT（lazy） 硬件名称： QEMU Standard PC （i440FX + PIIX， 1996）， BIOS 1.17.0-debian-1.17.0-1 04/01/2014 工作队列： 事件sk_psock_backlog调用跟踪： <TASK> dump_stack_lvl （lib/dump_stack.c：122） print_report （mm/kasan/report.c：379） kasan_report （mm/kasan/report.c：597） unix_del_edges （net/unix/garbage.c：118 net/unix/garbage.c：181 net/unix/garbage.c：251） unix_destroy_fpl （net/unix/garbage.c：317） unix_destruct_scm （./include/net/scm.h：80 ./include/net/scm.h：86 net/unix/af_unix.c：1976） sk_psock_backlog （./include/linux/skbuff.h：?)process_scheduled_works （kernel/workqueue.c：？） worker_thread （kernel/workqueue.c：？） kthread （kernel/kthread.c：438） ret_from_fork （arch/x86/kernel/process.c：164） ret_from_fork_asm （arch/x86/entry/entry_64.S：258） </TASK> 按任务 955 分配：kasan_save_track （mm/kasan/common.c：58 mm/kasan/common.c：78） __kasan_slab_alloc （mm/kasan/common.c：369） kmem_cache_alloc_noprof （mm/slub.c：4539） sk_prot_alloc （net/core/sock.c：2240） sk_alloc （net/core/sock.c：2301） unix_create1 （net/unix/af_unix.c：1099） unix_create （net/unix/af_unix.c：1169）
    __sock_create （net/socket.c：1606） __sys_socketpair （net/socket.c：1811） __x64_sys_socketpair （net/socket.c：1863 net/socket.c：1860 net/socket.c：1860） do_syscall_64 （arch/x86/entry/syscall_64.c：？） entry_SYSCALL_64_after_hwframe （arch/x86/entry/entry_64.S：130） 由任务 496 释放：kasan_save_track （mm/kasan/common.c：58 mm/kasan/common.c：78） kasan_save_free_info （mm/kasan/generic.c：587）
    __kasan_slab_free （mm/kasan/common.c：287） kmem_cache_free （mm/slub.c：6165） __sk_destruct （net/core/sock.c：2282 net/core/sock.c：2384） sk_psock_destroy （./include/net/sock.h：？） process_scheduled_works （kernel/workqueue.c：？） worker_thread （kernel/workqueue.c：？） kthread （kernel/kthread.c：438） ret_from_fork （arch/x86/kernel/process.c：164） ret_from_fork_asm （arch/x86/entry/entry_64.S：258） （CVE-2026-53005）

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

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

  - platform/x86：dell-wmi-sysman：边界枚举字符串聚合 populate_enum_data（） 将固件提供的值修饰符和可能值字符串聚合到固定的 512 字节结构成员中。当前代码会限制每个来源字符串，但随后会以原始 strcat（） 附加每个字符串和分隔符，且不会检查剩余空间。将聚合循环切换到有界的附加帮助程序，并拒绝其组合字符串不适合目标缓冲区的枚举程序包。[ij：添加包含]（CVE-2026-53022）

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

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

  - dm cache：修复传递模式切换中的脏映射检查 如提交 9b1cc9f251af（dm cache：在非活动和活动 DM 表之间共享 cache-metadata 对象）中所述，dm-cache 假设在暂停之后会重新加载表，而 LVM 的表预加载打破了此假设。针对传递模式的脏映射检查是围绕此假设而设计的，并在表创建期间执行，从而导致检查因预加载而失败，而元数据更新仍在进行中。这样可能会将脏映射加载到传递模式，从而导致数据丢失。重现步骤：1. 使用零migration_threshold创建用于生成脏映射的回写缓存 dmsetup 创建 cmeta --table 0 8192 linear /dev/sdc 0 dmsetup 创建 cdata --table 0 131072 linear /dev/sdc 8192 dmsetup 创建 corig --table 0 262144 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup 创建缓存
    --table 0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \ 2 migration_threshold 0 2.在传递模式下预加载一个表 dmsetup 重新加载缓存 --table 0 262144缓存 /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 传递 smq 0 3.
    写入首个缓存块以使其变脏 fio --filename=/dev/mapper/cache --name=populate
    --rw=write --bs=4k \ --direct=1 --size=64k 4.恢复不活动的表。现在可以加载脏块进入传递模式。dmsetup 恢复缓存 通过将检查移到预恢复阶段来修复，以支持表预加载。同时删除未使用的函数dm_cache_metadata_all_clean。（CVE-2026-53061）

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

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

  - ppp：需要在未附加的 ioctl 的目标 netns 中进行CAP_NET_ADMIN 当前授权 /dev/ppp open 可用于 file->f_cred->user_ns，而未附加的管理 ioctl 可在 current->nsproxy->net_ns 上操作。
    因此，本地非特权用户可以CLONE_NEWUSER创建新的用户命名空间，仅获取该新用户命名空间中的CAP_NET_ADMIN，并且仍然针对继承的网络命名空间发出 PPPIOCNEWUNIT、PPPIOCATTACH 或 PPPIOCATTCHAN。要求在拥有目标网络命名空间的用户命名空间中进行CAP_NET_ADMIN，然后才能处理未附加的 PPP 管理 ioctl。这会在其实际获得特权的网络命名空间中保留正常的 pppd 操作，同时拒绝仅限 userns-inherited-netns 的情况。（CVE-2026-53075）

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

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

  - scsi：target：core：修复 UNMAP 边界检查中的整数溢出 sbc_execute_unmap（） 检查 LBA + 范围不超过设备容量，但不能防止 64 位溢出时的 LBA + 范围回绕。
    添加与已用于同一文件中的WRITE_SAME模式的溢出检查。（CVE-2026-53021）

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

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

  - block：修复区域重新验证错误路径上的zones_cond内存泄漏 当 blk_revalidate_disk_zones（） 在 disk_revalidate_zone_resources（） 分配args.zones_cond后失败时，内存将发生泄漏，因为没有错误路径可以释放内存。（CVE-2026-53127）

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

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

  - netfilter：nft_ct：修复 obj eval 中缺失的期望 nft_ct_expect_obj_eval（） 分配一个期望并可能调用 nf_ct_expect_related（），但从不丢弃其本地引用。返回到余额分配之前添加 nf_ct_expect_put（exp）。（CVE-2026-52970）

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

ID	名称	严重性
322664	Linux Distros 未修补的漏洞：CVE-2026-52974	high
322663	Linux Distros 未修补的漏洞：CVE-2026-53003	high
322662	Linux Distros 未修补的漏洞：CVE-2026-53068	high
322661	Linux Distros 未修补的漏洞：CVE-2026-53059	high
322660	Linux Distros 未修补的漏洞：CVE-2026-53066	medium
322659	Linux Distros 未修补的漏洞：CVE-2026-53004	high
322658	Linux Distros 未修补的漏洞：CVE-2026-52977	medium
322657	Linux Distros 未修补的漏洞：CVE-2026-52953	high
322656	Linux Distros 未修补的漏洞：CVE-2026-56370	medium
322655	Linux Distros 未修补的漏洞：CVE-2026-53002	high
322654	Linux Distros 未修补的漏洞：CVE-2026-53069	high
322653	Linux Distros 未修补的漏洞：CVE-2026-53046	critical
322652	Linux Distros 未修补的漏洞：CVE-2026-52995	medium
322651	Linux Distros 未修补的漏洞：CVE-2026-53049	critical
322650	Linux Distros 未修补的漏洞：CVE-2026-53117	high
322649	Linux Distros 未修补的漏洞：CVE-2026-54904	high
322648	Linux Distros 未修补的漏洞：CVE-2026-53103	medium
322647	Linux Distros 未修补的漏洞：CVE-2026-52962	high
322646	Linux Distros 未修补的漏洞：CVE-2026-53106	medium
322645	Linux Distros 未修补的漏洞：CVE-2026-53017	medium
322644	Linux Distros 未修补的漏洞：CVE-2026-53035	medium
322643	Linux Distros 未修补的漏洞：CVE-2026-53050	high
322642	Linux Distros 未修补的漏洞：CVE-2026-53112	high
322641	Linux Distros 未修补的漏洞：CVE-2026-52988	high
322640	Linux Distros 未修补的漏洞：CVE-2026-53076	high
322639	Linux Distros 未修补的漏洞：CVE-2026-53012	medium
322638	Linux Distros 未修补的漏洞：CVE-2026-53062	high
322637	Linux Distros 未修补的漏洞：CVE-2026-53074	medium
322636	Linux Distros 未修补的漏洞：CVE-2026-52968	high
322635	Linux Distros 未修补的漏洞：CVE-2026-53077	high
322634	Linux Distros 未修补的漏洞：CVE-2026-49980	critical
322633	Linux Distros 未修补的漏洞：CVE-2026-53064	medium
322632	Linux Distros 未修补的漏洞：CVE-2026-53027	medium
322631	Linux Distros 未修补的漏洞：CVE-2026-52992	high
322630	Linux Distros 未修补的漏洞：CVE-2026-52982	critical
322629	Linux Distros 未修补的漏洞：CVE-2026-52946	high
322628	Linux Distros 未修补的漏洞：CVE-2026-53056	medium
322627	Linux Distros 未修补的漏洞：CVE-2026-52948	medium
322626	Linux Distros 未修补的漏洞：CVE-2026-52947	high
322625	Linux Distros 未修补的漏洞：CVE-2026-53015	medium
322624	Linux Distros 未修补的漏洞：CVE-2026-53034	medium
322623	Linux Distros 未修补的漏洞：CVE-2026-52961	medium
322622	Linux Distros 未修补的漏洞：CVE-2026-52969	high
322621	Linux Distros 未修补的漏洞：CVE-2026-53005	high
322620	Linux Distros 未修补的漏洞：CVE-2026-53022	medium
322619	Linux Distros 未修补的漏洞：CVE-2026-53061	medium
322618	Linux Distros 未修补的漏洞：CVE-2026-53075	high
322617	Linux Distros 未修补的漏洞：CVE-2026-53021	medium
322616	Linux Distros 未修补的漏洞：CVE-2026-53127	medium
322615	Linux Distros 未修补的漏洞：CVE-2026-52970	medium

检测

Nessus 的 Misc. 系列

high

high

high

high

medium

high

medium

high

medium

high

high

critical

medium

critical

high

high

medium

high

medium

medium

medium

high

high

high

high

medium

high

medium

high

high

critical

medium

medium

high

critical

high

medium

medium

high

medium

medium

medium

high

high

medium

medium

high

medium

medium

medium