linux-kernel - Re: [PATCH] ocfs2: fix slab-out-of-bounds in ocfs2_rotate_requires_path

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] [day] [month] [year] [list]

Message-Id: <20260119180147.1708-1-jiashengjiangcool@gmail.com>
Date: Mon, 19 Jan 2026 18:01:47 +0000
From: Jiasheng Jiang <jiashengjiangcool@...il.com>
To: heming.zhao@...e.com
Cc: jiashengjiangcool@...il.com,
	jlbec@...lplan.org,
	joseph.qi@...ux.alibaba.com,
	linux-kernel@...r.kernel.org,
	mark@...heh.com,
	ocfs2-devel@...ts.linux.dev
Subject: Re: [PATCH] ocfs2: fix slab-out-of-bounds in ocfs2_rotate_requires_path_adjustment

On Mon, 19 Jan 2026 22:50:00 +0800, Heming Zhao wrote:
> On Fri, Jan 16, 2026 at 05:21:13PM +0000, Jiasheng Jiang wrote:
>> In ocfs2_rotate_requires_path_adjustment(), the variable 'next_free' is
>> assigned the value of 'left_el->l_next_free_rec'. This value is then used
>> to index the 'l_recs' array as 'next_free - 1'.
>> 
>> If the filesystem is corrupted or in an unexpected state such that
>> 'l_next_free_rec' is 0, this leads to an array index of -1, triggering
>> a slab-out-of-bounds access.
>> 
>> Other functions in alloc.c, such as ocfs2_rotate_leaf() and
>> ocfs2_update_edge_lengths(), effectively guard against this condition.
>> This patch adds a similar check to return 0 immediately if 'next_free'
>> is 0, preventing the out-of-bounds access.
> 
> Do you have reproduction steps to support your analysis?
> 
> - Heming

Regarding the reproduction steps, we detected this issue through static
analysis. We do not have a specific script to reproduce this as it
requires a corrupted filesystem image.

However, if the filesystem metadata is corrupted (e.g., due to bit rot or
software bugs), it is possible that l_next_free_rec reads as 0. In the
current implementation, this leads to accessing l_recs with index -1,
causing a slab-out-of-bounds access.

This patch is intended as a hardening measure. Instead of crashing the
kernel when encountering such invalid on-disk data, it is safer to abort
the operation gracefully.

This change also improves consistency within fs/ocfs2/alloc.c. Other
functions such as ocfs2_rotate_leaf() and ocfs2_update_edge_lengths()
already guard against this specific condition (next_free == 0) to avoid
invalid access.

This also aligns with recent fixes like Commit 44acc46d182f ("ocfs2:
avoid NULL pointer dereference in dx_dir_lookup_rec()"), which addressed
issues caused by empty extent lists.

I will update the commit message in the next version to explicitly state
that this is a hardening measure against on-disk corruption.

- Jiasheng

>> 
>> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@...il.com>
>> ---
>>  fs/ocfs2/alloc.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>> 
>> diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
>> index 58bf58b68955..b15c6f751d99 100644
>> --- a/fs/ocfs2/alloc.c
>> +++ b/fs/ocfs2/alloc.c
>> @@ -2327,6 +2327,10 @@ static int ocfs2_rotate_requires_path_adjustment(struct ocfs2_path *left_path,
>>  
>>  	left_el = path_leaf_el(left_path);
>>  	next_free = le16_to_cpu(left_el->l_next_free_rec);
>> +
>> +	if (unlikely(next_free == 0))
>> +		return 0;
>> +
>>  	rec = &left_el->l_recs[next_free - 1];
>>  
>>  	if (insert_cpos > le32_to_cpu(rec->e_cpos))
>> -- 
>> 2.25.1
>>