PT-2026-85647 · Linux · Linux
CVE-2026-80806
·
Published
2026-09-04
·
Updated
2026-09-04
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux