CVE-2025-21674

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel<br /> <br /> Attempt to enable IPsec packet offload in tunnel mode in debug kernel<br /> generates the following kernel panic, which is happening due to two<br /> issues:<br /> 1. In SA add section, the should be _bh() variant when marking SA mode.<br /> 2. There is not needed flush_workqueue in SA delete routine. It is not<br /> needed as at this stage as it is removed from SADB and the running work<br /> will be canceled later in SA free.<br /> <br /> =====================================================<br /> WARNING: SOFTIRQ-safe -&gt; SOFTIRQ-unsafe lock order detected<br /> 6.12.0+ #4 Not tainted<br /> -----------------------------------------------------<br /> charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:<br /> ffff88810f365020 (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]<br /> <br /> and this task is already holding:<br /> ffff88813e0f0d48 (&amp;x-&gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30<br /> which would create a new lock dependency:<br /> (&amp;x-&gt;lock){+.-.}-{3:3} -&gt; (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}<br /> <br /> but this new dependency connects a SOFTIRQ-irq-safe lock:<br /> (&amp;x-&gt;lock){+.-.}-{3:3}<br /> <br /> ... which became SOFTIRQ-irq-safe at:<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock_bh+0x34/0x40<br /> xfrm_timer_handler+0x91/0xd70<br /> __hrtimer_run_queues+0x1dd/0xa60<br /> hrtimer_run_softirq+0x146/0x2e0<br /> handle_softirqs+0x266/0x860<br /> irq_exit_rcu+0x115/0x1a0<br /> sysvec_apic_timer_interrupt+0x6e/0x90<br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> default_idle+0x13/0x20<br /> default_idle_call+0x67/0xa0<br /> do_idle+0x2da/0x320<br /> cpu_startup_entry+0x50/0x60<br /> start_secondary+0x213/0x2a0<br /> common_startup_64+0x129/0x138<br /> <br /> to a SOFTIRQ-irq-unsafe lock:<br /> (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}<br /> <br /> ... which became SOFTIRQ-irq-unsafe at:<br /> ...<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock+0x2c/0x40<br /> xa_set_mark+0x70/0x110<br /> mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]<br /> xfrm_dev_state_add+0x3bb/0xd70<br /> xfrm_add_sa+0x2451/0x4a90<br /> xfrm_user_rcv_msg+0x493/0x880<br /> netlink_rcv_skb+0x12e/0x380<br /> xfrm_netlink_rcv+0x6d/0x90<br /> netlink_unicast+0x42f/0x740<br /> netlink_sendmsg+0x745/0xbe0<br /> __sock_sendmsg+0xc5/0x190<br /> __sys_sendto+0x1fe/0x2c0<br /> __x64_sys_sendto+0xdc/0x1b0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> other info that might help us debug this:<br /> <br /> Possible interrupt unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;xa-&gt;xa_lock#24);<br /> local_irq_disable();<br /> lock(&amp;x-&gt;lock);<br /> lock(&amp;xa-&gt;xa_lock#24);<br /> <br /> lock(&amp;x-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> 2 locks held by charon/1337:<br /> #0: ffffffff87f8f858 (&amp;net-&gt;xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90<br /> #1: ffff88813e0f0d48 (&amp;x-&gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30<br /> <br /> the dependencies between SOFTIRQ-irq-safe lock and the holding lock:<br /> -&gt; (&amp;x-&gt;lock){+.-.}-{3:3} ops: 29 {<br /> HARDIRQ-ON-W at:<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock_bh+0x34/0x40<br /> xfrm_alloc_spi+0xc0/0xe60<br /> xfrm_alloc_userspi+0x5f6/0xbc0<br /> xfrm_user_rcv_msg+0x493/0x880<br /> netlink_rcv_skb+0x12e/0x380<br /> xfrm_netlink_rcv+0x6d/0x90<br /> netlink_unicast+0x42f/0x740<br /> netlink_sendmsg+0x745/0xbe0<br /> __sock_sendmsg+0xc5/0x190<br /> __sys_sendto+0x1fe/0x2c0<br /> __x64_sys_sendto+0xdc/0x1b0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> IN-SOFTIRQ-W at:<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock_bh+0x34/0x40<br /> xfrm_timer_handler+0x91/0xd70<br /> __hrtimer_run_queues+0x1dd/0xa60<br /> <br /> ---truncated---