CVE-2026-98818

W jądrze Linuksa usunięto następującą lukę:

mm/płyta: nie budź kswapd w __kfree_rcu_sheaf()

Ponieważ funkcję kfree_rcu() można wywołać pod pi_lock (surowa blokada w pliku
harmonogram), sama funkcja kfree_rcu() nigdy nie powinna przydzielać pamięci
__GFP_KSWAPD_RECLAIM, gdy przebudzenie kswapd kończy się uzyskaniem pi_lock,
co prowadzi do impasu.

Odtworzenie problemu, nawet celowo, nie było proste.
Ścieżka set_cpus_allowed_force() wywoływana w pi_lock to
wykonywane bardzo rzadko, a konkurencyjne zadania alokujące pamięć będą
najprawdopodobniej obudzę się kswapd.

Dlatego też zweryfikowano istnienie zakleszczenia za pomocą zmodyfikowanego
jądro posiadające mapę lockdep do wybudzania kswapd:

=======================================================
OSTRZEŻENIE: wykryto możliwą zależność blokowania cyklicznego
7.2.0-rc1-slab-for-next+ #10 Nieskażone
----------------------------------------------------------------
git/6660 próbuje uzyskać blokadę:
ffff8e524533c550 (&p->pi_lock){-.-.}-{2:2}, w: _raw_spin_lock_irqsave+0x12/0x20

ale zadanie już blokuje:
ffff8e57bffff1a0 (&pgdat->kswapd_wait){....}-{3:3}, w: _raw_spin_lock_irqsave+0x12/0x20

który zamek zależy już od nowego zamka.

istniejący łańcuch zależności (w odwrotnej kolejności) to:

-> #2 (&pgdat->kswapd_wait){....}-{3:3}:
__lock_acquire+0x5a4/0xc50
lock_acquire.part.0+0xb7/0x240
blokada_nabycia+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
nowa_płyta+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
wybierz_fallback_rq+0x1e6/0x250
[...]

-> #0 (&p->pi_lock){-.-.}-{2:2}:
check_prev_add+0xe6/0xe00
valid_chain+0x51e/0x6e0
__lock_acquire+0x5a4/0xc50
lock_acquire.part.0+0xb7/0x240
blokada_nabycia+0x70/0x170
__raw_spin_lock_irqsave+0x44/0x80
_raw_spin_lock_irqsave+0x12/0x20
try_to_wake_up+0x77/0xa90
domyślna_funkcja_budzenia+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
nowa_płyta+0x52/0xb0
refill_objects+0x13d/0x190
refill_sheaf+0x5d/0xd0
__pcs_replace_empty_main+0x230/0xb10
[...]

inne informacje, które mogą nam pomóc w rozwiązaniu problemu:

Łańcuch istnieje:
&p->pi_lock --> kswapd_wakeup --> &pgdat->kswapd_wait

Możliwy niebezpieczny scenariusz blokowania:

Procesor0 Procesor1
---- ----
lock(&pgdat->kswapd_wait);
blokada(kswapd_wakeup);
lock(&pgdat->kswapd_wait);
lock(&p->pi_lock);

*** ZAMKNIĘCIE ***

3 blokady utrzymywane przez git/6660:
#0: ffff8e519f0e9e20 (&type->i_mutex_dir_key#6){++++}-{4:4}, w: lookup_slow+0x2d/0x60
#1: ffffffff8a31c460 (kswapd_wakeup){-.-.}-
---obcięty---