CVE-2026-64192: 
Linux Kernel Analisi e mitigazione delle vulnerabilità

CVE-2026-64192 is a Linux kernel vulnerability in the BPF subsystem that can cause a kernel panic (denial of service) when CONFIG_BPF_LSM=y is compiled into the kernel but BPF LSM is not explicitly enabled at boot time. When this condition exists, the BPF inode security blob offset (bpf_lsm_blob_sizes.lbs_inode) remains uninitialized at 8 bytes, causing bpf_inode() to alias the struct rcu_head.func callback pointer. A privileged local user creating and updating a BPF_MAP_TYPE_INODE_STORAGE map can trigger a NULL pointer dereference during RCU batch processing, resulting in an immediate kernel panic. The vulnerability was published on July 20, 2026, and affects Linux kernel versions starting from 5.10 up to the patched commits (GitHub Advisory). The CVSS severity is estimated as Medium (GitHub Advisory).

The root cause is an uninitialized security blob offset in the BPF LSM subsystem (related to CWE-665: Improper Initialization). When CONFIG_BPF_LSM=y is set but BPF LSM is omitted from the lsm= boot parameter, lsm_prepare() is never called, leaving bpf_lsm_blob_sizes.lbs_inode at its default compiled value of 8 bytes rather than a valid offset (typically ≥16 bytes past the reserved struct rcu_head). When a privileged user creates a BPF_MAP_TYPE_INODE_STORAGE map and updates it, bpf_inode() computes inode->i_security + 8, which erroneously aliases the rcu_head.func callback pointer. Subsequent map element cleanup or inode destruction writes NULL to owner_storage, clearing the queued RCU callback; when rcu_do_batch() later attempts to execute the callback, it fetches from address 0x0, triggering a kernel panic. The fix introduces a bpf_lsm_initialized boolean flag (__ro_after_init) set in bpf_lsm_init(), gating inode_storage_map_alloc() to return -EOPNOTSUPP if BPF LSM is uninitialized (GitHub Advisory).

Successful exploitation causes an immediate kernel panic, resulting in a complete denial of service for the affected system. The attack requires local privileged access (e.g., CAP_BPF or equivalent), limiting the blast radius to systems where such users exist; however, on multi-tenant or container environments where BPF privileges are delegated, the impact could affect all workloads on the host. There is no evidence of confidentiality or integrity impact — the vulnerability is strictly a denial-of-service condition (GitHub Advisory).

1. Precondition Check: Confirm the target system has a Linux kernel compiled with CONFIG_BPF_LSM=y but without BPF LSM listed in the lsm= boot parameter (e.g., check /boot/config-$(uname -r) and /proc/cmdline).
2. Privilege Acquisition: Obtain a local session with sufficient privileges to create BPF maps (e.g., CAP_BPF and CAP_SYS_ADMIN, or root access).
3. Create Inode Storage Map: Use the bpf() syscall with BPF_MAP_CREATE and map type BPF_MAP_TYPE_INODE_STORAGE to allocate a new inode storage map.
4. Update Map Element: Write an entry to the map targeting an inode, causing bpf_inode() to compute inode->i_security + 8, which aliases the struct rcu_head.func pointer.
5. Trigger Cleanup: Allow map element cleanup or inode destruction to occur (e.g., by closing the associated file descriptor or deleting the inode), which writes NULL to owner_storage, clearing the queued RCU callback pointer.
6. Kernel Panic: Wait for rcu_do_batch() to process the RCU queue; it attempts an instruction fetch at address 0x0, triggering an immediate kernel panic and system crash (GitHub Advisory).

• Logs: Kernel oops or panic messages in /var/log/kern.log or dmesg referencing a NULL pointer dereference at address 0x0 during rcu_do_batch() execution.
• Logs: Audit logs (/var/log/audit/audit.log) showing bpf() syscall invocations with BPF_MAP_CREATE and map type BPF_MAP_TYPE_INODE_STORAGE from unexpected processes or users.
• Process: Unexpected privileged processes invoking the bpf() syscall on systems where BPF usage is not routine.
• System: Sudden, unexplained system reboots or kernel panics on hosts with CONFIG_BPF_LSM=y kernels where BPF LSM is not in the lsm= boot parameter.

Apply the upstream kernel patches fixing this issue: commits c76b8abce575e0c6e4096957220b4515ed847d89 and a6f0643e4f63cfaa0d5d4a69de4f132eac4b8fe4 (GitHub Advisory). As an immediate workaround, explicitly enable BPF LSM at boot by adding bpf to the lsm= kernel boot parameter (e.g., lsm=lockdown,yama,bpf) if CONFIG_BPF_LSM=y is set. Additionally, restrict BPF map creation privileges to trusted users only by limiting CAP_BPF and CAP_SYS_ADMIN capabilities.