CVE-2026-80806: ext4: don't enable DAX on new encrypted files

Published Sep 4, 2026

Updated

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 ext4setinodeflags(inode, init=true) in ext4newinode() is made before EXT4INODEENCRYPT is set. As a result, it can set SDAX if the filesystem is mounted with "-o dax=always".

EXT4INODEENCRYPT then actually gets set a bit later in ext4newinode(), when it calls fscryptsetcontext() which calls ext4setcontext(). ext4setcontext() sets EXT4INODEENCRYPT and calls ext4setinodeflags(inode, init=false) to set SENCRYPTED too.

This was intended to clear SDAX as well. However, this was broken by commit 043546e46dc7 ("fs/ext4: Only change SDAX 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 ext4newinode() set EXT4INODEENCRYPT earlier. This makes it take effect in ext4setinodeflags(inode, init=true), making SDAX never be set.

Similarly, make EXT4STATEMAYINLINEDATA 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, ext4setcontext() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too.

Affected Software

1 affected component

Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade Linux kernel ext4 (fscrypt_set_context / __ext4_new_inode) to a version that resolves this vulnerability.
Patch 043546e46dc7
Configuration
Do not mount the ext4 filesystem with "-o dax=always"; this is called out as causing xfstests failures such as generic/548 when DAX is always enabled on new encrypted inodes.
ext4 filesystem mount dax = -o dax=always (remove/avoid)

Event History

Sep 4, 2026

CVE Published

via MITRE·03:13 PM

Data Sourced

via MITRE·03:13 PM

Description

Frequently Asked Questions

Which deployments are exposed to this issue?

The affected scenario is creation of new encrypted regular files on ext4 filesystems mounted with the dax=always option. The issue occurs because DAX can be enabled before the inode is marked encrypted.

What is the security impact if the issue is triggered?

Data written to the affected new encrypted file can bypass encryption. This undermines the expected protection for file contents written under that configuration.

How can this be identified during testing?

The issue causes xfstests failures including generic/548 when ext4 is mounted with dax=always. Testing encrypted new-file creation under that mount option can therefore expose the condition.

What is the remediation?

Use a Linux kernel containing the resolved ext4 change, which marks new encrypted inodes before inode flags are initialized so that S_DAX is not set.