CVE-2026-64192

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

include/linux/bpf_lsm.h
kernel/bpf/bpf_inode_storage.c
security/bpf/hooks.c

What this is

BPF [SECURITY & LSM] (Security Audit and Enforcement using BPF)MAINTAINERS section matched on include/linux/bpf_lsm.h · bpf@vger.kernel.org · Maintained

Check it on the machine

grep -w CONFIG_BPF_LSM /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

• bookwormy
• trixie, forky, sidYnot built on s390x/s390x
• bookworm · linux-6.12y

y

built into the kernel image on every flavour - only a patch removes it

Y

built in where it is built at all; some flavours do not build it

Build switch

CONFIG_BPF_LSM

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-07-20 (3 months ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.12%, higher than 1.6% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

include/linux

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
5.10	5.10.266	413b14b9623a
5.10	5.15.217	a6d634f794c8
5.10	6.1.184	721f669853bd
5.10	6.6.148	5337eebdf8c5
5.10	6.12.97	de984ea88340
5.10	6.18.40	267fdd9b6530
5.10	7.1.4	c76b8abce575
5.10	7.2	a6f0643e4f63

Debian advisories