linux-kernel - Re: [f2fs-dev] [PATCH v2 2/2] f2fs: fix infinite loop in __insert_extent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f6b74555-f10c-4a8e-8caa-1797a3d7a7cf@kernel.org>
Date: Tue, 16 Sep 2025 14:46:33 +0800
From: Chao Yu <chao@...nel.org>
To: wangzijie <wangzijie1@...or.com>, jaegeuk@...nel.org
Cc: chao@...nel.org, bintian.wang@...or.com, feng.han@...or.com,
 linux-f2fs-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [f2fs-dev] [PATCH v2 2/2] f2fs: fix infinite loop in
 __insert_extent_tree()

On 9/16/25 13:22, wangzijie wrote:
>> On 09/15, wangzijie wrote:
>>> When we get wrong extent info data, and look up extent_node in rb tree,
>>> it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by
>>> return NULL.
>>
>> This is the exact buggy case which we should fix the original one. Have
>> you seen this error? In that case, can we consider writing some kernel
>> message and handle the error properly?
> 
> Hi Jaegeuk,
> The original one is the bug I mentioned in the first patch of this patch set
> ("f2fs: fix zero-sized extent for precache extents"). 

Zijie,

Did you suffer this problem in product? right?

> 
> When we use a wrong extent_info(zero-sized) to do update, and there exists a
> extent_node which has same fofs as the wrong one, we will skip "invalidate all extent
> nodes in range [fofs, fofs + len - 1]"(en->ei.fofs = end = tei->fofs + tei->len = tei->fofs),
> which cause the infinite loop in __insert_extent_tree().
> 
> So we can add f2fs_bug_on() when there occurs zero-sized extent
> in f2fs_update_read_extent_cache_range(), and give up this zero-sized
> extent update to handle other unknown buggy cases. Do you think this will be better?
> 
> And do we need to solve this infinite loop?

IMO, it's worth to end such loop if there is any corrupted extent in rbtree to
avoid kernel hang, no matter it is caused by software bug or hardware flaw
potentially.

Thanks,

> 
> 
>>>
>>> Signed-off-by: wangzijie <wangzijie1@...or.com>
>>> ---
>>>  fs/f2fs/extent_cache.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
>>> index 199c1e7a8..6ed6f3d1d 100644
>>> --- a/fs/f2fs/extent_cache.c
>>> +++ b/fs/f2fs/extent_cache.c
>>> @@ -605,6 +605,7 @@ static struct extent_node *__insert_extent_tree(struct f2fs_sb_info *sbi,
>>>  			leftmost = false;
>>>  		} else {
>>>  			f2fs_bug_on(sbi, 1);
>>> +			return NULL;
>>>  		}
>>>  	}
>>>  
>>> -- 
>>> 2.25.1