CVE-2026-98215

What it actually does

SELinux fails to preserve the original user file SID when nested backing files (such as overlayfs over overlayfs or FUSE passthrough) are present, causing mprotect and similar checks to evaluate against the mounter SID instead of the user SID or to apply the wrong policy after a domain transition.

Why it matters to the business

Applications running on systems with layered filesystem mounts and SELinux enforcing mode may experience unexpected access denials or, in misconfigured cases, weaker enforcement, leading to operational disruptions or potential unauthorized memory operations in production workloads using containers or stacked filesystems.

How an attack unfolds

An attacker with the ability to trigger mprotect or similar syscalls on files opened through multiple layers of overlay or FUSE-backed mounts can cause SELinux to evaluate policy against an incorrect SID, resulting in either a denial that blocks legitimate access or, after a domain transition, enforcement against the wrong target and possible bypass of intended restrictions.

How to fix it

Update the Linux kernel to a version containing the fix that copies the saved user SID when user_file itself is a backing file; keep the regular file SID for the first backing layer. Rebuild and redistribute any custom kernels or distribution images that include the affected SELinux backing-file logic.

How to confirm the fix worked

Confirm the kernel source contains the change that checks whether user_file is a backing file and copies the original user SID; test with two nested overlayfs mounts and an enforcing SELinux policy that mprotect(PROT_READ) succeeds without an fd { use } denial against the mounter SID.

Typical attack path

1. Identify or create a workload using nested overlayfs or FUSE passthrough mounts under SELinux enforcing mode.
2. Open a top-level file and trigger mmap that replaces vm_file with a backing file.
3. Perform mprotect or equivalent operation on the mapped region.
4. Observe SELinux denial logged against the mounter SID rather than the user SID, or successful operation that should have been denied after domain transition.

How to detect it

Search kernel audit logs and SELinux AVC denials for fd { use } operations where the denied SID matches a known mounter context rather than the expected user domain; correlate with processes performing mmap followed by mprotect on files under overlay or FUSE mounts.

• SELinux denial: fd { use } against mounter SID
• mprotect(PROT_READ) returning EACCES under nested overlayfs with enforcing policy

What your security team should do

• Prioritize kernel updates on systems using nested overlayfs, FUSE passthrough, or container runtimes that rely on stacked filesystems.
• Monitor SELinux audit logs for fd { use } denials referencing mounter SIDs on files that should be accessible by user domains.
• Review and test SELinux policies in environments with multiple filesystem layers before deploying to production.
• Track upstream kernel releases for the next 30 days given the recent publication date and stable low EPSS.