The hp_bioscfg driver fails to enumerate BIOS attributes on
HP EliteBook 840 G2 (and potentially other older HP models) because:
1. hp_init_bios_package_attribute() hard-fails when a WMI ACPI package
contains fewer elements than the per-type expected count (11 < 13),
even though only the first 10 common elements are required to
register an attribute.
2. hp_populate_enumeration_elements_from_package() returns -EIO and
discards the entire attribute when any single element has an
unexpected ACPI object type - typically after a BIOS AML error
returns malformed data.
Hardware affected:
HP EliteBook 840 G2 (DMI: Hewlett-Packard HP EliteBook 840 G2/2216)
BIOS: M71 Ver. 01.31 (02/24/2020)
How to reproduce:
1. Boot a kernel with CONFIG_HP_BIOSCFG=m on an HP EliteBook 840 G2
2. modprobe hp_bioscfg
3. Observe dmesg:
hp_bioscfg: ACPI-package does not have enough elements: 11 < 13
Error expected type 2 for elem 13, but got type 1 instead
Changes since v1:
Patch 1/3 is new. Relaxing the element-count gate in patch 2/3 (v1's
patch 1/2) lets packages shorter than the per-type ELEM_CNT constant
reach hp_populate_*_elements_from_package(). Those loops don't bound
themselves against the real package size - each one re-derives a
"count" by reading ->package.count off elements[0], which is always
a string (NAME) object, so it's actually reading ->string.length
through the union. That was harmless while the old hard min_elements
gate guaranteed a full ELEM_CNT-sized package on every call, but once
patch 2/3 allows a shorter package through, the fixed ELEM_CNT loop
bound walks past the end of the real elements[] array - a heap
out-of-bounds read, on the exact EliteBook 840 G2 hardware this
series targets.
Patch 1/3 fixes this by threading the real, already-validated
obj->package.count down into every hp_populate_*_package_data()
wrapper instead of letting each one guess at it, and bounds
hp_populate_ordered_list_elements_from_package()'s main loop (which
previously ignored the count entirely) the same way. It's a no-op
for any package that already meets today's ELEM_CNT minimums, and
patch 2/3 is only safe to apply on top of it.
Patches 2/3 and 3/3 are otherwise unchanged from v1.
Thanks to Mario for the v1 Reviewed-by, carried forward on 2/3 and
3/3 since those are unmodified. Armin's point about migrating to the
buffer-based WMI API for correct marshaling is well taken as the
longer-term fix; this series is meant as a minimal, backportable fix
for the immediate enumeration failure and the OOB read it would
otherwise reintroduce, not a replacement for that migration.
Testing notes:
Tested on HP EliteBook 840 G2 running Arch Linux kernel 7.0.13-arch1-1.
After patches, hp_bioscfg loads successfully and enumerates available
BIOS attributes. Attributes with shortened packages are partially
populated and accessible via sysfs. No regressions on systems that
return full ELEM_CNT-element packages (patch 1/3 only changes
behavior once patch 2/3's relaxed gate can hand it a shorter one).
Relevant dmesg (before fix):
[ 11.xxx] hp_bioscfg: ACPI-package does not have enough elements:
11 < 13
[ 11.xxx] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT,
Index (0x000000032) is beyond end of object (length 0x32)
[ 11.xxx] ACPI Error: Aborting method \_SB.WMID.WQBE
[ 11.xxx] Error expected type 2 for elem 13, got type 1
[ 11.xxx] hp_bioscfg: Returned error 0x3
Muhammad Bilal (3):
platform/x86: hp-bioscfg: pass validated element count to package
parsers
platform/x86: hp-bioscfg: accept reduced ACPI packages from older HP
BIOS
platform/x86: hp-bioscfg: warn on element type mismatch instead of
failing
drivers/platform/x86/hp/hp-bioscfg/bioscfg.c | 16 +++++++++++++---
drivers/platform/x86/hp/hp-bioscfg/bioscfg.h | 8 ++++++++
.../platform/x86/hp/hp-bioscfg/enum-attributes.c | 10 ++++++----
.../platform/x86/hp/hp-bioscfg/int-attributes.c | 3 ++-
.../x86/hp/hp-bioscfg/order-list-attributes.c | 7 ++++---
.../x86/hp/hp-bioscfg/passwdobj-attributes.c | 5 +++--
.../x86/hp/hp-bioscfg/string-attributes.c | 3 ++-
7 files changed, 38 insertions(+), 14 deletions(-)
--
2.55.0