GHSA-XQ2X-F6M4-2HRP

Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-05-27 15:33
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ext4: drop extent cache after doing PARTIAL_VALID1 zeroout

When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent.

Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent.

   0  A      B  N
   [UUUUUUUUUUUU] on-disk extent      U: unwritten extent
   [UUUUUUUUUUUU] extent status tree
   [--DDDDDDDD--]                     D: valid data
      |<-  ->| ----> this range needs to be initialized

ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten.

   0  A      B  N
   [UUUUUUUUUUUU] on-disk extent
   [UUUUUUUUUUUU] extent status tree
   [--DDDDDDDDZZ]                     Z: zeroed data

ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N.

   0  A      B  N
   [UUWWWWWWWWWW] on-disk extent      W: written extent
   [UUUUUUUUUUUU] extent status tree
   [--DDDDDDDDZZ]

Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree.

   0  A      B  N
   [UUWWWWWWWWWW] on-disk extent      W: written extent
   [UUWWWWWWWWUU] extent status tree
   [--DDDDDDDDZZ]

Fix this issue by always cached extent status entry after zeroing out the second part.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-45892"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T14:17:03Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: drop extent cache after doing PARTIAL_VALID1 zeroout\n\nWhen splitting an unwritten extent in the middle and converting it to\ninitialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and\nEXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent.\n\nAssume we have an unwritten file and buffered write in the middle of it\nwithout dioread_nolock enabled, it will allocate blocks as written\nextent.\n\n       0  A      B  N\n       [UUUUUUUUUUUU] on-disk extent      U: unwritten extent\n       [UUUUUUUUUUUU] extent status tree\n       [--DDDDDDDD--]                     D: valid data\n          |\u003c-  -\u003e| ----\u003e this range needs to be initialized\n\next4_split_extent() first try to split this extent at B with\nEXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but\next4_split_extent_at() failed to split this extent due to temporary lack\nof space. It zeroout B to N and leave the entire extent as unwritten.\n\n       0  A      B  N\n       [UUUUUUUUUUUU] on-disk extent\n       [UUUUUUUUUUUU] extent status tree\n       [--DDDDDDDDZZ]                     Z: zeroed data\n\next4_split_extent() then try to split this extent at A with\nEXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and\nleave an written extent from A to N.\n\n       0  A      B  N\n       [UUWWWWWWWWWW] on-disk extent      W: written extent\n       [UUUUUUUUUUUU] extent status tree\n       [--DDDDDDDDZZ]\n\nFinally ext4_map_create_blocks() only insert extent A to B to the extent\nstatus tree, and leave an stale unwritten extent in the status tree.\n\n       0  A      B  N\n       [UUWWWWWWWWWW] on-disk extent      W: written extent\n       [UUWWWWWWWWUU] extent status tree\n       [--DDDDDDDDZZ]\n\nFix this issue by always cached extent status entry after zeroing out\nthe second part.",
  "id": "GHSA-xq2x-f6m4-2hrp",
  "modified": "2026-05-27T15:33:15Z",
  "published": "2026-05-27T15:33:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45892"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6d882ea3b0931b43530d44149b79fcd4ffc13030"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a1b962a821e7a52d48212ae269b45808b4411267"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c2ee51d684adca7645e4aa74adca13f6750390bc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d8ee559fccdef713f058cfe5f2c03dc9b18be3b1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f0931a5c17005a0c4fc35bd1a001245effc3354b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…