platform/x86: panasonic-laptop: Fix sentinel write past pcc->sinf[]
Summary
| CVE | CVE-2026-89436 |
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-09-11 20:19:23 UTC |
| Updated | 2026-09-11 20:19:23 UTC |
| Description | 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. |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected a3d0dbd18ce908292607bb6cf37c978ece8a33d4 a93df956ee4d903735b6d395362c839cb1dc07e3 git |
Not specified |
| CNA |
Linux |
Linux |
affected a3d0dbd18ce908292607bb6cf37c978ece8a33d4 329f10d8be193bf36af124e00b9dd6644cd71724 git |
Not specified |
| CNA |
Linux |
Linux |
affected 7.2 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.2 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.2.4 7.2.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.3-rc1 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/a93df956ee4d903735b6d395362c839cb1dc07e3 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/329f10d8be193bf36af124e00b9dd6644cd71724 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.