CVE-2026-64192 in Linux
Summary
by MITRE • 07/20/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/20/2026
The vulnerability described represents a critical kernel security flaw in the Linux kernel's BPF (Berkeley Packet Filter) subsystem that arises from improper initialization of the BPF Linux Security Module (LSM). This issue occurs specifically when the kernel is compiled with CONFIG_BPF_LSM=y but the BPF LSM is not explicitly enabled during boot through the lsm= boot parameter. The fundamental problem stems from a race condition between kernel subsystem initialization and security module setup, creating a scenario where critical data structures remain in an uninitialized state while still being referenced by active code paths.
The technical flaw manifests in the improper handling of memory offsets within the inode security blob structure. When BPF LSM is not initialized, the bpf_lsm_blob_sizes.lbs_inode offset remains at its default compiled value of 8 bytes instead of being properly set to a valid position that accounts for the reserved struct rcu_head structure which typically requires 16 bytes or more. This offset misalignment causes a memory aliasing issue where the inode->i_security pointer plus 8 bytes incorrectly points to the beginning of the struct rcu_head.func callback pointer field. This represents a classic case of improper memory management that can be categorized under CWE-783, which deals with operation on a resource after it has been released or invalidated.
The operational impact of this vulnerability is severe as it creates a kernel panic condition when privileged users attempt to create and manipulate BPF_MAP_TYPE_INODE_STORAGE maps. During normal operation, the bpf_inode() function evaluates inode->i_security + 8, which in the uninitialized state points directly to the callback pointer field. When map cleanup occurs and owner_storage is cleared, the previously queued RCU callback pointer gets overwritten with NULL, leading to an immediate kernel panic when rcu_do_batch() attempts instruction fetches from address 0x0. This represents a direct denial of service vulnerability that can be exploited by any user with privileges to create BPF maps, potentially causing system crashes that are difficult to recover from without manual intervention.
The fix implemented addresses this issue through a fail-fast design approach that introduces a global boolean flag bpf_lsm_initialized marked with __ro_after_init to ensure proper runtime state checking. This solution follows established security practices by preventing the creation of potentially problematic kernel data structures when underlying infrastructure is not properly initialized, which aligns with the principle of least privilege and defensive programming. The mitigation strategy requires that map allocation in inode_storage_map_alloc() be gated on this initialization flag, returning -EOPNOTSUPP to userspace when BPF LSM is uninitialized instead of allowing potentially malformed maps to be created. This approach prevents the creation of "zombie" map states that could persist and cause subtle issues later, providing a more robust security boundary that aligns with ATT&CK technique T1068 which involves privilege escalation through improper system configuration.
From a compliance perspective, this vulnerability addresses core requirements in security frameworks such as those outlined in NIST SP 800-53 where proper initialization of security modules is critical for maintaining system integrity. The fix ensures that the kernel maintains consistent state across all subsystems and prevents scenarios where one subsystem can be used to compromise another through improper resource management. The solution also demonstrates adherence to the principle of least privilege by ensuring that BPF map creation operations are only permitted when all required security infrastructure is properly available, preventing potential escalation paths that could allow unauthorized access to kernel memory structures through carefully crafted BPF programs.