CVE-2025-21674

一、漏洞信息
 漏洞编号：[CVE-2025-21674](https://nvd.nist.gov/vuln/detail/CVE-2025-21674)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.1.8,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：5.5 Medium
  Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnelAttempt to enable IPsec packet offload in tunnel mode in debug kernelgenerates the following kernel panic, which is happening due to twoissues:1. In SA add section, the should be _bh() variant when marking SA mode.2. There is not needed flush_workqueue in SA delete routine. It is notneeded as at this stage as it is removed from SADB and the running workwill be canceled later in SA free. ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 6.12.0+ #4 Not tainted ----------------------------------------------------- charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: ffff88810f365020 (&xa->xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core] and this task is already holding: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 which would create a new lock dependency:  (&x->lock){+.-.}-{3:3} -> (&xa->xa_lock#24){+.+.}-{3:3} but this new dependency connects a SOFTIRQ-irq-safe lock:  (&x->lock){+.-.}-{3:3} ... which became SOFTIRQ-irq-safe at:   lock_acquire+0x1be/0x520   _raw_spin_lock_bh+0x34/0x40   xfrm_timer_handler+0x91/0xd70   __hrtimer_run_queues+0x1dd/0xa60   hrtimer_run_softirq+0x146/0x2e0   handle_softirqs+0x266/0x860   irq_exit_rcu+0x115/0x1a0   sysvec_apic_timer_interrupt+0x6e/0x90   asm_sysvec_apic_timer_interrupt+0x16/0x20   default_idle+0x13/0x20   default_idle_call+0x67/0xa0   do_idle+0x2da/0x320   cpu_startup_entry+0x50/0x60   start_secondary+0x213/0x2a0   common_startup_64+0x129/0x138 to a SOFTIRQ-irq-unsafe lock:  (&xa->xa_lock#24){+.+.}-{3:3} ... which became SOFTIRQ-irq-unsafe at: ...   lock_acquire+0x1be/0x520   _raw_spin_lock+0x2c/0x40   xa_set_mark+0x70/0x110   mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]   xfrm_dev_state_add+0x3bb/0xd70   xfrm_add_sa+0x2451/0x4a90   xfrm_user_rcv_msg+0x493/0x880   netlink_rcv_skb+0x12e/0x380   xfrm_netlink_rcv+0x6d/0x90   netlink_unicast+0x42f/0x740   netlink_sendmsg+0x745/0xbe0   __sock_sendmsg+0xc5/0x190   __sys_sendto+0x1fe/0x2c0   __x64_sys_sendto+0xdc/0x1b0   do_syscall_64+0x6d/0x140   entry_SYSCALL_64_after_hwframe+0x4b/0x53 other info that might help us debug this:  Possible interrupt unsafe locking scenario:        CPU0                    CPU1        ----                    ----   lock(&xa->xa_lock#24);                                local_irq_disable();                                lock(&x->lock);                                lock(&xa->xa_lock#24);   <Interrupt>     lock(&x->lock);  *** DEADLOCK *** 2 locks held by charon/1337:  #0: ffffffff87f8f858 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90  #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&x->lock){+.-.}-{3:3} ops: 29 {    HARDIRQ-ON-W at:                     lock_acquire+0x1be/0x520                     _raw_spin_lock_bh+0x34/0x40                     xfrm_alloc_spi+0xc0/0xe60                     xfrm_alloc_userspi+0x5f6/0xbc0                     xfrm_user_rcv_msg+0x493/0x880                     netlink_rcv_skb+0x12e/0x380                     xfrm_netlink_rcv+0x6d/0x90                     netlink_unicast+0x42f/0x740                     netlink_sendmsg+0x745/0xbe0                     __sock_sendmsg+0xc5/0x190                     __sys_sendto+0x1fe/0x2c0                     __x64_sys_sendto+0xdc/0x1b0                     do_syscall_64+0x6d/0x140                     entry_SYSCALL_64_after_hwframe+0x4b/0x53    IN-SOFTIRQ-W at:                     lock_acquire+0x1be/0x520                     _raw_spin_lock_bh+0x34/0x40                     xfrm_timer_handler+0x91/0xd70                     __hrtimer_run_queues+0x1dd/0xa60   ---truncated---
 漏洞公开时间：2025-01-31 20:15:28
 漏洞创建时间：2025-01-31 23:30:37
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2025-21674
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/2c3688090f8a1f085230aa839cc63e4a7b977df0 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/6d3d69c070d920fbb146d73dd3899a50f25d0901 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/87c4417a902151cfe4363166245a3671a08c256c |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-21674 | https://bugzilla.suse.com/show_bug.cgi?id=1236688 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2025-21674 | https://bugzilla.suse.com/show_bug.cgi?id=1236688 |
| suse_bugzilla | https://git.kernel.org/stable/c/2c3688090f8a1f085230aa839cc63e4a7b977df0 | https://bugzilla.suse.com/show_bug.cgi?id=1236688 |
| suse_bugzilla | https://git.kernel.org/stable/c/6d3d69c070d920fbb146d73dd3899a50f25d0901 | https://bugzilla.suse.com/show_bug.cgi?id=1236688 |
| suse_bugzilla | https://git.kernel.org/stable/c/87c4417a902151cfe4363166245a3671a08c256c | https://bugzilla.suse.com/show_bug.cgi?id=1236688 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2025/CVE-2025-21674.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1236688 |
| redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2025013100-CVE-2025-21674-8b15@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2343185 |

</details>

漏洞分析指导链接：
  https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
 漏洞数据来源:
  openBrain开源漏洞感知系统
 漏洞补丁信息：
  <details>
<summary>详情(点击展开)</summary>

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
|  |  | https://git.kernel.org/stable/c/2c3688090f8a1f085230aa839cc63e4a7b977df0 |  | nvd |
|  |  | https://git.kernel.org/stable/c/6d3d69c070d920fbb146d73dd3899a50f25d0901 |  | nvd |
|  |  | https://git.kernel.org/stable/c/87c4417a902151cfe4363166245a3671a08c256c |  | nvd |
| linux_kernel | 6.6.74 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=87c4417a902151cfe4363166245a3671a08c256cIssue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4c24272b4e2befca6ad1409c3c9aaa16c24b1099 | linuxkernelcves |
| linux_kernel | 6.12.11 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6d3d69c070d920fbb146d73dd3899a50f25d0901Issue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4c24272b4e2befca6ad1409c3c9aaa16c24b1099 | linuxkernelcves |
| linux_kernel | 6.13 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2c3688090f8a1f085230aa839cc63e4a7b977df0Please | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4c24272b4e2befca6ad1409c3c9aaa16c24b1099 | linuxkernelcves |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnelAttempt to enable IPsec packet offload in tunnel mode in debug kernelgenerates the following kernel panic, which is happening due to twoissues:1. In SA add section, the should be _bh() variant when marking SA mode.2. There is not needed flush_workqueue in SA delete routine. It is notneeded as at this stage as it is removed from SADB and the running workwill be canceled later in SA free. ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 6.12.0+ #4 Not tainted ----------------------------------------------------- charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: ffff88810f365020 (&xa->xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core] and this task is already holding: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 which would create a new lock dependency:  (&x->lock){+.-.}-{3:3} -> (&xa->xa_lock#24){+.+.}-{3:3} but this new dependency connects a SOFTIRQ-irq-safe lock:  (&x->lock){+.-.}-{3:3} ... which became SOFTIRQ-irq-safe at:   lock_acquire+0x1be/0x520   _raw_spin_lock_bh+0x34/0x40   xfrm_timer_handler+0x91/0xd70   __hrtimer_run_queues+0x1dd/0xa60   hrtimer_run_softirq+0x146/0x2e0   handle_softirqs+0x266/0x860   irq_exit_rcu+0x115/0x1a0   sysvec_apic_timer_interrupt+0x6e/0x90   asm_sysvec_apic_timer_interrupt+0x16/0x20   default_idle+0x13/0x20   default_idle_call+0x67/0xa0   do_idle+0x2da/0x320   cpu_startup_entry+0x50/0x60   start_secondary+0x213/0x2a0   common_startup_64+0x129/0x138 to a SOFTIRQ-irq-unsafe lock:  (&xa->xa_lock#24){+.+.}-{3:3} ... which became SOFTIRQ-irq-unsafe at: ...   lock_acquire+0x1be/0x520   _raw_spin_lock+0x2c/0x40   xa_set_mark+0x70/0x110   mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]   xfrm_dev_state_add+0x3bb/0xd70   xfrm_add_sa+0x2451/0x4a90   xfrm_user_rcv_msg+0x493/0x880   netlink_rcv_skb+0x12e/0x380   xfrm_netlink_rcv+0x6d/0x90   netlink_unicast+0x42f/0x740   netlink_sendmsg+0x745/0xbe0   __sock_sendmsg+0xc5/0x190   __sys_sendto+0x1fe/0x2c0   __x64_sys_sendto+0xdc/0x1b0   do_syscall_64+0x6d/0x140   entry_SYSCALL_64_after_hwframe+0x4b/0x53 other info that might help us debug this:  Possible interrupt unsafe locking scenario:        CPU0                    CPU1        ----                    ----   lock(&xa->xa_lock#24);                                local_irq_disable();                                lock(&x->lock);                                lock(&xa->xa_lock#24);   <Interrupt>     lock(&x->lock);  *** DEADLOCK *** 2 locks held by charon/1337:  #0: ffffffff87f8f858 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90  #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&x->lock){+.-.}-{3:3} ops: 29 {    HARDIRQ-ON-W at:                     lock_acquire+0x1be/0x520                     _raw_spin_lock_bh+0x34/0x40                     xfrm_alloc_spi+0xc0/0xe60                     xfrm_alloc_userspi+0x5f6/0xbc0                     xfrm_user_rcv_msg+0x493/0x880                     netlink_rcv_skb+0x12e/0x380                     xfrm_netlink_rcv+0x6d/0x90                     netlink_unicast+0x42f/0x740                     netlink_sendmsg+0x745/0xbe0                     __sock_sendmsg+0xc5/0x190                     __sys_sendto+0x1fe/0x2c0                     __x64_sys_sendto+0xdc/0x1b0                     do_syscall_64+0x6d/0x140                     entry_SYSCALL_64_after_hwframe+0x4b/0x53    IN-SOFTIRQ-W at:                     lock_acquire+0x1be/0x520                     _raw_spin_lock_bh+0x34/0x40                     xfrm_timer_handler+0x91/0xd70                     __hrtimer_run_queues+0x1dd/0xa60   ---truncated---
 openEuler评分：
  5.5
 Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 受影响版本排查(受影响/不受影响)：
  1.openEuler-24.03-LTS:受影响
2.openEuler-24.03-LTS-SP1:受影响
3.openEuler-20.03-LTS-SP4(4.19.90):不受影响
4.openEuler-22.03-LTS-SP3:不受影响
5.openEuler-22.03-LTS-SP4:不受影响
6.master:不受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
  1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP3:否
3.master:否
4.openEuler-24.03-LTS:否
5.openEuler-24.03-LTS-Next:否
6.openEuler-22.03-LTS-SP4:否
7.openEuler-24.03-LTS-SP1:否

原因说明：
  1.openEuler-24.03-LTS:正常修复
2.openEuler-24.03-LTS-SP1:正常修复
3.master:不受影响-漏洞代码不能被攻击者触发
4.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
5.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在
6.openEuler-22.03-LTS-SP3:不受影响-漏洞代码不存在
7.openEuler-22.03-LTS-SP4:不受影响-漏洞代码不存在

src-openEuler/kernel
关闭

内容风险标识

评论 (18)

src-openEuler/kernel关闭 .gitee-modal { width: 500px !important; }

内容风险标识

CVE-2025-21674

评论 (18)

搜索帮助

src-openEuler/kernel
关闭