CVE Catalog

CVE-2026-81011

HighCVSS 7.1
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.13%

3th percentile - higher than 3% of all known CVEs

Summary

In the Linux kernel's platform/x86 hp-bioscfg module, the per-type ACPI package parsers were handed the wrong element count — instead of the validated obj->package.count they derived it from the NAME field (an ACPI_TYPE_STRING), effectively reading string.length through the acpi_object union. This is safe today because hp_init_bios_package_attribute() rejects packages with fewer elements than the type requires, but an upcoming relaxation of that check would cause an out-of-bounds heap read. The fix forwards the validated obj->package.count to every parser.

Risk Assessment

The vulnerability is not currently exploitable on its own, but it is a prerequisite for a future out-of-bounds heap read that could lead to data disclosure or a kernel crash once the change accepting shorter packages is applied.

Recommendation

Update the Linux kernel to a version containing this fix (hp-bioscfg module) and avoid applying changes that relax the element count check without this fix in place.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: pass validated element count to package parsers The per-type package parsers are handed the wrong element count. hp_init_bios_package_attribute() validates obj->package.count and then calls one of the five hp_populate_*_package_data() wrappers (string, integer, enumeration, ordered list, password). Each wrapper forwards a count to its hp_populate_*_elements_from_package() parser, but instead of forwarding the validated obj->package.count it derives the count from elements[0]. elements[0] is the NAME field and is always an ACPI_TYPE_STRING, so reading ->package.count from it in fact reads ->string.length through the union acpi_object. The parsers thus bound themselves against the length of the name string rather than against the real number of elements in the package. This is safe today because hp_init_bios_package_attribute() refuses any package that has fewer than the type's element count, so a parser only ever runs on a full package and never reads past it regardless of the bogus bound. An upcoming change relaxes that check to accept shorter packages. Once a parser can receive fewer elements than its per-type count, a bound taken from the name length no longer reflects the array size, and the "elem < count" loop conditions and "elem + n >= count" sub-loop guards read past the end of elements[] - an out-of-bounds heap read. Forward the validated obj->package.count to every *_package_data() wrapper so the parsers bound themselves against the real package size. This does not change behaviour for the packages that enumerate correctly today and is a prerequisite for accepting shorter packages safely.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS