All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-98214: selinux: recheck intermediate backing files on mprotect()
Date: Tue,  6 Oct 2026 10:45:15 +0200	[thread overview]
Message-ID: <2026100640-CVE-2026-98214-cedd@gregkh> (raw)

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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]

The Linux kernel CVE team has assigned CVE-2026-98214 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.6.144 with commit bc6c380c1159de52a252ed11f19a42c47f60a735 and fixed in 6.6.158 with commit 4d50ebe5a27724e020747ffd61a051dec67cb8ec
	Issue introduced in 6.12.95 with commit 8bacd09f12c27710228562e4d13163e58c5f4a45 and fixed in 6.12.112 with commit 89376fbfdcc1a728e1775f98752cdd90b0930a00
	Issue introduced in 6.18.38 with commit d844702198395d3f80222777030f69db6be6b709 and fixed in 6.18.54 with commit d127c7e1f3e1231d8ac8b2738e3f00bea12afe74
	Issue introduced in 7.1 with commit 82544d36b1729153c8aeb179e84750f0c085d3b1 and fixed in 7.2.8 with commit c2bbb905af2293549651b614a52ad91e0b462b60
	Issue introduced in 7.1 with commit 82544d36b1729153c8aeb179e84750f0c085d3b1 and fixed in 7.3-rc4 with commit 78fc54b934bfb2c18aad8154c7302067146946f9
	Issue introduced in 7.0.4 with commit cd0e707a927a70cdfd8bc5a512a9719a87f5ed51

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-98214
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	security/selinux/hooks.c
	security/selinux/include/objsec.h


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/4d50ebe5a27724e020747ffd61a051dec67cb8ec
	https://git.kernel.org/stable/c/89376fbfdcc1a728e1775f98752cdd90b0930a00
	https://git.kernel.org/stable/c/d127c7e1f3e1231d8ac8b2738e3f00bea12afe74
	https://git.kernel.org/stable/c/c2bbb905af2293549651b614a52ad91e0b462b60
	https://git.kernel.org/stable/c/78fc54b934bfb2c18aad8154c7302067146946f9

                 reply	other threads:[~2026-10-06  8:48 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026100640-CVE-2026-98214-cedd@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=gregkh@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.