Look up another CVE · open CVE-2026-89436 in the interactive tracker
CVE-2026-89436
platform/x86: panasonic-laptop: Fix sentinel write past pcc->sinf[]
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/platform. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89436 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | not affected | 7.2.11-1 | Nothing to do. forky never shipped the vulnerable code. |
| Debian unstablesid | not affected | 7.2.11-1 | Nothing to do. sid never shipped the vulnerable code. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/platform/x86/panasonic-laptop.c
- What this is
- PANASONIC LAPTOP ACPI EXTRAS DRIVERMAINTAINERS section matched on drivers/platform/x86/panasonic-laptop.c · platform-driver-x86@vger.kernel.org · Maintained
- Kernel module
- panasonic_laptop
Check it on the machine
grep -wE 'CONFIG_PANASONIC_LAPTOP|CONFIG_X86' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w panasonic_laptopPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/arm64, arm64/cloud-arm64, arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
- trixieMnot built on amd64/cloud-amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_PANASONIC_LAPTOP, CONFIG_X86
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/platform
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.2 | 7.2.4 | a93df956ee4d |
| 7.2 | 7.3 | 329f10d8be19 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The overflow is reached by reading world-readable sysfs files under /sys/bus/acpi/devices/MAT00xx:00/ (numbatt, lcdtype, mute, sticky_key, eco_mode, brightness) and /sys/class/backlight/panasonic/, which call acpi_pcc_retrieve_biosdata(); there is no network or remote-peer path into this ACPI laptop driver.
- AC:LAttack complexity, low
- On Panasonic Let's Note firmware where HKEY.SINF's package count equals SQTY+1, every sysfs or backlight read deterministically writes the sentinel one past pcc->sinf[]; no race is required. That DSDT off-by-one is a fixed property of the affected hardware being scored, not a per-attempt condition.
- PR:LPrivileges required, low
- The triggering attributes are DEVICE_ATTR_RO (0444) or DEVICE_ATTR_RW (0644), so any unprivileged local user can read them and cause the out-of-bounds write with no capability, group membership, or init-namespace root.
- UI:NUser interaction, none
- The attacker reads a sysfs attribute from their own process; no victim action such as mounting a filesystem, plugging hardware, or confirming a prompt is required.
- S:UScope, unchanged
- The 4-byte heap overflow corrupts host kernel slab memory belonging to the same kernel security authority that hosts the driver; it does not cross a VM, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- The off-by-one writes 0xffffffff one u32 past the kzalloc_flex pcc_acpi object, corrupting adjacent kmalloc slab contents including pointers on size-class-aligned allocations; that heap corruption can be leveraged for kernel information disclosure, so confidentiality is High.
- I:HIntegrity impact, high
- This is a repeatable 4-byte out-of-bounds heap write of the sentinel past pcc->sinf[]. Per kernel scoring guidance an OOB write is High because heap grooming can place a security-relevant object at the overwritten offset and turn it into a control-flow or privilege primitive.
- A:HAvailability impact, high
- Writing past the kmalloc object can corrupt neighboring slab objects or metadata and produce a kernel oops or panic, and debug kernels trip KASAN/UBSAN on the counted-by overflow; any such crash is Availability High.