CVE-2026-64192: Linux Kernel Privilege Escalation Flaw

CVE-2026-64192 Overview

CVE-2026-64192 is a Linux kernel vulnerability in the Berkeley Packet Filter (BPF) subsystem. The flaw affects BPF_MAP_TYPE_INODE_STORAGE map creation when the kernel is built with CONFIG_BPF_LSM=y but the BPF Linux Security Module (LSM) is not enabled at boot via the lsm= boot parameter. Under this configuration, the BPF inode security blob offset never initializes, causing subsequent map operations to corrupt an rcu_head.func callback pointer. When rcu_do_batch() later invokes the cleared callback, the kernel attempts an instruction fetch at address 0x0 and panics.

Critical Impact
A privileged local user can trigger an immediate kernel panic by creating and updating a BPF inode storage map on affected systems, resulting in denial of service.

Affected Products

Linux kernel builds with CONFIG_BPF_LSM=y where BPF LSM is not enabled at boot
Upstream Linux kernel branches prior to commits a6f0643e4f63 and c76b8abce575
Distributions shipping BPF LSM support without mandatory activation

Discovery Timeline

2026-07-20 - CVE-2026-64192 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64192

Vulnerability Analysis

The vulnerability resides in the BPF inode storage map allocation path within the Linux kernel. When CONFIG_BPF_LSM=y is compiled in, BPF_MAP_TYPE_INODE_STORAGE support is embedded into the kernel image. If an operator omits bpf from the lsm= boot parameter, the LSM framework never calls lsm_prepare() for the BPF LSM. Consequently, bpf_lsm_blob_sizes.lbs_inode retains its compile-time default of 8 bytes rather than being adjusted to sit past the reserved struct rcu_head region.

A privileged user who creates and updates one of these maps causes bpf_inode() to compute inode->i_security + 8. This offset aliases the rcu_head.func callback pointer at the head of the inode security blob. During map element cleanup or inode destruction, the kernel writes NULL to owner_storage, overwriting the queued RCU callback. When rcu_do_batch() dequeues the callback and attempts to invoke it, the CPU performs an instruction fetch at 0x0, producing an immediate kernel panic.

Root Cause

The root cause is missing initialization of bpf_lsm_blob_sizes.lbs_inode when the BPF LSM is compiled in but not registered. Map allocation code did not validate that the supporting LSM infrastructure had completed initialization before permitting BPF_MAP_TYPE_INODE_STORAGE allocations. This produced a class of kernel null pointer dereference [CWE-476] rooted in a state validation gap.

Attack Vector

Exploitation requires local access with privileges sufficient to invoke bpf() system calls for map creation, typically CAP_BPF or CAP_SYS_ADMIN. The attacker creates a BPF_MAP_TYPE_INODE_STORAGE map, associates an element with an inode, and triggers cleanup. No remote vector exists. The impact is limited to denial of service through kernel panic on vulnerable configurations. See the upstream fix commit a6f0643e and the stable backport commit c76b8abc for technical details.

Detection Methods for CVE-2026-64192

Indicators of Compromise

Unexpected kernel panics with faulting instruction pointer at address 0x0 following RCU callback processing
Kernel log entries referencing rcu_do_batch immediately preceding the panic
Recent bpf() syscall activity creating BPF_MAP_TYPE_INODE_STORAGE maps on kernels without bpf in the lsm= boot parameter

Detection Strategies

Audit kernel boot parameters and compare against CONFIG_BPF_LSM build configuration to identify vulnerable hosts
Enable auditd rules on the bpf syscall to log map creation requests with BPF_MAP_TYPE_INODE_STORAGE
Correlate crash dumps showing null instruction pointer faults with prior BPF map allocation events

Monitoring Recommendations

Forward kernel crash telemetry and dmesg output to a centralized logging platform for panic pattern analysis
Monitor process behavior for unprivileged escalation to CAP_BPF followed by BPF map operations
Track /sys/kernel/security/lsm contents across the fleet to inventory active LSM modules

How to Mitigate CVE-2026-64192

Immediate Actions Required

Apply the upstream patches referenced in commits a6f0643e4f63 and c76b8abce575 or the stable kernel updates that include them
Restrict CAP_BPF and CAP_SYS_ADMIN to trusted service accounts only
Inventory kernel builds to identify hosts running CONFIG_BPF_LSM=y without bpf in the active lsm= list

Patch Information

The fix introduces a global bpf_lsm_initialized boolean flag marked __ro_after_init. The flag is set to true inside bpf_lsm_init() only when the LSM framework successfully registers the BPF LSM. inode_storage_map_alloc() now checks this flag and returns -EOPNOTSUPP when the BPF LSM is uninitialized, preventing zombie map states. Distribution kernel maintainers have backported the fix into stable branches.

Workarounds

Add bpf to the lsm= kernel command line to ensure lsm_prepare() initializes the BPF LSM blob sizes correctly
Rebuild kernels without CONFIG_BPF_LSM if BPF LSM functionality is not required
Use sysctl kernel.unprivileged_bpf_disabled=1 to prevent unprivileged BPF operations as a defense-in-depth measure

bash

# Configuration example: enable BPF LSM at boot via GRUB
# Edit /etc/default/grub and append bpf to the lsm= parameter
GRUB_CMDLINE_LINUX="lsm=lockdown,yama,integrity,apparmor,bpf"

# Apply and reboot
sudo update-grub
sudo reboot

# Verify BPF LSM is active after reboot
cat /sys/kernel/security/lsm