[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

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

[Jiayuan Chen]

Hi Greg,

Any update here ?

We rebased the 6.6 stable one week ago and also found the same regression.

Are we planning to use this patch or just revert the blamed series like 6.1 did ?
https://lore.kernel.org/all/20260408010208.746177-1-sashal@kernel.org/

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

[Greg KH]

On Thu, Jul 02, 2026 at 09:48:33AM +0800, Jiayuan Chen wrote:
> Hi Greg,
> 
> Any update here ?

What is "here"?  There is no context in this email :(

> We rebased the 6.6 stable one week ago and also found the same regression.

What regression?  Again, no context :(

confused,

greg k-h

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

[Jiayuan Chen]

On 7/2/26 1:47 PM, Greg KH wrote:
> On Thu, Jul 02, 2026 at 09:48:33AM +0800, Jiayuan Chen wrote:
>> Hi Greg,
>>
>> Any update here ?
> What is "here"?  There is no context in this email :(


Sorry I dropped the context:

https://lore.kernel.org/stable/tencent_C982B0201FE8F041BD5B4FC1ED7D646A740A@qq.com/


This patch is trying to fix the regression which Introduced by this series:

     [PATCH 6.6 046/567] ext4: get rid of ppath in ext4_ext_insert_extent()

https://lore.kernel.org/all/20260323134534.939905793@linuxfoundation.org/


The series was also backported to 6.1 but reverted later.

https://lore.kernel.org/all/20260408010208.746177-1-sashal@kernel.org/


So I'm confused about the next action will we accept Wang Jun's patch or 
we just revert it as 6.1 did ?



>
>> We rebased the 6.6 stable one week ago and also found the same regression.
> What regression?  Again, no context :(
>
> confused,
>
> greg k-h

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(-)

The commit here does not match the upstream commit at all, and is not
documented as such, so obviously you don't want us to take it :)

thanks,

greg k-h

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

[Theodore Tso]

> 
> This patch is trying to fix the regression which Introduced by this series:
> 
>     [PATCH 6.6 046/567] ext4: get rid of ppath in ext4_ext_insert_extent()
>

The subject line in the patch did not make it clear that this was
fixing a breakage caused by a backport from upstream kernel into 6.6.
So I was quite confused, and given that no one pays me to work on LTS
kernels, and I wasted several days debugging the 6.1 backport before
figuring out what the guilty commit that needed reverting, and life
has gotten super busy at $WORK, I decided to say, oh well, the failure
was only triggered (as far as I know) by tests exercising the shutdown
path, and life was too short to figure out how to untangle 6.6 LTS.

Instead, I've just been telling people that they **really** should
just use far more recent LTS kernels, because from a security
perpsective, lots of patches never get backported to older LTS kernels
--- and in a post Mythos world, it's probably not reasonable to be
using 6.1 or 6.6 --- and sometimes the auto-backport results in flaky
LTS kernels --- and while there had been an attempt to organize
companies to contribute SWE effort to test and stablize xfs, (a) in
the past 18 months, all of the companies who had contriburted SWE time
had with drawn that effort, and (b) I've never been able to recruit
people willing to do this for ext4.  And I'm too busy to spend time
after midnight or on weekends doing it for older LTS kernels for free.

> So I'm confused about the next action will we accept Wang Jun's
> patch or we just revert it as 6.1 did ?

The commit description in Wang Jun's patch needs to explain that it's
fixing a but that was introduced in the LTS backport.  As memory
serves, after the several day effort to figure out the guilty commmt
in 6.1 LTS, we determined that the purported bug that the half-dozen
odd commits (including the dependencies), wasn't even **applicable**
for 6.1.  So it was all just a massive waste of my time.

I have not done the analysis to determine whether the patch series in
6.6 that caused the regression is actually fixing a bug in the 6.6 LTS
kernel.  If it doesn't, perhaps reverting the whole mess is the better
approach.  Or if someone wants to take Wang Jun's patch, and run it
through a full set of regression test suites, using something like:

   gce-xfstests ltm -c ext4/all -g auto

or the equivalent, and it passes without triggering crashes and
without causing more regressions, Wang Jun's patch seems to make
sense.  For more instructions on how to run the test, see [1][2].

[1] https://thunk.org/gce-xfstests
[2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md

And if you are interested in helping out with ext4 stable kernel
maintenace, I'd love the volunteer help.  After the mess with the 6.1
and 6.6 LTS backports, I've been tempted to just tell the stable
kernel maintainers to stop backporting fixes to 6.1 and 6.6.  (The XFS
community has standing instructions not to back *any* backports to LTS
kernels,b ecause of this instability problem.  The fix of having
developers actually do QA before sending out backports works, and is
certainly much better than the "it builds, ship it!" approach --- but
the downside is that most companies aren't willing to devote the time
to do that backports, especially now in the post Mythos world, your
internal security teams are probably requiring you to use much newer
LTS kernels anyway.)

Cheers,

						- Ted

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

[Baokun Li]

On 2026/7/2 13:47, Greg KH wrote:
> On Thu, Jul 02, 2026 at 09:48:33AM +0800, Jiayuan Chen wrote:
>> Hi Greg,
>>
>> Any update here ?
> What is "here"?  There is no context in this email :(
>
>> We rebased the 6.6 stable one week ago and also found the same regression.
> What regression?  Again, no context :(
>
> confused,
>
> greg k-h

For some reason, LTS only merged a subset of my patchset, causing
some commits to lack their prerequisite patches. This leads to error
numbers being interpreted as valid pointers.

For details, see the fix patchset that Erkun submitted to 6.6.y
(it fell through the cracks for some reason):

https://lore.kernel.org/all/20260421113416.4040274-1-yangerkun@huawei.com/

Either applying this fix patchset or reverting the incorrectly merged
commit should resolve the issue.


Thanks,
Baokun

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

[Greg KH]

On Fri, Jul 03, 2026 at 03:57:09PM +0800, Baokun Li wrote:
> On 2026/7/2 13:47, Greg KH wrote:
> > On Thu, Jul 02, 2026 at 09:48:33AM +0800, Jiayuan Chen wrote:
> >> Hi Greg,
> >>
> >> Any update here ?
> > What is "here"?  There is no context in this email :(
> >
> >> We rebased the 6.6 stable one week ago and also found the same regression.
> > What regression?  Again, no context :(
> >
> > confused,
> >
> > greg k-h
> 
> For some reason, LTS only merged a subset of my patchset, causing
> some commits to lack their prerequisite patches. This leads to error
> numbers being interpreted as valid pointers.
> 
> For details, see the fix patchset that Erkun submitted to 6.6.y
> (it fell through the cracks for some reason):
> 
> https://lore.kernel.org/all/20260421113416.4040274-1-yangerkun@huawei.com/
> 
> Either applying this fix patchset or reverting the incorrectly merged
> commit should resolve the issue.

How about submitting a revert so that we can start fresh and work from
there?

thanks,

greg k-h

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

[Baokun Li]

On 2026/7/3 16:20, Greg KH wrote:
> On Fri, Jul 03, 2026 at 03:57:09PM +0800, Baokun Li wrote:
>> On 2026/7/2 13:47, Greg KH wrote:
>>> On Thu, Jul 02, 2026 at 09:48:33AM +0800, Jiayuan Chen wrote:
>>>> Hi Greg,
>>>>
>>>> Any update here ?
>>> What is "here"?  There is no context in this email :(
>>>
>>>> We rebased the 6.6 stable one week ago and also found the same regression.
>>> What regression?  Again, no context :(
>>>
>>> confused,
>>>
>>> greg k-h
>> For some reason, LTS only merged a subset of my patchset, causing
>> some commits to lack their prerequisite patches. This leads to error
>> numbers being interpreted as valid pointers.
>>
>> For details, see the fix patchset that Erkun submitted to 6.6.y
>> (it fell through the cracks for some reason):
>>
>> https://lore.kernel.org/all/20260421113416.4040274-1-yangerkun@huawei.com/
>>
>> Either applying this fix patchset or reverting the incorrectly merged
>> commit should resolve the issue.
> How about submitting a revert so that we can start fresh and work from
> there?

Alright, I can help review the patches.


Thanks,
Baokun

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

[Theodore Tso]

On Fri, Jul 03, 2026 at 04:44:32PM -0500, Baokun Li wrote:
> >> Either applying this fix patchset or reverting the incorrectly merged
> >> commit should resolve the issue.
> > How about submitting a revert so that we can start fresh and work from
> > there?
> 
> Alright, I can help review the patches.

Can you also double check whether your patchset actually fixes a bug
in 6.6?  As near as I can tell, it wasn't needed for 6.1 at all.

Thanks,

						- Ted