CVE-2026-89762

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

apparmor: napraw błąd UAF spowodowany przez Begin_current_label_crit_section()

Begin_current_label_crit_section() aplikacji AppArmor to przerażająca funkcja o nazwie
z wielu haków LSM (w szczególności tych związanych z VFS/gniazdkiem), które sprawdzają
jeśli etykieta, do której odwołują się bieżące źródła, jest oznaczona FLAG_STALE i if
więc próbuje użyć aa_replace_current_label() do zastąpienia kredytów przez
zaktualizowana wersja, która używa nowej etykiety.

Pierwszym problemem jest to, że prowadziłoby to bezpośrednio do UAF
`struct cred`, jeśli cokolwiek w jądrze pobiera wskaźnik do bieżącego
creds i uzyskuje do nich dostęp po wywołaniu haka bezpieczeństwa, który zastępuje
kredyty, w ten sposób:
```
const struct cred *cred = current_cred();
alloc_file_pseudo(...);
uid_t uid = cred->euid;
```
Nie wiem, czy cokolwiek w jądrze faktycznie to robi, ale myślę, że tak
jest bardzo zaskakujące, że ten wzór może prowadzić do UAF.

Drugi problem polega na tym, że coś idzie nie tak, gdy aa_replace_current_label()
działa z zastąpionymi poświadczeniami. aa_replace_current_label() wycofuje się, jeśli
`current_cred() != current_real_cred()` (odzwierciedlając odprawę
proc_pid_attr_write()), ale ta kontrola nie pozwala na niezawodne wykrycie
nadpisane poświadczenia, ponieważ nadpisane poświadczenia mogą być takie same jak
obiektywne kredyty.

Zatem w mniej więcej następującym scenariuszu coś idzie nie tak:

1. zadanie rozpoczyna się od <kredytów A> (zarówno kredytów obiektywnych, jak i subiektywnych),
z przeliczeniem=2
2. zadanie pobiera dodatkowe odniesienie na <creds A> w celu zastąpienia
3. zadanie wywołuje override_creds(<creds A>), które zwraca wskaźnik do starego
subiektywne oceny (<creds A>)
4. zadanie trafia do haka AppArmor LSM
5. AppArmor sprawdza, czy wiarygodność obiektywna i subiektywna są sobie równe
6. AppArmor zastępuje oba wskaźniki cred przez <creds B> i dodaje 2 referencje
<kredyty A>
7. zadanie pozostawia hak AppArmor LSM
8. wywołania zadań revert_creds(<creds A>)
9. teraz zadanie->kredyt to <kredyty A>, podczas gdy zadanie->prawdziwy_kredyt to <kredyty B>, ale
task_struct logicznie przechowuje dwa odniesienia do <creds B>
10. inne zadanie usuwa dodatkowe odniesienie do <creds A>, do którego zostało użyte
zastąpienie, przeliczenie spada do 0
11. teraz zadanie->real_cred wskazuje na uwolnione kredyty

W tym momencie każdy dostęp do current_cred() będzie UAF.

Mam przypadek testowy, w którym uruchamiam aa-disable na profilu podczas procesu
używanie tego profilu jest blokowane przez funkcję splice() z pliku tranzytowego FUSE do
pełna rura; po aktualizacji profilu potok staje się pusty, splice()
zostaje wznowiony, poświadczenia tracą synchronizację i następuje wywołanie systemowe getuid().
skutkuje plamą KASAN UAF.

Aby to naprawić, zamiast bezpośrednio zastępować kredyty, zrób to poprzez task_work that
zostanie uruchomiony na końcu bieżącego wywołania systemowego. (Moment w czasie, w którym
wymiana danych nie powinna mieć wpływu na poprawność; to jest po prostu
optymalizacja wydajności, aby uniknąć niepotrzebnego dotykania przeliczania
nową etykietę.)

Należy pamiętać, że AppArmor nadal dokonuje bezpośredniej zamiany kredytów w plikach
sb_pivotroot LSM po tej zmianie i bezpośrednie zastąpienie kredytów
może nadal mieć miejsce w wywołaniach zwrotnych VFS ->write() za pośrednictwem proc_pid_attr_write().

Istnieją dwie możliwości wykorzystania funkcji aa_dup_task_ctx(): Albo
jawnie zresetuj nowy->label_replacement_pending po całym
aa_task_ctx został skopiowany lub przełącz się na ręczne kopiowanie członków.
Przechodzę na ręczne kopiowanie członków, ponieważ to powinno wystarczyć
błędy są bardziej oczywiste.