Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-08-28T08:16:42.930Z",
  "pubdate": "2026-08-28T08:16:42.930Z",
  "executiveSummary": "The Linux kernel module asus_atk0110 is susceptible to an out-of-bounds (OOB) read vulnerability located within the atk_ec_present() function. The vulnerability arises from an improper validation of ACPI sub-package element counts before access.\nA local attacker or a malicious process capable of influencing ACPI firmware tables could exploit this flaw to read beyond the memory bounds of an allocated array. This exposure potentially leads to kernel memory disclosure or system instability, such as a kernel panic, if the out-of-bounds access triggers a page fault in protected memory regions.\nThe risk is primarily tied to the integrity of the system's ACPI tables. Since the vulnerability triggers during the parsing of GGRP method results, it requires the underlying platform firmware to provide a malformed or malicious sub-package structure. While typically requiring physical or elevated access to modify firmware, the impact on kernel security is significant due to the nature of privileged memory access.",
  "technicalDetails": "The vulnerability resides in the atk_ec_present() function within the asus_atk0110 hardware monitoring driver. This function is responsible for parsing ACPI management group packages retrieved via the GGRP ACPI method. During iteration over these packages, the driver processes sub-packages intended to contain specific hardware identifiers.\nThe root cause is a lack of bounds checking on the package.count attribute before accessing the internal elements array. Specifically, the driver executes 'id = &obj->package.elements[0];' under the assumption that every sub-package contains at least one element. However, if the ACPI firmware returns a sub-package with a package.count of zero, the ACPICA (ACPI Component Architecture) implementation allocates an empty element array. Accessing index zero of this empty array results in an out-of-bounds read, as the code effectively reads memory adjacent to the structure's allocated buffer.\nThe attack flow proceeds as follows: 1) The system initializes the asus_atk0110 driver, which invokes GGRP to enumerate hardware sensors. 2) The ACPI firmware returns a specially crafted or corrupted GGRP package structure containing an empty sub-package. 3) The atk_ec_present() function iterates through the package list. 4) Upon encountering the empty sub-package, the function blindly attempts to dereference 'elements[0]'. 5) This action causes the kernel to read memory contents outside the intended object boundaries, potentially leaking sensitive kernel stack or heap data to the attacker, or causing a general protection fault if the access hits unmapped memory.\nThis vulnerability is distinct from the sibling function atk_debugfs_ggrp_open(), which correctly implements a conditional check ('if (package.count > 0)') before accessing elements, demonstrating that the design pattern for safe iteration was established but inconsistently applied.\nExploitation requires no specific network exposure, as the flaw is contained within the kernel's hardware abstraction layer. Authentication is not directly required to trigger the bug, provided the kernel attempts to enumerate the vulnerable ACPI tables during normal operation or via user-space triggers (e.g., accessing sysfs or debugfs interfaces associated with the driver). The post-exploitation impact ranges from information disclosure of kernel memory to denial-of-service via kernel panic."
}