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

[Hui Wang]

Acked-by: Hui Wang <hui.wang at canonical.com>

On 6/26/26 19:32, 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(-)
>