CVE-2026-89436: platform/x86: panasonic-laptop: Fix sentinel write past pcc->sinf[]
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: panasonic-laptop: Fix sentinel write past pcc->sinf[]
acpipccretrievebiosdata() rejects SINF packages only when pcc->numsifr 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->numsifr elements (valid indices 0..numsifr-1), so that write needs numsifr strictly greater than package.count to stay in bounds -- numsifr == package.count passes the existing check but still overflows by one element.
This is exactly the case probe()'s existing numsifr++ 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 numsifr 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: numsifr 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 CONFIGUBSAN.
Tightening the rejection check to numsifr <= package.count would avoid the overflow but breaks probe() entirely on exactly this hardware, since numsifr == 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch platform/x86: panasonic-laptop: Fix sentinel write past pcc->sinf[] - Configuration
Fix the off-by-one by tightening the sentinel-write logic in acpi_pcc_retrieve_biosdata(): only perform the trailing sentinel write when there is room (do not write past pcc->sinf[]). This corresponds to the 'sentinel write past pcc->sinf[]' fix for the panasonic-laptop platform.
acpi_pcc_retrieve_biosdata() (Linux kernel, ACPI PCC) sentinel write condition for pcc->sinf[] = Skip the trailing sentinel write when there is no room (i.e., when pcc->num_sifr is not strictly greater than hkey->package.count / package.count)
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems using the Linux kernel's panasonic-laptop driver are affected when their firmware reports an HKEY.SINF package with one more element than the HKEY.SQTY value. The reported triggering hardware returned SQTY=37 and a 38-element SINF package.
What condition triggers the out-of-bounds write?
The driver must allocate sinf[] with a count equal to the SINF package count, then write its trailing sentinel at the index equal to that count. This occurs when the existing num_sifr increment workaround makes num_sifr equal to package.count.
How can an affected system be identified?
The issue was detected by UBSan as an array-index-out-of-bounds condition during BIOS data retrieval. Affected firmware exposes a SINF package count that is one higher than its reported SQTY value.