From: Muhammad Bilal <meatuni001@gmail.com>
To: hdegoede@redhat.com, ilpo.jarvinen@linux.intel.com,
jorge.lopez2@hp.com, Thomas.Weissschuh@linutronix.de,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org, Mario Limonciello <superm1@kernel.org>,
Armin Wolf <W_Armin@gmx.de>,
Muhammad Bilal <meatuni001@gmail.com>
Subject: [PATCH v2 0/3] hp-bioscfg: fix attribute enumeration on older HP BIOS
Date: Sat, 4 Jul 2026 21:07:56 +0500 [thread overview]
Message-ID: <20260704160759.236249-1-meatuni001@gmail.com> (raw)
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
next reply other threads:[~2026-07-04 16:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-04 16:07 Muhammad Bilal [this message]
2026-07-04 16:07 ` [PATCH v2 1/3] platform/x86: hp-bioscfg: pass validated element count to package parsers Muhammad Bilal
2026-07-04 16:07 ` [PATCH v2 2/3] platform/x86: hp-bioscfg: accept reduced ACPI packages from older HP BIOS Muhammad Bilal
2026-07-04 16:07 ` [PATCH v2 3/3] platform/x86: hp-bioscfg: warn on element type mismatch instead of failing Muhammad Bilal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260704160759.236249-1-meatuni001@gmail.com \
--to=meatuni001@gmail.com \
--cc=Thomas.Weissschuh@linutronix.de \
--cc=W_Armin@gmx.de \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jorge.lopez2@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=superm1@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox