CVE-2026-89436

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: platform/x86: panasonic-laptop: pcc->sinf[] massivindən kənara sentinel yazılmasının düzəldilməsi acpi_pcc_retrieve_biosdata() funksiyası SINF paketlərini yalnız pcc->num_sifr dəyəri hkey->package.count dəyərindən ciddi şəkildə kiçik olduqda rədd edir, daha sonra isə şərtə baxmayaraq pcc->sinf[hkey->package.count] ünvanına sonuncu sentinel dəyərini yazır. Lakin pcc->sinf[] tam olaraq pcc->num_sifr elementi ilə ayrılır (etibarlı indekslər 0..num_sifr-1), buna görə də həmin yazma əməliyyatının sərhədlər daxilində qalması üçün num_sifr dəyəri package.count-dan ciddi şəkildə böyük olmalıdır — num_sifr == package.count halında mövcud yoxlama keçilir, lakin yenə də bir element miqdarında daşma baş verir. Bu, məhz probe() funksiyasındakı mövcud num_sifr++ müvəqqəti həllinin ("Bəzi DSDT-lərdə SINF paketi sayının hesabat verilən SQTY dəyərindən bir vahid çox olduğu 'off-by-one' xətası var") tətbiq edildiyi vəziyyətdir: DSDT-nin SINF paketi sayı SQTY+1-ə bərabər olduqda, bu müvəqqəti həll num_sifr-i package.count-a bərabər edir ki, bu da məhz burada daşmaya səbəb olan sərhəddir. Bu problem, HKEY.SQTY 37 qaytardığı və HKEY.SINF() paketinin 38 elementi olduğu aparat təminatı üzərində UBSan (array-index-out-of-bounds) vasitəsilə aşkar edilmişdir: += 1 müvəqqəti həllindən sonra num_sifr 38 olur, dövr 0..37 indekslərini düzgün doldurur və sentinel yazılması 38-ci indeksə, yəni sonundan bir vahid kənara yönəlir — bu, CONFIG_UBSAN olmayan nüvələrdə səssiz 4 baytlıq heap daşmasına səbəb olur. Rədd etmə yoxlamasının num_sifr <= package.count şəklində sərtləşdirilməsi daşmanın qarşısını alardı, lakin məhz bu aparat təminatında probe() funksiyasının işini tamamilə pozardı, çünki num_sifr == package.count halı "off-by-one" müvəqqəti həllinin dəstəklədiyi vəziyyətdir. Drayverdə heç bir digər hissə bu sentinel dəyərini geri oxumadığı üçün, yer olmadıqda sadəcə yazma əməliyyatından imtina edilir.