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

Alessio Faina alessio.faina at canonical.com
Fri Jun 26 13:22:52 UTC 2026


On Fri, Jun 26, 2026 at 01:32:07PM +0200, Manuel Diewald via kernel-team wrote:
> 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
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

Acked-by: Alessio Faina <alessio.faina at canonical.com>



More information about the kernel-team mailing list