CVE-2026-81011 Affecting linux-6.12 package, versions <6.12.111-1~deb12u1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-DEBIAN12-LINUX612-20506547
- published5 Oct 2026
- disclosed11 Sept 2026
Introduced: 11 Sep 2026
NewCVE-2026-81011 (opens in a new tab)How to fix?
Upgrade Debian:12 linux-6.12 to version 6.12.111-1~deb12u1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream linux-6.12 package and not the linux-6.12 package as distributed by Debian.
See How to fix? for Debian:12 relevant fixed versions and status.
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.
References
- https://security-tracker.debian.org/tracker/CVE-2026-81011
- https://git.kernel.org/stable/c/400cbc3ccc88a5ad37cd85056224635ce9eba018
- https://git.kernel.org/stable/c/436017808c7cbcdb5e49b2142090d4391e3de9a6
- https://git.kernel.org/stable/c/a38127df99ae8b1851560b35b837c9952416143a
- https://git.kernel.org/stable/c/e0ddfd77c0c320b7d12b6c9169303b140b798775
- https://git.kernel.org/stable/c/467e53f231f77a1677191b8cdabdaf1448439d55