CVE-2026-68325 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Bound the early ACPI HID map
The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size.
Check the capacity at the common found label before parsing the HID and UID or writing the entry.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/11/2026
This vulnerability resides within the AMD IOMMU driver of the Linux kernel, specifically affecting the early ACPI HID (Hardware ID) mapping functionality. The issue manifests in the ivrs_acpihid command-line parser which manages a fixed-size array called early_acpihid_map containing only four elements. This array serves as a critical component in the early boot phase for establishing IOMMU mappings based on ACPI hardware identifiers. The flaw occurs during the parsing process where the system does not properly validate array bounds before appending new entries, creating a potential buffer overflow condition that could be exploited to disrupt system operation or potentially escalate privileges.
The technical implementation of this vulnerability stems from inconsistent boundary checking practices within the kernel's ACPI parsing subsystem. While sibling parsers for IOAPIC and HPET devices correctly validate capacity limits before incrementing map sizes, the IVRS (IOMMU Virtualization Services) ACPI HID parser fails to perform this crucial validation step. The parser follows a common found label pattern that processes HID and UID values without first confirming whether the target array has sufficient capacity. This oversight allows for a fifth entry to be appended to the four-element array, effectively overwriting adjacent memory locations and potentially corrupting kernel data structures or executing arbitrary code.
The operational impact of this vulnerability extends beyond simple memory corruption, as it represents a classic buffer overflow scenario that could enable privilege escalation attacks within the kernel space. Attackers exploiting this flaw could manipulate the IOMMU mapping tables during early boot phases when system security controls are still being established. This timing is particularly critical since early boot vulnerabilities often provide attackers with opportunities to establish persistent backdoors or compromise the integrity of the entire system. The vulnerability also aligns with CWE-121, which describes stack-based buffer overflow conditions, and potentially CWE-787, representing out-of-bounds write conditions in heap or static memory.
The mitigation strategies for this vulnerability involve implementing proper bounds checking before array modifications, specifically ensuring that the capacity check occurs at the common parsing label as suggested in the fix description. This approach aligns with standard security practices outlined in the ATT&CK framework under T1068, which covers exploiting vulnerabilities in kernel modules. System administrators should prioritize updating to patched kernel versions where the early_acpihid_map array validation has been implemented correctly. Additionally, monitoring for unusual command-line parameters or ACPI parsing activities during system boot phases can serve as an operational security measure to detect potential exploitation attempts.
From a defensive perspective, this vulnerability demonstrates the importance of consistent boundary checking across all kernel subsystems and highlights how seemingly minor implementation differences between similar components can create significant security risks. The fix addresses both the immediate buffer overflow condition and reinforces proper input validation practices that should be applied throughout the kernel's ACPI parsing infrastructure. This aligns with industry best practices for secure coding and represents a typical example of how defensive programming techniques can prevent memory corruption vulnerabilities from being exploited in real-world scenarios.