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: 6+ 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-06 17:56 ` Ilpo Järvinen
2026-07-07 20:26 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.