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

  - ext4在 ext4_destroy_inline_data_nolock() 中添加 i_data_sem 保护 修复内联数据破坏和区块映射之间的争用。函数 ext4_destroy_inline_data_nolock() 通过清除 EXT4_INODE_INLINE_DATA 和设置 EXT4_INODE_EXTENTS 来更改 inode 数据布局。同时另一个线程可能执行 ext4_map_blocks()其会测试 EXT4_INODE_EXTENTS 以确定是调用 ext4_ext_map_blocks() 还是 ext4_ind_map_blocks()。若无 i_data_sem 保护ext4_ind_map_blocks() 可能会接收含有 EXT4_INODE_EXTENTS 标志的 inode 并触发断言。 fs/ext4/indirect.c:546! 的内核缺陷EXT4-fs (loop2)卸载文件系统。无效 opcode0000 [#1] PREEMPT SMP KASAN NOPTI 硬件名称
    QEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.12.0-1 2014 年 4 月 1 日 RIP
    0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546 调用跟踪 <TASK> ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c 822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x5d mm/0x59/0x259 filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/ 0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c :763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write. c:1255 __do_sys_sendfile64 fs/read_w rite.c:1323 [内联] __se_sys_sendfile64 fs/read_write.c:1309 [内联] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [内联] do_syscall_64+0x35/ 0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 (CVE-2025-68261)

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

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

  - mlx5修复创建 CQ 中的默认值 默认情况下不为不具有完成函数的 CQ 分配 mlx5_add_cq_to_tasklet 函数。这是有问题的因为只有通过 mlx5_ib 驱动程序创建的用户 CQ 才能使用此函数。此外所有将使用通知而非轮询完成情况的 CQ 都必须调用 mlx5_cq_arm。但是，默认 CQ 创建流在 CQ 的 arm_db 字段中留下一个有效值从而允许 FW 在某些极端情况下将中断发送至仅轮询 CQ。
    这两个因素可允许通过 EQ 中断触发仅轮询的内核 CQ并调用仅用于用户 CQ 的完成函数从而导致空指针异常。驱动程序中的某些区域已通过一次性补丁防止此问题发生但未解决根本原因。此修补程序通过将默认值添加到创建 CQ 流来修复所述问题。它添加了默认的虚拟完成函数以防止空指针异常它默认会在内核 CQ 中设置无效的命令序列号以防止固件在 CQ 配备之前将中断发送到 CQ。用户 CQ 对其自己的初始化值负责。mlx5_core_create_cq 的调用程序负责更改完成函数并根据其需求配备 CQ。 (CVE-2025-68209)

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

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

  - sched_ext修复 scx_dump_state() 中不安全的锁定。对于使用 CONFIG_PREEMPT_RT=y 构建的内核dump_lock 将转换为可休眠旋转锁而不是 disable-irq因此会发生以下情况
    不一致的 {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} 用法。 irq_work/0/27 [HC0[0]:SC0[0]:HE1:SE1] 导致
    (&rq->__lock){?...}-{2:2}raw_spin_rq_lock_nested+0x2b/0x40 {IN-HARDIRQ-W} 状态已在以下位置注册
    lock_acquire+0x1e1/0x510 _raw_spin_lock_nested+0x42/0x80 raw_spin_rq_lock_nested+0x2b/0x40 sched_tick+0xae/0x7b0 update_process_times+0x14c/0x1b0 tick_periodic+0x62/0x1f0 tick_handle_periodic+0x48/0xf0 timer_interrupt+0x55/0x80 __handle_irq_event_percpu+0x20a/0x5c0 handle_irq_event_percpu+0x18/0xc0 handle_irq_event+0xb5/0x150 handle_level_irq+0x220/0x460
    __common_interrupt+0xa2/0x1e0 common_interrupt+0xb0/0xd0 asm_common_interrupt+0x2b/0x40
    _raw_spin_unlock_irqrestore+0x45/0x80 __setup_irq+0xc34/0x1a30 request_threaded_irq+0x214/0x2f0 hpet_time_init+0x3e/0x60 x86_late_time_init+0x5b/0xb0 start_kernel+0x308/0x410 x86_64_start_reservations+0x1c/0x30 x86_64_start_kernel+0x96/0xa0 common_startup_64+0x13e/0x148 other info that might help我们对此进行调试可能不安全的锁定情况CPU0 ---- lock(&rq->__lock); <Interrupt> lock(&rq->__lock); *** DEADLOCK *** 堆栈回溯: CPU: 0 UID: 0 PID: 27 Comm: irq_work/0 Call Trace
    <TASK> dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 print_usage_bug+0x42e/0x690 mark_lock.part.44+0x867/0xa70 __pfx_mark_lock.part.44+0x10/0x10 string_nocheck+0x19c/0x310 number+0x739/0x9f0 ? __pfx_string_nocheck+0x10/0x10 ? __pfx_check_pointer+0x10/0x10 ? kvm_sched_clock_read+0x15/0x30 ? sched_clock_noinstr+0xd/0x20 ? local_clock_noinstr+0x1c/0xe0
    __lock_acquire+0xc4b/0x62b0 ? __pfx_format_decode+0x10/0x10 ? __pfx_string+0x10/0x10 ?
    __pfx___lock_acquire+0x10/0x10 ? __pfx_vsnprintf+0x10/0x10 lock_acquire+0x1e1/0x510 ? raw_spin_rq_lock_nested+0x2b/0x40 ? __pfx_lock_acquire+0x10/0x10 ? dump_line+0x12e/0x270 ? raw_spin_rq_lock_nested+0x20/0x40 _raw_spin_lock_nested+0x42/0x80 ? raw_spin_rq_lock_nested+0x2b/0x40 raw_spin_rq_lock_nested+0x2b/0x40 scx_dump_state+0x3b3/0x1270 finish_task_switch+0x27e/0x840 scx_ops_error_irq_workfn+0x67/0x80 irq_work_single+0x113/0x260 irq_work_run_list.part.3+0x44/0x70 run_irq_workd+0x6b/0x90 __pfx_run_irq_workd+0x10/0x10 smpboot_thread_fn+0x529/0x870
    __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x305/0x3f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x40/0x70 ?
    __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> 因此此提交使用 rq_lock_irqsave/irqrestore() 来替换 scx_dump_state() 中的 rq_lock/unlock()。 (CVE-2025-68202)

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

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

  - usb小工具f_eem修复 eem_unwrap 中的内存泄漏 现有代码未处理命令路径中的 usb_ep_queue 失败情况可能导致内存泄漏。改进错误处理以在 usb_ep_queue 失败时释放所有分配的资源。此修补程序继续使用 goto 逻辑进行错误处理因为现有的错误处理过于复杂且不易适应自动清理帮助程序。 kmemleak 结果
    unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4
    __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c 未引用的对象 0xffffff8aadbaac00大小 128
    backtraceslab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c 未引用对象 0xffffff89ccef3500大小 64backtrace
    slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36cCVE-2025-68289]

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

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

  - bpf考虑 widen_imprecise_scalars() 中当前分配的堆栈深度 widen_imprecise_scalars() 的使用模式如下所示 prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st);其中 prev_st 是探索的状态树中 queued_st 的祖先。不保证此祖先具有与 queued_st 相同的分配堆栈深度。例如在下列情况中def main(): for i in 1..2: foo(i) // same callsite, diffnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loop此处，对于第二个“foo”调用，prev_st->allocating_stack 为 128，而 queued_st->allocating_stack 小得多。
    widen_imprecise_scalars() 需要考虑到这一点并避免越界访问 bpf_verifier_state->frame[*]->stack。 (CVE-2025-68208)

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

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

  - NFS修复委派时间戳时的 LTP 测试失败启用委派时间戳时utimes01 和 utime06 测试失败尤其是在使用“nobody”用户 ID 修改 atime 和 mtime 字段的子测试中。此问题可按如下方式重现# echo /media *(rw,no_root_squash,sync) >> /etc/exports # export -ra # mount -o rw,nfsvers=4.2 127.0.0.1:/media /tmpdir # cd /opt/ ltp # ./runltp
    -d /tmpdir -s utimes01# ./runltp -d /tmpdir -s utime06 出现此问题的原因是在 inode 允许委派时间戳时nfs_setattr 未针对调用者的 fsuid 验证 inode 的 UID。
    此修补程序添加了 UID 检查如果不匹配则将请求发送到服务器进行权限检查。 (CVE-2025-68242)

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

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

  - idpf修复删除中可能的 vport_config 空指针取消引用。在 vport 初始化失败的情况下尝试删除驱动程序将造成崩溃。以下跟踪来自于尝试创建 VF 期间驱动程序失败的实例[ 1661.543624] idpf 0000:84:00.7启动了设备 HW 重置 [1722.923726] idpf 0000:84:00.7事务超时:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms[1723.353263] BUG内核空指针取消引用地址0000000000000028 ... [ 1723.358472] RIP
    0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] 调用跟踪[ 1723.365475] <TASK> [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+ 0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982[] ] idpf_sriov_configure+0x58/0x140 [idpf] [ ] 0x1c0 在释放 user_config.q_coalesce 之前通过为 vport_config[i] 添加空指针检查避免空指针取消引用。
    (CVE-2025-68213)

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

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

  - lan966x修复 atomic 上下文中的休眠问题 当尝试使用 ssh 连接到设备时出现以下警告。缺陷休眠从 kernel/locking/mutex.c:575 的无效上下文中调用的函数 in_atomic()
    1、irqs_disabled()0、non_block:0、pid:104、namedropbear preempt_count:1、预期0 INFOlockdep 已关闭。CPU0 UID0 PID104 Commdropbear TaintedGW 6.18.0-rc2-00399-g6f1ab1b109b9-dirty#530 NONE 受感染[W]=WARN 硬件名称基于 Generic DT 的系统调用跟踪来自 show_stack+0x10/0x14 show_stack 的 unwind_backtrace dump_stack_lvl+0x7c/0xac dump_stack_lvl 来自
    __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter +0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b11fa8 to 0xf0b11ff0) 1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001 1fe0: 0005404c be9048c0 00018684 b6ec2cd8 It seems that we are using a mutex in a atomic context which is wrong. 通过旋转锁更改互斥体。 (CVE-2025-68320)

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

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

  - netnetpoll修复导致错误清理提交的错误 refcount 处理netpoll修复释放后使用在 netpoll 清理期间未正确忽略 refcount 并过早将 dev->npinfo 设置为空从而导致不当行为和内存泄漏。导致缺少适当清理的情况1) netpoll 与 NIC例如 eth0关联且分配了 netdev->npinfo且 refcnt = 1 - 请注意npinfo 在所有 netpoll 实例之间共享。在本例中只有一个。 2) 另一个 netpoll 也与相同的 NIC 和 npinfo->refcnt += 1 关联。- 现在 dev->npinfo->refcnt = 2； - 只有一个 npinfo 与 netdev 关联。 3) 当第一次 netpolls 去清理时- 第一次清理成功并清除 np->dev->npinfo同时忽略 refcnt。- 它基本上会调用 “RCU_INIT_POINTER(np->dev->npinfo, NULL);” - 设置 dev->npinfo = NULL 未进行正确清理 - 否
    ->ndo_netpoll_cleanup() 被调用 4) 现在第二个目标尝试清理 - 第二次清理失败因为 np->dev->npinfo 已经为空。 * 在这种情况下从未调用 ops->ndo_netpoll_cleanup()且也未清理 skb 池针对第二个 netpoll 实例- 这会泄漏 npinfo 和 skbpool skbskmemleak 明确地报告了此问题。恢复提交 efa95b01da18netpoll修复释放后使用并添加澄清注释强调应仅在 refcount 达到零之后进行 npinfo 清理以确保稳定且正确的 netpoll 行为。 (CVE-2025-68245)

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

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

  - cankvaser_usbleaf修复命令解析器中可能的无限循环 “kvaser_usb_leaf_wait_cmd()”和“kvaser_usb_leaf_read_bulk_callback”函数包含用于处理零长度命令的逻辑。这些命令用于使 数据与 USB 端点的 wMaxPacketSize 边界对齐。驱动程序尝试使用“round_up()”函数将缓冲区位置“pos”与下一个数据包边界对齐来跳过这些占位符。但是如果正好在数据包边界上发现零长度命令即“pos”为 wMaxPacketSize 的倍数包括 0“round_up”函数将返回“pos”的未更改值。这会防止“pos”增加从而导致解析逻辑中发生无限循环。此修补程序通过改用“pos + 1”修复函数中的此问题。这可确保即使“pos”在边界上计算仍基于“pos + 1”从而强制“round_up()”始终返回下一个对齐的边界。 (CVE-2025-68308)

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

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

  - eofs避免因子页面压缩索引损坏而导致的无限循环 Robert 报告称观察到两个特制的 图像存在无限循环。根本原因是在损坏的子页面压缩索引中 !NONFHEAD “lclusters”的“clusterofs”可能大于“lclustersize”例如blocksize = lclustersize = 512 lcn = 6 clusterofs = 515 将完整压缩索引的相应检查移动到“ z_erofs_load_lcluster_from_disk()`也涵盖子页面压缩压缩索引。它还修复了“m->type >= Z_EROFS_LCLUSTER_TYPE_MAX”检查的位置因为其应紧接着放置在“z_erofs_load_{compact,full}_lcluster()”之后。 (CVE-2025-68251)

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

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

  - io_uring/zctx检查链接的 notif 上下文为来自相同上下文的请求仅发送 zc 链接 ubuf_info。存在一些有歧义的 syz 报告让我们检查有关通知完成情况的假设。
    (CVE-2025-68317)

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

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

  - ceph修复 multifs mds auth 端点问题 mds auth 端点检查还应验证 fsname 以及相关的端点。如果不这样做将导致在 multifs ceph 群集中将一个 fs 的 mds auth 端点应用到另一个 fs。此缺陷会导致用户认证发生多种问题以下是一个此类示例。重现步骤在 vstart 群集上1. 在群集中创建两个文件系统如“fsname1”和“fsname2”2. 向用户“client.usr”授予对 fs“fsname1”只读的权限 $ceph fs 授权fsname1 client.usr / rw 3. 向同一用户“client.usr”授权对 fs“fsname2”的读写权限 $ceph fs 授权 fsname2 client.usr / rw 4. 更新 keyring $ceph auth get client.usr > > ./keyring 将上述权限授予用户“client.usr”将出现以下预期。 a。“client.usr”应仅能够读取内容而不允许在文件系统“fsname1”上创建或删除文件。 b. “client.usr”应该能够在文件系统“fsname2”上进行读取/写入。但是由于存在此缺陷因此允许“client.usr”在文件系统“fsname1”上进行读取/写入。详情请参阅下文。 5. 以用户“client.usr”挂载文件系统“fsname1” $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/ 6. 尝试以用户“client”在文件系统“fsname1”上创建文件。 usr' 有关的未知矢量影响可用性。此操作应失败但由于此缺陷而通过。 $touch /kmnt_fsname1_usr/file1 7. 使用用户“client.admin”挂载文件系统“fsname1”并创建文件。 $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin $echo data > /kmnt_fsname1_admin/admin_file1 8. 尝试删除用户“client.usr”下文件系统“fsname1”上的一个现有文件。此操作不应成功但会在出现缺陷的情况下成功。 $rm -f /kmnt_fsname1_usr/admin_file1 有关更多信息请查看相应的 mds/fuse 修补程序和通过调查下面提到的跟踪器而添加的测试。 v2修复 doutc 中可能的空取消引用 v3不存储 mdsmap 中的 fsname针对 ceph_mount_options 的 fsname 进行验证并使用 v4代码重构、改进警告消息并修复可能存在的编译器警告 [ Slava.Dubeykofsname 检查失败 -> fsname不匹配 ] (CVE-2025-40362

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

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

  - nfs4_setup_readdir()不充分的锁定 ->d_parent->d_inode 取消引用 理论上这是一个可 oopsable 的争用但我不认为能够在实际的硬件上击中它可能在 KVM 上变为可攻击但仍不容易受到攻击。无论如何它很容易处理 - 由于 xdr_encode_hyper() 只是 put_unaligned_be64() 的调用因此我们可以将其放在 ->d_lock 下并进行处理。
    (CVE-2025-68185)

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

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

  - cangs_usbgs_usb_xmit_callback()修复对传输失败的 URB 的处理 驱动程序缺少对失败的 URB 传输的清理。这会将每个错误的可用 URB 数减少 1。这会导致性能降低并最终导致传输完全停止。如果发送批量 URB 失败请进行正确的清理 - 增加 netdev 统计数据 - 将 echo_sbk 标记为空闲 - 释放驱动程序的上下文并进行核算 - 唤醒发送队列 (CVE-2025-68307)

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

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

  - libceph防止 handle_auth_session_key() 中潜在的越界写入 len 字段源自不受信任的网络数据包。添加了边界检查以防止在解密连接密钥或处理服务票证时出现潜在的越界写入。 [ idryomov变更日志 ] (CVE-2025-68284)

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

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

  - riscvstacktrace禁用非当前任务的 KASAN 检查展开当前任务以外的任务堆栈KASAN 将报告 BUG: KASANwalk_stackframe+0x41c/0x460 中存在越界。在 x86 上存在相同的问题 并已发布已由提交 84936118bdf3 (x86/unwind禁用非当前任务的 KASAN 检查) 解决 该解决方案也可应用于 RISC-V。此修补程序还可解决以下问题
    https://seclists.org/oss-sec/2025/q4/23 [pjw@kernel.org清除 checkpatch 问题] (CVE-2025-40358)

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

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

  - comedi检查 compat ioctl 中设备的连接状态 Syzbot 发现一个可造成内核崩溃的问题 [1]似乎是因为不存在回调 dev->get_valid_routes() 所导致。无论如何不应发生此问题因为上述回调必须始终设为 __comedi_device_postconfig() 中的 get_zero_valid_routes()。由于崩溃似乎只发生在 i386 内核中因此从 [1] 报告判断原因在于标准 IOCTL 处理程序的兼容版本所致。其中多个经过修改且未使用 comedi_unlocked_ioctl()。虽然这些 ioctl 的功能本质上会复制其原始版本但未对设备的附加状态进行所需的健全性检查。这进而可能导致在未正确设置的设备上调用所选 IOCTL，即使通过 COMEDI_DEVCONFIG 也会如此。在未配置的设备上执行此操作意味着会错过例如指定 dev->get_valid_routes() 回调的多个关键步骤。通过在执行任何 ioctls 之前确保设备的连接状态稍微粗暴地修复此问题从而提高 现代函数与兼容函数之间的逻辑一致性。 [1] Syzbot 报告
    缺陷内核空指针取消引用地址0000000000000000 ... CR2: ffffffffffffffd6 CR3:
    000000006c717000 CR40000000000352ef0 调用跟踪 <TASK> get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline] parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401 do_insnlist_ioctl+0x272/0xedi_fops.c:1401 do_insnlist_ioctl+0x272/0xedi_fops.c:1400 drivers/15edi_fops.c:1322 compat_insnlist drivers/comedi/comedi_fops.c:3208 [内联] comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273 __do_compat_sys_ioctl fs/ioctl.c:695 [内联] __se_compat_sys_ioctl fs/ioctl_sys_ioctl fs/ioctl_sys__l_compatia32[内联] +0x242/0x370 fs/ioctl.c:638 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] ... (CVE-2025-68257)

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

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

  - netatlantic修复 RX 路径中的碎片溢出处理 atlantic 驱动程序在处理大型多描述符数据包时可能收到含有超过 MAX_SKB_FRAGS (17) 碎片的数据包。这会造成 skb_add_rx_frag_netmem() 中发生越界写入进而造成内核错误。发生此问题的原因是 驱动程序未在调用 skb_add_rx_frag() 之前检查碎片总数。当数据包需要超过 MAX_SKB_FRAGS 的碎片时碎片索引超出了数组边界。通过假设在 buff->len > AQ_CFG_RX_HDR_SIZE则考虑所有碎片时将存在额外的 frag来修复。并重用现有检查以防止代码路径中提早发生溢出。这则崩溃发生在生产环境中且使用 Aquantia AQC113 10G NIC。生产环境中的堆栈跟踪`RIP
    0010:skb_add_rx_frag_netmem+0x29/0xd0 代码 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 c08 08 01 ca 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP0018:ffffa9bec02a8d50 EFLAGS00010287 RAX: ffff925b22e80a00 RBX
    ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11:
     R120000000000000000  : ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 调用跟踪 <IRQ> aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ?
    __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 `__ v4 中的变更- 添加 Fixes: 标签以满足修补程序验证要求。v3 中的变更- 通过假设在 buff->len > AQ_CFG_RX_HDR_SIZE 则考虑所有碎片时将存在额外碎片来修复。 (CVE-2025-68301)

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

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

  - mm/huge_memory修复拆分 folio 提交时的空指针取消引用 c010d47f107fmmthp将大型页面拆分为任何较低顺序的页面引入了在继续拆分工作之前通过 mapping->flags 对 folio 的顺序进行提前检查。此检查引入了一个缺陷对于交换缓存中的 shmem folios 和截断的 folio映射指针可能为空。在此状态下访问 mapping->flags 会直接导致空指针取消引用。此次提交通过在尝试访问 mapping->flags 之前移动对 mapping != NULL 的检查来修复 问题。 (CVE-2025-68293)

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

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

  - cifs修复 smb3_fs_context_parse_param 错误路径中的内存泄漏向 cifs_parse_mount_err 错误处理程序添加 ctx->source 和 fc->source 的正确清理。这样可确保在所有错误路径上正确释放为源字符串分配的内存匹配 smb3_cleanup_fs_context_contents() 在成功路径中已执行的清理。释放后指针也会设置为空以防止潜在的双重释放问题。此更改修复最初由 syzbot 检测的内存泄漏。如果在成功分配 ctx->source 和 fc->source 之后但在函数完成之前发生错误则在处理 Opt_source 挂载选项时会发生泄露。具体的泄漏顺序为 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') 分配内存 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) 分配更多内存 3. 后续错误会跳转到 cifs_parse_mount_err 4. 旧的错误处理程序释放了密码但没有释放源字符串从而造成内存泄露。提交 e8c73eb7db0acifsclient修复 smb3_fs_context_parse_param 中的内存泄漏没有解决此问题它只修复来自重复的 fsconfig() 调用的泄漏而不是此错误路径。使用内核测试机器人建议的次要更改更新了修补程序 (CVE-2025-68219)

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

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

  - mtdchar修复读取/写入 ioctl 中的整数溢出 req.start 和 req.len 变量为在函数开始时由用户提供的 u64 值。我们屏蔽了 req.len 的高 32 位以便将其限制为 U32_MAX但 req.start 变量可达到 U64_MAX这意味着加法运算仍可发生整数溢出。使用 check_add_overflow() 修复此缺陷。 (CVE-2025-68237)

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

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

  - erofs避免由于不完整的 zstd 压缩数据而导致的无限循环。如果在特制故意损坏的图像中截断压缩数据目前解压缩逻辑会错误地旋转。
    (CVE-2025-68210)

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

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

  - drm/amdgpu/atom检查 amdgpu_atom_execute_table_locked() 中 WS 缓冲区的 kcalloc() kcalloc() 可能会失败。
    当 WS 为非零且分配失败时ectx.ws 在设置 ectx.ws_size 时保持为 NULL当访问 WS 条目时导致 atom_get_src_int() 中可能发生空指针取消引用。分配失败时返回 -ENOMEM 以避免空取消引用。 (CVE-2025-68190)

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

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

  - afs修复单元匿名密钥的延迟分配 单元匿名密钥的分配与其他单元设置一起在后台线程中完成例如执行 DNS 上调。在报告的缺陷中触发方式为 afs_parse_source() 解析提供给 mount() 的设备名称并使用单元名称调用 afs_lookup_cell()。然后正常密钥查找尝试使用匿名认证密钥的密钥描述作为 request_key() 的引用 - 但可能尚未设置因此可能发生 oops。修复动态查找失败后更有可能发生此问题。修复此问题的方法是在创建记录时首先分配引用名称并将其附加到 afs_cell 记录。它可与 cell name 共享内存分配遗憾的是它不能通过在单元格名称前面预加 afs@ 来将其重叠因为单元格名称已经具有用于其他目的的前缀“.”。然后此引用名称会传递至 request_key()。此外现在会在 afs_request_key() 中请求密钥时根据需要分配 anon 密钥如果尚未分配。互斥体用于防止对一个单元格进行多种分配。第三如果匿名密钥尚未分配如果我们需要使 afs_request_key_rcu() 返回 NULL然后调用程序可返回 -ECHILD 以退出 RCU 模式并且可调用 afs_request_key()。请注意匿名密钥对于使密钥查找缓存工作是必需的因为匿名密钥当前不会缓存负查找但可能值得进行一些调查以查看是否可以改用 NULL。 (CVE-2025-68299)

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

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

  - udp_tunnel使用 netdev_warn() 而非 netdev_WARN() netdev_WARN() 使用 WARN/WARN_ON 打印回溯以及文件和行信息。在这种情况下udp_tunnel_nic_register() 返回的错误只是失败的操作而非内核缺陷。 udp_tunnel_nic_register() 可能因内存分配失败kzalloc() 或 udp_tunnel_nic_alloc()而失败。这是正常的运行时错误不是内核缺陷。相应地将 netdev_WARN() 替换为 netdev_warn()。 (CVE-2025-68191)

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

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

  - drm/tegra添加对 put_pid() 的调用 添加对与 get_task_pid() 对应的 put_pid() 的调用。
    host1x_memory_context_alloc() 未取得 PID 的所有权因此我们需要在此处释放以避免泄漏。 [mperttunen@nvidia.com改写提交消息]CVE-2025-68233

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

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

  - drm/amd/display修复 debugfs odm_combine_segments 中的空取消引用。当连接器已连接但不活动时例如被桌面环境禁用pipe_ctx->stream_res.tg 将被破坏。然后读取 odm_combine_segments 会造成内核空指针取消引用。缺陷内核空指针取消引用地址0000000000000000 #PF内核模式下的主管读取访问权限 #PFerror_code(0x0000) - 不存在页面 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 16 UID 0 PID26474 Commcat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 硬件名称LENOVO 21Q4/LNVNB161216、BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0xpumpt[Code: 0010:odm_combine_segments_show+0x93] 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 00 8b 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX
    ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11:
     R120000000000000000  : ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 调用跟踪 <TASK> seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 count_memcg_events+0xc2/0x190? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00> RSP002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX
    ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10:
     R110000000000000000  : 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 </TASK> Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profilejoydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ 结束跟踪 0000000000000000 ]--- RIP:
    0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] 代码4183 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 bc 0d 85 c9 48 8b 74 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX
    ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12:
    ffffd1bf4b953d08 R130000000000040000 R140000000000000001 R150000000000000001 FS
    00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554通过检查 pipe_ctx-> 来修复此问题 ---truncated--- (CVE-2025-68180)

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

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

  - arm64mte如果已在 copy_highpage() 中标记页面则不发出警告 arm64 copy_highpage() 假设目标页面新分配且未标记 MTE (PG_mte_tated 未设置)并相应地发出警告。但是在提交 060913999d7ammmigrate支持从迁移 folio 中恢复之后会在 __folio_migrate_mapping() 之前调用 folio_mc_copy()。如果后者失败 (-EAGAIN)则将再次复制到相同的目标页面。由于 copy_highpage() 已设置 PG_mte_taged 标记因此第二个副本将发出警告。将 arm64 copy_highpage() 中的 WARN_ON_ONCE页面已被标记为注释。 (CVE-2025-40353)

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

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

  - mm/mempool修复了中毒的 HIGMEM order>0 页面 内核测试报告了BUG无法处理地址 fffba000 的页面错误 #PF内核模式下的主管写入访问 #PFerror_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm
    swapper/0 受感染GT 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca 受感染[T]=RANDSTRUCT 硬件名称QEMU Standard PC (i440FX + PIIX,1996)BIOS 1.1.16.3 -2 2014 年 4 月 1 日 EIPmemset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) 代码a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 <f3> aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 5 53 57 56 EAX: 0000006b EBX
    00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES
    007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 调用跟踪poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool_init_node (mm/mempool_init_node) .c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250标识符 1) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (dispensator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph 发现这是由于中毒代码未正确处理 CONFIG_HIGHMEM 因为只映射第一页然后映射整个潜在高阶页页进行访问。我们可以在此处放弃 HGHMEM但修复此问题十分简单通过可映射、中毒或检查和取消映射单个页面的循环即可。 (CVE-2025-68231)

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

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

  - timers修复 timer_shutdown_sync() 中的空函数指针争用 timer_shutdown_sync() 和定时器到期之间存在争用条件可导致在 expire_timers() 中命中 WARN_ON。当定时器仍在另一 CPU 上运行时timer_shutdown_sync() 将定时器函数清除为空时会出现此问题。争用场景如下所示 CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...
    timer_shutdown_sync() lock_timer_base() // 目前不会分离定时器而仅将其函数清除为空 if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn 退出] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // 现在定时器待定而其功能设置为 NULL。 // 下一个定时器触发器 <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // 命中 ... lock_timer_base() // 现在定时器将分离 if (base->running_timer != timer) ret = detach_if_pending(timer, base, true) ; if (shutdown) timer->function = NULL; unlock_timer_base() 问题在于 timer_shutdown_sync() 会清除定时器函数而不管定时器当前是否在运行。这可使待定定时器具有空函数指针从而触发 expire_timers() 中的 WARN_ON_ONCE(!fn) 检查。通过在实际分离定时器时仅清除定时器函数来修复此问题。如果定时器正在运行，请完整地保留函数指针。这样做是安全的，因为定时器将在其运行结束时正确分离。
    (CVE-2025-68214)

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

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

  - ftrace修复 ftrace_module_enable 中的软锁定。加载 amdgpu 模块时发现软锁定。如果模块具有大量可跟踪函数对 kallsyms_lookup 的多个调用可在 RCU 重要部分花费过多时间并且禁用禁用抢占从而导致内核错误。此问题在提交 d0b24b4e91fc (ftrace)防止 RCU 在 PREEMPT_VOLUNTARY 内核上停止和提交 42ea22e754ba (ftrace将 cond_resched() 添加到 ftrace_graph_set_hash()) 中修复的问题相同。通过在 ftrace_module_enable 中添加 cond_resched() 以相同的方式修复此问题。 (CVE-2025-68173)

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

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

  - nilfs2避免在释放 sci 之前有活动的 sc_timer 由于 kthread_stop 未正确停止 sc_task 并返回 -EINTRsc_timer 未正确关闭 最终导致释放 sci 时 syzbot 报告的问题 [1]原因在于未关闭 sc_timer 。由于线程 sc_task 主函数 nilfs_segctor_thread() 在成功时会返回 0因此在 nilfs_segctor_destroy() 中当 kthread_stop() 的返回值非 0 时我们认为其未正确关闭 sc_timer。我们使用 timer_shutdown_sync() 来同步等待 sc_timer 关闭并在锁 sc_state_lock 的保护下将 sc_task 的值设置为空以避免因 sc_timer 未正确关闭而造成的问题。 [1] ODEBUGfree activeactive state 0object: 00000000dacb411a object type: timer_list hint: nilfs_construction_timeout Call tracenilfs_segctor_destroy fs/nilfs2/segment.c:2811 [inline] nilfs_detach_log_writer+0x668/0x8cc fs/nilfs2/segment.c 2877 nilfs_put_super+0x4c/0x12c fs/nilfs2/super.c:509 (CVE-2025-68240)

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

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

  - sysfs自提交 0c17270f9b92 后在更改群组属性所有权之前检查可见性 (netsysfs
    为 phys_(port_id, port_name, switch_id)) 实现 is_visible当尝试更改不可见的文件的所有者时 __dev_change_net_namespace() 会命中 WARN_ON()。请参阅下面的跟踪WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30 CPU: 6 UID: 0 PID: 2938 Comm
    incusd 未受感染 6.17.1-1-mainline #1 PREEMPT(full) 4b783b4a638669fb644857f484487d17cb45ed1f 硬件名称Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07、BIOS 03.07 2025 年 2 月 19 日 RIP
    0010:__dev_change_net_namespace+0xb89/0xc30 [...] 调用跟踪 <TASK> ? if6_seq_show+0x30/0x50 do_setlink.isra.0+0xc7/0x1270 ? __nla_validate_parse+0x5c/0xcc0 ? security_capable+0x94/0x1a0 rtnl_newlink+0x858/0xc20 ? update_curr+0x8e/0x1c0 ? update_entity_lag+0x71/0x80 ? sched_balance_newidle+0x358/0x450 ? psi_task_switch+0x113/0x2a0 ? __pfx_rtnl_newlink+0x10/0x10 rtnetlink_rcv_msg+0x346/0x3e0 sched_clock+0x10/0x30 __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0
    __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 __sys_bind+0xe3/0x110 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? sock_alloc_file+0x63/0xc0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? alloc_fd+0x12e/0x190 ? put_unused_fd+0x2a/0x70 ? do_sys_openat2+0xa2/0xe0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> 通过在尝试接触属性之前检查 is_visible() 来修复此问题。 (CVE-2025-40355)

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

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

  - netconsole在导航配置层次之前获取 su_mutex 迭代 userdata cg_children 列表的操作与通过 configfs 并发添加/删除 userdata 项目之间存在争用。
    update_userdata() 函数会迭代 nt->userdata_group.cg_children 列表count_extradata_entries() 也会迭代此相同列表以计数节点。引用自 Documentation/filesystems/configfs.rst: > 子系统可以在 cg_children 列表和 ci_parent 指针中导航 > 以查看子系统创建的树状结构。这会与 configfs 的 > 层次管理争用因此 configfs 使用子系统互斥体 > 保护修改。每当子系统想要在 > 层次结构中导航时, 都必须在子系统 > 互斥体的保护下进行。在没有正确锁定的情况下，如果在迭代这些函数时并发添加或删除用户数据项目，则列表可能会处于不一致的状态。例如list_for_each() 循环可到达由 list_del_init() 从列表中删除的节点将节点的 .next 指针设置为指向其自身因此循环将永不结束或到达 update_userdata( )。通过在迭代 cg_children 的所有操作期间保留 configfs 子系统互斥体 (su_mutex) 来修复此问题。这包括 - 调用 update_userdata() 以迭代 cg_children 的 userdatum_value_store() - 调用 count_extradata_entries() 以迭代 cg_children 的所有 sysdata_*_enabled_store() 函数 必须在 dynamic_netconsole_mutex 之前获取 su_mutex 以避免潜在的锁定排序问题原因是 configfs 操作在调用我们的代码时可能已经保留了 su_mutex。 (CVE-2025-68319)

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

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

  - x86/fpu确保信号传递时的 XFD 状态Sean 报告了 [1] 在运行 KVM 测试时会出现以下 splat
    WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2]涉及信号传递的可重现场景非 AMX 任务被启用了 AMX 的任务抢占从而修改 XFD MSR。当非 AMX 任务恢复并重新加载具有 init 值的 XSTATE 时由于 fpstate::xfd 和 CPU 的当前 XFD 状态不匹配会触发警告。在抢占后fpu__clear_user_states() 当前不会重新同步 XFD 状态。存在动态功能时调用 xfd_update_state()其检测并修正不匹配情况。这也有利于 sigreturn 路径因为当 sigframe 不可访问时fpu__restore_sig() 可能会调用 fpu__clear_user_states()。 [ dhansen次要变更日志修改 ] (CVE-2025-68171

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

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

  - fs/namespace修复 grab_requested_mnt_ns lookup_mnt_ns() 已在 mnt_ns 中取得引用中的引用泄漏。 grab_requested_mnt_ns() 不需要采用额外的引用。 (CVE-2025-68300)

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

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

  - usb小工具udc修复 usb_gadget_state_work 中的释放后使用。小工具拆卸期间的争用条件可导致 usb_gadget_state_work() 中的释放后使用由 KASAN 报告缺陷KASANsysfs_notify+ 中存在无效访问0x2c/0xd0 工作队列事件 usb_gadget_state_work 发生基本的争用因为并发事件例如中断可在 usb_del_gadget() 中的清理过程期间随时调用 usb_gadget_set_state() 和计划 gadget->work。提交 399a45e5237c usbgadget:core在设备删除后刷新小工具工作队列尝试通过将 flush_work() 移动到 device_del() 之后来修复此问题。
    但是这并不能完全解决争用因为在 flush_work() 完成*之后*flush_work() 完成但在释放小工具的内存之前仍可计划新的工作项目进而导致相同的释放后使用。此修补程序通过向 usb_gadget 结构引入“teardown”标记和“state_lock”旋转锁彻底修复了争用条件。*在*之前*在清除期间*调用 flush_work() 以防止在清除开始后计划任何新工作时 usb_del_gadget() 中设置此标记。计划站点 usb_gadget_set_state() 现在会在排队工作之前检查锁定下的此标记从而安全关闭争用窗口。 (CVE-2025-68282)

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

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

  - netipv6修复 AH 输出中的跨域 memcpy 警告 修复 ah6_output() 和 ah6_output_done() 中的跨域 memcpy 警告其中扩展标头是复制到 IPv6 地址字段以及从 IPv6 地址字段复制触发关于超出 16 个写入的 fortify-string 警告-byte 地址字段。 memcpy在 net/ipv6/ah6.c:439 处检测到单个字段 &top_iph->saddr 的字段跨度写入大小 16警告net/ipv6/ah6.c:439 的 CPU0 PID8838 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439这些警告为误报因为有意将扩展标头放置在内存中的 IPv6 标头之后。通过分别正确复制地址和扩展标头修复 并引入辅助函数以避免代码重复。 (CVE-2025-40363)

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

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

  - ASoCSDCA解析时的缺陷 mipi-sdca-control-cn-list struct sdca_control 将值字段声明为整数数组。但为其分配的内存为 char 数组内存。这会造成 sdca_parse_function API 崩溃。此 修补程序通过分配正确的数据大小解决 问题。 (CVE-2025-68281)

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

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

  - nvme修复 admin request_queuelifetime 命名空间可访问控制器的 admin request_queue拆卸控制器后命名空间中的过时引用可能存在。在释放所有控制器引用后将控制器的“put”移至 以确保管理 request_queue 处于活动状态以确保没有人可以访问 request_queue。这修复了一个报告的释放后使用缺陷 BUG
    KASAN由任务 nvme/3287 CPU67 UID0 PID3287 Commnvme 受感染的 GE 6.13.2-ga1582f1a031e 在地址 ffff88c0a53819f8 进行大小 8 的 blk_queue_enter+0x41c/0x4a0 读取中发生 slab 释放后使用释放后使用 #15 受感染其他
    [E]=UNSIGNED_MODULE 硬件名称Jabil /EGS 2S MB1、BIOS 1.00 06/18/2025 调用跟踪 <TASK> dump_stack_lvl+0x4f/0x60 print_report+0xc4/0x620 ? _raw_spin_lock_irqsave+0x70/0xb0 ?
    _raw_read_unlock_irqrestore+0x30/0x30 ? blk_queue_enter+0x41c/0x4a0 kasan_report+0xab/0xe0 blk_queue_enter+0x41c/0x4a0 blk_queue_enter+0x41c/0x4a0 ? __irq_work_queue_local+0x75/0x1d0 ? blk_queue_start_drain+0x70/0x70 ? irq_work_queue+0x18/0x20 ? vprintk_emit.part.0+0x1cc/0x350 wake_up_klogd_work_func+0x60/0x60 blk_mq_alloc_request+0x2b7/0x6b0 ? __blk_mq_alloc_requests+0x1060/0x1060 ? __switch_to+0x5b7/0x1060 nvme_submit_user_cmd+0xa9/0x330 nvme_user_cmd.isra.0+0x240/0x3f0? force_sigsegv+0xe0/0xe0 ? nvme_user_cmd64+0x400/0x400 ? vfs_fileattr_set+0x9b0/0x9b0 cgroup_update_frozen_flag+0x24/0x1c0 ? cgroup_leave_frozen+0x204/0x330 ? nvme_ioctl+0x7c/0x2c0 blkdev_ioctl+0x1a8/0x4d0 ? blkdev_common_ioctl+0x1930/0x1930 ? fdget+0x54/0x380
    __x64_sys_ioctl+0x129/0x190 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP
    0033:0x7f765f703b0b 代码 ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 d00 <48> [0f 1e fa b8 10 00 00 d00] 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX
    00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11:
    0000000000000202 R120000000000000003 R1300000000c0484e41 R140000000000000001 R1500007ffe2cefea60 </TASK> (CVE-2025-68265)

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

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

  - nouveau/firmware添加 nvkm_falcon_fw::boot 缺少的 kfree() nvkm_falcon_fw::boot 已分配但无人释放。这会产生 kmemleak 警告。确保已取消分配此数据。 (CVE-2025-68235)

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

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

  - ring-buffer当阅读器跟上时不在 ring_buffer_map_get_reader() 中发出警告 函数 ring_buffer_map_get_reader() 比其他 get 阅读器函数更严格rb_get_reader_page() 不应返回 NULL。如果包含，则会触发警告。
    触发了此警告但查看原因后发现这是因为另一个可接受的情况正在发生而未对其进行检查。如果阅读器跟上写入器并且阅读器页面上仍有数据可读则 rb_get_reader_page() 将返回 NULL因为没有新的页面可获得。在这种情况下，不应更新阅读器页面并且不应触发任何警告。 (CVE-2025-68186)

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

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

  - drm/amd/display增加最大链接计数并修复 link->enc 空指针访问 [原因] 1.) dc->links[MAX_LINKS] 数组大小小于实际请求。 max_connector + max_dpia + 4 个虚拟 = 14。
    从 12 增加到 14。2.) dpia 非 display_endpoint 的 hw_init() 访问空 LINK_ENC。从提交 d7f5a61e1b04ed87b008c8d327649d184dc5bb45 中精选出的内容(CVE-2025-40354)

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

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

  - f2fs修复以检测 free_nid_list 中潜在损坏的 nid 据报告磁盘上的 footer.ino 和 footer.nid 是相同的但都超出范围我们来对 f2fs_alloc_nid() 添加健全性检查以检测 free_nid_list 中任何潜在的损坏。 (CVE-2025-68315)

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

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

  - veth更健全的争用处理以避免 txq 卡住。Commit dc82a33297fcveth在完整 ptr_ring 上应用 qdisc 背压以减少 TX 丢弃引入了一种争用条件可导致永久停止 TXQ。在 ARM64 系统 (Ampere Altra Max) 的生产中已发现此问题。veth_xmit() 中发生争用。生产者观察到 ptr_ring 已满并停止队列 (netif_tx_stop_queue())。
    预期在使用者刚清空队列时重新唤醒队列 (if (__ptr_ring_empty(...)) netif_tx_wake_queue()) 的后续条件逻辑可能会失败。这会导致 TXQ 保持停止状态时丢失唤醒 (QUEUE_STATE_DRV_XOFF) 和流量停止。此失败的原因是生产者端对 __ptr_ring_empty() API 的使用不正确。如内核注释中所述如果使用者在其他 CPU 上操作则不保证此检查是正确的。空测试基于 ptr_ring->consumer_head因此仅对使用者可靠。从生产者端使用此检查从根本上是有缺陷的。此修补程序通过采用修补程序集早期版本 V4 中更健全的逻辑修复争用该逻辑始终刷新对等(1) 在 veth_xmit() 中已删除 racy 条件唤醒逻辑及其内存屏障。相反，在停止队列后，我们会无条件调用
    __veth_xdp_flush(rq)。这可保证 NAPI 用户得到安排，使其独自负责重新唤醒 TXQ。这可处理 veth_poll() 消耗所有数据包并完成 NAPI 的争用
    * *之前* 生产者端的 veth_xmit() 已调用 netif_tx_stop_queue。__veth_xdp_flush(rq) 会发现 rx_notify_masked 为 false 并计划 NAPI。 (2) 在使用者端将用于唤醒对等机 TXQ 的逻辑从 veth_xdp_rcv() 中移出并放置在 veth_poll() 函数的末尾。此放置是修复争用的一部分因为 netif_tx_queue_stopped() 检查必须在 NAPI 完成期间rx_notify_masked 可能设置为 false 之后发生。这可处理 veth_poll() 消耗所有数据包但尚未完成的争用rx_notify_masked 仍为 true。生产者 veth_xmit() 停止 TXQ 并
    __veth_xdp_flush(rq) 会发现 rx_notify_masked 为 true表示不启动 NAPI。然后 veth_poll() 将 rx_notify_masked 更改为 false 并停止 NAPI。在退出 veth_poll() 之前将会观察到 TXQ 是否停止并将其唤醒。 (CVE-2025-68232)

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

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

  - cryptoaspeed - 修复 devm 造成的双重释放通过 devm_clk_get_enabled() 获得的时钟由 devres 自动管理并将在驱动程序分离时禁用和释放。在错误路径中手动调用 clk_disable_unprepare() 并删除函数会造成双重释放。删除 aspeed_acry_probe() 的错误路径和 aspeed_acry_remove() 中的手动时钟清理。 (CVE-2025-68172)

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

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

  - netsxgbe修复 sxgbe_rx() 中潜在的空取消引用目前当 skb 为空时驱动程序会打印一个错误然后在下一行取消引用 skb。要修复此问题我们在错误消息后添加一个“break”以切换至 sxgbe_rx_refill()其类似于其他驱动在此特定情况下所采用的方法例如带有 xgmac_rx() 的 calxeda。在代码审查期间发现。 (CVE-2025-68302)

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

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

  - comedimultiq3审查 multiq3_attach() 中的配置选项 Syzbot 在 multiq3_attach() 中发现一个问题 [1] 可因 open() 或 COMEDI_DEVCONFIG ioctl 操作而导致任务超时尤其是在 multiq3 驱动程序的情况下。当 syzkaller 设法构建用于指定编码器子设备中的通道数量的异常配置选项时出现此问题。如果通过 it->options[2] 将特别大的数字传递到 multiq3_attach() 中的 s->n_chan则在驱动程序特定的 attach() 方法结束时对 multiq3_encoder_reset() 的多次调用将运行数分钟因此也会阻止任务和受影响的设备。虽然此问题对于实际设备而言很可能不会太危险但其对于审查配置输入仍然有意义。为编码器芯片数量（最多 4 芯片，每个芯片有 2 个通道）启用合理的限制，以阻止此行为出现。 [1] Syzbot crash: INFO: task syz.2.19:6067 被阻断超过 143 秒。 ... 调用跟踪 <TASK> context_switch kernel/sched/core.c:5254 [inline] __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862 __schedule_loop kernel/sched/core.c:6944 [inline] schedule+0x165/0x360 kernel/sched/core.c:6959 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016 __mutex_lock_common kernel/locking/mutex.c:676 [inline] __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760 comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868 chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414 do_dentry_open+0x953/0x13f0 fs/open.c:965 vfs_open+0x3b/0x340 fs/open.c:1097 ... (CVE-2025-68258

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

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

  - media imon使 send_packet() 更强健 syzbot 报告 imon 存在三个问题由于永远保持设备锁定而导致任务挂起 [1]。第一个问题是如果 usb_rx_callback_intf0() 在 ictx->dev_present_intf0 为真后得到 -EPROTO 错误usb_rx_callback_intf0() 会在 printk() 后重新提交 urb 而重新提交的 urb 会造成 usb_rx_callback_intf0() 再次得到 -EPROTO 错误。这导致 printk() 洪流RCU 停止。Alan Stern 评论 [2] 理论上可以重新提交
    如果_驱动程序具有健全的错误恢复方案例如在错误数量的某些固定限制后或在经过某些固定时间后可能会延迟以防止错误洪流后放弃。
    大多数驱动程序不会打扰您执行此操作;他们会立即放弃。这使得它们在 USB 传输期间更容易受到短期噪声的干扰，但实际上这种干扰非常罕见。
    立即放弃并没有什么错。但 imon 的错误恢复方案表现不佳它会一直重试应修复此行为。由于不确定 imon 用户在遇到任何错误代码时放弃是否安全此修补程序仅处理从 drivers/media/rc/ 目录中用于处理 -EPROTO 错误即 ir_toy 、mceusb 和 igorplugusb。第二个问题是当 usb_rx_callback_intf0() 在 ictx->dev_present_intf0 变为 true 之前得到 -EPROTO 错误时usb_rx_callback_intf0() 始终会重新提交 urb 原因是提交 8791d63af0cf ([media] imon未在早期回调后插入硬件)。将提交 6f6b90c9231a[media] imon不要解析扫描码直到配置 intf引入的 ictx->dev_present_intf0 测试移动到紧接着的 imon_incoming_packet() 之前否则会发生上述第一个问题而无 printk() 洪流即任务挂起。第三个问题是当 usb_rx_callback_intf0() 由于某种原因未被调用时例如片状硬件此问题的重现器有时会阻止调用 usb_rx_callback_intf0()send_packet() 中的 wait_for_completion_interruptible() 永不返回即挂起的任务。作为此类情况的变通方案，将 send_packet() 更改为在超时为 10 秒的情况下等待完成。 (CVE-2025-68194)

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

ID	名称	严重性
278844	Linux Distros 未修补的漏洞：CVE-2025-68261	high
278843	Linux Distros 未修补的漏洞：CVE-2025-68209	medium
278842	Linux Distros 未修补的漏洞：CVE-2025-68202	medium
278841	Linux Distros 未修补的漏洞：CVE-2025-68289	medium
278840	Linux Distros 未修补的漏洞：CVE-2025-68208	high
278839	Linux Distros 未修补的漏洞：CVE-2025-68242	medium
278838	Linux Distros 未修补的漏洞：CVE-2025-68213	medium
278837	Linux Distros 未修补的漏洞：CVE-2025-68320	high
278836	Linux Distros 未修补的漏洞：CVE-2025-68245	medium
278835	Linux Distros 未修补的漏洞：CVE-2025-68308	medium
278834	Linux Distros 未修补的漏洞：CVE-2025-68251	medium
278832	Linux Distros 未修补的漏洞：CVE-2025-68317	medium
278831	Linux Distros 未修补的漏洞：CVE-2025-40362	high
278830	Linux Distros 未修补的漏洞：CVE-2025-68185	medium
278829	Linux Distros 未修补的漏洞：CVE-2025-68307	medium
278828	Linux Distros 未修补的漏洞：CVE-2025-68284	medium
278827	Linux Distros 未修补的漏洞：CVE-2025-40358	medium
278826	Linux Distros 未修补的漏洞：CVE-2025-68257	medium
278825	Linux Distros 未修补的漏洞：CVE-2025-68301	high
278824	Linux Distros 未修补的漏洞：CVE-2025-68293	medium
278823	Linux Distros 未修补的漏洞：CVE-2025-68219	medium
278822	Linux Distros 未修补的漏洞：CVE-2025-68237	high
278821	Linux Distros 未修补的漏洞：CVE-2025-68210	medium
278820	Linux Distros 未修补的漏洞：CVE-2025-68190	medium
278819	Linux Distros 未修补的漏洞：CVE-2025-68299	medium
278818	Linux Distros 未修补的漏洞：CVE-2025-68191	medium
278817	Linux Distros 未修补的漏洞：CVE-2025-68233	high
278816	Linux Distros 未修补的漏洞：CVE-2025-68180	high
278815	Linux Distros 未修补的漏洞：CVE-2025-40353	low
278814	Linux Distros 未修补的漏洞：CVE-2025-68231	high
278813	Linux Distros 未修补的漏洞：CVE-2025-68214	medium
278812	Linux Distros 未修补的漏洞：CVE-2025-68173	medium
278811	Linux Distros 未修补的漏洞：CVE-2025-68240	medium
278810	Linux Distros 未修补的漏洞：CVE-2025-40355	medium
278809	Linux Distros 未修补的漏洞：CVE-2025-68319	medium
278808	Linux Distros 未修补的漏洞：CVE-2025-68171	medium
278807	Linux Distros 未修补的漏洞：CVE-2025-68300	high
278806	Linux Distros 未修补的漏洞：CVE-2025-68282	high
278805	Linux Distros 未修补的漏洞：CVE-2025-40363	medium
278804	Linux Distros 未修补的漏洞：CVE-2025-68281	medium
278803	Linux Distros 未修补的漏洞：CVE-2025-68265	high
278802	Linux Distros 未修补的漏洞：CVE-2025-68235	high
278801	Linux Distros 未修补的漏洞：CVE-2025-68186	medium
278800	Linux Distros 未修补的漏洞：CVE-2025-40354	medium
278798	Linux Distros 未修补的漏洞：CVE-2025-68315	high
278797	Linux Distros 未修补的漏洞：CVE-2025-68232	medium
278796	Linux Distros 未修补的漏洞：CVE-2025-68172	medium
278795	Linux Distros 未修补的漏洞：CVE-2025-68302	medium
278794	Linux Distros 未修补的漏洞：CVE-2025-68258	medium
278793	Linux Distros 未修补的漏洞：CVE-2025-68194	medium

检测

Nessus 的 Misc. 系列

high

medium

medium

medium

high

medium

medium

high

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium

medium

high

high

low

high

medium

medium

medium

medium

medium

medium

high

high

medium

medium

high

high

medium

medium

high

medium

medium

medium

medium

medium