CVE-2026-81011: platform/x86: hp-bioscfg: pass validated element count to package parsers
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.
hpinitbiospackageattribute() validates obj->package.count and then calls one of the five hppopulatepackagedata() wrappers (string, integer, enumeration, ordered list, password). Each wrapper forwards a count to its hppopulateelementsfrompackage() 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 ACPITYPESTRING, so reading ->package.count from it in fact reads ->string.length through the union acpiobject. 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 hpinitbiospackageattribute() 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 packagedata() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Operational
After upgrading to the fixed kernel version containing the hp-bioscfg change, verify hp-bioscfg package parsing paths are using the forwarded validated obj->package.count (to prevent the out-of-bounds heap read described).
Event History
Frequently Asked Questions
Is this issue exploitable with the current package validation logic?
The described code path is safe today because it rejects packages with fewer than the required number of elements before a per-type parser runs. As a result, the incorrect parser bound does not currently cause reads beyond a full package.
What condition would make the incorrect count security-relevant?
It becomes relevant if the package validation is changed to accept shorter packages. In that case, a parser may use the ACPI name string length as its bound instead of the actual package element count, potentially allowing it to process beyond the available elements.
What input is involved in triggering the flawed parser bound?
The issue occurs while handling HP BIOS configuration ACPI package attributes for string, integer, enumeration, ordered-list, or password types. The first package element is a name string, and its string length is incorrectly interpreted as a package element count.