CVE-2026-53035

In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix af_unix iter deadlock

bpfiterunixseqshow() may deadlock when locksockfast() takes the fast path and the iter prog attempts to update a sockmap. Which ends up spinning at sockmapupdateelem()'s bhlock_sock():

WARNING: possible recursive locking detected testprogs/1393 is trying to acquire lock: ffff88811ec25f58 (slock-AFUNIX){+...}-{3:3}, at: sockmapupdate_elem+0xdb/0x1f0

but task is already holding lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __locksockfast+0x37/0xe0

other info that might help us debug this: Possible unsafe locking scenario:

   CPU0
   ----

lock(slock-AFUNIX); lock(slock-AFUNIX);

*** DEADLOCK ***

May be due to missing lock nesting notation

4 locks held by testprogs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpfseqread+0x59/0x10d0 #1: ffff88811ec25fd8 (sklock-AFUNIX){+.+.}-{0:0}, at: bpfseqread+0x42c/0x10d0 #2: ffff88811ec25f58 (slock-AFUNIX){+...}-{3:3}, at: _locksockfast+0x37/0xe0 #3: ffffffff85a6a7c0 (rcureadlock){....}-{1:3}, at: bpfiterrunprog+0x51d/0xb00

Call Trace: dumpstacklvl+0x5d/0x80 printdeadlockbug.cold+0xc0/0xce _lockacquire+0x130f/0x2590 lockacquire+0x14e/0x2b0 rawspinlock+0x30/0x40 sockmapupdateelem+0xdb/0x1f0 bpfprog2d0075e5d9b721cddumpunix+0x55/0x4f4 bpfiterrunprog+0x5b9/0xb00 bpfiterunixseqshow+0x1f7/0x2e0 bpfseqread+0x42c/0x10d0 vfsread+0x171/0xb20 ksysread+0xff/0x200 dosyscall64+0x6b/0x3a0 entrySYSCALL64afterhwframe+0x76/0x7e