Import Source
https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-99669.json
JSON Data
https://api.osv.dev/v1/vulns/AZL-99669
Upstream
Published
2026-09-04T16:18:07Z
Modified
2026-09-05T14:17:04.651850068Z
Summary
CVE-2026-80806 affecting package kernel 6.6.150.1-1
Details

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 ext4setinode_flags(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.

References

Affected packages

Azure Linux:3 / kernel

Package

Name
kernel
Purl
pkg:rpm/azure-linux/kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Last affected
6.6.150.1-1

Database specific

source
"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-99669.json"