CVE-2026-98818

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

mm/slab: do not wake up kswapd in kfree rcu sheaf()

Since kfree rcu() can be called under pi lock (a raw spinlock in the scheduler), kfree rcu() itself should never allocate memory with GFP KSWAPD RECLAIM as waking up kswapd ends up acquiring pi lock, which leads to a deadlock.

Reproducing the issue even intentionally was not straightforward. The set cpus allowed force() path that is called under pi lock is exercised very rarely, and competing tasks that allocate memory will most likely wake kswapd up.

Therefore the existence of the deadlock was verified with a modified kernel that has a lockdep map for waking up kswapd:

git/6660 is trying to acquire lock: ffff8e524533c550 (&p->pi lock){-.-.}-{2:2}, at: raw spin lock irqsave+0x12/0x20

but task is already holding lock: ffff8e57bffff1a0 (&pgdat->kswapd wait){....}-{3:3}, at: raw spin lock irqsave+0x12/0x20

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&pgdat->kswapd wait){....}-{3:3}: lock acquire+0x5a4/0xc50 lock acquire.part.0+0xb7/0x240 lock acquire+0x70/0x170 raw spin lock irqsave+0x44/0x80 raw spin lock irqsave+0x12/0x20 wake up common lock+0x31/0xa0 wake up+0x20/0x40 kswapd wakeup wake+0x7e/0x110 wakeup kswapd+0x295/0x320 wake all kswapds+0xac/0x1a0 alloc pages slowpath.constprop.0+0x282/0xf80 alloc frozen pages noprof+0x32a/0x360 alloc slab page+0x2e/0x160 allocate slab+0x82/0x420 new slab+0x52/0xb0 refill objects+0x13d/0x190 refill sheaf+0x5d/0xd0 pcs replace empty main+0x230/0xb10 [...]

-> #1 (kswapd wakeup){-.-.}-{0:0}: lock acquire+0x5a4/0xc50 lock sync.part.0+0x75/0x100 lock sync+0x36/0x70 might wakeup kswapd+0x61/0xa0 kfree rcu sheaf+0x33/0xd90 kvfree call rcu+0x1d4/0x3b0 set cpus allowed force+0x163/0x220 cpuset cpus allowed fallback+0x18b/0x240 select fallback rq+0x1e6/0x250 [...]

-> #0 (&p->pi lock){-.-.}-{2:2}: check prev add+0xe6/0xe00 validate chain+0x51e/0x6e0 lock acquire+0x5a4/0xc50 lock acquire.part.0+0xb7/0x240 lock acquire+0x70/0x170 raw spin lock irqsave+0x44/0x80 raw spin lock irqsave+0x12/0x20 try to wake up+0x77/0xa90 default wake function+0x27/0x60 autoremove wake function+0x23/0xb0 wake up common+0xb8/0x170 wake up common lock+0x51/0xa0 wake up+0x20/0x40 kswapd wakeup wake+0x7e/0x110 wakeup kswapd+0x295/0x320 wake all kswapds+0xac/0x1a0 alloc pages slowpath.constprop.0+0x282/0xf80 alloc frozen pages noprof+0x32a/0x360 alloc slab page+0x2e/0x160 allocate slab+0x82/0x420 new slab+0x52/0xb0 refill objects+0x13d/0x190 refill sheaf+0x5d/0xd0 pcs replace empty main+0x230/0xb10 [...]

other info that might help us debug this:

Chain exists of: &p->pi lock --> kswapd wakeup --> &pgdat->kswapd wait

Possible unsafe locking scenario:

 CPU0          CPU1
 ----          ----

lock(&pgdat->kswapd wait); lock(kswapd wakeup); lock(&pgdat->kswapd wait); lock(&p->pi lock);

*** DEADLOCK ***

3 locks held by git/6660: #0: ffff8e519f0e9e20 (&type->i mutex dir key#6){++++}-{4:4}, at: lookup slow+0x2d/0x60 #1: ffffffff8a31c460 (kswapd wakeup){-.-.}- ---truncated---