CVE-2026-98942

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

sched_ext: Zbuduj tabele cid prywatnie i opublikuj je za pomocą RCU

Tabele cid są widoczne dla cid kfuncs podczas modyfikacji: the
First Enable publikuje globalne wskaźniki przed ich wypełnieniem,
ops.init_cids() zastępuje je i ponownie umożliwia przebudowę
je na miejscu. Program wyścigowy TRACING lub SYSCALL może czytać niewypełnione
wpisy, w tym niezainicjowana pamięć w tabelach kmalloc lub podarta
aktualizacje topo.

Zamiast tego powiąż okresy istnienia tabel ze schematem głównym: włączenie każdego roota
buduje prywatnie nowy zestaw i raz publikuje globale __rcu dla każdej tabeli
układ jest ostateczny, a wyłączenie roota cofa publikację, a RCU zwalnia zestaw. A
Global o wartości innej niż NULL jest teraz zawsze w pełni zbudowaną tabelą, która pozostaje ważna dla
sekcja odczytu RCU czytnika i wyszukiwania pozostają dwa ładunki. Kfuncs traktuje NULL jako
no-mapping, także po wyjściu programu planującego, zamiast zgłaszać nieaktualne
ostatnie mapowanie.

Cid kfuncs są dostępne niezależnie od tego, czy program planujący główny ma postać cid, czy
cpu-forma, ta ostatnia umożliwia stopniową migrację do cid. Każdy korzeń
dlatego buduje i publikuje mapowanie domyślne.

Każdy czytnik musi być albo bramkowany pod kątem aktywności harmonogramu, albo sprawdzany przez NULL
wewnątrz sekcji odczytu RCU. Napraw dwa kfuncs, które nie były żadnym z nich:
scx_bpf_this_cid() odczytuje tabelę bez RCU lub zabezpieczenia przed wywłaszczeniem i
scx_bpf_task_cid() opiera się na KF_RCU, która nie udostępnia programu do spania
w sekcji odczytu RCU. Zamiast tego wywołania zwrotne typu hotplug są serializowane przez
wycofywanie tabel w sekcji cpus_read_lock(), która zostanie wyczyszczona
scx_root.

v2: Dokument, dlaczego każdy root tworzy tabele (desc + komentarz w cid.c).