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

  - smb 客户端修复 cifs_construct_tcon() 中的内存泄漏当指定了 domain= 进行多用户挂载并使用 cifscreds 时cifs_set_cifscreds() 最终将以设置 @ctx->domainname因此需要在离开 cifs_construct_tcon() 之前将其释放。此更新修复 kmemleak 报告的下列内存泄漏问题
    mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > / sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak 未引用的对象 0xffff8881203c3f08大小 8comm ls、pid 5060、jiffies 4307222943 十六进制转储前 8 个字节5a 45 4c 44 41 00 cc cc ZELDA。回溯 (crc d109a8cf)
    __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2025-68295)

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

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

  -mostusb修复延迟探测失败时的双重释放 MOST 子系统具有非标准注册函数可在注册失败和取消注册时释放接口。这不足为奇会导致 MOST 驱动程序中出现缺陷并且最近的一些更改将 USB 驱动程序中的引用下溢和释放后使用转变为延迟探测失败时的多个双重释放和释放后使用。
    (CVE-2025-68290)

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

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

  - scsitargettcm_loop修复 tcm_loop_tpg_address_show() 中的段错误 如果 tcm_loop_driver_probe() 中 tl_hba->sh 的分配失败而我们尝试在 tcm_loop_tpg_address_show() 中取消引用它则会发生段错误请参阅下文的示例。因此请在取消引用 tl_hba->sh 之前对其进行检查。无法分配 struct scsi_host BUG内核空指针取消引用地址0000000000000194 #PF内核模式下存在主管读取访问权限 #PFerror_code(0x0000) - 不存在页面 PGD 0 P4D 0 Oops0000 [#1] PREEMPT SMP NOPTI CPU1 PID8356 通信tokio-runtime-w 未受感染 6.6.104.2-4.azl3 #1 硬件名称Microsoft Corporation 虚拟机/虚拟机BIOS Hyper-V UEFI 版本 v4.1 2024 年 9 月 28 日 RIP其他
    0010tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... 调用跟踪 <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ... (CVE-2025-68229)

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

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

  - nvme-multipath修复由于分区扫描导致的 lockdep WARN Blktests 测试案例 nvme/014、057 和 058 偶尔因 lockdep WARN 而失败。据关闭标签 URL 中的报告该 WARN 表示由于 disk->open_mutex、kblockd workqueue 完成与 Partition_scan_work 完成之间的依存关系可能发生死锁。要避免 lockdep WARN 和潜在的死锁请通过 nvme_wq而非 kblockd 工作队列运行partition_scan_work来中断依存关系。 (CVE-2025-68218)

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

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

  - ksmbd在每个 IP 的限制拒绝连接时关闭已接受的套接字。在 ksmbd_kthread_fn() 中超过每个 IP 的连接限制时代码会设置 ret = -EAGAIN 并继续接受循环而不关闭刚接受的套接字。这样会从单个 IP 中每次被拒绝的尝试泄露一个套接字并造成轻微的远程 DoS。释放 client_sk 然后再继续。此缺陷在 ZeroPath 中发现。
    (CVE-2025-68246)

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

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

  - amd/amdkfd增强切换分区中的 kfd 进程检查当前切换分区仅检查 kfd_processes_table 是否为空。 kfd_processes_table 条目已在 kfd_process_notifier_release 中删除但 kfd_process 拆卸会在 kfd_process_wq_release 中进行。考虑使用两个进程进程 A (workqueue) -> kfd_process_wq_release -> 访问 kfd_node 成员进程 B 交换分区 -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw -> kfd_node 拆卸。进程 A 和 B 可能会触发争用如 dmesg 日志中所示。此修补程序通过添加原子 kfd_process 计数器 kfd_processes_count 来解决争用该问题在创建 kfd 进程时递增其在完成 kfd_process_wq_release 时递减。 v2按 kfd_dev 放置 kfd_processes_count将减量移动到 kfd_process_destroy_pdds 和缺陷补丁。(Philip Yang) [3966658.307702] 除法错误0000 [#1] SMP NOPTI [3966658.350818] i10nm_edac [3966658.356318] CPU124 PID38435 Commkworker/124:0 Kdumploaded Tainted [3966658.356890] Workqueuekfd_process_wq kfd_process_wq_release [amdgpu] [3966658.362839] nfit [3966658.366457] RIP0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu] [3966658.366460] 代码00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 <f7> be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 [3966658.38096700 ] x86_pkg_temp_thermal [3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246 [3966658.391531] RAX
    0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000 [3966658.391531] RDX: 0000000000000000 RSI
    ffff888129154400 RDIffff888129151c00 [3966658.391532] RBPffff8883ad79d400 R080000000000000000 R09
    ffff8890d2750af4 [3966658.391532] R100000000000000018 R11R120000000000000018 [] 0000000000000000 [3966658.391533R14R13ffff8883ad79d400 R15ffffe87ff662ba00 [3966658.391533b] 5084
    0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000 [3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4:
    0000000002770ee0 [3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [3966658.391536] PKRU:
    55555554 [3966658.391536] 调用跟踪[3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu] [3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu] [3966658.399754] intel_powerclam [3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu] [3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu] [3966658.410516] coretemp [3966658.434016] process_one_work+0x1ad/0x380 [3966658.434021] worker_thread+0x49/0x310 [3966658.438963] kvm_intel [3966658.446041] ? process_one_work+0x380/0x380 [3966658.446045] kthread+0x118/0x140 [3966658.446047] ?
    __kthread_bind_mask+0x60/0x60 [3966658.446050] ret_from_fork+0x1f/0x30 [3966658.446053] 链接的模块
    kpatch_20765354(OEK) [3966658.455310] kvm [3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK) [3966658.473462] idxd_mdev [3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo ---truncated--- (CVE-2025-68174)

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

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

  - page_pool始终添加 ATOMIC 分配的 GFP_NOWARN 驱动程序作者经常忘记为来自 datapath 的页面分配添加 GFP_NOWARN。这对用户来说很烦人因为 OOM 是不争的事实而我们非常希望网络 Rx 在 OOM 期间遇到页面分配失败。使页面池默认为 ATOMIC 分配添加 GFP_NOWARN。 (CVE-2025-68321)

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

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

  - drm/mediatek在 Mediatek DRM 驱动程序提交 c410fa9b07c3 上禁用 AFBC 支持drm/mediatek向 Mediatek DRM 驱动程序添加 AFBC 支持向 Mediatek DRM 添加 AFBC 支持并启用 32x8/split/sparse 修改程序。然而此问题目前在 Mediatek MT8188 Genio 700 EVK 平台上遭到破坏已使用上游“内核”和“Mesa (v25.2.1)”进行测试自 Mesa v25.0 起默认使用 AFBC。内核跟踪不断报告 vblank 超时并且渲染内容为乱码drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks 的 [CRTC:62:crtc-0] vblank 等待超时警告CPU:7 PID:70 .part.0+0x24c/0x27c [...] Hardware nameMediaTek Genio-700 EVK (DT) Workqueueevents_unbound commit_work pstate60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c sp : ffff80008337bca0 x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000 x26: 0000000000000001 x25: 0000000000000000 x24:
    ffff0000c9dcc000 x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80 x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a x17: 000000040044ffff x16: 005000f2b5503510 x15:
    0000000000000000 x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70 x8 : 0000000000057fa8 x7 : 0000000000000cce x6 :
    ffff8000823eea70 x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480 调用跟踪
    drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20 --- [ end trace 0000000000000000 ]--- --- 在上游修复此问题之前禁用此平台上的 AFBC 支持因为上游 Mesa 当前已破坏此支持。
    (CVE-2025-68184)

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

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

  - Bluetoothbtusbmediatek避免 btusb_mtk_claim_iso_intf() 空取消引用在 btusb_mtk_setup() 中我们将 `btmtk_data->isopkt_intf` 设置为 usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) 该函数在某些情况下会返回 NULL。但即使其返回 NULL我们仍会继续调用 btusb_mtk_claim_iso_intf()。自提交 e9087e828827 起Bluetooth: btusb: mediatek为 usb_driver_claim_interface() 添加锁在“btmtk_data->isopkt_intf”为 NULL 时调用 btusb_mtk_claim_iso_intf() 将造成崩溃因为我们最终会将错误的指针传递到 device_lock()。 。在此提交之前我们将空指针直接传递至 usb_driver_claim_interface()后者会检测并返回错误 已处理此问题。通过在 btusb_mtk_claim_iso_intf() 的开头添加 NULL 检查解决了该函数中的崩溃。这使代码处理空“btmtk_data->isopkt_intf”的方式与有问题的提交之前相同。只是对打印的错误消息稍作更改。 (CVE-2025-68298)

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

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

  - bfs从磁盘加载时重构文件类型syzbot 报告当从磁盘加载的 32 位模式字段的 S_IFMT 位损坏或从磁盘加载的 32 位属性字段损坏时inode->i_mode 的 S_IFMT 位可能变成虚假的。文档称 BFS 仅使用模式字段的较低 9 位。但是我无法找到明确的解释未使用的上限 23 位尤其是 S_IFMT 位被初始化为 0。因此请忽略从磁盘加载的模式字段的 S_IFMT 位。此外验证从磁盘加载的属性字段的值是否为 BFS_VREG 或 BFS_VDIR因为 BFS 仅支持常规文件和根目录。 (CVE-2025-68266)

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

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

  - drm/sysfb不在平面重置中取消引用空指针 中的平面状态
    __drm_gem_reset_shadow_plane() 可以为空。不取消引用该指针而是将 NULL 转发到其他平面重置帮助程序。将 Plane->state 清除为 NULL。 v2 - 修复提交描述中的拼写错误 (Javier)CVE-2025-40360

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

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

  - 在 Google Chrome 143.0.7499.147 之前的版本中，WebGPU 中存在释放后使用漏洞，远程攻击者可能利用此漏洞，通过构建的 HTML 页面利用堆损坏。（Chromium 安全严重性：高）(CVE-2025-14765)

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

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

  - drm、fbcon、vga_switcheroo避免 fbcon 设置中的争用条件通过控制台锁定保护 vga_switcheroo_client_fb_set()。避免 fbcon_remap_all() 中的 OOB 访问。在没有保持控制台锁定的情况下调用会与切换输出争用。VGA switcheroo 在切换客户端时调用 fbcon_remap_all()。fbcon 函数使用由 register_framebuffer() 设置的 struct fb_info.node。由于 fb-helper 代码当前在注册帧缓冲区之前设置 VGA switcheroo因此 node 的值为 -1因此不是合法值。例如fbcon 使用 set_con2fb_map() [1] 中的值作为数组的索引。在 register_framebuffer() 之后移动 vga_switcheroo_client_fb_set() 可导致 VGA 切换功能不正确地切换 fbcon。因此将 vga_switcheroo_client_fb_set() 移动到 fbcon_fb_registered() 下该函数已持有控制台锁定。Fbdev 从 register_framebuffer() 内调用 fbcon_fb_registered()。
    通过 VGA switcheroo 对 fbcon_remap_all() 的调用序列化帮助程序。尽管 vga_switcheroo_client_fb_set() 将 struct fb_info 的实例作为参数但它实际上仅需要包含的 fbcon 状态。因此，将调用移动到 fbcon 初始化比以前更干净。仅 amdgpu、i915、nouveau 和 radeon 支持 vga_switcheroo。对于所有其他驱动程序，此更改无任何影响。
    (CVE-2025-68296)

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

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

  - libceph针对来自不受信任的网络数据包的 map->max_osd OSD 索引将 BUG_ON 替换为边界检查。已添加边界检查以针对 map->max_osd 对这些内容进行验证。 [ idryomov删除 ceph_get_primary_affinity() 中的 BUG_ON次要外观编辑 ] (CVE-2025-68283)

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

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

  - scsiufsufs-qcom修复了 UFS 断电 (PC=3) 期间的 UFS OCP 问题 根据 UFS 规范UFS 设备的断电顺序包括 - 发送 Power_Condition=3 的 SSU 命令并等待响应。- 断言 RST_N 为低危。- 关闭 REF_CLK。- 关闭 VCC。- 正在关闭 VCCQ/VCCQ2。作为 ufs 关闭的一部分在 SSU 命令完成后断言硬件重置 (HWRST) 会触发设备固件唤醒并执行其重置例程。此例程对硬件块进行初始化需要几毫秒的时间才能完成。在此期间，ICCQ 会消耗大电流。此 ICCQ 大电流可能会造成向 UFS 供货的调节器出现问题因为调节器框架在 UFS 驱动程序向调节器框架发出关闭请求后会立即发出低功耗模式 (LPM) 请求。这是由框架完成的因为唯一的客户端 UFS 在请求禁用。因此，如果在 ICCQ 超过 LPM 当前阈值时电源轨仍在关闭过程中，并且在此状态下硬件中激活了 LPM 模式，则可能会在调节器中触发过流保护 (OCP) 错误。为防止发生此问题在断言 HWRST 之后添加了 10 毫秒的延迟。
    这允许在电源导轨保持活动状态和高功耗模式的同时完成重置操作。
    目前主机无法查询重置是否完成因此此延迟是基于在多个 UFS 供应商的 Qualcomm UFS 控制器上进行的实验得出的。 (CVE-2025-68236)

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

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

  - tcp使用 tcp_fastopen_active_disable_ofo_check() 中的 dst_dev_rcu() 使用 RCU 避免 dst_dev()->flags 上的一对原子操作和潜在的 UAF。 (CVE-2025-68188)

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

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

  - gpiolib修复 debugfs 中的无效指针访问。如果 gpiolib_seq_start() 中的内存分配失败则 s->private 字段会保持未初始化状态且会在未在 gpiolib_seq_stop() 中签入的情况下取消引用。
    在调用 kzalloc() 之前将 s->private 初始化为空并在取消引用之前对其进行检查。
    (CVE-2025-68167)

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

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

  - NFS检查 nfs_match_client() 中的 TLS 证书字段如果 TLS 安全策略的类型为 RPC_XPRTSEC_TLS_X509则 cert_serial 和 privkey_serial 字段也需要匹配因为它们定义提供给服务器的客户端标识。 (CVE-2025-68243)

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

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

  - mtdrawnandcadence修复了 DMA 设备空指针取消引用 DMA 设备指针“dma_dev”在确保正确初始化“cdns_ctrl->dmac”之前被取消引用。在成功获取 DMA 通道后移动“dma_dev”的分配以在使用前确保指针有效。
    (CVE-2025-68238)

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

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

  - net/mlx5eRX为跨步 RQ XDP 程序修复了从线性 xdp_buff 生成 skb 可通过 bpf_xdp_adjust_tail() 和 bpf_xdp_adjust_head() 更改 xdp_buff 布局的问题。因此，驱动程序无法假设线性数据区域或片段的大小。通过在 XDP 程序运行后根据 xdp_buff 生成 skb修复 mlx5 中的缺陷。目前在处理多缓冲区 XDP 时mlx5 驱动程序会假设 xdp_buff 的布局未更改。即线性数据区域持续为空而碎片保持不变。这可能造成驱动程序生成错误的 skb 或触发内核警告。当 XDP 程序通过 bpf_xdp_adjust_head() 添加线性数据时线性数据将被忽略因为 mlx5e_build_linear_skb() 会在没有线性数据的情况下构建 skb然后从片段中拉取数据以填充线性数据区域。当 XDP 程序通过 bpf_xdp_adjust_tail() 缩小了线性数据时传递至 __pskb_pull_tail() 的 delta 可能超过实际的线性数据大小并触发其中的 BUG_ON。要修复该问题请首先记录片段的原始数量。如果片段数量在 XDP 程序运行后发生更改则按差值回绕结束片段指针并重新计算 truesize。然后使用匹配 xdp_buff 的线性数据区域构建 skb。
    最后仅在存在线性数据时才拉入数据并将线性部分填充至 256 字节。
    (CVE-2025-40350)

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

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

  - drm/amdgpu删除两个无效 BUG_ON()可由用户空间轻松触发。 (CVE-2025-68201)

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

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

  - ksmbdipc修复 ipc_msg_send_request ipc_msg_send_request() 等待通用 netlink 回复时使用堆栈上的 ipc_msg_table_entry 中的释放后使用。通用 netlink 处理程序 (handle_generic_event()/handle_response()) 填充 ipc_msg_table_lock 下的 entry->response但 ipc_msg_send_request() 用于验证和释放 entry->response 而不保持相同的锁定。在高并发情况下可能会发生争用handle_response() 正在将数据复制到 entry->response 而 ipc_msg_send_request() 才刚释放数据进而导致由 KASAN 在 handle_generic_event() 中报告 slab 释放后使用缺陷KASAN handle_generic_event+0x3c4/0x5f0 中的 slab 释放后使用 [ksmbd] 由 task pool/109349 在 addr ffff888198ee6e20 写入大小 12 ... 由任务释放 kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd] 修复方式- 验证 entry->response 时在 ipc_msg_send_request() 中获取 ipc_msg_table_lock在无效时将其释放并从 ipc_msg_table 中删除该条目。- 仅在删除锁定下的哈希条目之后才将最终 entry->response 指针返回给调用程序。- 在错误路径中返回 NULL保留原始 API 语义。这使得对 entry->response 的所有访问与 handle_response() 一致它已经更新并填充 ipc_msg_table_lock 下的响应缓冲区并结束允许 UAF 的争用。 (CVE-2025-68263)

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

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

  - pmdomainarmscmi修复提供程序注册失败时的 genpd 泄露 如果 of_genpd_add_provider_onecell() 探测期间失败则不会删除之前创建的通用 power 域从而导致之后 genpd_debug_add() 中发生内存泄漏并可能发生内核崩溃。添加适当的错误处理以在探测返回之前展开初始化的域以确保在发生故障时正确释放所有资源。观察到的崩溃跟踪示例无此补丁|无法处理虚拟地址 fffffffffffffc70 | 内核页面的请求。 CPU1 UID 0 PID 1 Commswapper/0 未受感染 6.18.0-rc1 #405 PREEMPT |硬件名称ARM Ltd ARM Juno 开发平台/ARM Juno 开发平台 | pstate00000005 (nzcv daif
    -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | | pc genpd_debug_add+0x2c/0x160 | lr genpd_debug_init+0x74/0x98 |调用跟踪| genpd_debug_add+0x2c/0x160 (P) | | genpd_debug_init+0x74/0x98 | | do_one_initcall+0xd0/0x2d8 | | do_initcall_level+0xa0/0x140 | | do_initcalls+0x60/0xa8 | | do_basic_setup+0x28/0x40 | | kernel_init_freeable+0xe8/0x170 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | kernel_init+0x2c/0x140 ret_from_fork+0x10/0x20CVE-2025-68204

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

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

  - binfmt_misc关闭由 open_exec() 打开的文件之前还原写入访问权限 bm_register_write() 打开使用 open_exec() 的可执行文件该文件内部调用 do_open_execat() 并拒绝对文件的写入访问以避免在执行时被修改。但是当发生错误时bm_register_write() 会直接使用 filp_close() 关闭文件。这不会还原写入权限可能会造成对同一文件的后续写入操作失败。通过在 filp_close() 之前调用 exe_file_allow_write_access() 以正确还原写入权限可修复此问题。 (CVE-2025-68239)

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

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

  - drm/xe/guc添加 devm 释放操作以安全拆卸 CT 当为缓冲区对象 (BO) 分配了 XE_BO_FLAG_GGTT_INVALIDATE 标记时驱动程序会在释放 BO 时通过 CTB 机制发起 TLB 失效请求。但是过早释放 CTB BO 可导致系统崩溃如在 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:h2g_write+0x2f3/0x7c0 [xe] 调用跟踪
    guc_ct_send_locked+0x8b/0x670 [xe] xe_guc_ct_send_locked+0x19/0x60 [xe] send_tlb_invalidation+0xb4/0x460 [xe] xe_gt_tlb_invalidation_ggtt+0x15e/0x2e0 [xe] ggtt_invalidate_gt_tlb.part.0+0x16/0x90 [xe] ggtt_node_remove+0x110/0x140 [ xe] xe_ggtt_node_remove+0x40/0xa0 [xe] xe_ggtt_remove_bo+0x87/0x250 [xe] 在 xe_guc_ct_init() 和 xe_guc_ct_init() 和 xe_guc_ct_init_post_hwconfig() 期间引入受 devm 管理的释放操作以确保在资源解除分配之前正确禁用 CTB从而防止释放后使用情况。
    (CVE-2025-68193)

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

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

  - mptcp在调用 mptcp_do_fastclose() 中的 tcp_send_active_reset() 之前初始化 rcv_mss。 syzbot 报告了 MPTCP 套接字导致的 __tcp_select_window() 中的除以零。 [0] 裸 TCP 存在类似问题已在提交 499350a5a6e7 中修复 (tcp将 rcv_mss 初始化为 TCP_MIN_MSS 而不是 0)。让我们对 mptcp_do_fastclose() 应用相同的补丁。 [0]Oops除法错误0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 未受感染 syzkaller #0 PREEMPT(full) 硬件名称Google Google Compute Engine/Google Compute Engine、BIOS Google 10/25/2025 RIP0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336 代码ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00 RSP: 009018:ff7ffLA 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000 RBP
     R08ffffc90003017730  : ffff888033268143 R09: 1ffff1100664d028 R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS:
    000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0 Call Trace: <TASK> tcp_select_window net/ipv4/tcp_output.c:281 [inline] __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568 tcp_transmit_skb net/ipv4/tcp_output.c 1649 [inline] tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836 mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793 mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253 mptcp_opensf8sgend /0x580 net/mptcp/protocol.c:1776 mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+ 0x3bd/0x520 net/socket.c:2244 __do_sys_sendto net/socket.c:2251 [内联]
    __se_sys_sendto net/socket.c:2247 [内联] __x64_sys_sendto+0xde/0x100 net/socket.c:2247 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64 .c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66e998f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749 RDX
    0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13:
    00007f66e9be5fa0 R1400007f66e9be5fa0 R15: 0000000000000006 </TASK> (CVE-2025-68291)

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

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

  - PCIcadence在使用 cdns_pcie::ops 之前检查其是否存在 cdns_pcie::ops 可能不是所有 Cadence glue 驱动程序所填充。这对于即将推出的 Sophgo 平台而言更是如此，该平台不会设置 ops。因此添加检查以防止空指针取消引用。 [mani改写主题和描述] (CVE-2025-68176)

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

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

  - usbdwc3修复并发 dwc3_remove_requests() 调用路径之间的争用条件。此修补程序解决由于多个调用路径的非同步执行造成的争用条件调用 `dwc3_remove_requests()`从而导致过早释放 USB 请求和后续崩溃。三个不同的执行路径与“dwc3_remove_requests()”交互路径 1：在 USB 重置处理期间通过“dwc3_gadget_reset_interrupt()”触发。调用堆dwc3_stop_active_transfers()`。调用堆栈包括 - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` 路径 3
    在“adb root”执行期间独立发生，可触发 USB 函数取消绑定和绑定操作。
    该序列包括 - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - 状态为“-ESHUTDOWN”的“dwc3_remove_requests()”路径 3 异步运行并且缺少与路径 1 和 2 的同步。当路径 3完成后，它会禁用端点并释放“out”请求。如果路径 1 或 2 仍在处理这些请求访问已释放的内存将因释放后使用的情况而导致崩溃。要修复此问题已添加对请求完成情况的检查和在已完成情况下跳过处理的检查并添加排队时 ep0 的请求状态。 (CVE-2025-68287)

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

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

  - parisc避免因平铺中未对齐访问而导致的崩溃 Guenter Roeck 报告了其仿真 B160L 计算机上的此内核崩溃正在启动网络udhcpc: 启动v1.36.1 回溯 [<104320d4>] unwind_once+0x1c/0x5c [<10434a00>] walk_stackframe。 isra.0+0x74/0xb8 [<10434a6c>] arch_stack_walk+0x28/0x38 [<104e5efc>] stack_trace_save+0x48/0x5c [<105d1bdc>] set_track_prepare+0x44/0x6c [<105d9c80>]
    ___slab_alloc+0xfc4/0x1024 [<105d9d38>] __slab_alloc.isra.0+0x58/0x90 [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0 [<105b8e54>] __anon_vma_prepare+0x60/0x280 [<105a823c>]
    __vmf_anon_prepare+0x68/0x94 [<105a8b34>] do_wp_page+0x8cc/0xf10 [<105aad88>] handle_mm_fault+0x6c0/0xf08 [<10425568>] do_page_fault+0x110/0x440 [<10427938>] handle_interruption+0x184/0x748 [<11178398>] schedule+0x4c/0x190 BUG CPU#0上的自旋锁递归ifconfig/2420 lockterminate_lock.2+0x0/0x1c、.magic: dead4ead、.ownerifconfig/2420、.owner_cpu: 0 创建堆栈跟踪时回退程序使用猜测上一帧以从内存中读取上一个堆栈指针。发生崩溃的原因是回退程序尝试从未对齐的内存中读取并因此触发不对齐陷阱处理程序然后导致自旋锁递归并最终导致死锁。通过在访问内存之前检查对齐来修复此问题。 (CVE-2025-68322)

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

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

  - drm/xe/guc将失效 CT 工作线程与取消绑定取消同步并等待任何失效 CT 工作线程完成后再继续设备取消绑定。否则工作线程将最终使用由 undind 操作释放的资源。从提交 492671339114e376aaa38626d637a2751cdef263 中精选出的内容(CVE-2025-68207)

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

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

  - drm/i915绑定到 CHV/BXT+VTD 上的 GGTT 时避免锁定反转 i915_vma_pin_ww() 中会调用 dma_fence_work_commit() 的同步变体。在 Cherry View 系列处理器上或在启用了 VTD 的 Broxton Generation SoC 上例如当从 intel_ggtt_bind_vma() 调用 stop_machine() 时这可能会导致 reserve_ww 和 cpu_hotplug 之间的锁定反转锁。 [86.861179] ============================================== ======== [86.861193] 警告检测到可能的循环锁定依赖关系 [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 TaintedGU [86.861226]
    -------------------------------------------------- ---- [86.861238] i915_module_loa/1432 正在尝试获取锁[86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}位于 stop_machine+0x1c/0x50 [86.861290] 但任务已持有锁 [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] 哪个锁已依赖于新的lock。 [86.862251] 现有依存关系链逆序为
    [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0} [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f086.862454[86.862470] kernel_init_freeable+0x3cd/0x680 [86.862482] kernel_init+0x1b/0x200 [ [ ] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm +0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [+0xcferate_dir86.862635] /0x2b0 [86.862648]
    __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){+++ +}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+ 0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836]
    __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908]010xkernel/010x220 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969]
    __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995]
    86.863012...86.863026​86.863041​86.863054​86.863068​ [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}[86.863135]
    __lock_acquire+0x16 ---truncated--- (CVE-2025-68244)

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

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

  - drm/radeon不是 kfree() devres 管理的 rdev 由于驱动程序主要结构的分配已更改为 devm_drm_dev_alloc()rdev 由 devres 管理我们不应在其上调用 kfree()。此更新修复了驱动程序探查失败以及 devres 在我们已经释放 rdev 后对其进行清理时发生的事件爆炸。
    从提交 16c0681617b8a045773d4d87b6140002fa75b03b 中精选出的内容(CVE-2025-68170)

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

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

  - ceph修复加密目录的 process_v2_sparse_read() 中的崩溃 据报告fscrypt 加密的目录的 process_v2_sparse_read() 会发生崩溃。安全模式下 Ceph msgr2 协议会发生问题。以下步骤可以重现此问题sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted .tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt -test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) 已触发问题[ 408.072247] ------------[在此处切换 ]------------ [ 408.072251] WARNINGCPU:1 PID: 392 at net/ceph/messenger_v2 .c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp par port efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0 -5.fc42 04/01/2014 [ 408.072310] Workqueueceph-msgr ceph_con_workfn [408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] 代码c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS
    00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08:
    0000000000000000 R0900000000000000c8 [ 408.072326] R1000000000000000c8 R110000000000000000 R12
    00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS:
    0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 000000000772ef0 [ 408.072337408.072336] PKRU: 555555554 408.072338<TASK>408.072340] 调用跟踪sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] finish_task_switch.isra.0+0x15d/0x830 [408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ?
    __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ?
    __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ?
    __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [] </TASK>408.072407] ---[ end trace 0000000000000000 ]--- [408.072418] Oops一般保护错误，可能因非规范问题地址 0xdffffc00000000
    ---truncated--- (CVE-2025-68297)

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

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

  - cryptozstd - 修复每个 CPU 流清理中的双重释放 crypto/zstd 模块存在一个当分配和释放多个 tfms 时会发生的双重释放缺陷。发生此问题的原因是在每次 tfm 损毁期间 zstd_exit() 中都会释放 zstd_streams依 CPU 环境而非在模块级别进行管理。存在多个 tfms 时每个 tfm 退出都会尝试释放相同的共享每个 CPU 流从而导致双重释放。这会导致出现类似类似于 BUG: Bad page state in process kworker/u16:1 pfn:106fd93 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x106fd93 flags:
    0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: nonzero entire_mapcount Modules linked in: ... CPU3 UID0 PID
    2506 Commkworker/u16:1 Kdump已加载 受感染的GB 硬件名称... Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 bad_page+0x71/0xd0 free_unref_page_prepare+0x24e/0x490 free_unref_page+0x60/0x170 crypto_acomp_free_streams+0x5d/0xc0 crypto_acomp_exit_tfm+0x23/0x50 crypto_destroy_tfm+0x60/0xc0 ... 更改 zstd_streams 的生命周期管理以在模块清理期间仅将流释放一次。 (CVE-2025-68262)

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

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

  - mm/memfd修复 hugetlb folios 中的信息泄漏为 memfd 分配 hugetlb folios 时缺少三个初始化步骤1. Folio 未归零导致内核内存泄露给用户空间 2. Folio 在添加到页面缓存之前未标记为 uptodate 3. hugetlb_fault_mutex 未在 hugetlb_add_to_page_cache() 之前执行 memfd 分配路径绕过将处理所有这些初始化步骤的正常页面错误处理程序 (hugetlb_no_page)。这会造成问题尤其对于 udmabuf 使用情况其中 folio 已固定并由用户空间通过 DMA 直接访问。通过匹配 hugetlb_no_page() 中使用的初始化模式进行修复- 使用针对大型页面优化的 folio_zero_user() 将 folio 归零 - 使用 folio_mark_uptodate() 将其标记为最新 - 在添加到页面缓存之前获取 hugetlb_fault_mutex 以防止争用 folio_zero_user() 更改也修复了一个潜在的安全问题其中未初始化的内核内存可通过 memfd 上的 read() 或 mmap() 操作泄露给用户空间。 (CVE-2025-68292)

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

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

  - drm/amd/display在访问 [WHAT] IGT kms_cursor_legacy 的 long-nonblocking-modeset-vs-cursor-atomic 之前检查 NULL因空指针取消引用而失败。可通过连接的 eDP 面板和 DP 监视器来重现这一点。缺陷内核空指针取消引用地址0000000000000000 #PF内核模式下的主管读取访问权限 #PFerror_code(0x0000) - 不存在页面 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID 0 PID2960 Commkms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT自主硬件名称AMD .. RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] 代码57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 8900 48 79 48 7 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP0018:ffffd0f3c2bd7608 EFLAGS
    00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI
    ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14:
     R15ffffd0f3c2bd7668  : ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3:
    00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 调用跟踪 <TASK> dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ?
    __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c (CVE-2025-68286)

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

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

  - stagingrtl8723bs修复 rtw_get_ie() 解析器中的越界读取 信息元素 (IE) 解析器 rtw_get_ie() 信任每个 IE 的 length 字节但未验证 IE 正文2 字节标头后的 len 字节适合剩余的帧缓冲区。畸形帧可通告大于可用数据的 IE 长度从而导致解析器将其指针递增到缓冲区末尾之外。这会导致越界读取，或者根据模式而定，造成无限循环。通过在接受 IE 或前进到下一个元素之前验证 (offset + 2 + len) 未超过该限制来修复 。这可以防止 OOB 读取并确保解析器在遇到畸形帧时安全终止。 (CVE-2025-68256)

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

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

  - mm当 gfp 标记不允许 syzbot 能够找到以下路径时add_stack_record 中不旋转
    add_stack_record_to_list mm/page_owner.c:182 [内联] inc_stack_record_count mm/page_owner.c:214 [内联]
    __set_page_owner+0x2c3/0x4a0 mm/page_owner.c:333 set_page_owner include/linux/page_owner.h:32 [内联] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [内联] get_page_from_freelist+ 0x21e4/0x22c0 mm/page_alloc.c:3858 alloc_pages_nolock_noprof+0x94/0x120 mm/page_alloc.c:7554 从 *_nolock() 上下文调用 add_stack_record_to_list() 时不在其中旋转。
    (CVE-2025-68253)

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

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

  clktheadth1520-ap将所有 AXI 时钟设置为 CLK_IS_CRITICAL TH1520 的 AXI crossbar 未进行适当的超时处理这意味着门控 AXI 时钟很容易导致总线超时并因此导致系统挂起。将所有 AXI 时钟门设置为 CLK_IS_CRITICAL。系统重置时所有这些时钟门控默认为取消门控。此外将所有当前的 CLK_IGNORE_UNUSED 用法转换为 CLK_IS_CRITICAL 以避免不需要的时钟门控。
    (CVE-2025-68318)

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

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 依赖供应商报告的程序包是否存在进行判断。

ID	名称	严重性
278883	Linux Distros 未修补的漏洞：CVE-2025-68295	medium
278882	Linux Distros 未修补的漏洞：CVE-2025-68290	high
278881	Linux Distros 未修补的漏洞：CVE-2025-68229	medium
278880	Linux Distros 未修补的漏洞：CVE-2025-68218	medium
278879	Linux Distros 未修补的漏洞：CVE-2025-68246	medium
278878	Linux Distros 未修补的漏洞：CVE-2025-68174	high
278877	Linux Distros 未修补的漏洞：CVE-2025-68321	medium
278876	Linux Distros 未修补的漏洞：CVE-2025-68184	high
278875	Linux Distros 未修补的漏洞：CVE-2025-68298	medium
278874	Linux Distros 未修补的漏洞：CVE-2025-68266	high
278873	Linux Distros 未修补的漏洞：CVE-2025-40360	medium
278872	Linux Distros 未修补的漏洞：CVE-2025-14765	high
278871	Linux Distros 未修补的漏洞：CVE-2025-68296	medium
278870	Linux Distros 未修补的漏洞：CVE-2025-68283	high
278869	Linux Distros 未修补的漏洞：CVE-2025-68236	high
278868	Linux Distros 未修补的漏洞：CVE-2025-68188	high
278867	Linux Distros 未修补的漏洞：CVE-2025-68167	medium
278866	Linux Distros 未修补的漏洞：CVE-2025-68243	high
278865	Linux Distros 未修补的漏洞：CVE-2025-68238	medium
278864	Linux Distros 未修补的漏洞：CVE-2025-40350	medium
278863	Linux Distros 未修补的漏洞：CVE-2025-68201	medium
278862	Linux Distros 未修补的漏洞：CVE-2025-68263	critical
278861	Linux Distros 未修补的漏洞：CVE-2025-68204	medium
278860	Linux Distros 未修补的漏洞：CVE-2025-68239	high
278859	Linux Distros 未修补的漏洞：CVE-2025-68193	high
278858	Linux Distros 未修补的漏洞：CVE-2025-68291	medium
278857	Linux Distros 未修补的漏洞：CVE-2025-68176	medium
278856	Linux Distros 未修补的漏洞：CVE-2025-68287	high
278855	Linux Distros 未修补的漏洞：CVE-2025-68322	medium
278854	Linux Distros 未修补的漏洞：CVE-2025-68207	high
278853	Linux Distros 未修补的漏洞：CVE-2025-68244	high
278852	Linux Distros 未修补的漏洞：CVE-2025-68170	high
278851	Linux Distros 未修补的漏洞：CVE-2025-68297	medium
278850	Linux Distros 未修补的漏洞：CVE-2025-68262	high
278849	Linux Distros 未修补的漏洞：CVE-2025-68292	medium
278848	Linux Distros 未修补的漏洞：CVE-2025-68286	medium
278847	Linux Distros 未修补的漏洞：CVE-2025-68256	medium
278846	Linux Distros 未修补的漏洞：CVE-2025-68253	medium
278845	Linux Distros 未修补的漏洞：CVE-2025-68318	medium
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

检测

Nessus 的 Misc. 系列

medium

high

medium

medium

medium

high

medium

high

medium

high

medium

high

medium

high

high

high

medium

high

medium

medium

medium

critical

medium

high

high

medium

medium

high

medium

high

high

high

medium

high

medium

medium

medium

medium

medium

high

medium

medium

medium

high

medium

medium

high

medium

medium

medium