GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-JQXC-3F8R-HC2F

Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 18:31
VLAI
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 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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-80806"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-04T16:18:07Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: don\u0027t enable DAX on new encrypted files\n\nCurrently, when a new encrypted regular file is created, the call to\next4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made\nbefore EXT4_INODE_ENCRYPT is set.  As a result, it can set S_DAX if the\nfilesystem is mounted with \"-o dax=always\".\n\nEXT4_INODE_ENCRYPT then actually gets set a bit later in\n__ext4_new_inode(), when it calls fscrypt_set_context() which calls\next4_set_context().  ext4_set_context() sets EXT4_INODE_ENCRYPT and\ncalls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too.\n\nThis was intended to clear S_DAX as well.  However, this was broken by\ncommit 043546e46dc7 (\"fs/ext4: Only change S_DAX on inode load\").  This\ncauses data written to the file to bypass encryption, also causing\nxfstests failures such as generic/548 (when \"-o dax=always\" is used).\n\nFix this by simplifying the flow by making __ext4_new_inode() set\nEXT4_INODE_ENCRYPT earlier.  This makes it take effect in\next4_set_inode_flags(inode, init=true), making S_DAX never be set.\n\nSimilarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first\nplace on new encrypted inodes.  Then it doesn\u0027t need to be cleared.\n\nAs a result of these simplifications, ext4_set_context() no longer needs\nto change inode flags or state when \u0027handle != NULL\u0027.  Remove that too.",
  "id": "GHSA-jqxc-3f8r-hc2f",
  "modified": "2026-09-04T18:31:27Z",
  "published": "2026-09-04T18:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80806"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3392391b363a63ebb531d45318a729b1c998565b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/458776af0061afec1014cb3cd0061e282e482e83"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5959cad3cfa852ec07bbdaf9c17f4838a94a8e6c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a13f61ba9b2a7a4ff1f140949ccfad23c5313757"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/add98959b220935b243170214c787bc03044a44d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/da32af420d6d466e247c43ac0b829edeac7ae0ad"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e27bae352158c007143d5bb50f3af33a177c0a37"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ed1cd834da65db127f1c30ff67e78f14825a06c1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f53b325068bca0b238c3e0d2eb7de9b1f2268cab"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.