[PATCH] ext4: get rid of ppath in get_ext_path()

[PATCH] ext4: get rid of ppath in get_ext_path()

[Wang Jun]

[ Upstream commit 6b854d552711aa33f59eda334e6d94a00d8825bb ]

The use of path and ppath is now very confusing, so to make the code more
readable, pass path between functions uniformly, and get rid of ppath.

After getting rid of ppath in get_ext_path(), its caller may pass an error
pointer to ext4_free_ext_path(), so it needs to teach ext4_free_ext_path()
and ext4_ext_drop_refs() to skip the error pointer. No functional changes.

Without this fix, ext4_ext_insert_extent() returning ERR_PTR(-ENOSPC) in
ext4_ext_map_blocks() triggers a kernel Oops, observed via SyzKing
fuzzing on v6.6.142:

  BUG: unable to handle page fault for address: ffffffffffffffec
  R15: ffffffffffffffe4  (= ERR_PTR(-ENOSPC))
  RIP: ext4_ext_drop_refs+0x...->ext4_free_ext_path+0x...->
       ext4_ext_map_blocks+0x509/0x53a0

Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Wang Jun <1742789905@qq.com>
---
 fs/ext4/extents.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index a94798e23..8e23563bb 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4510,7 +4510,8 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
 	allocated = map->m_len;
 	ext4_ext_show_leaf(inode, path);
 out:
-	ext4_free_ext_path(path);
+	if (!IS_ERR(path))
+		ext4_free_ext_path(path);
 
 	trace_ext4_ext_map_blocks_exit(inode, flags, map,
 				       err ? err : allocated);
-- 
2.43.0

Re: [PATCH] ext4: get rid of ppath in get_ext_path()

[Greg KH]

On Fri, Jun 26, 2026 at 01:17:21PM +0800, Wang Jun wrote:
> [ Upstream commit 6b854d552711aa33f59eda334e6d94a00d8825bb ]
> 
> The use of path and ppath is now very confusing, so to make the code more
> readable, pass path between functions uniformly, and get rid of ppath.
> 
> After getting rid of ppath in get_ext_path(), its caller may pass an error
> pointer to ext4_free_ext_path(), so it needs to teach ext4_free_ext_path()
> and ext4_ext_drop_refs() to skip the error pointer. No functional changes.
> 
> Without this fix, ext4_ext_insert_extent() returning ERR_PTR(-ENOSPC) in
> ext4_ext_map_blocks() triggers a kernel Oops, observed via SyzKing
> fuzzing on v6.6.142:
> 
>   BUG: unable to handle page fault for address: ffffffffffffffec
>   R15: ffffffffffffffe4  (= ERR_PTR(-ENOSPC))
>   RIP: ext4_ext_drop_refs+0x...->ext4_free_ext_path+0x...->
>        ext4_ext_map_blocks+0x509/0x53a0
> 
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> Reviewed-by: Jan Kara <jack@suse.cz>
> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> Signed-off-by: Wang Jun <1742789905@qq.com>
> ---
>  fs/ext4/extents.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index a94798e23..8e23563bb 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -4510,7 +4510,8 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
>  	allocated = map->m_len;
>  	ext4_ext_show_leaf(inode, path);
>  out:
> -	ext4_free_ext_path(path);
> +	if (!IS_ERR(path))
> +		ext4_free_ext_path(path);
>  
>  	trace_ext4_ext_map_blocks_exit(inode, flags, map,
>  				       err ? err : allocated);
> -- 
> 2.43.0
> 
> 

What stable kernel(s) is this for?

Re: [PATCH] ext4: fix crash when ext4_ext_insert_extent() returns error

[Wang Jun]

Hi,

This patch fixes a NULL/error pointer dereference issue that I triggered
and verified on the v6.6.142 kernel using syzkaller.

Based on this, I believe this fix should be backported to the **v6.6.y**
stable kernel series.

For other currently supported stable series (e.g., v6.1.y, v5.15.y,
v5.10.y, etc.), I have not yet verified if they contain the same
vulnerable code path. It would be prudent to check and potentially
backport the fix there as well, if applicable.

Please let me know if you need any further information or testing.

Thanks,
Wang Jun