Skip to content
Heist/ feed
Back to feed
UnratedFix available

bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized

Type: advisorySources: OSV

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 source

Published 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"
}