Docker Desktop 的版本低于 4.54.0。因此会受到数据泄露漏洞的影响。
据发现，由于对象序列化错误问题，Docker Desktop 诊断包中含有过期的 Hub PAT。这会造成导出诊断中存在敏感信息泄漏的风险，尤其是在发生访问被拒错误的情况下。(CVE-2025-13743)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

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

  - Grassroot DICOM 的 JPEGBITSCodec::InternalCode 功能中存在一个越界读取漏洞 3.024。特别构建的 DICOM 文件可导致信息泄漏。攻击者可提供恶意文件以触发此漏洞。系统会根据指定图像像素数据预期解释的恶意 DICOM 文件的值调用函数“null_convert”(CVE-2025-53619)

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

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

  - 在 PHP 8.1.34之前版本8.1.*、 8.2之前的 8.2.30] .*、 8.3之前的 8.3.29.*、 8.4之前的 8.4.16.*、 8.5之前的 8.5.1.* 中getimagesize() 函数可能当以多区块模式读取图像例如通过 php://filter时将未初始化的堆内存泄漏到 APPn 段例如 APP1中。出现此问题的原因是 php_read_stream_all_chunks() 中存在一个缺陷其会在不推进指针的情况下覆盖缓冲区从而使尾部字节保持未初始化。这可能导致敏感堆数据的信息泄露并影响目标服务器的机密性。 (CVE-2025-14177)

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

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

  - PyMdown Extensions 是“Python-Markdown” markdown 项目的一组扩展。 10.16.1 之前的版本在图形标题扩展中发现一个 ReDOS 缺陷`pymdownx.blocks.caption`。在采用未经检查的用户内容的系统中如果构建了恶意负载这可在处理数据时造成长时间的挂起。此问题已在版本 10.16.1中修补。作为变通方案如果在没有超时或其他保障措施的情况下处理未知用户内容则此类用户可在能够升级之前避免使用“pymdownx.blocks.caption”。
    (CVE-2025-68142)

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

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

  - Grassroot DICOM 的 JPEGBITSCodec::InternalCode 功能中存在一个越界读取漏洞 3.024。特别构建的 DICOM 文件可导致信息泄漏。攻击者可提供恶意文件以触发此漏洞。会根据指定图像像素数据预期解释的恶意 DICOM 文件的值调用函数“grayscale_convert”(CVE-2025-53618)

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

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

  - mptcp修复 mptcp_pm_nl_rm_addr 中的地址删除逻辑 修复阻止地址删除计数器正常更新的反向 WARN_ON_ONCE 条件。当前代码仅在计数器为 0异常状态时才执行递减逻辑而正常删除操作计数器 > 0会被忽略。 (CVE-2025-68221)

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

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

  - PHP 版本中低于 [] 8.1.34的 [ 8.1.* 、低于 8.2.308.2的 8.3[] .* 、低于 的  .* 8.3.29、低于 的 8.48.5.* 8.4.16、低于 8.5.1 [] 的 PDO PostgreSQL 驱动程序时  .*启用 PDO::ATTR_EMULATE_PREPARES 时预处理语句参数中的无效字符序列例如 \x99可能导致引用函数 PQescapeStringConn 返回 NULL从而导致 pdo_parse_params() 函数中发生空指针取消引用。
    这可能导致崩溃分段错误并影响目标服务器的可用性。
    (CVE-2025-14180)

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

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

  - Netty 是一个异步、事件驱动的网络应用程序框架。在 4.1.129.Final 和 4.2.8.Final 之前的版本中“io.netty.handler.codec.http.HttpRequestEncoder”在构建请求时会以请求 URI 进行 CRLF 注入。这会导致在未正确审查 URI 的情况下使用“HttpRequestEncoder”时发生请求走私。任何使用 `HttpRequestEncoder` 的应用程序/框架都可能受到滥用，以使用 CRLF 注入执行请求走私。版本 4.1.129.Final 和 4.2.8.Final 修复此问题。 (CVE-2025-67735)

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

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

  - 应用程序捆绑的解释器 (Python) 继承了用户授予主应用程序捆绑的透明、同意和控制 (TCC) 权限时存在身份验证绕过漏洞通过直接执行捆绑的解释器攻击者的脚本以应用程序的 权限运行TCC 权限 在已修复的版本中父限制用于仅允许主应用程序通过这些权限启动解释器此问题影响 macOS 上的 LibreOffice从 之前的 25.2 < 25.2.4。 (CVE-2025-14714)

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

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

  - Grassroot DICOM 的 RLECodec::DecodeByStreams 功能中存在一个越界读取漏洞 3.024。特别构建的 DICOM 文件可导致堆数据泄漏。攻击者可提供恶意路径来触发此漏洞。(CVE-2025-48429)

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

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

  - 在 PHP 8.1.34之前的 8.1.*、 8.2之前的 8.2.30] .*、 8.3之前的 8.3.29.*、 8.4之前的 8.4.16] .*、 8.5之前的 8.5.1.* 中打包数组的总元素计数超过 32 位限制或 HT_MAX_SIZE 时由于使用 zend_hash_num_elements() 预先计算元素计数时的整数溢出而导致 array_merge()。这可能会导致内存损坏或崩溃，并影响目标服务器的完整性和可用性。 (CVE-2025-14178)

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

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

  - Spip 4.1.10 包含一个文件上传漏洞允许攻击者上传带有嵌入式外部链接的恶意 SVG 文件。攻击者可诱骗管理员点击构建的 SVG 徽标该徽标会通过不正确的文件上传筛选重定向至可能存在危险的 URL。 (CVE-2023-53900)

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

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

  - Grassroot DICOM 的 Overlay::GrabOverlayFromPixelData 功能存在一个越界读取漏洞 3.024。特别构建的 DICOM 文件可导致信息泄漏。攻击者可提供恶意路径来触发此漏洞。(CVE-2025-52582)

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

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

  - Eclipse Paho Go MQTT v3.1 库 (paho.mqtt.golang) 版本 <= 中存在1.5.0 如果字符串的长度超过 65535 字节则可能对传递到库中的 UTF-8 编码字符串进行错误编码。这可能导致数据包中的非预期内容发送到服务器例如部分 MQTT 主题可能泄漏到 PUBLISH 数据包的消息正文中。出现此问题的原因是在未检查溢出的情况下将传入的数据长度从 int64/int32取决于 CPU转换为 int16。然后写入 int16 长度，然后再写入数据（例如主题）。这意味着当数据（例如主题）超过 65535 字节时，写入的数据量将超过长度字段指示的数量。这可能导致数据包损坏或者意味着过量数据泄漏到其他字段例如主题泄漏到消息正文。 (CVE-2025-10543)

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

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

  - smb客户端修复 cfids_invalidation_worker() 中不完整的向后移植 上一个提交 bdb596ceb4b7 (smb客户端修复 smb2_close_cached_fid() 中潜在的 UAF)是不完整的向后移植错过了 cfids_invalidation_worker() 中的一个本应转换为 的 kref_put() 调用close_cached_dir()。
    (CVE-2025-68226)

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

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

  - wifiiwlwifi修复 iwl_mld_remove_link() 中潜在的释放后使用 此代码通过调用 kfree_rcu(link, rcu_head) 释放链接然后取消引用链接以获取 link->fw_id。先保存 link->fw_id 以避免潜在的释放后使用。 (CVE-2025-68182)

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

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

  - net/smc修复 __smc_diag_dump 中的一般保护错误syzbot 报告崩溃错误一般保护错误可能针对非规范地址 0xfbd5a5d5a0000003: 0000 [#1] SMP KASAN NOPTI KASAN
    可能在范围 [0xdead4ead00000018-0xdead4ead0000001f] CPU: 1 UID: 0 PID: 6949 Comm
    syz.0.335 未受感染 syzkaller #0 PREEMPT(full) 硬件名称Google Compute Engine/Google Compute Engine、BIOS Google 08/18/2025 RIP: 0010:smc_diag_msg_common_fill net/smc/smc_diag.c:44 [inline] RIP
    0010:__smc_diag_dump.constprop.0+0x3ca/0x2550 net/smc/smc_diag.c:89 调用跟踪 <TASK> smc_diag_dump_proto+0x26d/0x420 net/smc/smc_diag.c:217 smc_diag_dump+0x27/0x90 net/smc/smc_diag. c:234 netlink_dump+0x539/0xd30 net/netlink/af_netlink.c:2327 __netlink_dump_start+0x6d6/0x990 net/netlink/af_netlink.c:2442 netlink_dump_start include/linux/netlink.h:341 [inline] smc_diag_handler_dump+0x1f9/0x240 net /smc/smc_diag.c:251 __sock_diag_cmd net/core/sock_diag.c:249 [inline] sock_diag_rcv_msg+0x438/0x790 net/core/sock_diag.c:285 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [内联] netlink_unicast+0x5a7/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [内联] __sock_sendmsg net/socket.c:729 [内联]____sys_sendmsg+0xa95/0xc70 net/socket.c:2614 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2668
    __sys_sendmsg+0x16d/0x220 net/socket.c:2700 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 该过程如下所示(CPU2) ----------------------------------|------------- ------------------ inet_create() | | // 将 clcsock 初始化为 NULL | | sk = sk_alloc() | sk_alloc() | sk_alloc() | sk_alloc() | sk_alloc() | // 意外更改 clcsock | inet_init_csk_locks() | inet_init_csk_locks() | inet_init_csk_locks() | inet_init_csk_locks() | | // 将 sk 添加到哈希表 | smc_inet_init_sock() | smc_inet_init_sock() | smc_inet_init_sock() smc_sk_init() | smc_sk_init() | smc_sk_init() | smc_sk_init() | smc_sk_init() smc_hash_sk() | smc_hash_sk() | smc_hash_sk() | smc_hash_sk() | smc_hash_sk() | | // 遍历哈希表 | smc_diag_dump_proto | smc_diag_dump_proto __smc_diag_dump() | | // 访问错误的 clcsock | smc_diag_msg_common_fill() // alloc clcsock | smc_diag_msg_common_fill() smc_create_clcsk| sock_create_kern | sock_create_kern由于 CONFIG_DEBUG_LOCK_ALLOC=yinet_init_csk_locks() 中的 smc->clcsock 会意外更改。smc 不需要 INET_PROTOSW_ICSK标记只需将其删除。删除 INET_PROTOSW_ICSK 标记后此修补程序也可以恢复提交 6fd27ea183c2 (net/smc修复 IPPROTO_SMC 的 icsk_syn_mss 缺少问题)以避免将 smc_sock 转换为 inet_connection_sock。 (CVE-2025-40357)

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

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

  - bnxt_en修复了 bnxt_bs_trace_check_wrap() 中的空指针取消引用。使用较旧的固件时我们可能会获得尚未初始化的固件跟踪数据类型的 ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER。这将导致 bnxt_bs_trace_type_wrap() 中的崩溃。添加防护以在继续操作之前检查有效的 magic_byte 指针。 (CVE-2025-68197)

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

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

  - arch_topology修复 topology_parse_cpu_capacity() 中不正确的错误检查。修复 topology_parse_cpu_capacity() 中未正确使用 PTR_ERR_OR_ZERO()此问题导致代码以空时钟指针继续进行。当前逻辑使用的 !PTR_ERR_OR_ZERO(cpu_clk) 对于有效指针和 NULL 值均为 true从而导致 clk_get_rate() 中可能发生空指针取消引用。根据 include/linux/err.h 文档PTR_ERR_OR_ZERO(ptr) 返回 @ptr 中的错误代码如果它是错误指针则为 0。这意味着 PTR_ERR_OR_ZERO() 会为有效指针和空指针返回 0。因此当 cpu_clk 为 valid 或为 NULL 时 !PTR_ERR_OR_ZERO(cpu_clk) 评估为 true (proceed)从而导致在 of_clk_get() 返回 NULL 时调用 clk_get_rate(NULL)。替换为 !IS_ERR_OR_NULL(cpu_clk)后者仅对有效指针进行操作从而防止 clk_get_rate() 中可能发生的空指针取消引用。
    (CVE-2025-40346)

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

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

  - drm/plane修复 create_in_format_blob() 返回值 create_in_format_blob() 应该返回有效指针或错误但从不返回 NULL。非错误时调用程序将取消引用 blob因此如果返回 NULL也会 oops。在失败的情况下返回正确的错误值。 (CVE-2025-68228)

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

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

  - slab避免 alloc_slab_obj_exts 中的 slab->obj_exts 发生争用如果两个竞争线程进入 alloc_slab_obj_exts()且其中一个线程未能分配对象扩展向量则其可能用 OBJEXTS_ALLOC_FAIL 替代另一个线程分配的有效 slab->obj_exts。这将导致丢失此争用并预期有效指针的线程稍后取消引用空指针。使用 cmpxchg() 以原子方式更新 slab->obj_exts以避免争用线程造成 slab->obj_exts 替代。感谢 Vlastimil 和 Suren 提供的调试帮助。 (CVE-2025-40348)

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

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

  - mptcp修复 BPF 的 proto 回退检测 sockmap 功能允许来自用户空间的 bpf syscall或者基于 bpf sockops的 bpf syscall从而在使用 sockmap 的自定义读取/写入接口进行协议堆栈处理期间替换套接字的 sk_prot。 ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== 调用 bpf 帮助程序 tcp_bpf_update_proto() <== 当 TCP 服务器 MP 已启用“”时客户端发送无 MPTCP 的 TCP SYNsubflow_syn_recv_sock() 在子流上执行回退从而将子流 sk 的 sk_prot 替换为本机 sk_prot。 ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() '''则此子流可正常由 sockmap 使用以 sockmap 的自定义 sk_prot 替换本机 sk_prot。当用户执行 accept::mptcp_stream_accept::mptcp_fallback_tcp_ops() 时会发生此问题。此处它使用 sk->sk_prot 与本机 sk_prot 进行比较但在使用 sockmap 时这是不正确的因为我们可能错误地设置 sk->sk_socket->ops。
    此修复转而使用更通用的 sk_family 进行比较。此外这也可防止发生警告来自 ./scripts/decode_stacktrace.sh 的结果------------[在此剪切]------------ 警告CPU0 PID337 at net/mptcp/protocol.c:68 mptcp_stream_accept \ (net/mptcp/protocol.c:4005) 模块中链接了PKRU: 55555554 调用跟踪 <TASK> do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86) /entry/syscall_64.c:41) 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:130) RIP
    0033:0x7f87ac92b83d ---[结束跟踪 0000000000000000 ]--- (CVE-2025-68227)

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

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

  - drm/amd/display执行 LT 自动化时缓存流瞄准 link [原因] 最新的 LT 自动化更新可通过引用 current_state 和调用 dc_update_planes_and_stream 造成崩溃进而可能破坏 current_state。[HOW] 缓存相关流指针并对其进行迭代而不是依赖于 current_state。 (CVE-2025-68196)

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

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

  - io_uring/net确保矢量化缓冲区节点导入与通知相关联。在添加对矢量化已注册缓冲区的支持时导入本身使用“req”而非通知 io_kiocb, sr->notif。对于非矢量导入正确使用 sr->notif。这很重要，因为两者的生命周期可能不同。将正确的 io_kiocb 用于矢量缓冲区导入。 (CVE-2025-68294)

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

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

  - fs修复 statmount_string() 中未初始化的“offp”。在 statmount_string() 中大多数标记会分配一个输出偏移指针 (offp)该指针稍后会使用字符串偏移进行更新。但是STATMOUNT_MNT_UIDMAP 和 STATMOUNT_MNT_GIDMAP 情况会直接设置结构字段而不是使用 offp。这会使 offp 保持未初始化状态从而导致在更新 *offp 时可能出现未初始化的取消引用。通过也为 UIDMAP 和 GIDMAP 分配 offp 来修复此问题从而保持代码路径的一致性。 (CVE-2025-68212)

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

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

  - netenetc修复 enetc_mdio_lock 的死锁 在应用 err050089 的变通方案之后LS1028A 平台会在 RT 内核上遇到 RCU 停止。此问题是由递归获取读取锁定 enetc_mdio_lock 造成的。下列列出了在 enetc_poll 路径下识别出的可能会导致死锁的一些调用堆栈enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdio 在 enetc_poll 获取读取锁定高优先级的写入器尝试获取锁定造成抢占。写入器检测到已保留读取锁定并将其排 除。
    但是 enetc_poll 下的读取程序无法再次获取读取锁定因为写入程序已在等待这导致线程挂起。目前可通过调整 enetc_lock_mdio 以防止递归锁定获取来避免死锁。 (CVE-2025-40347)

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

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

  - ksm使用 range-walk 函数跳过 scan_get_next_rmap_item 中的漏洞 当前scan_get_next_rmap_item() 会遍历 VMA 中的每个页面地址以定位可合并的页面。在扫描大部分包含未映射区域的大型虚拟内存区域时该操作的效率变得非常低下从而导致 ksmd 使用大量的 cpu 而没有对太多页面进行重复数据删除操作。此修补程序将按照地址的查找替换为使用 walk_page_range() 的范围遍历。range walker 可让 KSM 跳过 VMA 中整个未映射的漏洞，从而避免不必要的查找。之前的 [1] 中讨论了此问题。考虑以下测试程序其在虚拟地址空间中创建 32 TiB 映射但仅填充一个页面：
    #include <unistd.h> #include <stdio.h> #include<sys/mman.h> /* 32 TiB */ const size_t size = 32ul * 1024
    * 1024 * 1024 * 1024 int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror(mmap() failed\n);返回 -1 /* 填充单个页面以便获得 anon_vma。 */ *area = 0; /* 启用 KSM。 */ madvise(area, size, MADV_MERGEABLE); pause(); return 0 } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run 如果没有此修补程序ksmd 会长时间使用 100% 的 cpu在我的测试计算机中超过 1 小时扫描所有 32 个内核仅包含一个映射页面的 TiB 虚拟地址空间。这使得 ksmd 本质上死锁无法删除任何重要的重复数据。通过此修补程序ksmd 仅遍历一个映射的页面并跳过 32 TiB 虚拟地址空间的其余部分从而使用少量 cpu 实现快速扫描。 (CVE-2025-68211)

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

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

  - codetagdebug处理 slabobj_ext 的 mark_objexts_empty 中的现有 CODETAG_EMPTY 当 alloc_slab_obj_exts() 分配 slab 扩展向量时失败且稍后成功时会调用 handle_failed_objexts_alloc() 以将向量中的所有对象标记为空。因此此 slab (slabA) 中的所有对象的扩展都将设为 CODETAG_EMPTY。稍后如果此 slabA 用于为另一个 slab (slabB) 分配 slabobj_ext 向量则 slabB->obj_exts 指向本身具有等于 CODETAG_EMPTY 的非空 slabobj_ext 的 slabB->obj_exts 即可结束。释放 slabB 时会调用 free_slab_obj_exts() 以释放 slabB->obj_exts 向量。 free_slab_obj_exts() 调用 mark_objexts_empty(slabB->obj_exts) 其将生成警告因为其预期 slabobj_ext 矢量含有空 obj_ext而非 CODETAG_EMPTY。修改 mark_objexts_empty() 以跳过警告并设置 obj_ext 值如果已设置为 CODETAG_EMPTY。为了快速检测此 WARN，我将代码从 WARN_ON(slab_exts[offs].ref.ct) 修改为 BUG_ON(slab_exts[offs].ref.ct == 1);然后我们收到此消息
    [21630.898561] ------------[ 在此处切换 ]------------ [21630.898596] mm/slub.c:2050! 的内核缺陷[21630.898611] 内部错误Oops - BUG: 00000000f2000800 [#1] SMP [21630.900372] 模块中链接的位置
    squashfs isofs vfio_iommu_type1 vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi net_failover virtio_console failover virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject] [21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process- m Kdump
    21630.911625已加载受感染的 GW 6.18.021630.910867- rc1+ #74 PREEMPT(21630.910495设80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [21630.912392] pc __free_slab+0x228/0x250 [21630.912868] lr
    __free_slab+0x18c/0x250[21630.913334] sp ffff8000a02f73e0 [21630.913830] x29ffff8000a02f73e0 x28
    ffffdffc43fc800 x27ffff0000c0011c40 [21630.914677] x26ffff0000c000cac0 x25ffff00010fe5e5f0 x24
    ffff000102199b40 [21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21: ffff0000c0011c40 [21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18: 0000000000000000 [21630.917048] x17:
    0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [21630.917837] x14: 0000000000000000 x13:
    0000000000000000 x12ffff70001405ee66 [21630.918640] x111ffff0001405ee65 x10ffff70001405ee65 x9
    ffff800080a295dc [21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 : 0000000000003000 [21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 : 0000000000000007 [21630.921021] x2 :
    0000000000001b40 x1 : 000000000000001f x0 : 0000000000000001 [21630.921810] 调用跟踪 [21630.922130]
    __free_slab+0x228/0x250 (P) [21630.922669] free_slab+0x38/0x118 [21630.923079] free_to_partial_list+0x1d4/0x340 [21630.923591] __slab_free+0x24c/0x348 [21630.924024]
    ___cache_free+0xf0/0x110 [21630.924468] qlist_free_all+0x78/0x130 [21630.924922] kasan_quarantine_reduce+0x11 ---truncated--- (CVE-2025-68199)

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

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

  - medianxpimx8-isi修复版本上的流清理 当前实现无条件调用 mxc_isi_video_release() 中的 mxc_isi_video_cleanup_streaming()。这可导致以下情况在此类设备上调用时任何释放调用例如来自简单的 v4l2-ctl -l 都可以释放当前的流队列。这可在 i.MX8MP 板上重现通过从 ISI 采集设备使用 gstreamergst-launch-1.0 -v v4l2src device=/dev/videoX 进行流式处理\ video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 \ fakesink 此流运行时查询相同设备的端点会引发错误状态 v4l2-ctl -l -d /dev/videoX 这将导致以下跟踪[ 155.452152] -------- ----[ 在此处切换 ]------------ [ 155.452163] WARNINGCPU0 PID
    1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] [ 157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6 [157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT [157.064369] 硬件名称imx8mp_board_01 (DT) [ 157.068205] pstate: 400000c5 nZcv daIF -PAN -UAO -TCO
    -DIT -SSBS BTYPE=--) [ 157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] [ 157.081195] lr :
    mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi] [ 157.087126] sp ffff800080003ee0 [ 157.090438] x29
    ffff800080003ee0 x28ffff0000c3688000 x270000000000000000 [ 157.097580] x26: 0000000000000000 x25
    ffff0000c1e7ac00 x24ffff800081b5ad50 [ 157.104723] x2300000000000000d1 x220000000000000000x21
    ffff0000c25e4000 [ 157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000 [157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000 [ 157.126146] x14:
    0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 157.133287] x11: 0000000000000040 x10:
    ffff0000c01445f0 x9 : ffff80007a053a38 [ 157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6
    0000000000000000 [ 157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000 [157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200 [ 157.161850] Call trace: [157.164296] mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P) [ 157.170319]
     157.175029... 157.178867​ 157.182968​ 157.186723​ 157.191346​ [ 157.195098] call_on_irq_stack+0x24/0x30 [ 157.199027] do_interrupt_handler+0x88/0x98 [ 157.203212] el0_interrupt+0x44/0xc0 [ 157.206792] __el0_irq_handler_common+0x18/0x28 [ [ 157.211328] el0t_64_irq_handler+0x10/0x20 [64_irq_handler+0x10/0x20 157.215429el  64_irq_handler+0x10/0x20 +0x198/0x1a0 [ 157.219009] ---[ 结束跟踪 0000000000000000 ]--- 通过将流准备和清理移动到 vb2 .prepare_streaming() 和 .unprepare_streaming() 操作来解决此问题。这样还可直接使用 vb2_ioctl_streamon() 和 vb2_ioctl_streamoff() 辅助函数并取消 mxc_isi_video_release() 中的手动清理从而简化了驱动程序。 (CVE-2025-68175)

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

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

  - filelock 是针对 Python 的平台无关文件锁定。在 3.20.1之前的版本中检查时间和使用时间 (TOCTOU) 争用条件允许本地攻击者通过符号链接攻击损坏或截断任意用户文件。Unix 和 Windows 锁定文件创建过程中存在此漏洞其中 filelock 在使用 O_TRUNC 打开文件之前会检查该文件是否存在。攻击者可在检查和打开文件之间的时间间隔中创建指向受害者文件的符号链接造成 os.open() 追踪该符号链接并截断目标文件。Unix、Linux、macOS 和 Windows 系统上的所有 filelock 用户都会受到影响。
    漏洞级联到依赖的库。攻击需要具备本地文件系统访问权限并且能够创建 symlinkUnix 上为标准用户权限Windows 10+ 上为开发人员模式。当锁定文件路径可预测时漏洞利用 1-3 次尝试便可成功。已在版本 3.20.1中修复此问题。
    如果无法立即升级请使用 SoftFileLock而不是 UnixFileLock/WindowsFileLock注意
    不同的锁定语义可能不适用于所有用例确保锁定文件目录具有限制性权限 (chmod 0700) 以防止不受信任的用户创建符号链接和/或 在运行受信任的应用程序之前，应监控可疑符号链接的锁定文件目录。这些变通方案仅提供部分缓解。争用条件仍然可被利用。强烈建议升级到版本 3.20.1 。 (CVE-2025-68146)

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

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

  - pinctrls32cc修复 s32_pinctrl_desc 中未初始化的内存 s32_pinctrl_desc 是使用 devm_kmalloc() 分配但未初始化其所有字段。值得注意的是pinconf_generic_parse_dt_config() 中使用了 num_custom_params进而导致间歇性分配错误例如在探测 i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 时显示以下错误
    __alloc_pages_noprof+0x290/0x300 [...] 硬件名称：NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] 调用跟踪：__alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168
    __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 real_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] 这会导致后续解析失败从而可在依赖的驱动程序 s32g-siul2-pinctrl 4009c240.pinctrl 中造成问题/soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0无法解析节点属性 s32g-siul2-pinctrl 4009c240.pinctrl/soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0:
    无法解析节点属性 [...] pca953x 0-0022写入寄存器失败-6 i2c i2c-0IMX I2C 适配器已注册 s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2- pins/i2c2-grp0无法解析节点属性 s32g-siul2-pinctrl 4009c240.pinctrl/soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0
    无法解析节点属性 i2c i2c-1IMX I2C 适配器注册 s32g-siul2-pinctrl 4009c240.pinctrl
    /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0无法解析节点属性 s32g-siul2-pinctrl 4009c240.pinctrl /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0无法解析 i2c 节点属性 i2c-2
    IMX I2C 适配器已注册 通过在 s32_pinctrl_probe() 中使用 devm_kzalloc() 而不是 devm_kmalloc() 初始化 s32_pinctrl_desc从而将之前未初始化的字段设置为零从而修复此问题。
    (CVE-2025-68222)

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

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

  - netfilter: nft_ct为 natted 连接添加 seqadj 扩展具有 PASV/EPSV 模式的 FTP 流量可能需要调整序列。原因是需要在 ftp 控制连接上重写数据包负载IP、端口。这可能需要更改 TCP 长度和预期 seq / ack_seq。重现此问题的最简单的方法是使用 PASV 模式。规则集示例table inet ftp_nat { ct helper ftp_helper { type ftp protocol tcp l3proto inet } chain 预路由 { type filter hook 预路由优先级 0; }策略接受tcp dport 21 ct state new ct helper set ftp_helper } } table ip nat { chain 预路由 { type nat hook 预路由优先级 -100; }策略接受tcp dport 21 dnat ip 前缀到 ip daddr 映射 {192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postroutingpriority 100 ;策略接受tcp port 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } } } 请注意ftp 帮助程序在 dnat 设置*之后*会进行分配。反向帮助程序分配后 nat 由 nf_nat_setup_info() 中的现有检查处理因此不会显示此问题。Topoloy: +--------------------+ +-------------------------- --------+ | FTP 192.168.13.2 | | FTP <-> NAT 192.168.13.3[] 、[] | | NAT  、 192.168.100.1 +--------------------+ +---------------------------- | ------+ | +------------------------+ |客户端
    192.168.100.2 +------------------------+ ftp nat 变更在此情况下无法正常工作已连接到 192.168.100.1。 [..] ftp> epsv IPv4 上的 EPSV/EPRT 关闭。 ftp> ls 227 进入被动模式 (192,168,100,1,209,129)。 421 服务不可用远程服务器已关闭连接。内核日志
    缺少 nfct_seqadj_ext_add() 设置调用警告net/netfilter/nf_conntrack_seqadj.c:41 上的 CPU1 PID0 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d111 nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 .. 将 conntrack 帮助程序分配给具有 nat 绑定的连接时通过添加所需的扩展来修复此问题。
    (CVE-2025-68206)

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

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

  - ipv4route防止 rt_bind_exception() 重新绑定过时的 fnhe sit 驱动程序的数据包传输路径调用 sit_tunnel_xmit() -> update_or_create_fnhe()这导致调用 fnhe_remove_oldest() 以删除超过 FNXE_RECLAIM_DEPTH+random 的条目。争用窗口介于选择 fnheX 进行删除的 fnhe_remove_oldest() 和随后选择 kfree_rcu() 之间。在此期间，并发路径的
    __mkroute_output() -> find_exception() 可获取即将被删除的 fnheX然后 rt_bind_exception() 使用 dst_hold() 将其与新的 dst 绑定。通过 RCU 释放原始 fnheX 时dst 引用仍然永久泄漏。CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU 回调 [fnheX 释放、dst 泄漏] 此问题表现为设备引用计数泄漏和警告在取消注册网络设备时dmesg 中unregister_netdevice等待 sitX 释放。使用计数 = N Ido Schimmel 提供简单的测试验证方法 [1]。此补丁会在调用 fnhe_flush_routes() 之前清除 'oldest->fnhe_daddr'。由于 rt_bind_exception() 会检查此字段因此将其设置为零可防止过时的 fnhe 在释放前再次使用和绑定到新的 dst。 [1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 tasket -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep ns1 | 10 ip netns pids xargs kill ip netns del ns1 (CVE-2025-68241)

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

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

  - platform/x86intelpunit_ipc修复内存损坏目的是传递指针本身 punit_ipcdev不带 & 符号时这会传递指针 &punit_ipcdev 的地址。
    这意味着 complete(&ipcdev->cmd_complete); intel_punit_ioc() 中的 会写入导致崩溃的错误内存地址。 (CVE-2025-68303)

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

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

  - usbnet阻止自由活动的 kevent 此问题的根本原因为1。当探测 usbnet 设备时执行 usbnet_link_change(dev, 0, 0);将 kevent 工作放入全局工作队列中。但是，当取消注册 usbnet 设备时，尚未计划 kevent。因此执行 free_netdev() 会导致此处报告释放活动对象 (kevent) 错误。 2. 另一个因素是调用 usbnet_disconnect()->unregister_netdev() 时如果 usbnet 设备已启动执行 ndo_stop() 以取消 kevent。但是由于设备未启动因此未执行 ndo_stop()。此问题的解决方案是在执行 free_netdev() 之前取消 kevent。 (CVE-2025-68312)

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

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

  - blk-cgroup修复配置策略时可能的死锁 lockdep 可轻松触发跟随死锁警告检测到可能的循环锁定检测到 6.17.0-rc3-00124-ga12c2658ced0 #1665 未受感染 ---------- ------------------------------------------------------ check/1334 尝试获取锁定
    ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}，位于 blk_unregister_queue+0x53/0x180 但任务已保持锁定ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++ }-{0:0}, atdel_gendisk+0xba/0x110 哪个锁已依赖于新的锁。现有依存关系链逆序为 -> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+ 0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&q- >rq_qos_mutex){+.+.}-{4:4}
    __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 real_probe+0x136/0x620
    __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0
    __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30 #0 [&] (&) }-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0
    __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e 可帮助我们调试此链的其他信息 存在
    &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 可能的不安全锁定情况
    CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3) lock(&q->rq_qos_mutex);
    lock(&q->q_usage_counter(queue)#3) lock(&q->sysfs_lock);根本原因是 queue_usage_counter 被保存在 blkg_conf_prep() 中的 rq_qos_mutex 影响但队列应在其他环境的 rq_qos_mutex 之前冻结。blkg_conf_prep() 中的 blk_queue_enter() 用于防范已受到 blkcg_mutex 保护的策略停用因此将 blk_queue_enter() 转换为 blkcg_mutex 以修复此问题。同时考虑到在队列因策略停用而冻结之后 blkcg_mutex 会保持也将 blkg_alloc() 转换为使用 GFP_NOIO。 (CVE-2025-68178)

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

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

  - libceph修复have_mon_and_osd_map() 中潜在的释放后使用 __ceph_open_session() 中的等待循环可能与客户端在收到初始映射后不久接收新的 monmap 或 osdmap 发生争用。ceph_monc_handle_map() 和 handle_one_map() 在释放旧映射后立即安装新映射 kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap;
    分别在 client->monc.mutex 和 client->osdc.lock 下但由于在have_mon_and_osd_map() 中两者均未采用因此可能用于客户端中的 client->monc.monmap->epoch 和 client->osdc.osdmap->epoch 监控->monc.monmap && 客户端->monc.monmap->epoch && 客户端->osdc.osdmap && 客户端->osdc.osdmap->epoch;
    条件来取消引用已释放的映射。此问题正好可使用启用了 KASAN 的 generic/395 和 generic/397来重现: BUG: KASAN: Have_mon_and_osd_map+0x56/0x70 中的 slab-use-after-free 在 addr ffff88811012d810 上大小为 4 的读取由任务 mount.ceph/13305 CPU: 2 UID0 PID13305 Commmount.ceph Not tainted 6.14.0-rc2-build2+ #1266... Call Trace: <TASK> have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd /0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3 /0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 work_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x24/0x300 ork_asm+0x1a/0x30 重写等待循环以适当时采用 client->monc.mutex 和 client->osdc.lock 直接检查上述条件。改进超时处理之前在 wait_event_interruptible_timeout() 休眠多次的情况下可超过 mount_timeout在 client->monc.mutex 下访问 client->auth_err 以符合 finish_auth() 中的设置方式。
    monmap_show() 和 osdmap_show() 现在也会在访问映射之前获取相应的锁定。
    (CVE-2025-68285)

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

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

  - cpufreq/long就绪处理 longhao_exit 中的空策略 longhal_exit() 会调用 cpufreq_cpu_get(0) 而不检查空策略指针。在某些系统上这可导致空取消引用以及内核警告或错误。此修补程序添加了使用不太可能() 的检查并在策略为 NULL 时提前返回。
    Bugzilla：#219962 (CVE-2025-68177)

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

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

  - ttyserialip22zilog在提交 84a9582fd203 之后使用平台设备进行探测 (serialcore: 开始管理串行控制器以启用运行时 PM) 串行驱动程序需要在 struct uart_port.dev 中提供设备否则会发生 oops。要修复 ip22zilog 驱动程序的此问题可将驱动程序切换至平台驱动程序并在 sgi-ip22 代码中设置串行设备。 (CVE-2025-68311)

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

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

  - s390/pci避免 PCI 错误恢复和 mlx5 crdump 之间的死锁执行 PCI 错误恢复的 s390 变体时不通过 pci_cfg_access_lock() 阻断 PCI 配置访问按照 powerpc 的 EEH 和 generic PCI 仅获取 device_lock() 而不是 pci_dev_lock() AER 处理 do。据报告在错误恢复测试期间一对任务挂起 mlx5_core 0000:00:00.1
    mlx5_safe_try_recover:338(pid 5553)运行状况恢复流已中止PCI 读取仍然无法正常工作信息 INFO
    任务 kmcheck:72 阻断超过 122 秒。未受感染 5.14.0-570.12.1.bringup7.el9.s390x #1 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 调用跟踪 [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/ 0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO
    任务 kworker/u1664:6:1514 阻断超过 122 秒。未受感染 5.14.0-570.12.1.bringup7.el9.s390x #1 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue
    mlx5_safe0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] 调用跟踪[<000000065256f030>]
    __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+ 0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_heart_do_dump.part.0+0x82/0x168 [[] ] devlink_heart_report+0x19a/0x230 [[] ] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [[<0000000652513212>] devlink_safe_do_dump.part.0+0x82/0x168 [<000003ff80075a12>] devlink_heart_report+0x19a/0x230 [[] ] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 mlx5_core] 没有与上游内核的完全相同的错误的内核日志可用 - 但也可在此处构建完全相同的死锁情况- 任务kmcheck mlx5_unload_one() 尝试在已设置 PCI 错误恢复代码时获取 devlink 锁定通过 pci_cfg_access_lock() 的方式实现 pdev->block_cfg_access - 任务当 devlink_heart_report() 已获取 devlink 锁定时kworker mlx5_crdump_collect() 尝试通过 pci_cfg_access_lock() 设置 block_cfg_access。当 mlx5_core 的 pci_error_handlers 在同一个 <BDF> 物理函数上执行 PCI 错误恢复时可通过使用 > devlink history dump show pci/<BDF> reporter fw_fatal 请求 crdump来重现类似的死锁情况。在 s390 上可通过 > zpcictl 注入此漏洞 --reset-fw <BDF> 使用此修补程序的测试未能重现第二个死锁情况devlink 命令被拒绝内核回答权限被拒绝 - 并且我们收到如下内核日志消息mlx5_core 1ed0:00:00.1其他
    mlx5_crdump_collect:50:(pid 254382)crdump未锁定 vsc gw err -5因为 VSC_SEMAPHORE 的配置读取被底层硬件拒绝。先前解决此问题的两次尝试经讨论但最终遭到拒绝 [请参阅链接]主要论点是 s390 的 PCI 错误恢复实现强加了 powerpc 的 EEH 和 PCI AER 处理都不需要的限制。测试显示即使未阻断对 PCI 配置空间的访问也可在 s390 上完成 PCI 错误恢复。
    (CVE-2025-68310)

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

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

  - Inputpegasus-notetker - 修复潜在的越界访问 在 pegasus_notetker 驱动程序中pegasus_probe() 函数使用来自端点描述符的 wMaxPacketSize 值分配 URB 传输缓冲区。攻击者可使用恶意 USB 描述符来强制分配非常小的缓冲区。随后如果设备发送具有特定模式的中断数据包例如第一个字节为 0x80 或 0x42pegasus_parse_packet() 函数会在不检查分配的缓冲区大小的情况下解析数据包。这会导致越界内存访问。 (CVE-2025-68217)

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

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

  - drm/radeon删除对 drm_put_dev() 的调用由于驱动程序主要结构的分配已更改为 devm_drm_dev_alloc()drm_put_dev()“触发其释放”应由 devres 完成。但是drm_put_dev() 仍在探测错误和设备删除路径中。由于 devres 在驱动程序已执行 drm_put_dev() 后仍尝试执行 drm_put_dev()因此驱动程序无法探测时会显示如下警告。 [5.642230] radeon 0000:01:05.0通过驱动程序 radeon 进行的探测因错误 -22 而失败 [ 5.649605] ------------[在此处切换 ]---------- -- [ 5.649607] refcount_t下溢释放后使用。 [ 5.649620] WARNINGCPU0 PID
    lib/refcount.c:28 refcount_warn_slurate+0xbe/0x110 中的第 357 项从提交 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4 中精选出的内容 (CVE-2025-68181)

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

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

  - KVMSVM如果替换 INT3/INTO则不跳过不相关的指令当从 INT3、INT0 或选定的 INTn 指令重新注入软中断时丢弃异常并重试指令如果更改了代码流（例如通过不同的 vCPU）当 CPU 执行指令与 KVM 解码指令以获得下一个 RIP 时之间。正如 commit 6ef88d6e36c2 所有效预测的 (KVM
    SVM重新注入 INT3/INTO 而不是重试指令无法验证是否解码了正确的 INTn 指令 会因解码错误的指令从而指定错误的下一个 RIP而有效破坏客户机状态。此缺陷在 Linux 客户机中最常表现为 Oops静态分支检查中的 int3 错误。在 Linux 中启用或禁用静态分支会使用内核的文本 poke 代码修补机制。为在其他 CPU 可能正在执行的情况下修改代码Linux暂时将原始指令的第一个字节替换为 int3 (opcode 0xcc)然后在新代码流中修补第一个字节以外的代码最后将 int3 替换为 int3 (opcode 0xcc)。会生成新代码流的第一个字节。如果 CPU 在修改代码时命中 int3即执行代码则来宾机内核必须查找 RIP 以确定如何处理 #BP例如通过仿真新指令。如果 RIP 不正确，则此查找失败，并且客户机内核会发生错误。通过入侵客户机内核在主机上运行 drgn 脚本[2] 时重复检查静态分支 [1] 以不断换出包含客户机 TSS 的内存此缺陷几乎会立即重现。 [1]
    https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a [2]
    https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b (CVE-2025-68259)

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

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

  - perf/x86/intel修复 KASAN 全局越界警告。在 CWF 上运行 perf mem 记录命令时可以看到以下 KASAN 全局越界警告。
    ================================================== ================ BUG: KASAN由任务 dtlb/9850 调用跟踪的 cmt_latency_data+0x176/0x1b0 处 addr ffffffffb721d000 处大小 4 的全局越界读取
    kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80 问题由
    __grt_latency_data()。该代码尝试访问在 CWF 等非混合平台上不存在的 x86_hybrid_pmu 结构。WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big) 因此在调用此 WARN_ON_ONCE 以修复全局越界访问问题之前添加 is_hybrid() 检查。 (CVE-2025-40359)

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

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

  - netethernettinetcp标准化 knav_dma_open_channel出错时返回 NULL 使 knav_dma_open_channel出错始终返回 NULL而不是 ERR_PTR。当前标头 include/linux/soc/ti/knav_dma.h 在禁用驱动程序时返回 NULL 但驱动程序实现在失败时甚至不返回 NULL 或 ERR_PTR从而导致用户不一致。这会导致 netcp_free_navigator_resources 中的崩溃如下所示修剪过未处理的错误0xffffff2 处的对齐异常 (0x221) [fffffff2] *pgd=80000800207003、*pmd=82ffda003、*pte=00000000 内部错误221 [#1] 链接的 SMP ARM 模块inCPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE 硬件名称 Keystone PC 位于 knav_dma_close_channel+0x30/0x19c LR 位于 netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] 调用跟踪knav_dma_close_channel来自 netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources来自 netcp_ndo_open+0x430/0x46c netcp_ndo_open来自 __dev_open+0x114/0x29c __dev_open来自 __dev_change_flags+0x190/0x208
    __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [ ... TRIM...] 通过使函数在所有错误条件下返回 NULL 来标准化错误处理。该 API 仅在 netcp_core.c 中使用因此影响有限。请注意此变更实际上恢复了提交 5b6cb43b4d62 (net: ethernet: ti: netcp_core在 dma 通道打开问题时返回错误)但提供了不易出错的实现。 (CVE-2025-68220)

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

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

  - stagingrtl8723bs修复 OnAssocReq IE 解析中的堆栈缓冲区溢出 当复制到固定大小的 16 字节堆栈缓冲区 (supportRate) 时直接使用传入关联请求帧中受支持的速率 IE 长度作为 memcpy() 长度。恶意站点可公告大于 16 字节的 IE 长度从而导致堆栈缓冲区溢出。在复制支持的费率 IE 之前将 ie_len 限制为缓冲区大小并在合并扩展的支持的费率时更正边界检查以防止第二次发生潜在的溢出。这可以防止由畸形关联请求触发的内核堆栈损坏。
    (CVE-2025-68255)

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

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

  - ima设置或删除非 IMA xattr 时不清除 IMA_DIGSIG 标记当前当 IMA 和 EVM 处于修复模式时如果程序首先在 security.ima 中存储 IMA 签名然后写入/删除文件的某些其他安全 xattr。例如在 Fedora 中通过 ima_appraise=fix evm=fix ima_policy=appraise_tcb 引导内核并安装 rpm-plugin-ima 之后安装/重新安装程序包将无法生成良好的引用 IMA 签名。而是生成 IMA 哈希# getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash 安全性。ima=0x0404... 发生这种情况的原因是设置 security.selinux 时清除了提前设置的 IMA_DIGSIG 标记。因此当关闭文件时会生成 IMA 哈希。同样地删除安全 xattr如 security.evm或设置/删除 ACL之后可在文件关闭时清除 IMA 签名。通过防止重置 IMA_DIGSIG 标记来防止将 IMA 文件签名替换为文件哈希。这是一个最小的 C 重现器其将 security.selinux 设置为最后一个步骤也可通过删除 security.evm 或设置 ACL#include 来替换 <stdio.h> #include<sys/xattr.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdlib.h> int main() { const char* file_path = /usr/sbin/test_binary; const char* hex_string = 030204d33204490066306402304; int length = strlen(hex_string); char* ima_attr_value; int fd;
    fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror(打开文件时出错); return 1 } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) {sscanf(hex_string + i, %2hhx, &ima_attr_value[j]); } if (fsetxattr(fd, security.ima, ima_attr_value, length/2, 0) == -1) { perror(设置扩展属性时出错); close(fd); return 1 } const char* selinux_value= system_u:object_r:bin_t:s0; if (fsetxattr(fd, security.selinux, selinux_value, strlen(selinux_value), 0) == -1) { perror(设置扩展属性时出错); close(fd); return 1 close(fd); return 0 } (CVE-2025-68183)

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

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

  - bpf添加 bpf_prog_run_data_pointers() syzbot 发现 cls_bpf_classify() 能够变更 tc_skb_cb(skb)->drop_reason从而在 sk_skb_reason_drop() 中触发警告。警告CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [内联] 警告CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop +0x76/0x170 net/core/skbuff.c:1214 已在提交 ec624fe740b4 (net/sched以 tc 控制区块扩展 qdisc 控制区块)中添加 struct tc_skb_cb添加了与 db58ba459202bpf数据中的线路和cls_act_bpf 的 data_end。 drop_reason 之后添加。添加 bpf_prog_run_data_pointers() 辅助函数以保存/还原与 BPF data_meta/data_end 冲突的 net_sched 存储。 (CVE-2025-68200)

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

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

  - drm/amdgpu修复 PF 传递中休眠之后的 gpu 页面错误 在 PF 传递环境中在休眠然后恢复之后coralgemm 将导致 gpu 页面错误。休眠期间发生 Mode 1 重置但恢复时未还原分区模式未在恢复后立即还原 mmCP_HYP_XCP_CTL 和 mmCP_PSP_XCP_CTL 寄存器。CP 访问 MQD BO 时使用了错误的跨度这将造成 MQD BO 上的越界访问从而导致页面错误。补丁用于确保从休眠恢复时调用 gfx_v9_4_3_switch_compute_partition()。在重置恢复或从暂停序列恢复期间单独调用 KFD resume。因此无需将其作为分区切换的一部分进行调用。从提交 5d1b32cfe4a676fe552416cb5ae847b215463a1a 中精选出的内容 (CVE-2025-68230)

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

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

  - crash修复 crashkernel 资源缩小。当 crashkernel 配置为高预留时将其值缩小到低 crashkernel 预留以下会导致两个问题1. 无效 crashkernel 资源对象2. 如果进行两次 crashkernel 缩小会发生内核崩溃例如使用 crashkernel= 200M高内核保留 200MB 的高内存和一些默认的低内存（例如 256MB）。保留显示为 cat /proc/iomem | grep -i crash af000000-beffffff崩溃内核 433000000-43f7fffff崩溃内核如果 crashkernel随后缩小为 50MB (echo 52428800 > /sys/kernel/kexec_crash_size)/proc/iomem 仍显示保留了 256MBaf000000-beffffff: 崩溃内核而应显示 50MBaf000000-b21fffff 内核崩溃进一步将 crashkernel 缩小到 40MB 会导致内核崩溃并提示以下跟踪 (x86): BUG
    内核空指针取消引用地址0000000000000038 PGD 0 P4D 0 Oops0000 [#1] PREEMPT SMP NOPTI <snip...> 调用跟踪 <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 __release_resource+0xd/0xb0 release_resource+0x26/0x40
    __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 <snip...> 发生这种情况的原因是 __crash_shrink_kernel() 更新了 object_crash_kernel()即使应该更新 crashk_low_res 。通过确保在缩小 crashkernel 内存时更新正确的 crashkernel 资源对象来修复此问题。 (CVE-2025-68198)

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

ID	名称	严重性
278980	Docker Desktop < 4.54.0 敏感数据泄漏	low
278977	Linux Distros 未修补的漏洞：CVE-2025-53619	critical
278976	Linux Distros 未修补的漏洞：CVE-2025-14177	medium
278975	Linux Distros 未修补的漏洞：CVE-2025-68142	medium
278974	Linux Distros 未修补的漏洞：CVE-2025-53618	critical
278973	Linux Distros 未修补的漏洞：CVE-2025-68221	medium
278972	Linux Distros 未修补的漏洞：CVE-2025-14180	high
278971	Linux Distros 未修补的漏洞：CVE-2025-67735	medium
278970	Linux Distros 未修补的漏洞：CVE-2025-14714	medium
278969	Linux Distros 未修补的漏洞：CVE-2025-48429	critical
278968	Linux Distros 未修补的漏洞：CVE-2025-14178	high
278967	Linux Distros 未修补的漏洞：CVE-2023-53900	medium
278965	Linux Distros 未修补的漏洞：CVE-2025-52582	high
278964	Linux Distros 未修补的漏洞：CVE-2025-10543	medium
278931	Linux Distros 未修补的漏洞：CVE-2025-68226	medium
278930	Linux Distros 未修补的漏洞：CVE-2025-68182	high
278929	Linux Distros 未修补的漏洞：CVE-2025-40357	medium
278928	Linux Distros 未修补的漏洞：CVE-2025-68197	medium
278927	Linux Distros 未修补的漏洞：CVE-2025-40346	medium
278926	Linux Distros 未修补的漏洞：CVE-2025-68228	medium
278925	Linux Distros 未修补的漏洞：CVE-2025-40348	medium
278920	Linux Distros 未修补的漏洞：CVE-2025-68227	high
278919	Linux Distros 未修补的漏洞：CVE-2025-68196	medium
278918	Linux Distros 未修补的漏洞：CVE-2025-68294	medium
278917	Linux Distros 未修补的漏洞：CVE-2025-68212	high
278916	Linux Distros 未修补的漏洞：CVE-2025-40347	medium
278915	Linux Distros 未修补的漏洞：CVE-2025-68211	medium
278914	Linux Distros 未修补的漏洞：CVE-2025-68199	high
278913	Linux Distros 未修补的漏洞：CVE-2025-68175	medium
278912	Linux Distros 未修补的漏洞：CVE-2025-68146	medium
278911	Linux Distros 未修补的漏洞：CVE-2025-68222	medium
278910	Linux Distros 未修补的漏洞：CVE-2025-68206	high
278908	Linux Distros 未修补的漏洞：CVE-2025-68241	medium
278907	Linux Distros 未修补的漏洞：CVE-2025-68303	high
278906	Linux Distros 未修补的漏洞：CVE-2025-68312	high
278905	Linux Distros 未修补的漏洞：CVE-2025-68178	medium
278904	Linux Distros 未修补的漏洞：CVE-2025-68285	high
278903	Linux Distros 未修补的漏洞：CVE-2025-68177	medium
278902	Linux Distros 未修补的漏洞：CVE-2025-68311	high
278901	Linux Distros 未修补的漏洞：CVE-2025-68310	medium
278900	Linux Distros 未修补的漏洞：CVE-2025-68217	high
278899	Linux Distros 未修补的漏洞：CVE-2025-68181	high
278898	Linux Distros 未修补的漏洞：CVE-2025-68259	high
278897	Linux Distros 未修补的漏洞：CVE-2025-40359	high
278896	Linux Distros 未修补的漏洞：CVE-2025-68220	medium
278895	Linux Distros 未修补的漏洞：CVE-2025-68255	high
278894	Linux Distros 未修补的漏洞：CVE-2025-68183	high
278893	Linux Distros 未修补的漏洞：CVE-2025-68200	high
278892	Linux Distros 未修补的漏洞：CVE-2025-68230	medium
278891	Linux Distros 未修补的漏洞：CVE-2025-68198	medium

检测

Nessus 的 Misc. 系列

low

critical

medium

medium

critical

medium

high

medium

medium

critical

high

medium

high

medium

medium

high

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

high

medium

medium

medium

high

medium

high

high

medium

high

medium

high

medium

high

high

high

high

medium

high

high

high

medium

medium