Cloudanix VulnDB

CVE-2026-98214

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux security feature meant to stop unauthorized code from running can be skipped when memory protections are changed after a file is first opened through multiple layered storage setups.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Authorization Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

mprotect() bypasses SELinux permission checks on intermediate layers of stacked filesystems (e.g. nested overlayfs) because only the lowest backing file is present in vma->vm_file; mmap() performs full descent checks but mprotect() skips mounter layers between the top-level user and lowest mounter.

Why it matters to the business

Systems relying on SELinux to enforce execute restrictions across nested filesystem mounts may allow unauthorized code execution, increasing risk of policy bypass in container or complex storage environments.

How an attack unfolds

An attacker performs mmap(PROT_NONE) on a payload through two nested overlayfs mounts (where policy denies mounter_t -> middle_file_t:file { execute }), then calls mprotect(PROT_EXEC); the kernel rechecks only the top and bottom layers, allowing the mapping to succeed and code to execute where a direct mmap would have been denied.

How to fix it

Apply the upstream kernel fix that stores intermediate mounter SIDs and paths in the backing-file security blob, rechecks fd use and inode rights for every saved mounter during mprotect, and releases the array in backing_file_free; rebuild and boot the patched kernel.

How to confirm the fix worked

Confirm the kernel tree contains the referenced commit and the backing-file security blob changes; reproduce the nested overlayfs + SELinux test case to verify mmap(PROT_EXEC) and mmap+ mprotect now produce identical denials.

Typical attack path

  1. Mount two or more overlayfs layers with SELinux policy restricting intermediate mounter execute rights
  2. Open payload file and call mmap with PROT_NONE
  3. Call mprotect to add PROT_EXEC on the resulting VMA
  4. Execute or interpret the now-executable mapping

How to detect it

Inspect SELinux AVC logs for execute denials on mmap followed by successful mprotect calls on overlay-backed files; correlate with process names performing nested filesystem operations and policy contexts involving mounter_t or middle_file_t labels.

  • avc: denied { execute } for pid=.* comm="nested_exec"
  • path="/payload" dev="overlay"
  • scontext=.*:mounter_t
  • tcontext=.*:middle_file_t

What your security team should do

  • Prioritize kernel updates on systems using SELinux with stacked filesystems
  • Audit SELinux policies for intermediate mounter execute and execmod permissions required by nested mounts
  • Add SELinux AVC logging for mprotect operations in high-risk environments

The record

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]

Affected packages

Ecosystem Package Introduced Fixed