PT-2026-61645 · Linux · Linux
CVE-2026-64192
·
Published
2026-07-20
·
Updated
2026-07-20
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:
bpf: Reject BPF MAP TYPE INODE STORAGE creation if BPF LSM is uninitialized
When CONFIG BPF LSM=y is set, BPF inode storage maps
(BPF MAP TYPE INODE STORAGE) are compiled into the kernel. However,
if the BPF LSM is not explicitly enabled at boot time (e.g. omitted
from the "lsm=" boot parameter), lsm prepare() is never executed for
the BPF LSM.
Consequently, the BPF inode security blob offset
(bpf lsm blob sizes.lbs inode) is never initialized and remains at
its default compiled size of 8 bytes instead of being updated to a
valid offset past the reserved struct rcu head (typically 16 bytes
or more).
When a privileged user creates and updates a BPF MAP TYPE INODE STORAGE
map, bpf inode() evaluates inode->i security + 8. This erroneously
aliases the struct rcu head.func callback pointer at the beginning
of the inode->i security blob. During subsequent map element cleanup
or inode destruction, writing NULL to owner storage clears the queued
RCU callback pointer. When rcu do batch() later executes the queued
callback, it attempts an instruction fetch at address 0x0, triggering
an immediate kernel panic.
Fix this by introducing a global bpf lsm initialized boolean flag
marked with ro after init. Set this flag to true inside bpf lsm init()
when the LSM framework successfully registers the BPF LSM. Gate map
allocation in inode storage map alloc() on this flag, returning
-EOPNOTSUPP if the BPF LSM is in turn uninitialized.
This fail-fast approach prevents userspace from allocating inode
storage maps when the supporting BPF LSM infrastructure is absent,
avoiding zombie map states.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux