[PATCH 09/13] platform/x86: hp-bioscfg: advance elem past consumed array elements in enum-attributes
Muhammad Bilal <[email protected]> Mon, 3 Aug 2026 19:30:32 +0500
| Newsgroups | org.kernel.vger.platform-driver-x86,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
The outer parsing loop advances "elem" (the index into the ACPI
package's element array) by exactly one per iteration:
for (elem = 1, eloc = 1; elem < enum_obj_count; elem++, eloc++) {
but the PREREQUISITES and ENUM_POSSIBLE_VALUES cases each consume
"size" consecutive elements (elem, elem + 1, ..., elem + size - 1) to
populate an array, without adjusting "elem" to account for the extra
elements consumed beyond the first. The next outer iteration then
re-reads a leftover element from the array just consumed instead of
the next real property, and the type check against
expected_enum_types[eloc] fails on that stale element, aborting the
parse with -EIO.
This produces exactly the failure visible in dmesg on the test
hardware, on every boot:
Error expected type 2 for elem 13, but got type 1 instead
hp_bioscfg: Returned error 0x3, "Invalid command value/Feature not
supported"
Note: this exact message string is shared by more than one file in
this driver (see the companion patches to int-attributes.c,
string-attributes.c, order-list-attributes.c, and
passwdobj-attributes.c in this series, which fix the identical
pattern), so this dmesg line cannot be attributed to this file alone
without further instrumentation; it is included here as evidence that
this class of bug is live and reachable on real hardware, not as
proof this specific instance is the one firing.
Fix by advancing "elem" by (size - 1) after each of the two loops, so
the outer loop's own "elem++" lands on the correct next element.
"eloc" is intentionally left alone, it indexes the logical property
schema (expected_enum_types[]), not the physical element array, and
each of PREREQUISITES/ENUM_POSSIBLE_VALUES is still exactly one
logical property regardless of how many physical elements it spans.
Fixes: 6b2770bfd6f9 ("platform/x86: hp-bioscfg: enum-attributes")
Cc: [email protected]
Signed-off-by: Muhammad Bilal <[email protected]>
---
drivers/platform/x86/hp/hp-bioscfg/enum-attributes.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/platform/x86/hp/hp-bioscfg/enum-attributes.c b/drivers/platform/x86/hp/hp-bioscfg/enum-attributes.c
index af4d1920d488..43beb639051e 100644
--- a/drivers/platform/x86/hp/hp-bioscfg/enum-attributes.c
+++ b/drivers/platform/x86/hp/hp-bioscfg/enum-attributes.c
@@ -227,6 +227,8 @@ static int hp_populate_enumeration_elements_from_package(union acpi_object *enum
kfree(str_value);
str_value = NULL;
}
+ if (size)
+ elem += size - 1;
break;
case SECURITY_LEVEL:
@@ -280,6 +282,8 @@ static int hp_populate_enumeration_elements_from_package(union acpi_object *enum
kfree(str_value);
str_value = NULL;
}
+ if (size)
+ elem += (size < MAX_VALUES_SIZE ? size : MAX_VALUES_SIZE) - 1;
break;
default:
pr_warn("Invalid element: %d found in Enumeration attribute or data may be malformed\n", elem);
--
2.55.0