CVE-2026-80593 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (asus_atk0110) Check package count before accessing element
atk_ec_present() walks the management group package returned by the GGRP ACPI method and, for each sub-package, reads its first element:
id = &obj->package.elements[0];
if (id->type != ACPI_TYPE_INTEGER)
without checking that the sub-package is non-empty. ACPICA allocates the element array with exactly package.count entries, so for a sub-package with a zero count this reads past the allocation.
The sibling function atk_debugfs_ggrp_open() performs the same access but skips empty packages with a package.count check first. Add the same check to atk_ec_present() so a malformed firmware package cannot trigger an out-of-bounds read.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in the Linux kernel within the hwmon driver for ASUS ATK0110 devices represents a classic out-of-bounds read condition arising from insufficient input validation of ACPI data structures. The core issue resides in the atk_ec_present function, which is responsible for parsing management group packages returned by the GGRP ACPI method. This routine iterates through sub-packages contained within the main package and attempts to access the first element of each sub-package to determine its type, specifically checking if it is an integer. However, the implementation fails to verify whether the sub-package contains any elements before attempting this access. In C programming terms, the code directly references obj->package.elements[0] without ensuring that the array has a size greater than zero. This oversight creates a critical security gap where malformed or unexpected firmware data can lead to memory corruption or information disclosure.
From a technical perspective, the root cause is linked to how ACPICA allocates memory for ACPI package elements. The allocation mechanism reserves space strictly equal to the count specified in the package structure. When a sub-package has a zero element count, the allocated array size is effectively zero. Attempting to read index 0 from an empty array constitutes an out-of-bounds read, allowing the kernel to access memory outside the intended buffer boundaries. This behavior contrasts sharply with the sibling function atk_debugfs_ggrp_open(), which correctly implements defensive programming by checking package.count before accessing elements. The absence of this check in atk_ec_present indicates a lack of consistency in error handling across related code paths within the driver, leaving one specific entry point vulnerable to exploitation via maliciously crafted ACPI tables provided by firmware or potentially manipulated hardware interfaces.
The operational impact of this vulnerability is significant due to its potential for privilege escalation and system instability. An out-of-bounds read can lead to kernel panics if the accessed memory location contains invalid data or triggers a page fault, resulting in a denial of service against the host system. More critically, depending on what adjacent memory contents are exposed, an attacker could potentially leak sensitive kernel information such as stack pointers, function addresses, or other security-critical data structures. This aligns with CWE-125, which describes out-of-bounds read vulnerabilities where software reads beyond the end of a buffer. Furthermore, this flaw facilitates exploitation techniques categorized under MITRE ATT&CK Tactic TA0043: Discovery, as it allows for information gathering that could aid in further attacks against the system's security posture.
Mitigation strategies primarily involve applying the vendor-provided kernel patch that introduces the missing validation check. The fix ensures that atk_ec_present() mirrors the logic of atk_debugfs_ggrp_open by verifying package.count is greater than zero before accessing elements[0]. System administrators should prioritize updating to a patched version of the Linux kernel as soon as it becomes available for their distribution. In environments where immediate patching is not feasible, monitoring system logs for hardware-related errors or ACPI parsing failures may provide early indicators of exploitation attempts. Additionally, ensuring that firmware updates are sourced from trusted manufacturers can reduce the risk of encountering malformed ACPI tables designed to trigger this vulnerability. Regular auditing of driver code for similar patterns of unchecked array access in other parts of the kernel is also recommended to prevent analogous issues elsewhere in the system.