---
id: CVE-2026-45892
title: 'ext4: drop extent cache after doing PARTIAL_VALID1 zeroout'
summary: |-
  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() wit…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= ddf854e59166533b0f46ba32cd6cd9aca3197d1b <
    28db4bfc6f82fd20e2aadb7fc162244109a4eb31
  - >-
    Linux >= 58ddae5d77b1db3a27b891c75a8fa120239ac092 <
    f0931a5c17005a0c4fc35bd1a001245effc3354b
  - >-
    Linux >= d17857b4fb9ba5745b59be0ef38fd532991fccbf <
    d8ee559fccdef713f058cfe5f2c03dc9b18be3b1
  - >-
    Linux >= d67c8ecf3d8fda9b8ef80e6f665d84b6d6ac9d88 <
    c2ee51d684adca7645e4aa74adca13f6750390bc
  - >-
    Linux >= 7015fcf473796e1d2d876f241bd9e0c36f3d4eef <
    a1b962a821e7a52d48212ae269b45808b4411267
  - >-
    Linux >= 1bf6974822d1dba86cf11b5f05498581cf3488a2 <
    6d882ea3b0931b43530d44149b79fcd4ffc13030
  - Linux >= 6.1.167 < 6.1.168
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: partial
  timestamp: '2026-11-06T15:43:46.849985Z'
published: '2026-05-27'
updated: '2026-11-06'
sourceUpdated: '2026-11-06T15:53:11.239Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-45892'
references:
  - url: 'https://git.kernel.org/stable/c/28db4bfc6f82fd20e2aadb7fc162244109a4eb31'
  - url: 'https://git.kernel.org/stable/c/f0931a5c17005a0c4fc35bd1a001245effc3354b'
  - url: 'https://git.kernel.org/stable/c/d8ee559fccdef713f058cfe5f2c03dc9b18be3b1'
  - url: 'https://git.kernel.org/stable/c/c2ee51d684adca7645e4aa74adca13f6750390bc'
  - url: 'https://git.kernel.org/stable/c/a1b962a821e7a52d48212ae269b45808b4411267'
  - url: 'https://git.kernel.org/stable/c/6d882ea3b0931b43530d44149b79fcd4ffc13030'
tags:
  - cve.org
epss: 0.0016
epssPercentile: 0.05261
ingestedAt: '2026-11-06T16:57:43.391Z'
---

## Overview

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.

## Affected

- `Linux >= ddf854e59166533b0f46ba32cd6cd9aca3197d1b < 28db4bfc6f82fd20e2aadb7fc162244109a4eb31`
- `Linux >= 58ddae5d77b1db3a27b891c75a8fa120239ac092 < f0931a5c17005a0c4fc35bd1a001245effc3354b`
- `Linux >= d17857b4fb9ba5745b59be0ef38fd532991fccbf < d8ee559fccdef713f058cfe5f2c03dc9b18be3b1`
- `Linux >= d67c8ecf3d8fda9b8ef80e6f665d84b6d6ac9d88 < c2ee51d684adca7645e4aa74adca13f6750390bc`
- `Linux >= 7015fcf473796e1d2d876f241bd9e0c36f3d4eef < a1b962a821e7a52d48212ae269b45808b4411267`
- `Linux >= 1bf6974822d1dba86cf11b5f05498581cf3488a2 < 6d882ea3b0931b43530d44149b79fcd4ffc13030`
- `Linux >= 6.1.167 < 6.1.168`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.