{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.85-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.18.14-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "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           |\u003c-  -\u003e| ----\u003e 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.",
  "id": "DEBIAN-CVE-2026-45892",
  "modified": "2026-09-14T16:47:28.491753915Z",
  "published": "2026-05-27T14:17:03.353Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-45892"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-45892"
  ]
}