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

  - btrfsqgroup修复配额禁用和配额重新扫描 ioctl 之间的争用 一个禁用配额的任务和另一个运行重新扫描 ioctl 的任务之间存在争用可导致 fs_info->qgroup_tree rbtree 中 qgroup 记录的释放后使用。这种情况的发生方式如下1) 任务 A 进入 btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan() 2) 任务 B 进入 btrfs_quota_disable() 并调用 btrfs_qgroup_wait_for_completion()但该函数不执行任何操作因为 fs_info->qgroup_rescan_running 此时为 false任务 A 尚未对其进行设置3) 任务 B 调用 btrfs_free_qgroup_config()该配置开始从 fs_info->qgroup_tree 释放 qgroup而无需锁定 fs_info->qgroup_lock 4) 任务 A 在保持 fs_info->qgroup_lock 时进入 qgroup_rescan_zero_tracking()开始迭代 fs_info->qgroup_tree 树但任务 B 未保持锁定就从该树中释放 qgroup 记录从而导致释放后使用。通过获取 btrfs_free_qgroup_config() 的 fs_info->qgroup_lock 修复此问题。此外如果配额已禁用则 btrfs_qgroup_rescan() 不启动重新扫描工作线程。 (CVE-2025-39759)

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

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

  - scsiufsexynos修复 Google gs101 中的 HCI_UTRL_NEXUS_TYPE 编程 UTP 传输请求插槽数 (nutrs) 为 32在这种情况下驱动程序最终将 UTRL_NEXUS_TYPE 错误地编程为 0。这是因为左侧移位的宽度为 1，类型为 int，即 31 位宽。移动超过该宽度会导致未定义的行为。通过切换至 BIT() 宏来修复此问题将根据需要应用正确的类型转换。这可确保将正确值写入 UTRL_NEXUS_TYPE在 gs101 上为 0xffffffff同时修复 UBSAN 位移警告UBSANdrivers/ufs/host/ufs-exynos.c:1113:21 shift 中的位移越界exponent 32 对于 32 位“int”类型过大 为保持一致性请将相同的更改应用到 nutmrs / UTMRL_NEXUS_TYPE 写入。 (CVE-2025-39788)

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

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

  - 已修复 Linux 内核中的下列漏洞：x86/vmscape: Add conditional IBPB mitigation VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.
    Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB. This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace. The intent is to integrate and optimize these cases post-embargo. [dhansen: elaborate on suboptimal IBPB solution ] (CVE-2025-40300)

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

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

  - 调节器pca9450使用 devm_register_sys_off_handler 对于模块测试存在错误 dump------------[此处剪切]------------ 通知程序回调 pca9450_i2c_restart_handler 已注册 警告其他
    kernel/notifier.c:23 at notifier_chain_register+0x5c/0x88 CPU#0kworker/u16:3/50 调用跟踪
    notifier_chain_register+0x5c/0x88 (P) atomic_notifier_chain_register+0x30/0x58 register_restart_handler+0x1c/0x28 pca9450_i2c_probe+0x418/0x538 i2c_device_probe+0x220/0x3d0 really_probe+0x114/0x410 __driver_probe_device+0xa0/0x150 driver_probe_device+0x40/0x114
    __device_attach_driver+0xd4/0x12c因此使用 devm_register_sys_off_handler 让内核处理资源释放以避免内核转储。 (CVE-2025-39771)

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

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

  - mm/mremap修复具有禁用了 remap 事件的 uffd 的 WARN在至少跨越一个 PMD 的 VMA 上注册 userfaultd然后进行 mremap()'ing从由于页面 导致的页表移动失败中恢复时VMA 可触发 WARN表分配错误。代码最终做了正确的事情递归、避免移动实际的页表但触发该警告是令人不快的 WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [ inline] 警告CPU:2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline] 警告CPU:2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852 模块中链接到了 CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full) 硬件名称: QEMU Standard PCQ35 + ICH92009BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline] RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline] RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852 代码... RSP0018ffffc900037a76d8 EFLAGS00010293 RAX0000000000000000 RBX
    0000000032930007 RCX: ffffffff820c6645 RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007 RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000032930007 R11:
     R120000000000000000  : 0000000000000000 R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000 FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0 调用跟踪 <TASK> copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0x1ffad/0x1f80 mm0x1f80 mm /mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe +0x77/0x7f RIP0033:0x7f00d0b8ebe9 代码...
    RSP002b:00007ffe5ea5ee98 EFLAGS00000246 ORIG_RAX: 0000000000000019 RAXffffffffffffffda RBX
    00007f00d0db5fa0 RCX: 00007f00d0b8ebe9 RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000 RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000 R10: 0000000000000003 R11:
    0000000000000246 R120000000000000002 R1300007f00d0db5fa0 R1400007f00d0db5fa0 R150000000000000005 </TASK> 最根本的问题是我们在原始页表移动期间递归但在恢复移动期间不递归。通过检查两个 VMA 并在 pmd_none() 健全性检查之前执行检查来修复此问题。添加新的帮助程序在其中执行+记录检查 PMD 和 PUD 级别。感谢 Harry 平分。 (CVE-2025-39775)

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

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

  - Erlang OTP sshssh_sftp 模块中存在无限制的资源分配或节流漏洞允许过度分配、洪流。此漏洞与程序文件 lib/ssh/src/ssh_sftpd.erl 相关。此问题影响 OTP 格式的 OTP 17.0 至 OTP 28.0.3、与 27.3.4.3 至 26.2.5.15 之间的 ssh 对应的 OTP 3.0.1 和 5.3.3、 5.2.11.3 和 5.1.4.12。 (CVE-2025-48041)

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

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

  - busmhihost检测到指向非预期 TRE 的事件当远程设备将完成事件发送到主机时其包含指向所消耗 TRE 的指针。主机使用此指针来处理它与环的读取指针的主机本地副本之间的所有 TRE。此功能在处理链式事务的完成时有效，但如果设备针对读取指针比主机的读取指针超前多个元素的单一元素事务发送事件，则可能导致不良结果。例如如果主机在设备更新事件环时对其进行访问则事件内部的指针可能仍指向旧 TRE。如果主机使用通道的 xfer_cb() 直接释放由 TRE 指向的缓冲区则缓冲区将被双重释放。在使用上游 EP 堆栈而无“commit 6f18d174b73d bus: mhi: ep仅在缓冲区写入后更新读取指针”的 ep 上会观察到此行为。
    设备在更新事件内容之前更新了事件环指针，因此在设备有机会更新窗口之前，主机能够在其中访问事件指向的过时数据。通常的模式是主机接收到的指向 TRE 的事件并非紧接着上次处理的事件之后因此会将其视为链式事务处理两个读取指针之间的所有 TRE。此提交旨在通过确保链接事件指向非 local_rp + 1 的 TRE 的事务来强化主机。 [mani添加了稳定标签并改写了提交消息] (CVE-2025-39790)

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

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

  - ACPIAPEI如果未恢复同步内存错误则将 SIGBUS 发送到当前任务如果由于用户空间进程触发 2 位未修正的错误而检测到同步错误CPU 将采取同步错误例如同步外部错误Arm64 上的 中止 (SEA)。内核会将 memory_failure() 工作排入队列其会毒化相关页面、取消映射页面然后将 SIGBUS 发送到进程从而可避免出现全系统的错误。但是，当发生异常同步错误时，则不会将 memory_failure() 工作排入队列。这些错误可能包括无效 PA、非预期的严重性、无内存故障配置支持、无效 GUID 部分等情况。在这种情况下用户空间进程将再次触发 SEA。此循环可能超过平台固件阈值甚至触发内核硬锁定从而导致系统重新启动。如果没有 memory_failure() 工作排队等待同步错误则通过执行强制终止来修复此问题。 [ rjw变更日志编辑 ] (CVE-2025-39763)

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

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

  - Erlang OTP ssh (ssh_sftp 模块) 中存在无限制的资源分配或限制漏洞允许过度分配和资源泄露。此漏洞与程序文件 lib/ssh/src/ssh_sftpd.erl 相关。此问题影响 OTP 格式的 OTP 17.0 至 OTP 28.0.3、与 27.3.4.3 至 26.2.5.15 之间的 ssh 对应的 OTP 3.0.1 和 5.3.3、 5.2.11.3 和 5.1.4.12。 (CVE-2025-48039)

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

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

  - sched/ext修复类切换时的无效任务状态转换当启用 sched_ext 计划程序时我们可能会触发无效任务状态转换从而导致类似以下的警告可通过循环运行热插拔 selftest 轻松重现fish[770] 警告的无效任务状态转换 0 -> 3 kernel/sched/ext.c:3862 scx_set_task_state+0x7c/0xc0 ... RIP
    0010scx_set_task_state+0x7c/0xc0 ... 调用跟踪 <TASK> scx_enable_task+0x11f/0x2e0switching_to_scx+0x24/0x110 scx_enable.isra.0+0xd14/0x13d0 bpf_struct_ops_link_create+0x136/0x1a0
    __sys_bpf+0x1edd/0x2c30 __x64_sys_bpf+0x21/0x30 do_syscall_64+0xbb/0x370 entry_SYSCALL_64_after_hwframe+0x77/0x7f 发生这种情况的原因是我们跳过了对已经死了其使用情况计数器设置为零的任务的初始化但我们没有在计划类转换阶段。修复此问题的方法是在类切换期间也跳过死任务并防止无效的任务状态转换。 (CVE-2025-39780)

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

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

  - mm/smaps修复 smaps_hugetlb_range 和迁移之间的争用 smaps_hugetlb_range() 在不保持 ptl 的情况下处理 pte并且可能与迁移并发导致 pfn_swap_entry_to_page() 中存在 BUG_ON。争用情况如下。 smaps_hugetlb_range migrate_pages huge_ptep_get remove_migration_ptes folio_unlock pfn_swap_entry_folio BUG_ON若要修复此问题请保持 smaps_hugetlb_range() 中的 ptl 锁定。 (CVE-2025-39754)

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

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

  - PCI修复重新培训失败时的链接速度计算 当 pcie_failed_link_retrain() 重新培训失败时它会尝试恢复到之前的链接速度。但是，它会根据 Link Control 2 寄存器计算速度，而不会首先屏蔽掉非速度位。PCIE_LNKCTL2_TLS2SPEED() 将此类错误值转换为 PCI_SPEED_UNKNOWN (0xff)进而导致 pcie_set_target_speed() 中发生 WARN splatpci 0000:00:01.1: [1022:14ed] 类型 01 类 0x060400 PCIe Root 端口 pci 0000:00:01.1损坏的设备在 2.5GT/s pci 0000:00:01.1处重新培训无效的下游链接重新培训失败警告CPU1PID:1位于 drivers/pci/pcie/bwctrl.c:168 pcie_set_target_speed RDX: 0000000000000001 RSI 00000000000000ff RDIffff9acd82efa000 pcie_failed_link_retrain pci_device_add pci_scan_single_device 屏蔽掉 PCIE_LNKCTL2_TLS2SPEED() 和 PCIE_LNKCAP_SLS2SPEED() 中的非速度位以便它们不会错误地返回 PCI_SPEED_UNKNOWN。 [bhelgaas提交日志从 https://lore.kernel.org/r/1c92ef6bcb314ee6977839b46b393282e4f52e74.1750684771.git.lukas@wunner.de](CVE-2025-39784] 中添加详细信息

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

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

  - LoongArch通过优化 PLT/GOT 计数来优化模块加载时间。同时当启用 CONFIG_KASAN、CONFIG_PREEMPT_VOLUNTARY_BUILD 和 CONFIG_PREEMPT_VOLUNTARY 时将会出现软死锁, 相关日志如下rcu: INFOrcu_sched 在 CPU 上自我检测停止。 .. 调用跟踪：
    [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler +0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>]constant_timer_interrupt+0x64/0x80 [<9000000000349938>]
    __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158 经分析为加载 amdgpu 模块速度慢导致长时间占用 cpu然后是软死锁。加载模块时module_frob_arch_sections() 会尝试计算处理所有 RELA 所需的 PLT/GOT 数量。它将调用 count_max_entries() 以在乱序日期中查找具有 O(n^2) 复杂性的计数算法。为提高速度我们按信息和加数对重定位列表进行排序。这样，只需与上一个条目进行比较，即可检查重复的重定位。这可将算法的复杂性降低至 O(n log n), 与在提交 d4e0340919fb (arm64/module) 中所做的一样通过优化 PLT 计数优化模块加载时间。这可大大减少具有大量重定位的模块的模块加载时间。应用此修补程序后软死锁问题已解决内核会在没有调用跟踪的情况下正常启动。
    使用默认配置测试某些模块时结果如下模块大小 ip_tables 36Kfat 143K radeon 2.5MB amdgpu 16MB 如果没有此修补程序Module 模块加载时间 (ms) Count(PLTs/GOTs) ip_tables 18 59/6fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098 安装此修补程序后获得模块模块加载时间ms Count(PLTs/GOTs) ip_tables 18 59/6fat 0 162/14 radeon 221221/84 amdgpu 45 4525/1098 (CVE-2025-39767)

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

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

  - bpf在 JSET Syzbot 报告因以下 BPF 程序中的范围不变违反而存在内核警告后优化 tnum 时忘记范围。 0调用 bpf_get_netns_cookie 1如果 r0 == 0 前往 <exit> 2如果 r0 & Oxffffffff 前往 <exit> 问题在于我们通过两个跳转的路径。The path is unreachable at runtime在 insn 1 之后我们知道 r0 != 0但利用 jset 上的符号扩展我们只会在 r0 == 0 时回退 insn 2。 遗憾的是 is_branch_taken() 当前无法了解这一点，以便验证程序遍历所有分支。然后验证程序使用第二个条件优化寄存器边界我们最终会在此无法访问的路径上获得不一致的边界: 1: if r0 == 0 goto <exit> r0:
    u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2如果 r0 & 0xffffffff 在 reg_bounds_sync 之前转到 <exit> r0u64=[0x1, 0xffffffffffffffff] 在 reg_bounds_sync 之后var_off=(0, 0) r0u64=[0x1, 0] var_off=(0, 0) 改进 JSET 的范围细化以涵盖所有情况具有一定技巧性。鉴于 LLVM 不会生成这些指令我们预计不会有很多用户依赖 JSET。因此Eduard 建议我们在缩小 JSET 后的 tnums 时忘记范围而不是改进 JSET 的范围细化。此修补程序可实现该方法。 (CVE-2025-39748)

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

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

  - parisc从 flush_cache_vmap 终止 WARN_ON_ONCE() 我发现警告偶尔会触发。
    (CVE-2025-39781)

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

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

  - jbd2防止 jbd2_log_do_checkpoint() 中的 softlockup jbd2_log_do_checkpoint() 和 jbd2_journal_shrink_checkpoint_list() 都会在处理一批缓冲区后定期释放 j_list_lock以避免 j_list_lock 保持时间过长。但是由于这两个函数都争用 j_list_lock因此等待和处理所用的总时间可能会相当巨大。 need_resched() 为真时jbd2_journal_shrink_checkpoint_list() 明确调用 cond_resched()以避免长时间操作期间 softlockups。但是 jbd2_log_do_checkpoint() 仅在 need_resched() 为真时才退出其循环并依赖可能休眠的函数如 __flush_batch() 或 wait_on_buffer() 来触发重新计划。如果这些函数不休眠内核可能会死锁。 watchdog缺陷软锁定 - CPU#3 卡住达 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump已加载未受感染 6.6.0+ #10 硬件名称：Huawei TaiShan 2280 /BC11SPCD、BIOS 1.27 2017 年 6 月 13 日 Workqueue writeback wb_workfn (flush-7:2) pstate20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc
    native_queued_spin_lock_slowpath+0x358/0x418 lr jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] 调用跟踪
    native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]
    __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2]
    __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback +0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20 因此在 jbd2_log_do_checkpoint() 中明确调用 cond_resched() 以避免 softlockup。 (CVE-2025-39782)

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

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

  - Erlang OTP ssh (ssh_sftp 模块) 中存在无限制的资源分配或限制漏洞允许过度分配和资源泄露。此漏洞与程序文件 lib/ssh/src/ssh_sftpd.erl 相关。此问题影响 OTP 格式的 OTP 17.0 至 OTP 28.0.3、与 27.3.4.3 至 26.2.5.15 之间的 ssh 对应的 OTP 3.0.1 和 5.3.3、 5.2.11.3 和 5.1.4.12。 (CVE-2025-48038)

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

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

  - rcu保护 ->defer_qs_iw_pending 免受数据争用在使用 CONFIG_IRQ_WORK=y 构建的内核上在禁用中断禁用的代码区域内调用 rcu_read_unlock() 时 [1] 将调用使用 irq-work 处理程序的 rcu_read_unlock_special()以强制系统在 RCU 读取端关键部分实际结束时发出通知。在最早启用中断之前，这种情况不会发生。在某些内核中例如通过 rcuttree.use_softirq=y 引导的内核会无条件使用 irq-work 处理程序。per-CPU rcu_data 结构的 ->defer_qs_iw_pending 字段由 irq-work 处理程序更新并由 rcu_read_unlock_special() 读取和更新。这导致了以下 KCSAN splat ------------------------------------------ ------------------------------ BUGKCSANrcu_preempt_deferred_qs_handler / rcu_read_unlock_special 中的数据争用任务 90 读取 0xffff96b95f42d8d8 中的 1 个字节在 cpu 8 上rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0
    __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8
    rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 no locks held by irq_work/8/88. irq 事件标记200272 hardirqs last启用时间 (200272)
    [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs 上次禁用的时间为 (200271)
    [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs 上次启用的时间为 (0)[<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs 上次禁用的时间为 (0): [<0000000000000000>] 0x0
    -------------------------------------------------- ---------------------- 问题在于 irq-work 处理程序在启用中断的情况下运行这意味着 rcu_preempt_deferred_qs_handler() 可以被中断并且该中断处理程序可能包含 RCU 读取端关键区段其可能调用 rcu_read_unlock_special()。在 RCU 使用的严格 KCSAN 操作模式中这构成 ->defer_qs_iw_pending 字段上的数据争用。因此此提交禁用了 rcu_preempt_deferred_qs_handler() 中用于更新 ->defer_qs_iw_pending 字段的部分的中断。这已足够因为此处理程序不是快速路径。 (CVE-2025-39749)

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

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

  - RDMAhfi1修复 find_hw_thread_mask() 中可能发生的除以零 函数将在线 CPU 数量除以 num_core_siblings然后再检查除以零。这意味着可能 发生 除以零运行时错误。通过在拆分之前移动检查来修复此问题。这也有助于节省一个缩进级别。 (CVE-2025-39742)

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

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

  - usbcoreconfig防止 SS 端点配套解析中的 OOB 读取 usb_parse_ss_endpoint_companion() 在长度之前检查描述符类型从而可能在缓冲区大小之外进行奇数读取。通过在查看描述符中的任何字段之前首先检查大小来修复此问题。 (CVE-2025-39760)

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

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

  - Erlang OTP ssh (ssh_sftp 模块) 中存在不受控制的资源消耗漏洞允许过度分配、洪流。此漏洞与程序文件 lib/ssh/src/ssh_sftpd.erl 相关。此问题影响 OTP 格式的 OTP 17.0 至 OTP 28.0.3、与 27.3.4.3 至 26.2.5.15 之间的 ssh 对应的 OTP 3.0.1 和 5.3.3、 5.2.11.3 和 5.1.4.12。 (CVE-2025-48040)

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

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

  - drm/msm在元数据设置中添加 krealloc 的错误处理 函数 msm_ioctl_gem_info_set_metadata() 现在会检查 krealloc 失败并返回 -ENOMEM从而避免可能的空指针取消引用。明确避免因死锁风险和分配限制而导致的 __GFP_NOFAIL。patchwork
    https://patchwork.freedesktop.org/patch/661235/ (CVE-2025-39747)

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

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

  - netfilterctnetlink删除预期转储程序中的引用计数与之前的修补程序模式相同不通过引用计数保持预期对象活动仅存储 Cookie 值然后将其用作转储恢复的跳过提示。AFAICS 具有与在 conntrack 转储程序中解决的问题相同的问题如果 (!refcount_inc_not_zero(&exp->use)) 执行 if (!refcount_inc_not_zero(&exp->use)) 以增加 refcount 时可能会出现 exp == last从而导致双倍增加和后续的内存泄漏问题。 (CVE-2025-39764)

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

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

  - PCI 端点修复了 configfs 群组列表头处理。在 pci_epf_remove_cfs() 中的 struct pci_epf_driver 的 epf_group 字段上执行 list_del() 的方式不正确因为此字段是列表头而不是列表条目。当拆卸具有 configfs 属性组的端点功能驱动程序时此 list_del() 调用会触发 KASAN 警告 ========================== ======================================== 缺陷KASANslab-use-after- pci_epf_remove_cfs+0x17c/0x198 中由任务 rmmod/319 CPU3 UID0 PID319 Commmod 未受感染的地址 ffff00010f4a0d80 中大小 8 的释放 6.16.0-rc2 #1 NONE 硬件名称Radxa ROCK 5B (DT) Call trace: show_stack+0x2c/0x84 (C) dump_stack_lvl+0x70/0x98 print_report+0x17c/0x538 kasan_report+0xb8/0x190 __asan_report_store8_noabort+0x20/0x2c pci_epf_remove_cfs+0x17c/0x198 pci_epf_unregister_driver+0x18/0x30 nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf]
    __arm64_sys_delete_module+0x264/0x424 invoke_syscall+0x70/0x260 el0_svc_common.constprop.0+0xac/0x230 do_el0_svc+0x40/0x58 el0_svc+0x48/0xdc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync_handler+0x10c/0x138 el0840t_640t_619/0x138 el080t_640t_619/0x138
    删除 pci_epf_remove_cfs() 中这个不正确的 list_del() 调用。 (CVE-2025-39783)

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

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

  - ALSAtimer修复未分配时的 ida_free 调用。在 snd_utimer_create() 函数中如果 kasprintf() 函数返回 NULL将调用 snd_utimer_put_id()最终使用 ida_free() 释放未分配的 id 0。syzkaller 报告下列信息------------[ cut here ]------------ ida_free 调用了未分配的 id=0。警告CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592 中链接的模块: CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 未受感染 6.15.8 #3 PREEMPT(lazy) 硬件名称QEMU Standard PC(i440FX + PIIX,1996)BIOS 1.16.3-4.fc42 04/01/2014 RIP
    0010:ida_free+0x1fd/0x2f0 lib/idr.c:592 代码 f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...) RSP
    0018:ffffc900007f79c8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5 RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200 RBP: 0000000000000000 R08:
     R09ffffffff87ba60a5  : 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES0000 CR00000000080050033 CR2
    00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0 Call Trace: <TASK> snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer] snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer] snd_utimer_ioctl_create sound/core/ timer.c:2202 [内联] [snd_timer]
    __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer] snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer] vfs_ioctl fs/ioctl.c:51 [内联]
    __do_sys_ioctl fs/ioctl.c:907 [内联] __se_sys_ioctl fs/ioctl.c:893 [内联] __x64_sys_ioctl+0x198/0x200 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64 +0x7b/0x160 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] 应在使用 kasprintf() 函数之前正确设置 utimer->id确保 snd_utimer_put_id() 函数将释放已分配 id。 (CVE-2025-39765)

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

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

  - OpenPrinting CUPS 是用于 Linux 和其他 Unix-like 操作系统的开源打印系统。在 2.4.12 及更低版本中当 `AuthType` 设置为除 `Basic` 以外的任何选项时如果请求包含 `Authorization: Basic ...` 标头则不会检查密码。这会导致身份验证绕过。
    任何允许使用“Basic”以外的“AuthType”的配置都会受到影响。版本 2.4.13 已修复该问题。(CVE-2025-58060)

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

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

  - mm/kmemleak避免 __kmemleak_do_cleanup() 中发生软锁定。在启用 kmemleak 的情况下运行调试内核时在具有 16 GB 的小型系统 x86-64 系统上观察到软锁定警告。
    watchdog缺陷软锁定 - CPU#8 卡住 33 秒[kworker/8:1:134] 测试系统运行工作负载与热拔出并行发生。然后kemleak 决定自行禁用因为它无法分配更多的 kmemleak 对象。调试内核的 CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE 设置为 40,000。当通过工作队列循环移除现有 kmemleak 对象时kmemleak_do_cleanup() 中会发生软锁定。在此特殊情况下至少有 40,000 个对象需要处理考虑到调试内核的缓慢以及必须在 __delete_object() 中获取和释放 raw_spinlock这一事实可能需要一段时间才能正确处理所有对象这些对象。由于 kmemleak 在此情况下已禁用因此实际上不需要锁定可进一步优化对象移除和删除过程。但是，可能不值得针对这种应该很少发生的边缘情况进行优化。因此简单的解决方案是在迭代循环中定期调用 cond_resched() 以避免软锁定。 (CVE-2025-39737)

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

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

  - wifiath10k硬件不可靠时的关机驱动程序 在极少数情况下ath10k 可能会由于某些未知原因失去与 PCIe 总线的连接这可进一步导致在恢复期间因监控程序超时而发生系统崩溃ath10k_pci 0000:01:00.0 wmi 命令 20486 超时重新启动硬件 ath10k_pci 0000:01:00.0已在重新启动 ath10k_pci 0000:01:00.0未能停止 WMI vdev 0-11 ath10k_pci 0000:01:00.0未能停止 vdev 0:-11 ieee80211 phy0 PM**** DPM 设备超时 **** 调用跟踪
    panic+0x125/0x315 dpm_watchdog_set+0x54/0x54 dpm_watchdog_handler+0x57/0x57 call_timer_fn+0x31/0x13c 此时所有 WMI 命令都将超时并尝试重新启动设备。因此，请设置连续重新启动失败的阈值。如果超过阈值，则认为硬件不可靠，并应跳过所有 ath10k 操作，以避免系统崩溃。 fail_cont_count 和 pending_recovery 是原子变量，不涉及复杂的条件逻辑。因此，即使同时执行恢复检查和 reconfig complete，恢复机制也不会中断。已在以下设备上进行测试 QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 (CVE-2025-39746)

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

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

  - dmdm-crypt不要部分接受具有分区目标的写入 BIO 根据 max_read_size 和 max_write_size 模块参数定义的 dm-crypt 内部限制默认为 128 KB。目的是通过将大型 BIO 拆分为可在不同 CPU 上并行的较小操作来改进大型 BIO 的处理时间。对于已分区的 dm-crypt 目标仍会进行此 BIO 拆分但不会并行执行以确保向底层设备发出的写入操作保持连续。然而拆分本身会造成其他问题1) 由于 dm-crypt 依赖区块层区域写入插入来处理使用常规写入操作的区域附加仿真拆分写入 BIO 的提醒将始终插入目标区域写入插入中。正在进行的写入 BIO 完成后此提醒 BIO 已拔出并从区域写入插入工作发出。如果需要拆分此提醒 BIO 本身则会重新发布并再次插入该提醒但是这会导致调用 blk_queue_enter()如果发起了队列冻结操作可能会阻断该调用。这会导致死锁因为 DM 提交仍保留队列冻结端正在等待的 BIO。 2) dm-crypt 依赖由区块层使用常规写入操作处理区域附加操作所完成的仿真。这仍然需要正确返回写入的扇区作为原始 BIO 的 BIO 扇区。但是，只有并且只有存在用于处理用户发出的原始区域附加操作的单个克隆 BIO 时，才能正确完成此操作。如果区域附加操作的大小大于 dm-crypt max_write_size则原始 BIO 将被当作一系列常规写入操作来拆分和处理。
    此类链接会导致将错误的写入扇区返回到使用原始 BIO 扇区的区域附加颁发者。这进而导致使用 xfs 或 btrfs 的文件系统数据损坏。可通过修改 get_max_request_size() 使其始终返回 BIO 的大小来修复此问题从而避免在 crypt_map() 中被 dm_accpet_partial_bio() 拆分。 get_max_request_size() 已重命名为 get_max_request_sectors()以阐明返回值的单位其接口已更改以便获取一个指向正在处理的 struct bio 的指针。除了此更改之外要确保 crypt_alloc_buffer() 正常工作请将 dm-crypt 设备 max_hw_sectors 限制设置为至多 BIO_MAX_VECS << PAGE_SECTORS_SHIFT4KB 页面架构中为 1 MB。这会强制 DM 核心拆分写入 BIO然后再将其传递给 crypt_map()从而保证 dm-crypt 始终可接受整个写入 BIO而无需拆分。此更改对 dm-crypt 的读取路径没有任何影响。
    仍可拆分读取操作并并行处理 BIO 片段。鉴于所有区域写入 BIO 均已内联而非并行处理则上述情况也不会影响写入路径的性能。此变更也不会以任何方式影响常规的 dm-crypt 区块设备。 (CVE-2025-39791)

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

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

  - drm/hisilicon/hibmc修复 hibmc 加载失败缺陷 当 hibmc 加载失败时驱动程序将使用 hibmc_unload 来释放资源但 mode.config 中的互斥体未初始化从而将访问空指针。只需将 goto 语句更改为 return因为 hibnc_hw_init() 不需要释放任何内容。 (CVE-2025-39772)

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

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

  - OpenPrinting CUPS 是用于 Linux 和其他 Unix-like 操作系统的开源打印系统。在 2.4.12 及更低版本中打印机属性的不安全反序列化和验证导致 libcups 库中出现空指针取消引用。这是默认配置的本地子网中可用的远程 DoS 漏洞。它可导致本地网络中监听打印机的所有计算机上的 cups 和 cups-browsed 崩溃因此默认情况下适用于所有常规 linux 计算机。在漏洞 CVE-2024-47176 cups-filters 1.x/cups-browsed 2.x 漏洞未修复的系统上计算机上的防火墙不拒绝与 IPP 端口的传入通信并且计算机设置为对公共可以访问互联网、攻击矢量网络。当前版本的 CUPS 和 cups-browsed 项目的默认配置中包含 Adjacent 攻击途径。版本 2.4.13 包含用于 CVE-2025-58364的修补程序。 (CVE-2025-58364)

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

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

  - fs防止文件描述符表分配超过 INT_MAX 当 sysctl_nr_open 设置为非常高的值时由 systemd 设置为 1073741816则尝试使用接近限制的文件描述符的进程可触发超过 INT_MAX 的大量内存分配尝试的警告中的 mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 发生这种情况的原因是 kvmalloc_array() 和 kvmalloc() 检查请求的大小是否超过 INT_MAX 并发出分配未标记 __GFP_NOWARN 时的警告。特别是当 nr_open 设置为 1073741816 (0x3ffffff8) 且进程调用 dup2(oldfd, 1073741880) 时内核会尝试分配- 文件描述符数组1073741880 * 8 字节 = 8,589,935,040 字节 - 多个位图~400MB - 总分配大小更多信息包括 <unistd.h> #include<sys/resource.h> int main() { struct rlimit rlim = {1073741824, 1073741824};
    setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // 触发警告 return 0 3. 观察 dmesg at mm/slub.c:5027 中的警告。systemd 提交 a8b627a 引入了将 fs.nr_open 自动升级为可能的最大值。理由是具有内存控制组 (memcg) 的系统不再需要单独的文件描述符限制因为内存已得到正确计算。但是此更改忽略了 1. 无论 memcg 核算如何内核的分配函数仍然强制 INT_MAX 作为最大大小 2. 合法测试文件描述符限制的程序和测试可无意中触发大量分配 3. 生成的分配 (>8GB)不切实际且始终失败 systemd 的算法以 INT_MAX 开头并持续将值减半直到内核接受。在大多数系统上这会导致 nr_open 被设置为 1073741816 (0x3ffffff8)即文件描述符刚好低于 1GB。
    虽然在正常操作中进程很少使用接近此限制的文件描述符但某些 selftest如 tools/testing/selftests/core/unshare_test.c和测试文件描述符限制的程序可能会触发此问题。通过在 alloc_fdtable() 中添加检查确保请求的分配大小不超过 INT_MAX从而修复此问题。这会导致操作因 -EMFILE 而失败而不是触发内核警告，并避免不切实际的 >8GB 内存分配请求。 (CVE-2025-39756)

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

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

  - drm/amd/display添加空指针检查 [原因] 防止空指针取消引用以增强函数稳定性 [操作方法] 添加早期空指针检查并在无效时返回 false。 (CVE-2025-39762)

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

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

  - ARMrockchip修复 smp 初始化期间的内核挂起 为了启动辅助 CPU 主 CPU 请将 trampoline 代码写入 SRAM。trampoline 代码会在次要 CPU 启动时写入至少对于 RK3188 CPU 如此。有时这会导致内核挂起。可能是因为辅助 CPU 执行了 trampoline 代码而内核则未执行。该修补程序将 SRAM 初始化步骤移动到了所有辅助 CPU 均已关闭的位置。修复很少挂起 RK3188[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4 (CVE-2025-39752)

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

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

  - btrfs不允许重定位部分终止的子卷 [BUG] 有个内部报告称天平触发的事务中止具有下列调用追踪 item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0树状区块 backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0树状区块 backref root 7 ...
    BTRFS 错误设备 loop0未找到用于插入的盘区项目bytenr 594526208 num_bytes 16384 父 449921024 root_objectid 934 所有者 1 偏移 0 BTRFS 错误设备 loop0无法对逻辑 594526208 num_bytes 16384 类型 182 操作 1 ref_mod 1 运行延迟的引用-117 ------------[ 在此处切换 ]------------ BTRFS事务中止错误 -117警告CPU11 PID 6963 位于 .. /fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs] 并且 btrfs 检查未报告与 extent 树相关的任何错误。[原因] 原因稍微复杂首先范围树确实没有 594526208 的 backref。范围树在磁盘上只有关于该 byter 的以下两个 backref
    item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK 树区块 skinny level 0 (176 0x7) 树区块 backref 根 CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 19571树块 skinny level 0 (176 0x7) 树块 backref 根 CSUM_TREE 但此类缺失 backref 项目并非磁盘上的损坏因为有问题的延迟 ref 属于子卷 934而该子卷将被丢弃项目 0 密钥 (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229 And that offending tree block 594526208 is inside the dropped range of该子卷。这解释了为何该 byter 没有 backref 项目以及为何 btrfs 检查未报告任何错误。但是这也说明了另一个问题因为 btrfs 将以读写挂载执行所有孤立的子卷清理。因此在 RW 挂载之后不应该存在 half-dropped 子卷而且 balance 本身也是子卷清理所独有的这意味着我们在重定位期间不应遇到 subvolume-half-dropped。根本原因是没有此子卷的孤立项目。实际上有 2021 年左右的 5 个子卷存在相同的问题。原始报告似乎在运行某些较旧的内核并造成这些僵尸子卷。值得感谢的是上游提交 8d488a8c7ba2btrfs修复挂载时未触发子卷/快照删除早已修复了该缺陷。[增强] 将增强 btrfs-progs 以修复此类旧 fs。考虑到问题出现的延迟程度（在运行延迟的 ref 时间），而到时候我们已经必须中止事务，那么为时已晚。相反，我们在此处尽早拒绝 reloc 树的任何半丢弃的子卷，以防混淆，并防止在调试类似缺陷时额外花费时间。 (CVE-2025-39738)

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

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

  - net/sched使 candle_enqueue 在超过 buffer_limit 时返回 NET_XMIT_CN。下列设置可在以下情况下于 htb_activate 中触发警告!cl->leaf.q->q.qlen tc qdisc del dev lo root tc qdisc add dev lo root handle 1htb default 1 tc class add dev lo parent 1: classid 1:1 \ htb rate 64bit tc qdisc add dev lo parent 1:1 handle f: \ graphite memlimit 1b ping -I lo -f -c1 -s64 -W0.001 127.0.0.1 这是因为低 memlimit 导致低 buffer_limit 进而造成数据包丢弃。但是 graphite_enqueue 仍返回 NET_XMIT_SUCCESS导致 htb_enqueue 以空子 qdisc 调用 htb_activate。当数据包从相同 ten 和 flow 中丢弃时我们应返回 NET_XMIT_CN。我认为 NET_XMIT_CN 的返回值对于 ack 过滤情况下的数据包丢弃而言并非必要条件因为这样做是为了优化性能而非表示拥塞。 (CVE-2025-39766)

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

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

  - jfs当硬链接为 0 时截断好的 inode 页面 复制程序从磁盘复制的 inode 的文件集值为 AGGR_RESERVED_I。执行 evict 时其硬链接编号为 0因此其 inode 页不会被截断。由于 nrpages 大于 0这会导致在执行 clear_inode() 时触发 bugon。CVE-2025-39743

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

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

  - cryptox86/aegis - 添加缺少的错误检查 skcipher_walk 函数可分配内存并可能失败因此有必要检查错误。 (CVE-2025-39789)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/mlx5: HWS, fix complex rules rehash error flow Moving rules from matcher to matcher should not fail. However, if it does fail due to various reasons, the error flow should allow the kernel to continue functioning (albeit with broken steering rules) instead of going into series of soft lock-ups or some other problematic behaviour. Similar to the simple rules, complex rules rehash logic suffers from the same problems. This patch fixes the error flow for moving complex rules: - If new rule creation fails before it was even enqeued, do not poll for completion - If TIMEOUT happened while moving the rule, no point trying to poll for completions for other rules. Something is broken, completion won't come, just abort the rehash sequence. - If some other completion with error received, don't give up. Continue handling rest of the rules to minimize the damage.
    - Make sure that the first error code that was received will be actually returned to the caller instead of replacing it with the generic error code. All the aforementioned issues stem from the same bad error flow, so no point fixing them one by one and leaving partially broken code - fixing them in one patch.
    (CVE-2025-39768)

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: acomp - Fix CFI failure due to type punning To avoid a crash when control flow integrity is enabled, make the workspace (stream) free function use a consistent type, and call it through a function pointer that has that same type.
    (CVE-2025-39777)

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

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

  - iioadcad7173修复 syscalib_mode 的通道索引 修复访问 syscalib_mode 属性时用于查找通道的索引。address 字段是一个从 0 开始的索引与 scan_index 相同用于在整个驱动程序中访问 ad7173_channels 数组中的通道。另一方面，根据设备树中指定的通道配置，通道字段可能与地址字段不匹配，并可能造成越界访问。 (CVE-2025-39786)

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

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

  - socqcommdt_loader确保没有读取超过 ELF 标头。在 remoteproc 中使用 MDT 加载程序时会事先审查 ELF 标头但其他客户端则不必如此。验证固件缓冲区的大小，以确保在迭代标头时不会超出末尾。
    e_phentsize 和 e_shentsize 也会经过验证以确保遍历中有关步长大小的假设有效。 (CVE-2025-39787)

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

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

  - btrfssubpage保留 TOWRITE 标签直到 folio 被清除。btrfs_subpage_set_writeback() 会在 folio 第一次写回时调用 folio_start_writeback()并且也会清除 PAGECACHE_TAG_TOWRITE 标签即使 folio 中仍有脏区块。这会破坏排序保证例如 btrfs_wait_ordered_extents() 要求的排序保证。该排序破坏会导致真正的失败。例如在分区的设置上运行 generic/464 将命中以下 ASSERT。发生这种情况的原因是被破坏的顺序无法在截断文件大小之前刷新现有的脏页面。
    断言失败!list_empty(&ordered->list) :: 0在 fs/btrfs/zoned.c:1899 ------------[在此剪切]-------- --- fs/btrfs/zoned.c:1899! 的内核缺陷Oops无效的 opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump已加载未受感染 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(optional) 硬件名称Supermicro Super Server/H12SSL-NT、BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP
    0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08:
     R0900000000ffffdfff  : ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES0000 CR00000000080050033 CR2
    00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 调用跟踪 <TASK> ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ?
    __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ?
    __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> 考虑进程 A 通过 WB_SYNC_NONE 调用 writepages()。在区域模式下或压缩写入时会锁定 delalloc 的多个 folio 并开始将其写出。我们将最后一个锁定的 folio folio X 命名为 folio X。假设写入范围仅部分覆盖 folio X留下一些脏页。进程 A 在构建 bio 时调用 btrfs_subpage_set_writeback()。此函数调用清除 folio X 的 TOWRITE 标签，其大小 = 8K，块大小 = 4K。处于跟随状态。 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> 进程 A 将写入此范围。现在假设进程 B 同时通过 WB_SYNC_ALL 调用 writepages()。它会调用 tag_pages_for_writeback() 以使用 PAGECACHE_TAG_TOWRITE 标记脏作品集。由于 folio X 仍然是脏的因此它会被标记。然后B 使用 filemap_get_folios_tag() 收集带标记的 folio必须等待 folio X 写入然后才能从 writepages() 返回。 0 4K 8K |/////|/////|标记 DIRTY标签DIRTY|TOWRITE但是在标记和收集之间进程 A 可能会调用 btrfs_subpage_set_writeback() 并清除 folio X 的 TOWRITE 标签。
    0 4K 8K | 0 |/////|标记 DIRTY|WRITEBACK标记DIRTY因此进程 B 在其批处理中不会看到 folio X并且不等待就返回。这违反了 WB_SYNC_ALL 排序要求。使用 btrfs_subpage_set_writeback_keepwrite() 修复此问题其会保留 TOWRITE 标签。我们现在仅在 folio 变干净之后通过 xas 操作手动清除标签。 (CVE-2025-39779)

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

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

  - iioadcrzg2l_adc通过在循环中反复取消绑定和绑定 ADC 设备对系统进行压力测试并且该 ADC 是另一设备的供应商时设置驱动程序数据启用运行时 PM 时读取为的温度），ADC 设备可能会在运行时 PM 启用后立即恢复运行时由其使用者触发。此时由于尚未设置 drvdata且驱动程序的运行时 PM 回调依赖它因此可能会发生崩溃。为避免此问题请在分配 drvdata 后立即对其进行设置。 (CVE-2025-39774)

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

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

  - wifiath12k减少 RX 对等机 frag 设置错误处理上的 TID 目前在 ath12k_dp_rx_peer_frag_setup() 处理路径错误期间对等机清理之前不会减少 TID。这可导致 peer-> 中的越界访问rx_tid[]。因此，在对等清理之前添加 TID 的减少操作可确保在 RX 对等 frag 设置失败时进行正确清理并防止越界访问问题。在代码审查期间发现。仅测试编译文件。(CVE-2025-39761)

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

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

  - ALSAusb-audio验证 UAC3 群集段描述符需要验证 UAC3 类段描述符其大小是否与声明的长度匹配以及是否也适合分配的缓冲区大小。否则恶意固件可能导致意外的 OOB 访问。 (CVE-2025-39757)

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

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

  - rcutorture修复 RT 内核中的 rcutorture_one_extend_check() splat 对于使用 CONFIG_PREEMPT_RT=y 构建的内核运行 rcutorture 测试将导致以下 splat：[ 68.797425] 变更期间的 rcutorture_one_extend_check当前 0x1 要添加 0x1 要删除 0x0 preempt_count() 0x0 [68.797533] 警告CPU2 PID512 at kernel/rcu/rcutorture.c:1993 rcutorture_one_extend_check+0x419/0x560 [rcutorture] [ 68.797601] 调用跟踪 [ 68.797602] <TASK> [68.797619] ? lockdep_softirqs_off+0xa5/0x160 [ 68.797631] rcutorture_one_extend+0x18e/0xcc0 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [ 68.797646] ? local_clock+0x19/0x40 [ 68.797659] rcu_torture_one_read+0xf0/0x280 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [ 68.797678] ?
    __pfx_rcu_torture_one_read+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [ 68.797804] ?
    __pfx_rcu_torture_timer+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [ 68.797815] rcu-torture: rcu_torture_reader task started [ 68.797824] rcu-torture: Creating rcu_torture_reader task [68.797824] rcu_torture_reader+0x238/0x580 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [68.797836] ? kvm_sched_clock_read+0x15/0x30 禁用 BH 不会针对 RT 内核更改 preempt_count() 中的 SOFTIRQ 相应位此提交因此会使用 softirq_count() 来检查 BH 是否已禁用。
    (CVE-2025-39745)

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

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

  - iommu/arm-smmu-qcom添加 SM6115 MDSS 兼容版 将 SM6115 MDSS 兼容版添加至 客户端兼容列表因为它也需要该变通方案。如果没有此变通方案例如基于 SM4250/SM6115 的 [ QRB4210 RB2 会在启动时产生大量 smmu 未处理的环境错误arm_smmu_context_fault: 116854 回调抑制 arm-smmu c600000.iommu: 未处理的环境错误 fsr=0x402、 iova=0x5c0ec600、 fsynr=0x320021、 cbfrsynra=0x420、cb=5 arm-smmu c600000.iommuFSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommuFSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu未处理的上下文错误 fsr=0x402、 iova=0x5c0d7800、 fsynr=0x320021、 cbfrsynra=0x420、cb=5 arm-smmu c600000.iommuFSR = 00000402 [Format=2 TF]、SID=0x420 和 也无法初始化发现 lontium lt9611uxc、gpu 和 dpu由 lt9611uxc 触发的绑定 MDSS 组件失败------------[在此处剪切]------------ !aspace警告CPU6 PID 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] 链接的模块长模块列表CPU 6 UID 0 PID 324 Comm(udev-worker) 未受感染 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT 硬件名称 Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc
    msm_gem_vma_init+0x150/0x18c [msm] lr msm_gem_vma_init+0x150/0x18c [msm] spffff80008144b280 ... 调用跟踪msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x5b0adreno 0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+ 0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device +0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+ 0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c /0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* 无法分配 memprs-22 msm_dpu 5e01000.display-controller无法加载 adreno gpu 平台 a400000.remoteproc:glink-edge:apr:service@7:dais添加到 iommu 群组 19 msm_dpu 5e01000.display-controller 无法绑定 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controlleradev bind 失败-22 lt9611uxc 0-002b无法将 dsi 连接到主机 lt9611uxc 0-002b驱动程序 lt9611uxc 的探测失败并出现错误 -22CVE-2025-39739

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

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

  - mm/kmemleak将 pr_warn() 移动到 kmemleak_lock 之外避免死锁启用 netpoll 时在 mem_pool_alloc() 中保持 kmemleak_lock 的同时调用 pr_warn_once() 可因 netconsole 子系统的锁定反转而造成死锁。出现这种情况的原因是 pr_warn_once() 可能触发 netpoll其最终导致 __alloc_skb() 返回 kmemleak 代码从而尝试重新获取 kmemleak_lock。这是死锁的路径。 mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once()
    -> netconsole Subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags);通过设置一个标记并在 kmemleak_lock 释放后发出 pr_warn_once()可修复此问题。 (CVE-2025-39736)

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

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

  - mm/debug_vm_pgtable清除 destroy_args() 中的页表条目 mm/debug_vm_pagetable 测试为其运行的测试分配页表条目同时使用其手动分配的 mm_struct。其本身没有问题但当其退出时在 destroy_args() 中无法使用 *_clear 函数清除这些条目。问题在于 会保留过时条目。如果另一个进程使用相同地址的 pgd 分配 mm_struct则可能以遇到过时条目而告终。实际上在 CONFIG_DEBUG_VM_PGTABLE=y 的调试内核上会发生这种情况例如这是我添加了一些额外调试的输出如果 pgtables_bytes 变为负值除了在 check_mm() 函数发出警告它还会打印警告跟踪 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000 [ 2.539366] kmem_cache info [ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508 [2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e (... ) [ 2.552800] WARNINGCPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0 [ 2.552816] 中链接的模块[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY [2.552859] 硬件名称IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv :phyp pSeries [ 2.552872] NIPc0000000007eef3c LRc0000000007eef30 CTRc0000000003d8c90 [ 2.552885] REGSc0000000622e73b0 TRAP0700 未受感染 (6.12.0-105.debug_v m2.el10.ppc64le+debug[ 2.552899] MSR
    800000000282b033<SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 0000000a [ 2.552954] CFAR
    c0000000008f03f0 IRQMASK: 0 [ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001 [ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff [2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000 [ 2.552954] GPR12:
    00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb [ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0 [ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000 [ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001 [ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760 [2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0 [ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0 [ 2.553199] Call Trace: [ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable) [ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0 [ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570 [2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650 [ 2.553292] [c0000000622e7a30 ] [c0000000001b95b8] __mmput+0x98/0x290 [ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0 [ 2.558361] [c0000000622e7ac0] [c0000000001d1c0000000001d1c] ec/0x870 [ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150 [ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50 [ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0 [ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec (...) [ 2.558892] ---[ end trace 0000000000000000 ]--- [ 2.559022] BUG不正确的 rss-counter 状态 mm:000000002267MM_ANONSPAGEONSPAGE9e type val:1 [ 2.559037] BUG释放 mm 时非零 pgtables_bytes: -6144 此处 modprobe 进程以来自 debug_vm_pgtable 测试之前使用的 mm_struct slab 中的已分配 mm_struct 告终。这不是问题因为 mm_stru ---truncated--- (CVE-2025-39776]

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

ID	名称	严重性
264768	Linux Distros 未修补的漏洞：CVE-2025-39759	high
264767	Linux Distros 未修补的漏洞：CVE-2025-39788	high
264766	Linux Distros 未修补的漏洞：CVE-2025-40300	medium
264765	Linux Distros 未修补的漏洞：CVE-2025-39771	medium
264764	Linux Distros 未修补的漏洞：CVE-2025-39775	medium
264763	Linux Distros 未修补的漏洞：CVE-2025-48041	high
264762	Linux Distros 未修补的漏洞：CVE-2025-39790	high
264761	Linux Distros 未修补的漏洞：CVE-2025-39763	medium
264760	Linux Distros 未修补的漏洞：CVE-2025-48039	medium
264759	Linux Distros 未修补的漏洞：CVE-2025-39780	medium
264758	Linux Distros 未修补的漏洞：CVE-2025-39754	medium
264757	Linux Distros 未修补的漏洞：CVE-2025-39784	medium
264756	Linux Distros 未修补的漏洞：CVE-2025-39767	medium
264755	Linux Distros 未修补的漏洞：CVE-2025-39748	medium
264754	Linux Distros 未修补的漏洞：CVE-2025-39781	medium
264753	Linux Distros 未修补的漏洞：CVE-2025-39782	medium
264752	Linux Distros 未修补的漏洞：CVE-2025-48038	medium
264751	Linux Distros 未修补的漏洞：CVE-2025-39749	high
264750	Linux Distros 未修补的漏洞：CVE-2025-39742	medium
264749	Linux Distros 未修补的漏洞：CVE-2025-39760	high
264748	Linux Distros 未修补的漏洞：CVE-2025-48040	medium
264747	Linux Distros 未修补的漏洞：CVE-2025-39747	medium
264746	Linux Distros 未修补的漏洞：CVE-2025-39764	medium
264745	Linux Distros 未修补的漏洞：CVE-2025-39783	high
264744	Linux Distros 未修补的漏洞：CVE-2025-39765	medium
264743	Linux Distros 未修补的漏洞：CVE-2025-58060	high
264742	Linux Distros 未修补的漏洞：CVE-2025-39737	medium
264741	Linux Distros 未修补的漏洞：CVE-2025-39746	medium
264740	Linux Distros 未修补的漏洞：CVE-2025-39791	medium
264739	Linux Distros 未修补的漏洞：CVE-2025-39772	medium
264738	Linux Distros 未修补的漏洞：CVE-2025-58364	medium
264737	Linux Distros 未修补的漏洞：CVE-2025-39756	medium
264735	Linux Distros 未修补的漏洞：CVE-2025-39762	medium
264734	Linux Distros 未修补的漏洞：CVE-2025-39752	medium
264733	Linux Distros 未修补的漏洞：CVE-2025-39738	high
264732	Linux Distros 未修补的漏洞：CVE-2025-39766	high
264731	Linux Distros 未修补的漏洞：CVE-2025-39743	high
264730	Linux Distros 未修补的漏洞：CVE-2025-39789	medium
264729	Linux Distros 未修补的漏洞：CVE-2025-39768	medium
264728	Linux Distros 未修补的漏洞：CVE-2025-39777	medium
264727	Linux Distros 未修补的漏洞：CVE-2025-39786	high
264726	Linux Distros 未修补的漏洞：CVE-2025-39787	medium
264725	Linux Distros 未修补的漏洞：CVE-2025-39779	medium
264724	Linux Distros 未修补的漏洞：CVE-2025-39774	medium
264723	Linux Distros 未修补的漏洞：CVE-2025-39761	high
264722	Linux Distros 未修补的漏洞：CVE-2025-39757	high
264721	Linux Distros 未修补的漏洞：CVE-2025-39745	medium
264720	Linux Distros 未修补的漏洞：CVE-2025-39739	medium
264719	Linux Distros 未修补的漏洞：CVE-2025-39736	medium
264718	Linux Distros 未修补的漏洞：CVE-2025-39776	high

检测

Nessus 的 Misc. 系列

high

high

medium

medium

medium

high

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

high

medium

medium

medium

high

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

high

high

high

medium

medium

medium

high

medium

medium

medium

high

high

medium

medium

medium

high