CVE-2026-81014platform/x86: hp-bioscfg: fix heap OOB read in sk_store() and kek_store()
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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] == '\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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 19, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from b2715aa2e1352c0060b9dcba57a2e465bbfbcd68 before 81db79fed115640736188e56595b1e9aec317d5b; from b2715aa2e1352c0060b9dcba57a2e465bbfbcd68 before 4c6374dcb270d12907b880cf82a5a5ef21785fc3; from b2715aa2e1352c0060b9dcba57a2e465bbfbcd68 before 7cd8fe01aba303a2382db0966eb6c8ab41d5f3c2; from b2715aa2e1352c0060b9dcba57a2e465bbfbcd68 before 67b60703d7d8af1ca0e49f72e1bdb1ccecd41b5b; from b2715aa2e1352c0060b9dcba57a2e465bbfbcd68 before a7508c7959ff8d037327d377ed21a9c0eabe4674 | CNA record |
References
- https://git.kernel.org/stable/c/81db79fed115640736188e56595b1e9aec317d5b
- https://git.kernel.org/stable/c/4c6374dcb270d12907b880cf82a5a5ef21785fc3
- https://git.kernel.org/stable/c/7cd8fe01aba303a2382db0966eb6c8ab41d5f3c2
- https://git.kernel.org/stable/c/67b60703d7d8af1ca0e49f72e1bdb1ccecd41b5b
- https://git.kernel.org/stable/c/a7508c7959ff8d037327d377ed21a9c0eabe4674
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.