CVE-2026-80806 in Linux
Riassunto
di VulDB • 04/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
ext4: non abilitare DAX sui nuovi file crittografati
Attualmente, quando viene creato un nuovo file regolare crittografato, la chiamata a `ext4_set_inode_flags(inode, init=true)` in `__ext4_new_inode()` avviene prima che venga impostato il flag `EXT4_INODE_ENCRYPT`. Di conseguenza, può essere impostato `S_DAX` se il filesystem è montato con l'opzione `-o dax=always`.
Il flag `EXT4_INODE_ENCRYPT` viene effettivamente impostato in un momento successivo all'interno di `__ext4_new_inode()`, quando viene chiamata `fscrypt_set_context()` che a sua volta chiama `ext4_set_context()`. `ext4_set_context()` imposta `EXT4_INODE_ENCRYPT` e chiama `ext4_set_inode_flags(inode, init=false)` per impostare anche `S_ENCRYPTED`.
Questo era inteso come un meccanismo per azzerare anche `S_DAX`. Tuttavia, questa logica è stata compromessa dal commit 043546e46dc7 ("fs/ext4: Only change S_DAX on inode load"). Ciò fa sì che i dati scritti nel file bypassino la crittografia, causando inoltre il fallimento di test come xfstests generic/548 (quando viene utilizzata l'opzione `-o dax=always`).
Si risolve questo problema semplificando il flusso facendo in modo che `__ext4_new_inode()` imposti prima `EXT4_INODE_ENCRYPT`. In questo modo, tale flag ha effetto all'interno di `ext4_set_inode_flags(inode, init=true)`, impedendo l'impostazione di `S_DAX`.
Allo stesso modo, si impedisce che il flag `EXT4_STATE_MAY_INLINE_DATA` venga mai impostato sui nuovi inode crittografati. Di conseguenza, non è necessario azzerarlo successivamente.
A seguito di queste semplificazioni, `ext4_set_context()` non ha più bisogno di modificare i flag o lo stato dell'inode quando 'handle != NULL'. Tale codice viene rimosso.
If you want to get best quality of vulnerability data, you may have to visit VulDB.