GHSA-CWV8-MJRX-V4V5
Vulnerability from github – Published: 2026-10-06 09:31 – Updated: 2026-10-06 09:31In the Linux kernel, the following vulnerability has been resolved:
selinux: recheck intermediate backing files on mprotect()
mprotect() can be used to bypass the SELinux checks that mmap() performs against the intermediate layers of a stacked filesystem.
mmap() checks every backing layer as the request descends through the stack. mprotect() only has the lowest backing file in vma->vm_file, so it rechecks the top-level user and the lowest mounter, but skips the mounters of every layer in between. With two nested overlayfs mounts and a policy denying mounter_t -> middle_file_t:file { execute }, a direct mmap(PROT_EXEC) is denied:
avc: denied { execute } for pid=71 comm="nested_exec" path="/payload" dev="overlay" ino=9 scontext=user_u:base_r:mounter_t tcontext=user_u:object_r:middle_file_t tclass=file permissive=0
while mmap(PROT_NONE) followed by mprotect(PROT_EXEC) succeeds.
Preserve each intermediate path, mounter SID and file-description SID in the backing-file security blob, copying the saved entries when another backing layer is opened. Allocate the array only for nested backing files, and release it and the path references in the backing_file_free hook.
During mprotect(), recheck fd { use } and the requested inode permissions for every saved mounter, and include the intermediate layers in the execmod checks. Policy for nested stacking may then need to grant intermediate mounters what a direct mmap() already requires, and execmod on intermediate labels for binaries using text relocations.
Tested on arm64 QEMU with a small BusyBox initramfs and a purpose-built SELinux policy, on a mainline tree containing commit f2381b546e7e ("fs: fix user path of nested backing files").
[PM: subject tweak]
{
"affected": [],
"aliases": [
"CVE-2026-98214"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T09:18:07Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nselinux: recheck intermediate backing files on mprotect()\n\nmprotect() can be used to bypass the SELinux checks that mmap() performs\nagainst the intermediate layers of a stacked filesystem.\n\nmmap() checks every backing layer as the request descends through the\nstack. mprotect() only has the lowest backing file in vma-\u003evm_file, so it\nrechecks the top-level user and the lowest mounter, but skips the mounters\nof every layer in between. With two nested overlayfs mounts and a policy\ndenying mounter_t -\u003e middle_file_t:file { execute }, a direct\nmmap(PROT_EXEC) is denied:\n\n avc: denied { execute } for pid=71 comm=\"nested_exec\"\n path=\"/payload\" dev=\"overlay\" ino=9\n scontext=user_u:base_r:mounter_t\n tcontext=user_u:object_r:middle_file_t tclass=file permissive=0\n\nwhile mmap(PROT_NONE) followed by mprotect(PROT_EXEC) succeeds.\n\nPreserve each intermediate path, mounter SID and file-description SID in\nthe backing-file security blob, copying the saved entries when another\nbacking layer is opened. Allocate the array only for nested backing files,\nand release it and the path references in the backing_file_free hook.\n\nDuring mprotect(), recheck fd { use } and the requested inode permissions\nfor every saved mounter, and include the intermediate layers in the execmod\nchecks. Policy for nested stacking may then need to grant intermediate\nmounters what a direct mmap() already requires, and execmod on intermediate\nlabels for binaries using text relocations.\n\nTested on arm64 QEMU with a small BusyBox initramfs and a purpose-built\nSELinux policy, on a mainline tree containing\ncommit f2381b546e7e (\"fs: fix user path of nested backing files\").\n\n[PM: subject tweak]",
"id": "GHSA-cwv8-mjrx-v4v5",
"modified": "2026-10-06T09:31:30Z",
"published": "2026-10-06T09:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98214"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d50ebe5a27724e020747ffd61a051dec67cb8ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78fc54b934bfb2c18aad8154c7302067146946f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89376fbfdcc1a728e1775f98752cdd90b0930a00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2bbb905af2293549651b614a52ad91e0b462b60"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d127c7e1f3e1231d8ac8b2738e3f00bea12afe74"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.