CVE-2026-64192
CVE CVE-2026-64192EUVD EUVD-2026-46012Published 2026-07-20T16:27:51.000ZLast changed 2026-08-03T09:32:37.000Z
What the advisory describes
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.
Source: EUVD (ENISA), in the words of the advisory.
Products the advisory names
These come from the advisory itself, not from any check we performed.
- Linux — Linux patch: 6.18.40; patch: 7.2-rc2; 8ea636848aca35b9f97c5b5dee30225cf2dd0fe6 <5337eebdf8c5d4810b1913047f078d2815d5645f; 8ea636848aca35b9f97c5b5dee30225cf2dd0fe6 <267fdd9b6530c399dfd996e1a0a7628b45baf9f0; patch: 0; patch: 6.12.97; 8ea636848aca35b9f97c5b5dee30225cf2dd0fe6 <de984ea883405420fdc416ae8964b752df586970; 8ea636848aca35b9f97c5b5dee30225cf2dd0fe6 <c76b8abce575e0c6e4096957220b4515ed847d89; patch: 7.1.4; 5.10; patch: 6.6.148; 8ea636848aca35b9f97c5b5dee30225cf2dd0fe6 <a6f0643e4f63cfaa0d5d4a69de4f132eac4b8fe4
The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.
Carried in the product catalogue
An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.
- Linux — Linux
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.