{"id":"CVE-2026-64192","summary":"bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized\n\nWhen CONFIG_BPF_LSM=y is set, BPF inode storage maps\n(BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However,\nif the BPF LSM is not explicitly enabled at boot time (e.g. omitted\nfrom the \"lsm=\" boot parameter), lsm_prepare() is never executed for\nthe BPF LSM.\n\nConsequently, the BPF inode security blob offset\n(bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at\nits default compiled size of 8 bytes instead of being updated to a\nvalid offset past the reserved struct rcu_head (typically 16 bytes\nor more).\n\nWhen a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE\nmap, bpf_inode() evaluates inode-\u003ei_security + 8. This erroneously\naliases the struct rcu_head.func callback pointer at the beginning\nof the inode-\u003ei_security blob. During subsequent map element cleanup\nor inode destruction, writing NULL to owner_storage clears the queued\nRCU callback pointer. When rcu_do_batch() later executes the queued\ncallback, it attempts an instruction fetch at address 0x0, triggering\nan immediate kernel panic.\n\nFix this by introducing a global bpf_lsm_initialized boolean flag\nmarked with __ro_after_init. Set this flag to true inside bpf_lsm_init()\nwhen the LSM framework successfully registers the BPF LSM. Gate map\nallocation in inode_storage_map_alloc() on this flag, returning\n-EOPNOTSUPP if the BPF LSM is in turn uninitialized.\n\nThis fail-fast approach prevents userspace from allocating inode\nstorage maps when the supporting BPF LSM infrastructure is absent,\navoiding zombie map states.","modified":"2026-07-25T04:14:49.417340996Z","published":"2026-07-20T16:27:51.720Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64192.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/267fdd9b6530c399dfd996e1a0a7628b45baf9f0"},{"type":"WEB","url":"https://git.kernel.org/stable/c/a6f0643e4f63cfaa0d5d4a69de4f132eac4b8fe4"},{"type":"WEB","url":"https://git.kernel.org/stable/c/c76b8abce575e0c6e4096957220b4515ed847d89"},{"type":"WEB","url":"https://git.kernel.org/stable/c/de984ea883405420fdc416ae8964b752df586970"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64192.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64192"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"8ea636848aca35b9f97c5b5dee30225cf2dd0fe6"},{"fixed":"de984ea883405420fdc416ae8964b752df586970"},{"fixed":"267fdd9b6530c399dfd996e1a0a7628b45baf9f0"},{"fixed":"c76b8abce575e0c6e4096957220b4515ed847d89"},{"fixed":"a6f0643e4f63cfaa0d5d4a69de4f132eac4b8fe4"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64192.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.10.0"},{"fixed":"6.12.97"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.40"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.1.4"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64192.json"}}],"schema_version":"1.7.5"}