wireguard-linux/drivers/platform/x86/hp, branch stable

Merge tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

2026-09-11T19:52:48Z

Pull x86 platform driver fixes from Ilpo Järvinen: - amd/pmf: Fix build on !CONFIG_AMD_PMF_DEBUG - asus-laptop: Fix ACPI event handling - hp-wmi: Fix board_params typo for 8DD6 board - x86-android-tablets: Fix Arizona and Crystal Cove GPIO lookups * tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: MAINTAINERS: fix sysfs-platform-ayaneo-ec documentation path platform/x86: x86-android-tablets: fix gpio_secondary_fwnode_init() not working platform/x86: x86-android-tablets: use shared battery swnode group on Yoga Tab 2 platform/x86: x86-android-tablets: drop redundant swnode group on YT3 platform/x86: x86-android-tablets: add Crystal Cove GPIO swnode support platform/x86: x86-android-tablets: pass node group to gpio_secondary_fwnode_init() platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown platform/x86: x86-android-tablets: fix Arizona GPIO swnode references platform/x86/amd/pmf: fix build on !CONFIG_AMD_PMF_DEBUG platform/x86: asus-laptop: Fix ACPI event handling platform/x86: hp-wmi: Fix board_params typo for 8DD6 board

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00Z

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

platform/x86: hp-wmi: Fix board_params typo for 8DD6 board

2026-08-31T18:18:28Z

When adding support for board 8DD6, &omen_v1_no_ec_thermal_params was passed as driver_data instead of &omen_v1_no_ec_board_params. Because active_board_params expects a pointer to struct hp_wmi_board_params, dereferencing active_board_params->thermal_profile results in a type confusion bug and invalid memory access. Update the entry to point to omen_v1_no_ec_board_params. Fixes: a7320d6eb9c42 ("platform/x86: hp-wmi: Add support for OMEN MAX 16-ak0xxx (8DD6)") Cc: stable@vger.kernel.org Signed-off-by: Arda Doğu Ari Reviewed-by: Krishna Chomal Link: https://patch.msgid.link/20260827235139.154462-1-arfeliousheres@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86: hp-bioscfg: advance elem past consumed array elements

2026-08-18T14:30:09Z

The outer parsing loop in each attribute-type parser advances "elem" (the index into the ACPI package element array) by exactly one per iteration, but cases that consume multi-element arrays (PREREQUISITES, ENUM_POSSIBLE_VALUES, PSWD_ENCODINGS) read "size" consecutive elements without adjusting "elem" for the extra entries 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 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" Fix by advancing "elem" by (size - 1) after each array-consuming loop, so the outer loop's own "elem++" lands on the correct next element. "eloc" is intentionally left alone: it indexes the logical property schema, not the physical element array, and each array case is still exactly one logical property regardless of how many physical elements it spans. The defect is identical across all five attribute-type parsers (enum, integer, string, ordered-list, password), which were copy-pasted from the same template when the driver was introduced. Fixes: 6b2770bfd6f9 ("platform/x86: hp-bioscfg: enum-attributes") Fixes: 6f2c06d5a467 ("platform/x86: hp-bioscfg: int-attributes") Fixes: e6c7b3e15559 ("platform/x86: hp-bioscfg: string-attributes") Fixes: 4b2672ec71a3 ("platform/x86: hp-bioscfg: order-list-attributes") Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-10-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86: hp-bioscfg: fix ORD_LIST_ELEMENTS never being parsed

2026-08-18T14:30:07Z

The ACPI_TYPE_STRING case explicitly skips the string conversion for elem == ORD_LIST_ELEMENTS: if (elem != PREREQUISITES && elem != ORD_LIST_ELEMENTS) { ret = hp_convert_hexstr_to_str(..., &str_value, &value_len); if (ret) continue; } so by the time the ORD_LIST_ELEMENTS case in the eloc switch runs, str_value is NULL (it was freed and reset to NULL at the end of the previous iteration). That case then does: ret = hp_convert_hexstr_to_str(str_value, value_len, &tmpstr, &tmp_len); hp_convert_hexstr_to_str() rejects a NULL input with -EINVAL, which sends this function to exit_list, and exit_list unconditionally returns 0. The net effect is that any ordered-list attribute with elements present silently ends up with an empty elements list, with no error surfaced anywhere. Fix by converting the current element directly, order_obj[elem], the same way the PREREQUISITES case already handles its own array elements, instead of reusing the unrelated str_value/value_len left over from earlier processing. Fixes: 4b2672ec71a3 ("platform/x86: hp-bioscfg: order-list-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-9-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86: hp-bioscfg: fix new_password_store() overwriting current_password

2026-08-18T14:30:06Z

current_password_store() and new_password_store() both call store_password_instance() with is_current = true: static ssize_t new_password_store(...) { return store_password_instance(kobj, buf, count, true); } so a write to new_password is routed to current_password instead, and the new_password field is never written by either sysfs entry point. Fix by passing false from new_password_store(), matching what the is_current parameter is meant to select. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-8-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86: hp-bioscfg: fix password encoding bounds check

2026-08-18T14:29:44Z

The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values] while copying the supported password encodings from the ACPI package. The outer loop only guarantees that elem is within password_obj_count. The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not guarantee that the ACPI package contains enough entries for all elem + pos_values accesses. A malformed package can therefore declare a non-zero encoding count without providing enough string objects, causing the parser to read past the ACPI package array and pass an out-of-bounds string pointer and length to hp_convert_hexstr_to_str(). Add the same computed-index bounds check used by the other offset-based package parsing loops before reading password_obj[elem + pos_values]. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260708090937.740435-1-lgs201920130244@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86: hp-bioscfg: fix heap OOB read on empty password write

2026-08-18T12:11:06Z

validate_password_input() computes length = strlen(buf) and then checks buf[length - 1] to strip a trailing newline, without checking that length is nonzero first. Writing an empty string (a bare '\n') to current_password or new_password gives length == 0, and buf[length - 1] reads buf[-1], one byte before the heap allocation holding the copied input. KASAN confirms this directly: BUG: KASAN: slab-out-of-bounds in store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] Read of size 1 at addr ffff88811bd8da9f by task sh/13740 ... store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] current_password_store+0x14/0x20 [hp_bioscfg] ... The buggy address is located 23 bytes to the right of allocated 8-byte region [ffff88811bd8da80, ffff88811bd8da88) Reproduced identically via new_password_store. Execution continues past the bad read (the garbage byte only affects whether "length" is decremented by one), so the write completes and returns success; this is a pure information read past the buffer, not a crash, but it is still an out-of-bounds access KASAN correctly flags. Fix by only checking buf[length - 1] when length is nonzero. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-4-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86: hp-bioscfg: fix heap OOB read in sk_store() and kek_store()

2026-08-18T12:11:05Z

sk_store() and kek_store() strip a trailing newline from the sysfs write before allocating the key buffer: length = count; if (buf[length - 1] == '\n') length--; bioscfg_drv.spm_data.signing_key = kmemdup(buf, length, GFP_KERNEL); but then pass the original "count" (not "length") as the copy size to hp_wmi_perform_query(), which memcpy()s that many bytes out of the "length"-sized allocation, reading one byte past it whenever the write ends in a newline, the normal case for a shell "echo" into sysfs. KASAN confirms this directly: BUG: KASAN: slab-out-of-bounds in hp_wmi_perform_query+0x1e9/0x460 [hp_bioscfg] Read of size 28 at addr ffff88813c8e2b80 by task python3/16022 ... sk_store+0xa7/0x240 [hp_bioscfg] kernfs_fop_write_iter+0x3e1/0x5d0 ... The buggy address is located 0 bytes inside of allocated 27-byte region [ffff88813c8e2b80, ffff88813c8e2b9b) Reproduced identically for kek_store, and at multiple write sizes (28, 57, 201 bytes), each time reading exactly one byte past a kmemdup() allocation one byte smaller than the write. Fix by passing "length" instead of "count" to hp_wmi_perform_query() in both functions. Fixes: b2715aa2e135 ("platform/x86: hp-bioscfg: spmobj-attributes") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-3-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86: hp-bioscfg: fix off-by-one write in hp_get_string_from_buffer()

2026-08-18T12:11:02Z

hp_get_string_from_buffer() clamps the converted string length against the destination buffer size with "size > dst_size", so when the converted length is exactly equal to dst_size, conv_dst_size is left at dst_size and the unconditional NUL terminator write dst[conv_dst_size] = 0; lands one byte past the destination buffer. This is the same shape of bug as the previously fixed off-by-one in hp_convert_hexstr_to_str(): the buffer is sized correctly for the content, but the terminator write is never checked against that size. Fix by changing the comparison to ">=" so conv_dst_size is always left with room for the terminator. All fixed-size destinations that reach this function (path[512], current_value[512], current_password/current_value[64], and the per-entry buffers in encodings[][512] and prerequisites[][512]) are affected. Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260812111829.172273-2-meatuni001@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen