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

CVE-2026-80806

Affected Products

Linux