CVE-2026-81011
CVE CVE-2026-81011EUVD EUVD-2026-76334Veröffentlicht 2026-09-11T19:43:01.000ZZuletzt geändert 2026-09-14T11:59:43.000ZCVSS 7.1
Was das Advisory beschreibt
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.
Quelle: EUVD (ENISA), im Wortlaut der Meldung.
Produkte, die das Advisory nennt
Diese Angaben stammen aus der Meldung selbst, nicht aus einer Prüfung durch uns.
- Linux — Linux patch: 6.18.50; patch: 7.3-rc1; a34fc329b1895fc8a6eb12099adc47009421ba6a <e0ddfd77c0c320b7d12b6c9169303b140b798775; patch: 6.6.157; patch: 7.2.4; a34fc329b1895fc8a6eb12099adc47009421ba6a <a38127df99ae8b1851560b35b837c9952416143a; a34fc329b1895fc8a6eb12099adc47009421ba6a <467e53f231f77a1677191b8cdabdaf1448439d55; patch: 6.12.109; patch: 0; a34fc329b1895fc8a6eb12099adc47009421ba6a <400cbc3ccc88a5ad37cd85056224635ce9eba018; 6.6; a34fc329b1895fc8a6eb12099adc47009421ba6a <436017808c7cbcdb5e49b2142090d4391e3de9a6
Die genannten Versionen sind die Angabe der Meldung. Patchlage vergleicht keine Versionsnummern und leitet aus ihnen keine Aussage ab — welche Version installiert ist, muss ein Mensch nachsehen.
Im Produktkatalog geführt
Für diese Produkte kann ein Bestand in Patchlage erfasst werden. Ein Advisory dazu erscheint am Morgen danach im Lagebericht.
- Linux — Linux
Betrifft das einen Ihrer Kundenbestände?
Diese Seite kann die Frage nicht beantworten — sie kennt Ihren Bestand nicht. Wer seine Umgebungen erfasst hat, bekommt die Antwort am Morgen nach der Veröffentlichung, zusammen mit einem Absatz, den er unverändert an den Kunden weitergeben kann.
28 Tage testenPatchlage meldet Treffer und Verdachtsfälle. Zu allem anderen sagt dieses System nichts — weder diese Seite noch der Lagebericht behauptet je, dass ein Bestand sicher ist.