CVE-2026-98214 json
selinux: recheck intermediate backing files on mprotect()
published last mo. modified 24d ago also EUVD-2026-93142
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 12%
- public exploits
- 0
- none known
Summary
In 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]
Patch / fix
- Linux Linux 6.6.158, 6.12.112, 6.18.54, 7.1, 7.3
- linux Debian 13 6.12.113-1
- linux Debian 14 7.2.8-1
- linux-6.12 Debian 12 6.12.113-1~deb12u1
debian advisories DEBIAN-CVE-2026-98214
- linux Ubuntu 26.04 LTS 7.0.0-42.42
- linux-aws Ubuntu 26.04 LTS 7.0.0-1016.17
- linux-gcp Ubuntu 26.04 LTS 7.0.0-1016.18
- linux-ibm Ubuntu 26.04 LTS 7.0.0-1017.17
- linux-riscv Ubuntu 26.04 LTS 7.0.0-42.42.1
- linux-oracle Ubuntu 26.04 LTS 7.0.0-1015.16
- linux-hwe-7.0 Ubuntu 24.04 LTS 7.0.0-42.42~24.04.1
- linux-oem-7.0 Ubuntu 26.04 LTS 7.0.0-1017.17
ubuntu advisories UBUNTU-CVE-2026-98214
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-source openSUSE Tumbleweed 7.2.10-1.1
opensuse advisories openSUSE-SU-2026:12131-1
- git.kernel.org/stable/c/4d50ebe5a27724e020747ffd61a051dec67cb8ec commit
- git.kernel.org/stable/c/89376fbfdcc1a728e1775f98752cdd90b0930a00 commit
- git.kernel.org/stable/c/d127c7e1f3e1231d8ac8b2738e3f00bea12afe74 commit
- git.kernel.org/stable/c/c2bbb905af2293549651b614a52ad91e0b462b60 commit
- git.kernel.org/stable/c/78fc54b934bfb2c18aad8154c7302067146946f9 commit
Is CVE-2026-98214 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerVendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-98214 updated cvss 5.8
kernel: selinux: recheck intermediate backing files on mprotect()
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 moreaffected: workaround, no fix planned “Out of support scope”
-
Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8, openshift/ose-rhel-coreos-9 Red Hat OpenShift Container Platform 5 openshift/ose-rhel-coreos-9affected: workaround, no fix available
-
Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 morenot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.22% chance of exploitation in the next 30 days, higher than 12% of all scored CVEs (FIRST EPSS, 2026-11-11).
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/4d50ebe5a27724e020747ffd61a051dec67cb8ec
- git.kernel.org /stable/c/89376fbfdcc1a728e1775f98752cdd90b0930a00
- git.kernel.org /stable/c/d127c7e1f3e1231d8ac8b2738e3f00bea12afe74
- git.kernel.org /stable/c/c2bbb905af2293549651b614a52ad91e0b462b60
- git.kernel.org /stable/c/78fc54b934bfb2c18aad8154c7302067146946f9
Sources
- CVE List CVE-2026-98214
- NVD CVE-2026-98214
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.