{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98214 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98214 is a vulnerability in Linux, published on 6 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-98214 and fix it if it is affected.\n\nWhat it is: CVE-2026-98214 is a vulnerability in Linux, published on 6 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-98214 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-98214/ (Markdown: https://insights.sbomify.com/CVE-2026-98214/index.md)","id":"CVE-2026-98214","markdown":"https://insights.sbomify.com/CVE-2026-98214/index.md","name":"CVE-2026-98214","record":{"aliases":["AZL-106467","BELL-CVE-2026-98214","DEBIAN-CVE-2026-98214","GHSA-cwv8-mjrx-v4v5","UBUNTU-CVE-2026-98214"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["security_bypass"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"Local attackers can bypass SELinux execute restrictions on nested overlay filesystems by using mprotect instead of mmap, requiring specific SELinux policies and nested mounts.","user_interaction":"not_required","vuln_class":"security_feature_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"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]","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"selinux: recheck intermediate backing files on mprotect()","id":"CVE-2026-98214","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"security_feature_bypass","year":"2026"},"n_packages":0,"n_references":5,"next":{"headline":"selinux: preserve user SID across nested backing files","id":"CVE-2026-98215"},"packages":[],"prev":{"headline":"mmc: core: Cancel SDIO IRQ work before freeing host","id":"CVE-2026-98213"},"products":["Linux"],"published":"2026-10-06","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"Local attackers can bypass SELinux execute restrictions on nested overlay filesystems by using mprotect instead of mmap, requiring specific SELinux policies and nested mounts.","url":"https://insights.sbomify.com/CVE-2026-98214/"}