{"cve":"CVE-2025-21674","nvd":{"published":"2025-01-31T12:15:28.560","modified":"2026-06-17T08:43:59.427","status":"Modified","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel\n\nAttempt to enable IPsec packet offload in tunnel mode in debug kernel\ngenerates the following kernel panic, which is happening due to two\nissues:\n1. In SA add section, the should be _bh() variant when marking SA mode.\n2. There is not needed flush_workqueue in SA delete routine. It is not\nneeded as at this stage as it is removed from SADB and the running work\nwill be canceled later in SA free.\n\n =====================================================\n WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected\n 6.12.0+ #4 Not tainted\n -----------------------------------------------------\n charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:\n ffff88810f365020 (&xa->xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]\n\n and this task is already holding:\n ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30\n which would create a new lock dependency:\n  (&x->lock){+.-.}-{3:3} -> (&xa->xa_lock#24){+.+.}-{3:3}\n\n but this new dependency connects a SOFTIRQ-irq-safe lock:\n  (&x->lock){+.-.}-{3:3}\n\n ... which became SOFTIRQ-irq-safe at:\n   lock_acquire+0x1be/0x520\n   _raw_spin_lock_bh+0x34/0x40\n   xfrm_timer_handler+0x91/0xd70\n   __hrtimer_run_queues+0x1dd/0xa60\n   hrtimer_run_softirq+0x146/0x2e0\n   handle_softirqs+0x266/0x860\n   irq_exit_rcu+0x115/0x1a0\n   sysvec_apic_timer_interrupt+0x6e/0x90\n   asm_sysvec_apic_timer_interrupt+0x16/0x20\n   default_idle+0x13/0x20\n   default_idle_call+0x67/0xa0\n   do_idle+0x2da/0x320\n   cpu_startup_entry+0x50/0x60\n   start_secondary+0x213/0x2a0\n   common_startup_64+0x129/0x138\n\n to a SOFTIRQ-irq-unsafe lock:\n  (&xa->xa_lock#24){+.+.}-{3:3}\n\n ... which became SOFTIRQ-irq-unsafe at:\n ...\n   lock_acquire+0x1be/0x520\n   _raw_spin_lock+0x2c/0x40\n   xa_set_mark+0x70/0x110\n   mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]\n   xfrm_dev_state_add+0x3bb/0xd70\n   xfrm_add_sa+0x2451/0x4a90\n   xfrm_user_rcv_msg+0x493/0x880\n   netlink_rcv_skb+0x12e/0x380\n   xfrm_netlink_rcv+0x6d/0x90\n   netlink_unicast+0x42f/0x740\n   netlink_sendmsg+0x745/0xbe0\n   __sock_sendmsg+0xc5/0x190\n   __sys_sendto+0x1fe/0x2c0\n   __x64_sys_sendto+0xdc/0x1b0\n   do_syscall_64+0x6d/0x140\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n other info that might help us debug this:\n\n  Possible interrupt unsafe locking scenario:\n\n        CPU0                    CPU1\n        ----                    ----\n   lock(&xa->xa_lock#24);\n                                local_irq_disable();\n                                lock(&x->lock);\n                                lock(&xa->xa_lock#24);\n   <Interrupt>\n     lock(&x->lock);\n\n  *** DEADLOCK ***\n\n 2 locks held by charon/1337:\n  #0: ffffffff87f8f858 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90\n  #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30\n\n the dependencies between SOFTIRQ-irq-safe lock and the holding lock:\n -> (&x->lock){+.-.}-{3:3} ops: 29 {\n    HARDIRQ-ON-W at:\n                     lock_acquire+0x1be/0x520\n                     _raw_spin_lock_bh+0x34/0x40\n                     xfrm_alloc_spi+0xc0/0xe60\n                     xfrm_alloc_userspi+0x5f6/0xbc0\n                     xfrm_user_rcv_msg+0x493/0x880\n                     netlink_rcv_skb+0x12e/0x380\n                     xfrm_netlink_rcv+0x6d/0x90\n                     netlink_unicast+0x42f/0x740\n                     netlink_sendmsg+0x745/0xbe0\n                     __sock_sendmsg+0xc5/0x190\n                     __sys_sendto+0x1fe/0x2c0\n                     __x64_sys_sendto+0xdc/0x1b0\n                     do_syscall_64+0x6d/0x140\n                     entry_SYSCALL_64_after_hwframe+0x4b/0x53\n    IN-SOFTIRQ-W at:\n                     lock_acquire+0x1be/0x520\n                     _raw_spin_lock_bh+0x34/0x40\n                     xfrm_timer_handler+0x91/0xd70\n                     __hrtimer_run_queues+0x1dd/0xa60\n   \n---truncated---","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":["CWE-667"],"references":["https://git.kernel.org/stable/c/2c3688090f8a1f085230aa839cc63e4a7b977df0","https://git.kernel.org/stable/c/6d3d69c070d920fbb146d73dd3899a50f25d0901","https://git.kernel.org/stable/c/87c4417a902151cfe4363166245a3671a08c256c"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T21:58:41.599736885+00:00"},"epss":{"cve":"CVE-2025-21674","score":0.00175,"percentile":0.07032,"date":"2026-10-31"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}