CVE-2025-21674: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel  Attempt to enable IPsec packet offload in tunnel mode in debug kernel generates the following kernel panic, which is happening due to two issues: 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 not needed as at this stage as it is removed from SADB and the running work will 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---