PT-2026-90144 · Linux · Linux

CVE-2026-81014

·

Published

2026-09-11

·

Updated

2026-09-11

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: fix heap OOB read in sk store() and kek store()
sk store() and kek store() strip a trailing newline from the sysfs write before allocating the key buffer:
length = count;
if (buf[length - 1] == '
') 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.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-81014

Affected Products

Linux