CVE-2026-97453 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: validate byte_count in acpi_ps_get_next_package_length()
Validate package length reading in acpi_ps_get_next_package_length().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The Advanced Configuration and Power Interface (ACPI) specification defines a complex subsystem within the Linux kernel responsible for hardware discovery, configuration, and power management. A critical component of this subsystem is the ACPI Component Architecture (ACPICA), which provides the reference implementation of the ACPI specifications. Within this architecture, the parsing logic handles various data structures defined in the Differentiated System Description Table (DSDT) and other ACPI tables. One such structure is the Package object, which can contain a variable number of elements of different types. The function acpi_ps_get_next_package_length() is responsible for reading and validating the length field associated with these package objects during the parsing process. A lack of sufficient validation in this specific routine created a potential security vulnerability that could be exploited by malicious ACPI tables or corrupted firmware images.
The core technical flaw lies in the insufficient validation of the byte_count parameter when processing package lengths. In normal operation, the parser reads a length value from the ACPI table and uses it to determine how many bytes follow for the package contents. If an attacker can influence this value through a maliciously crafted DSDT or SSDT (Secondary System Description Table), they may cause the kernel to read beyond allocated buffers or interpret invalid memory regions as valid data structures. This scenario typically arises when the length field is either negative, excessively large, or otherwise inconsistent with the actual size of the ACPI table in memory. Without proper bounds checking, the parser might proceed to dereference pointers based on this unvalidated count, leading to out-of-bounds reads or writes depending on subsequent operations within the parsing engine.
From a security perspective, this vulnerability aligns with CWE-125: Out-of-Bounds Read and potentially CWE-787: Out-of-Bounds Write if the invalid length leads to memory corruption during package element processing. The impact of such an issue can range from information disclosure, where sensitive kernel data is leaked through improper memory access, to denial of service via system crashes or panics caused by accessing unmapped pages. In more severe cases, particularly in environments with privileged ACPI execution contexts, it could potentially lead to arbitrary code execution if the corrupted state allows for control flow hijacking. The vulnerability highlights the risks associated with trusting firmware-provided data structures without rigorous validation, a common attack vector against operating system kernels that rely on hardware descriptions provided by BIOS or UEFI implementations.
Mitigation strategies primarily involve ensuring that the ACPICA parser strictly validates all length fields before proceeding with memory operations. This includes checking for negative values, verifying that the calculated end address does not exceed the bounds of the ACPI table in physical memory, and handling malformed structures gracefully without crashing the system. For administrators using affected kernel versions, applying vendor-provided security patches is essential to resolve this issue. Additionally, organizations should consider implementing firmware integrity verification mechanisms such as Secure Boot or custom TPM-based attestation to prevent the loading of maliciously modified ACPI tables from compromised BIOS/UEFI environments. Regular auditing of hardware compatibility and ensuring that system firmware remains up-to-date with vendor-supplied fixes further reduces the attack surface associated with ACPI parsing vulnerabilities.