bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized
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 uninit
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.266, 5.15.217, 6.1.184, 6.12.97, 6.18.40, 6.6.148, 7.1.4
- CVEs
- CVE-2026-64192
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 7 Nov 2026, 14:21 UTC · Revision 1
Source evidence
bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized
core-osv · Original sourcePublished 20 Jul 2026, 16:27 UTC
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 uninit
osv:CVE-2026-64192
Kernel
Fixed versions: 5.10.266, 5.15.217, 6.1.184, 6.6.148, 6.12.97, 6.18.40, 7.1.4
Complete source record
{
"id": "4730c08e906adffb0a96d34104037b7cf4d027e6fb66fc89952921d2e61d7395",
"url": "https://osv.dev/vulnerability/CVE-2026-64192",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized",
"summary": "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 uninit",
"evidence": "osv:CVE-2026-64192",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.10.266",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.217",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.184",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.148",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.97",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.40",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-64192",
"aliases": [
"CVE-2026-64192"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "8ea636848aca35b9f97c5b5dee30225cf2dd0fe6"
},
{
"fixed": "413b14b9623a2e6ee131c2b2152b304aeb04e378"
},
{
"fixed": "a6d634f794c808a261eac7d5af023a7e06b9ecd8"
},
{
"fixed": "721f669853bdbf46b475a81bb5d05d610f8c19de"
},
{
"fixed": "5337eebdf8c5d4810b1913047f078d2815d5645f"
},
{
"fixed": "de984ea883405420fdc416ae8964b752df586970"
},
{
"fixed": "267fdd9b6530c399dfd996e1a0a7628b45baf9f0"
},
{
"fixed": "c76b8abce575e0c6e4096957220b4515ed847d89"
},
{
"fixed": "a6f0643e4f63cfaa0d5d4a69de4f132eac4b8fe4"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64192.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.10.0"
},
{
"fixed": "5.10.266"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.217"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.184"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.148"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.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"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64192.json"
}
}
],
"modified": "2026-10-28T02:30:51.027553844Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/267fdd9b6530c399dfd996e1a0a7628b45baf9f0",
"https://git.kernel.org/stable/c/413b14b9623a2e6ee131c2b2152b304aeb04e378",
"https://git.kernel.org/stable/c/5337eebdf8c5d4810b1913047f078d2815d5645f",
"https://git.kernel.org/stable/c/721f669853bdbf46b475a81bb5d05d610f8c19de",
"https://git.kernel.org/stable/c/a6d634f794c808a261eac7d5af023a7e06b9ecd8",
"https://git.kernel.org/stable/c/a6f0643e4f63cfaa0d5d4a69de4f132eac4b8fe4",
"https://git.kernel.org/stable/c/c76b8abce575e0c6e4096957220b4515ed847d89",
"https://git.kernel.org/stable/c/de984ea883405420fdc416ae8964b752df586970",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64192.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-64192",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64192.json"
}
},
"related_cves": [
{
"value": "CVE-2026-64192",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 519609,
"published_at": "2026-07-20T16:27:51.72+00:00"
}