CVE-2026-89436

In the Linux kernel, the following vulnerability has been resolved:

platform/x86: panasonic-laptop: Fix sentinel write past pcc->sinf[]

acpi pcc retrieve biosdata() rejects SINF packages only when pcc->num sifr is strictly less than hkey->package.count, then unconditionally writes a trailing sentinel at pcc->sinf[hkey->package.count]. But pcc->sinf[] is allocated with exactly pcc->num sifr elements (valid indices 0..num sifr-1), so that write needs num sifr strictly greater than package.count to stay in bounds -- num sifr == package.count passes the existing check but still overflows by one element.

This is exactly the case probe()'s existing num sifr++ workaround ("Some DSDT-s have an off-by-one bug where the SINF package count is one higher than the SQTY reported value") is written to accommodate: when a DSDT's SINF package count equals SQTY+1, the workaround makes num sifr equal to package.count, which is precisely the boundary that overflows here. Found via UBSan (array-index-out-of-bounds) on hardware where HKEY.SQTY returns 37 and HKEY.SINF()'s package has 38 elements: num sifr becomes 38 after the += 1 workaround, the loop correctly fills indices 0..37, and the sentinel write then targets index 38, one past the end -- a silent 4-byte heap overflow on kernels without CONFIG UBSAN.

Tightening the rejection check to num sifr <= package.count would avoid the overflow but breaks probe() entirely on exactly this hardware, since num sifr == package.count is the case the off-by-one workaround exists to support. Nothing else in the driver reads this sentinel value back, so simply skip the write when there is no room for it instead.