CVE-2026-64192

What it actually does

This is a local denial-of-service flaw in the Linux kernel BPF inode storage implementation. Systems built with CONFIG_BPF_LSM=y but booted without the BPF LSM actually initialized can still allow creation of BPF_MAP_TYPE_INODE_STORAGE maps. Because the BPF LSM inode security blob offset is not initialized, inode-storage operations can write through an incorrect pointer into the inode security area and corrupt the queued RCU callback pointer. When the kernel later processes the RCU callback, it may attempt to execute a NULL function pointer, causing an immediate kernel panic.

Why it matters to the business

Successful exploitation can crash affected Linux systems, causing service outages, workload interruption, node reboots, and potential availability loss for applications hosted on those systems. The attacker generally needs local privileged capability to create BPF maps, which reduces broad remote-exploitation risk, but the issue is still important for shared servers, container hosts, CI/build workers, Kubernetes nodes, and environments where privileged containers or delegated BPF capabilities are allowed. EPSS is currently low and there is no known KEV listing or ransomware association, so remediation should be prioritized based on exposure to local privileged users and BPF-enabled workloads rather than internet exposure alone.

How an attack unfolds

An attacker first obtains local access with sufficient privileges to invoke the bpf() syscall for map creation, typically CAP_BPF, CAP_SYS_ADMIN, or equivalent privileges depending on kernel version and configuration. They then target a system where the kernel was compiled with BPF LSM support but the BPF LSM was not enabled during boot, for example because the boot-time lsm= parameter omits bpf. The attacker creates a BPF_MAP_TYPE_INODE_STORAGE map and performs operations that associate or update storage for an inode. Because the BPF LSM initialization path did not run, the kernel uses an invalid inode security blob offset. Subsequent cleanup or inode teardown clears memory that overlaps with an RCU callback function pointer. When the RCU subsystem later processes that queued callback, the kernel attempts to call address 0x0 and panics, forcing a system crash or reboot.

How to fix it

Upgrade to a Linux kernel version that contains the fix rejecting BPF_MAP_TYPE_INODE_STORAGE creation when the BPF LSM is not initialized. If vendor fixed package versions are available, apply the vendor kernel update rather than relying on upstream commit state. As interim mitigation, ensure BPF LSM is either properly enabled when CONFIG_BPF_LSM=y is used, or restrict access to BPF map creation to trusted administrators only. Review and minimize CAP_BPF, CAP_SYS_ADMIN, privileged container access, unprivileged BPF settings, and any workload profiles that allow direct bpf() syscall use. Where operationally acceptable, disable unprivileged BPF and block BPF syscalls for untrusted workloads using seccomp, container runtime policy, or host hardening controls.

How to confirm the fix worked

Confirm the running kernel includes the patch that gates inode_storage_map_alloc() on successful BPF LSM initialization and returns -EOPNOTSUPP when BPF LSM is unavailable. Validate that kernel packages are updated and that the host has rebooted into the fixed kernel. Check whether CONFIG_BPF_LSM is enabled in the running kernel configuration and whether bpf appears in the active LSM list, commonly visible through /sys/kernel/security/lsm when securityfs is mounted. On fixed systems where BPF LSM is not active, attempts by a privileged test process to create BPF_MAP_TYPE_INODE_STORAGE should fail rather than create a map. Also validate that untrusted users and containers do not retain CAP_BPF, CAP_SYS_ADMIN, privileged mode, or broad bpf() syscall access.

Typical attack path

1. Gain local execution on a Linux system with privileges sufficient to create BPF maps.
2. Confirm or assume the kernel is built with CONFIG_BPF_LSM=y while the BPF LSM is not active in the boot-time LSM list.
3. Use the bpf() syscall to create a BPF_MAP_TYPE_INODE_STORAGE map.
4. Update or attach inode storage entries so the kernel exercises the vulnerable bpf_inode() path.
5. Trigger map cleanup, file/inode lifecycle changes, or object destruction that clears the aliased RCU callback pointer.
6. Wait for RCU callback processing, causing a NULL instruction fetch and kernel panic.

How to detect it

To determine whether exploitation may have occurred, review kernel logs, persistent journald records, crash dumps, kdump/vmcore data, audit logs, and EDR telemetry around unexpected reboots or kernel panics. Look for panic traces showing a NULL instruction fetch or NULL pointer dereference during RCU callback processing, especially with call traces containing rcu_do_batch, bpf_inode, inode storage, BPF map cleanup, or bpf syscall activity shortly beforehand. If auditd records BPF syscalls, search for bpf() map creation events by privileged users or containers preceding a crash. On container hosts, correlate privileged container starts, CAP_BPF/CAP_SYS_ADMIN grants, eBPF tooling execution, or unusual custom BPF loader activity with the time of the panic. Absence of logs is possible because exploitation causes a kernel crash; crash dump collection and persistent logging materially improve forensic confidence.

• BPF_MAP_TYPE_INODE_STORAGE
• bpf_inode
• inode_storage_map_alloc
• rcu_do_batch
• RIP: 0010:0x0
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• syscall=bpf
• comm="bpftool"
• CAP_BPF
• CAP_SYS_ADMIN
• /sys/kernel/security/lsm
• lsm=
• CONFIG_BPF_LSM=y

What your security team should do

• Prioritize patching Linux hosts that allow privileged containers, local administrator access, CI workloads, eBPF observability agents, or other users capable of invoking the bpf() syscall.
• Inventory kernels compiled with CONFIG_BPF_LSM=y and compare them against the active LSM list to identify systems where BPF LSM support is compiled in but not initialized at boot.
• Apply vendor kernel updates and reboot into the corrected kernel; live patching should only be considered sufficient if the vendor explicitly covers this flaw.
• Restrict CAP_BPF, CAP_SYS_ADMIN, privileged container mode, and direct bpf() syscall access to trusted workloads only.
• Disable unprivileged BPF where possible and use seccomp or container runtime policy to block bpf() for untrusted workloads.
• Monitor kernel logs and crash dumps for NULL instruction fetches involving RCU callback execution, bpf_inode(), or BPF inode storage activity.
• Because public exploit maturity is currently reported as none and EPSS is low, align urgency with local privilege exposure rather than internet-facing asset priority alone.