[SRU][N][PATCH 0/1] ext4: writeback causes kernel oops when low on space

Manuel Diewald manuel.diewald at canonical.com
Fri Jun 26 11:32:07 UTC 2026


BugLink: https://bugs.launchpad.net/bugs/2158377

SRU Justification:

[Impact]

The noble upstream stable patchset 2026-05-28 (LP: #2154496) introduced
refactoring patches targeting ext4 code, originating from upstream stable
branch linux-6.6.y. During regression testing of the generic noble kernel, the
ltp tests mmap14 and mmap16 were observed to fail, causing a kernel oops.
Through bisecting, upstream commit f7d1331f16a8 ("ext4: get rid of ppath in
ext4_ext_insert_extent()") was found to be cause. This commit was the first in
the refactoring series of commits targeting ext4 in v6.6.130.

The crash is triggered during normal writeback when the filesystem is low on
space. Any workload that writes to ext4 with unwritten
(preallocated/fallocated) extents under space pressure can hit this. It is
fatal to the affected writeback worker thread.

[Fix]

Cherry-pick this missing prerequisite patch:

6b854d552711 ("ext4: get rid of ppath in get_ext_path()").

This patch adds `IS_ERR_OR_NULL()` guards to both `ext4_ext_drop_refs()` and
`ext4_free_ext_path()`. This teaches these cleanup functions to gracefully
handle error pointers by returning immediately, which is necessary now that the
refactored call chain can leave `path` set to an `ERR_PTR` value when reaching
cleanup code.

[Test Plan]

Run the ltp tests mmap14 and mmp16 that reliably trigger the crash. The tests
should complete successfully without triggering a kernel crash.

[Where problems could occur]

If problems with this fix were to occur, they would manifest as silent memory
leaks in ext4 extent handling - specifically, any code path that previously
relied on `ext4_free_ext_path()` to actually free a valid path object but now
mistakenly passes an `IS_ERR()` value would silently skip the free and leak the
already-freed (or never-allocated) path, making such bugs harder to detect
rather than causing a visible crash. Conversely, if any code path were to
accidentally store an `ERR_PTR` in a path variable that is later reused (rather
than cleaned up), the `IS_ERR_OR_NULL` guard would mask what should be a loud
failure, potentially leading to subtle use-after-free or NULL-dereference bugs
downstream when that variable is subsequently passed to `ext4_find_extent()`
for recycling.

Baokun Li (1):
  ext4: get rid of ppath in get_ext_path()

 fs/ext4/extents.c     |  5 +++--
 fs/ext4/move_extent.c | 34 +++++++++++++++++-----------------
 2 files changed, 20 insertions(+), 19 deletions(-)

-- 
2.34.1




More information about the kernel-team mailing list