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 flushworkqueue 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->xalock#24){+.+.}-{3:3}, at: mlx5exfrmdelstate+0xca/0x1e0 [mlx5_core]

and this task is already holding: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrmstatedelete+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: lockacquire+0x1be/0x520 _rawspinlockbh+0x34/0x40 xfrmtimerhandler+0x91/0xd70 _hrtimerrunqueues+0x1dd/0xa60 hrtimerrunsoftirq+0x146/0x2e0 handlesoftirqs+0x266/0x860 irqexitrcu+0x115/0x1a0 sysvecapictimerinterrupt+0x6e/0x90 asmsysvecapictimerinterrupt+0x16/0x20 defaultidle+0x13/0x20 defaultidlecall+0x67/0xa0 doidle+0x2da/0x320 cpustartupentry+0x50/0x60 startsecondary+0x213/0x2a0 commonstartup64+0x129/0x138

to a SOFTIRQ-irq-unsafe lock: (&xa->xa_lock#24){+.+.}-{3:3}

... which became SOFTIRQ-irq-unsafe at: ... lockacquire+0x1be/0x520 _rawspinlock+0x2c/0x40 xasetmark+0x70/0x110 mlx5exfrmaddstate+0xe48/0x2290 [mlx5core] xfrmdevstateadd+0x3bb/0xd70 xfrmaddsa+0x2451/0x4a90 xfrmuserrcvmsg+0x493/0x880 netlinkrcvskb+0x12e/0x380 xfrmnetlinkrcv+0x6d/0x90 netlinkunicast+0x42f/0x740 netlinksendmsg+0x745/0xbe0 _socksendmsg+0xc5/0x190 _syssendto+0x1fe/0x2c0 _x64syssendto+0xdc/0x1b0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53

other info that might help us debug this:

Possible interrupt unsafe locking scenario:

    CPU0                    CPU1
    ----                    ----

lock(&xa->xalock#24); localirqdisable(); lock(&x->lock); lock(&xa->xalock#24); <Interrupt> lock(&x->lock);

* DEADLOCK *

2 locks held by charon/1337: #0: ffffffff87f8f858 (&net->xfrm.xfrmcfgmutex){+.+.}-{4:4}, at: xfrmnetlinkrcv+0x5e/0x90 #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrmstatedelete+0x16/0x30

the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&x->lock){+.-.}-{3:3} ops: 29 { HARDIRQ-ON-W at: lockacquire+0x1be/0x520 _rawspinlockbh+0x34/0x40 xfrmallocspi+0xc0/0xe60 xfrmallocuserspi+0x5f6/0xbc0 xfrmuserrcvmsg+0x493/0x880 netlinkrcvskb+0x12e/0x380 xfrmnetlinkrcv+0x6d/0x90 netlinkunicast+0x42f/0x740 netlinksendmsg+0x745/0xbe0 _socksendmsg+0xc5/0x190 _syssendto+0x1fe/0x2c0 _x64syssendto+0xdc/0x1b0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53 IN-SOFTIRQ-W at: lockacquire+0x1be/0x520 _rawspinlockbh+0x34/0x40 xfrmtimerhandler+0x91/0xd70 _hrtimerrun_queues+0x1dd/0xa60

---truncated---