CVE-2026-89436

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

platforma/x86: panasonic-laptop: Napraw zapis Sentinel obok pcc->sinf[]

acpi_pcc_retrieve_biosdata() odrzuca pakiety SINF tylko wtedy, gdy
pcc->num_sifr jest zatem dokładnie mniejsze niż hkey->package.count
bezwarunkowo zapisuje końcowy wartownik w
pcc->sinf[hkey->package.count]. Ale pcc->sinf[] jest przydzielany za pomocą
dokładnie elementy pcc->num_sifr (ważne indeksy 0..num_sifr-1), tak że
write potrzebuje num_sifr ściśle większej niż package.count, aby pozostać
bounds -- num_sifr == package.count przechodzi istniejącą kontrolę ale
nadal przepełnia się o jeden element.

Dokładnie tak jest w przypadku istniejącego obejścia num_sifr++ dla sondy().
(„Niektóre DSDT mają błąd związany z liczbą pakietów SINF
o jeden wyższy niż podana wartość SQTY”) jest zapisywany, aby uwzględnić:
gdy liczba pakietów SINF DSDT jest równa SQTY+1, stosuje się obejście
num_sifr równe package.count, czyli dokładnie ta granica
tutaj się przelewa. Znaleziono przez UBSan (indeks tablicy poza granicami) na
hardware, gdzie HKEY.SQTY zwraca 37, a pakiet HKEY.SINF() ma 38
elementy: num_sifr staje się 38 po obejściu += 1, czyli pętli
poprawnie wypełnia indeksy 0..37, a wartownik zapisuje następnie cele
indeks 38, jeden za końcem — ciche 4-bajtowe przepełnienie sterty w jądrach
bez CONFIG_UBSAN.

Zaostrzenie kontroli odrzucenia do num_sifr <= package.count spowodowałoby
unikaj przepełnienia, ale całkowicie przerywa sondę() dokładnie na tym
hardware, ponieważ num_sifr == package.count jest przypadkiem off-by-one
istnieje obejście, które można wesprzeć. Nic innego w sterowniku tego nie czyta
wartość wartowniczą z powrotem, więc po prostu pomiń zapis, gdy nie ma miejsca
zamiast tego.