# CVE-2026-81011: platform/x86: hp-bioscfg: pass validated element count to package parsers

> A logic error in the HP BIOS configuration driver could lead to out-of-bounds heap reads if package validation is relaxed, potentially exposing kernel memory.

- **Severity:** High 7.1 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 11 Sep 2026
- **Updated:** 19 Oct 2026
- **Also known as:** AZL-100598, BELL-CVE-2026-81011, DEBIAN-CVE-2026-81011, GHSA-9rrq-fppg-695h, UBUNTU-CVE-2026-81011

## What is CVE-2026-81011?

CVE-2026-81011 is a high-severity memory corruption vulnerability in Linux, published on 11 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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.

## Which versions are affected by CVE-2026-81011?


## How do I fix CVE-2026-81011?

Apply the vendor's patch.

## Is CVE-2026-81011 being exploited?

There is no known exploitation of CVE-2026-81011 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-81011 and fix it if it is affected.

What it is: CVE-2026-81011 is a high-severity memory corruption vulnerability in Linux, published on 11 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-81011 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-81011/ (Markdown: https://insights.sbomify.com/CVE-2026-81011/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-81011
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-81011
- OSV: https://osv.dev/vulnerability/CVE-2026-81011

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-81011/
Summaries are generated and may contain mistakes; the official description above is the record.