CVE-2026-97936

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

śledzenie: Napraw uszkodzenie pamięci przez modyfikator śledzenia stosu histogramu

parse_field() ustawia HIST_FIELD_FL_STACKTRACE z „.stacktrace”
modyfikator przed sprawdzeniem nazwy pola i nic później
sprawdza, czy nazwa została przekształcona w pole zawierające znacznik stosu.
create_hist_field() wybiera HIST_FIELD_FN_STACK na podstawie siły
sam wskaźnik pola, który odczytuje słowo __data_loc z rekordu i
podąża za swoimi najniższymi 16 bitami jako przesunięcie w tym samym rekordzie.
event_hist_trigger() przyjmuje pierwsze słowo jako liczbę wpisów i
kopiuje tyle longów do tablicy zawierającej 31 wpisów:

n_entries = *stos;
memcpy(wpisy, ++stack, n_entries * sizeof(długie bez znaku));

Żaden koniec tej kopii nie jest ograniczony, a liczba zależy od zdarzenia
trzyma przesunięcie, więc dowolne pole zrobi:

# cd /sys/kernel/tracing/events/sched/sched_process_fork
# echo 'hist:keys=parent_pid.stacktrace' > wyzwalacz
# (prawda)

BŁĄD: wyłuskiwanie wskaźnika NULL jądra, adres: 0000000000000008
RIP: 0010:rb_insert_color+0x18/0x130
timerqueue_linked_add+0x7e/0xd0
enqueue_hrtimer+0x39/0xb0
__hrtimer_run_queues+0x10f/0x1f0
</IRQ>
RIP: 0010:memcpy+0xc/0x30
event_hist_trigger+0x165/0x690

Przerwanie czasowe wylądowało na drzewie rb, przez które kopia już przejechała.
Nie są do tego potrzebne żadne opcje debugowania; KASAN zgłasza ten sam zapis co an
odczyt poza granicami 13835058055416381440 bajtów.

Dokumentacja/trace/histogram.rst już określa zasadę „musi być
long[]”, więc wymuś go po rozwiązaniu nazwy. Nazwy które
nie rezygnować z żadnego pola, „hitcount.stacktrace” i common_*
pseudo-pola są odrzucane z tego samego powodu: nie zawierają one śladu stosu
czytać.