CVE-2026-89587: ACPI: pfr_update: fix stack buffer overflow in query_capability()
In the Linux kernel, the following vulnerability has been resolved:
ACPI: pfrupdate: fix stack buffer overflow in querycapability()
querycapability() copies four ACPI buffer objects returned by the firmware DSM into fixed-size u8[16] fields in struct pfruupdatecapinfo using memcpy with the firmware-supplied length:
memcpy(&caphdr->codetype, elements[CAPCODETYPEIDX].buffer.pointer, elements[CAPCODETYPEIDX].buffer.length);
The same pattern repeats for drvtype, platformid, and oemid. If the firmware returns buffer.length > 16 for any of these fields, memcpy writes past the destination array.
struct pfruupdatecapinfo is stack-allocated in pfruioctl().
Confirmed with KASAN on 7.2-rc6: three stack-out-of-bounds reports are generated when a DSM returns 64-byte buffers, with writes reaching 44 bytes past the end of caphdr's [64, 156) frame window into adjacent stack redzones.
Introduce a helper pointer to outobj->package.elements and use it to validate each buffer length against its destination field size before copying, returning -EINVAL if the firmware supplies an oversized buffer.
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel's ACPI PFR update functionality are exposed when firmware provides a crafted or malformed _DSM response containing one or more capability buffers longer than 16 bytes. The vulnerable copy occurs while handling the relevant capability query through pfru_ioctl().
What does an attacker or triggering condition need to exploit the overflow?
The triggering condition is firmware-controlled ACPI _DSM data with an oversized buffer for code_type, drv_type, platform_id, or oem_id. A buffer longer than 16 bytes causes a memcpy into a fixed-size 16-byte stack field without a length check.
How can this be detected or confirmed?
KASAN can detect the condition as stack-out-of-bounds writes during the capability query. In the reported test case, 64-byte _DSM buffers produced three reports and writes up to 44 bytes beyond the relevant stack frame window.
What behavior changes after the fix?
The fix validates each firmware-provided buffer length against the size of its destination field before copying. If firmware supplies an oversized buffer, the capability query fails with -EINVAL instead of copying the data.