Linux kernel ACPI Platform Firmware Runtime Update: firmware-supplied length overflows a stack buffer

Impact

query_capability() memcpy's four ACPI buffer objects returned by the firmware _DSM into fixed u8[16] fields of a stack-allocated struct pfru_update_cap_info, using the firmware-supplied length without checking it. Firmware returning more than 16 bytes for code_type, drv_type, platform_id or oem_id writes past the destination array; KASAN on 7.2-rc6 shows three stack-out-of-bounds reports with writes reaching 44 bytes past the end of the frame window into adjacent redzones. This is the runtime firmware update path on platforms that support it, so the trust boundary at stake is exactly the one an operator relies on when applying microcode or platform firmware without a reboot. Exploitation requires firmware that returns oversized buffers, so the realistic threat is already-tampered or simply buggy platform firmware turning a firmware-update operation into kernel stack corruption.

Who can reach it

Local, via the pfru ioctl, combined with platform firmware that returns oversized _DSM buffers. The ioctl is administrative and the firmware side must misbehave, so this is not reachable by a tenant workload on a machine with sound firmware.

What to do

Apply the stable kernel update, which validates each buffer length against its destination field size and returns -EINVAL on an oversized buffer, and reboot the node. No firmware flash is required - the fix is entirely on the kernel side. Nodes without ACPI Platform Firmware Runtime Update support are not exposed. The record gives four stable commits and no fixed release numbers.

References

Related entries

• Linux kernel APEI GHES: wrong sizeof lets ARM error-record parsing read past the CPER sectionCVE-2026-89588 · Linux kernel ACPI APEI GHES (ARM processor CPER section length accounting)Unscored
• ASPEED BMC (host-to-BMC bridges generally): The ASPEED LPC/PCIe bridge architecture exists to let the host talkNCVD-0000-001-aspeed-bmc-host-to-bmc-bridges-g · ASPEED BMC (host-to-BMC bridges generally)Unscored
• IPMI over LAN as a protocol: IPMI has no transport confidentiality guarantees worth relying on, weak session handlingNCVD-0000-002-ipmi-over-lan-as-a-protocol · IPMI over LAN as a protocolUnscored
• Internet-exposed BMC: Shodan-visible BMCs are a recurring finding at colo/neocloud buildoutsNCVD-0000-003-internet-exposed-bmc · Internet-exposed BMCUnscored
• InfiniBand subnet manager (OpenSM / UFM): The IB subnet manager has unilateral authority over LID assignment, routingNCVD-0000-004-infiniband-subnet-manager-opensm · InfiniBand subnet manager (OpenSM / UFM)Unscored
• RDMA / RoCE: RoCE and IB RDMA have no cryptographic authentication of the QP connection setup or of subsequentNCVD-0000-005-rdma-roce · RDMA / RoCEUnscored