From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-80806: ext4: don't enable DAX on new encrypted files
Date: Fri, 4 Sep 2026 17:11:45 +0200 [thread overview]
Message-ID: <2026090410-CVE-2026-80806-ced9@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't enable DAX on new encrypted files
Currently, when a new encrypted regular file is created, the call to
ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made
before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the
filesystem is mounted with "-o dax=always".
EXT4_INODE_ENCRYPT then actually gets set a bit later in
__ext4_new_inode(), when it calls fscrypt_set_context() which calls
ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and
calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too.
This was intended to clear S_DAX as well. However, this was broken by
commit 043546e46dc7 ("fs/ext4: Only change S_DAX on inode load"). This
causes data written to the file to bypass encryption, also causing
xfstests failures such as generic/548 (when "-o dax=always" is used).
Fix this by simplifying the flow by making __ext4_new_inode() set
EXT4_INODE_ENCRYPT earlier. This makes it take effect in
ext4_set_inode_flags(inode, init=true), making S_DAX never be set.
Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first
place on new encrypted inodes. Then it doesn't need to be cleared.
As a result of these simplifications, ext4_set_context() no longer needs
to change inode flags or state when 'handle != NULL'. Remove that too.
The Linux kernel CVE team has assigned CVE-2026-80806 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.8 with commit 043546e46dc70c25ff7e2cf6d09cbb0424fc9978 and fixed in 5.10.269 with commit add98959b220935b243170214c787bc03044a44d
Issue introduced in 5.8 with commit 043546e46dc70c25ff7e2cf6d09cbb0424fc9978 and fixed in 5.15.220 with commit f53b325068bca0b238c3e0d2eb7de9b1f2268cab
Issue introduced in 5.8 with commit 043546e46dc70c25ff7e2cf6d09cbb0424fc9978 and fixed in 6.1.187 with commit 5959cad3cfa852ec07bbdaf9c17f4838a94a8e6c
Issue introduced in 5.8 with commit 043546e46dc70c25ff7e2cf6d09cbb0424fc9978 and fixed in 6.6.156 with commit a13f61ba9b2a7a4ff1f140949ccfad23c5313757
Issue introduced in 5.8 with commit 043546e46dc70c25ff7e2cf6d09cbb0424fc9978 and fixed in 6.12.108 with commit ed1cd834da65db127f1c30ff67e78f14825a06c1
Issue introduced in 5.8 with commit 043546e46dc70c25ff7e2cf6d09cbb0424fc9978 and fixed in 6.18.47 with commit 458776af0061afec1014cb3cd0061e282e482e83
Issue introduced in 5.8 with commit 043546e46dc70c25ff7e2cf6d09cbb0424fc9978 and fixed in 7.1.11 with commit 3392391b363a63ebb531d45318a729b1c998565b
Issue introduced in 5.8 with commit 043546e46dc70c25ff7e2cf6d09cbb0424fc9978 and fixed in 7.2.1 with commit e27bae352158c007143d5bb50f3af33a177c0a37
Issue introduced in 5.8 with commit 043546e46dc70c25ff7e2cf6d09cbb0424fc9978 and fixed in 7.3-rc1 with commit da32af420d6d466e247c43ac0b829edeac7ae0ad
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-80806
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:
fs/ext4/crypto.c
fs/ext4/ialloc.c
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/add98959b220935b243170214c787bc03044a44d
https://git.kernel.org/stable/c/f53b325068bca0b238c3e0d2eb7de9b1f2268cab
https://git.kernel.org/stable/c/5959cad3cfa852ec07bbdaf9c17f4838a94a8e6c
https://git.kernel.org/stable/c/a13f61ba9b2a7a4ff1f140949ccfad23c5313757
https://git.kernel.org/stable/c/ed1cd834da65db127f1c30ff67e78f14825a06c1
https://git.kernel.org/stable/c/458776af0061afec1014cb3cd0061e282e482e83
https://git.kernel.org/stable/c/3392391b363a63ebb531d45318a729b1c998565b
https://git.kernel.org/stable/c/e27bae352158c007143d5bb50f3af33a177c0a37
https://git.kernel.org/stable/c/da32af420d6d466e247c43ac0b829edeac7ae0ad
reply other threads:[~2026-09-04 15:18 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=2026090410-CVE-2026-80806-ced9@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.