From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA822375F99 for ; Wed, 1 Apr 2026 03:49:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775015349; cv=none; b=cNT/2/DK+/IcUnu08SPlLAoIIhz8S3EIUwplxL83H+0qtFFVUkHxBC4GJ/22E20Jl6VtkUJ1kDoBk8PUH7zcDXmtiSdQiLUIxF9qe5go2scSiQ6/MtfX62VUN8D11xKHsPsb2FqX+Pd7fK/oYNzjaQIPN2xIzX19wCHAx7G42AI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775015349; c=relaxed/simple; bh=/nHOpsAURJzhtSbmSOKGrTd4oeMuwm3/3LSNpRNa4g8=; h=Date:To:From:Subject:Message-Id; b=cHpYQNbaa9EhqeOMmTExIr1GCi0EBK5YPytxxmqgJOMevi3ttplFqUnyrXm9131z/oCeZ3agoXvL6q52uZN4Wn4G5ypSeGvyPslpzBDYp6qe64zMyVG8l5TE/v9a7whIBgaAGyGev2ALwrNK1flAHOBEpp4Zv5pXKq3lwSQ65+c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=sD0qCh43; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="sD0qCh43" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2937CC116C6; Wed, 1 Apr 2026 03:49:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1775015349; bh=/nHOpsAURJzhtSbmSOKGrTd4oeMuwm3/3LSNpRNa4g8=; h=Date:To:From:Subject:From; b=sD0qCh43XjBTIQbkyOZBkxwSFsQfrkMzw9VvOD/i2nwroGl0gNJwXmhVjc6vzc+rX /PnNxBbEznYWTDmOA2ziFua7nPOUTbQVcf9EBJGAh89M9oe/9EgwkDvpaWVhfqCXhQ +6i8sIify8uIChIfVYebCxOBZO0BlDxkZOoQUpwM= Date: Tue, 31 Mar 2026 20:49:08 -0700 To: mm-commits@vger.kernel.org,piaojun@huawei.com,mark@fasheh.com,junxiao.bi@oracle.com,joseph.qi@linux.alibaba.com,jlbec@evilplan.org,heming.zhao@suse.com,gechangwei@live.cn,gality369@gmail.com,akpm@linux-foundation.org From: Andrew Morton Subject: + ocfs2-validate-bg_list-extent-bounds-in-discontig-groups.patch added to mm-nonmm-unstable branch Message-Id: <20260401034909.2937CC116C6@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: ocfs2: validate bg_list extent bounds in discontig groups has been added to the -mm mm-nonmm-unstable branch. Its filename is ocfs2-validate-bg_list-extent-bounds-in-discontig-groups.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/ocfs2-validate-bg_list-extent-bounds-in-discontig-groups.patch This patch will later appear in the mm-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: ZhengYuan Huang Subject: ocfs2: validate bg_list extent bounds in discontig groups Date: Wed, 1 Apr 2026 10:16:22 +0800 [BUG] Running ocfs2 on a corrupted image with a discontiguous block group whose bg_list.l_next_free_rec is set to an excessively large value triggers a KASAN use-after-free crash: BUG: KASAN: use-after-free in ocfs2_bg_discontig_fix_by_rec fs/ocfs2/suballoc.c:1678 [inline] BUG: KASAN: use-after-free in ocfs2_bg_discontig_fix_result+0x4a4/0x560 fs/ocfs2/suballoc.c:1715 Read of size 4 at addr ffff88801a85f000 by task syz.0.115/552 Call Trace: ... __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 ocfs2_bg_discontig_fix_by_rec fs/ocfs2/suballoc.c:1678 [inline] ocfs2_bg_discontig_fix_result+0x4a4/0x560 fs/ocfs2/suballoc.c:1715 ocfs2_search_one_group fs/ocfs2/suballoc.c:1752 [inline] ocfs2_claim_suballoc_bits+0x13c3/0x1cd0 fs/ocfs2/suballoc.c:1984 ocfs2_claim_new_inode+0x2e7/0x8a0 fs/ocfs2/suballoc.c:2292 ocfs2_mknod_locked.constprop.0+0x121/0x2a0 fs/ocfs2/namei.c:637 ocfs2_mknod+0xc71/0x2400 fs/ocfs2/namei.c:384 ocfs2_create+0x158/0x390 fs/ocfs2/namei.c:676 lookup_open.isra.0+0x10a1/0x1460 fs/namei.c:3796 open_last_lookups fs/namei.c:3895 [inline] path_openat+0x11fe/0x2ce0 fs/namei.c:4131 do_filp_open+0x1f6/0x430 fs/namei.c:4161 do_sys_openat2+0x117/0x1c0 fs/open.c:1437 do_sys_open fs/open.c:1452 [inline] __do_sys_openat fs/open.c:1468 [inline] ... [CAUSE] ocfs2_bg_discontig_fix_result() iterates over bg->bg_list.l_recs[] using l_next_free_rec as the upper bound without any sanity check: for (i = 0; i < le16_to_cpu(bg->bg_list.l_next_free_rec); i++) { rec = &bg->bg_list.l_recs[i]; l_next_free_rec is read directly from the on-disk group descriptor and is trusted blindly. On a 4 KiB block device, bg_list.l_recs[] can hold at most 235 entries (ocfs2_extent_recs_per_gd(sb)). A corrupted or crafted filesystem image can set l_next_free_rec to an arbitrarily large value, causing the loop to index past the end of the group descriptor buffer_head data page and into an adjacent freed page. [FIX] Validate discontiguous bg_list.l_count against ocfs2_extent_recs_per_gd(sb), then reject l_next_free_rec values that exceed l_count. This keeps the on-disk extent list self-consistent and matches how the rest of ocfs2 uses l_count as the extent-list bound. Link: https://lkml.kernel.org/r/20260401021622.3560952-1-gality369@gmail.com Signed-off-by: ZhengYuan Huang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton --- fs/ocfs2/suballoc.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) --- a/fs/ocfs2/suballoc.c~ocfs2-validate-bg_list-extent-bounds-in-discontig-groups +++ a/fs/ocfs2/suballoc.c @@ -197,6 +197,31 @@ static int ocfs2_validate_gd_self(struct 8 * le16_to_cpu(gd->bg_size)); } + /* + * For discontiguous block groups, validate the on-disk extent list + * against the maximum number of extent records that can physically + * fit in a single block. + */ + if (ocfs2_gd_is_discontig(gd)) { + u16 max_recs = ocfs2_extent_recs_per_gd(sb); + u16 l_count = le16_to_cpu(gd->bg_list.l_count); + u16 l_next_free_rec = le16_to_cpu(gd->bg_list.l_next_free_rec); + + if (l_count != max_recs) { + do_error("Group descriptor #%llu bad discontig l_count %u expected %u\n", + (unsigned long long)bh->b_blocknr, + l_count, + max_recs); + } + + if (l_next_free_rec > l_count) { + do_error("Group descriptor #%llu bad discontig l_next_free_rec %u max %u\n", + (unsigned long long)bh->b_blocknr, + l_next_free_rec, + l_count); + } + } + return 0; } _ Patches currently in -mm which might be from gality369@gmail.com are ocfs2-validate-bg_list-extent-bounds-in-discontig-groups.patch