CVE-2026-89436
nicheOff-by-one heap overflow in Linux kernel panasonic-laptop ACPI driver
The Linux kernel's panasonic-laptop driver (drivers/platform/x86/panasonic-laptop.c) unconditionally writes a 4-byte sentinel one element past the end of the heap-allocated pcc->sinf[] array in acpi_pcc_retrieve_biosdata(), and this out-of-bounds write fires exactly when the ACPI SINF package count equals num_sifr — the boundary case that probe()'s existing off-by-one workaround deliberately creates on Panasonic firmware where the SINF package count is SQTY+1 (observed hardware: SQTY=37, SINF=38 elements). The overflow is triggered whenever the driver reads HKEY.SINF BIOS data, such as via sysfs attribute reads or hotkey/battery event processing, so a local low-privileged user on affected hardware can cause silent kernel heap corruption. On CONFIG_UBSAN kernels the write is caught and reported, but on standard kernels it is a silent 4-byte heap overflow that can corrupt adjacent heap objects and crash the machine; the written value is a fixed sentinel, which limits but does not eliminate impact (CVSS 3.1: 7.8, AV:L/AC:L/PR:L with C:H/I:H/A:H). Only systems running Linux on Panasonic laptops whose DSDT exhibits this SINF/SQTY off-by-one mismatch are affected. No public proof of concept is known and the flaw is not on the CISA KEV list.
What to do: Upgrade to a kernel containing the upstream fix, which skips the sentinel write when there is no room for it rather than tightening the bounds check; watch for stable-branch backports. Until patched, affected Panasonic systems can unload and blacklist the panasonic-laptop module to remove the trigger at the cost of hotkey/brightness functionality. Check dmesg for UBSan 'array-index-out-of-bounds' reports on pcc->sinf to identify machines actually hitting the bug.
| Linux kernel (panasonic-laptop platform/x86 driver) | — |
| Panasonic Laptops exposing the HKEY ACPI interface with a DSDT where the SINF package count equals SQTY+1 | Confirmed on hardware where HKEY.SQTY returns 37 and HKEY.SINF returns a 38-element package; exact model list not enumerated in this data |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.