CVE-2026-81011
massOut-of-bounds heap read in Linux kernel hp-bioscfg BIOS-attribute parser
The Linux kernel's hp-bioscfg driver, which exposes HP BIOS settings through the firmware-attributes interface on HP laptops and desktops, bounds its per-type ACPI package parsers against the wrong value: instead of the validated obj->package.count, it derives the element count from elements[0] — the attribute's NAME string — effectively using the string's length as the array bound. If a parser receives a package with fewer elements than its type expects, the 'elem = count' sub-loop guards can read past the end of elements[], an out-of-bounds heap read that can leak kernel heap memory (high confidentiality impact) or crash the machine (high availability impact); the attack vector is local and assumes a low-privileged attacker on an HP system where malformed or shortened BIOS attribute packages get parsed. Importantly, the flaw is currently latent: hp_init_bios_package_attribute() rejects any package shorter than the type's expected element count, so the out-of-bounds read is not reachable in today's code, and this fix is the prerequisite for a planned follow-up change that will accept shorter packages. Organizations running Linux on HP hardware should patch before any kernel that relaxes the length check ships without this fix; no public PoC is known and there is no evidence of exploitation in the wild.
What to do: Apply kernel updates that include the hp-bioscfg fix (commit "platform/x86: hp-bioscfg: pass validated element count to package parsers"), especially on HP fleets running Linux 6.1 or later, and verify that any distro kernel carrying the follow-up change to accept shorter packages also carries this fix. Because the vector is local and the bug is unreachable while the strict length check remains in place, no emergency workaround is needed beyond normal local-access hygiene. Since no fixed-version numbers were enumerated, check your distribution's kernel changelog for the patch before treating a system as remediated.
| Linux kernel (hp-bioscfg driver, drivers/platform/x86/hp/hp-bioscfg) | No specific version range given in the advisory; the driver ships in mainline kernels (it first appeared in the 6.1 kernel series) and any build containing the |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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" 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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.