CVE-2026-98818 in Linux
Riassunto
di VulDB • 19/10/2026
Nel kernel Linux, la seguente vulnerabilità è stata risolta:
mm/slab: non svegliare kswapd in __kfree_rcu_sheaf()
Poiché kfree_rcu() può essere chiamata sotto pi_lock (un raw spinlock nello scheduler), kfree_rcu() stessa non dovrebbe mai allocare memoria con __GFP_KSWAPD_RECLAIM, poiché il risveglio di kswapd finisce per acquisire pi_lock, portando a un deadlock.
Riprodurre l'issue, anche intenzionalmente, non era semplice. Il percorso set_cpus_allowed_force(), chiamato sotto pi_lock, viene esercitato molto raramente e i task concorrenti che allocano memoria risveglieranno probabilmente kswapd.
Pertanto, l'esistenza del deadlock è stata verificata con un kernel modificato dotato di una mappa lockdep per il risveglio di kswapd:
====================================================== WARNING: possibile dipendenza circolare nel rilevamento dei locking 7.2.0-rc1-slab-for-next+ #10 Not tainted ------------------------------------------------------ git/6660 sta cercando di acquisire il lock: ffff8e524533c550 (&p->pi_lock){-.-.}-{2:2}, at: _raw_spin_lock_irqsave+0x12/0x20
ma il task ha già in possesso il lock: ffff8e57bffff1a0 (&pgdat->kswapd_wait){....}-{3:3}, at: _raw_spin_lock_irqsave+0x12/0x20
che questo lock dipende già dal nuovo lock.
la catena di dipendenze esistente (in ordine inverso) è:
-> #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 [...]
altre informazioni che potrebbero aiutarci nel debug:
La catena esiste di: &p->pi_lock --> kswapd_wakeup --> &pgdat->kswapd_wait
Possibile scenario di locking non sicuro:
CPU0 CPU1 ---- ---- lock(&pgdat->kswapd_wait); lock(kswapd_wakeup); lock(&pgdat->kswapd_wait); lock(&p->pi_lock);
*** DEADLOCK ***
3 locks detenuti da git/6660: #0: ffff8e519f0e9e20 (&type->i_mutex_dir_key#6){++++}-{4:4}, at: lookup_slow+0x2d/0x60
#1: ffffffff8a31c460 (kswapd_wakeup){-.-.}-
---truncated---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.