From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 8D68437BE71 for ; Mon, 3 Aug 2026 07:46:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785743173; cv=none; b=de7gQJUbgki0aF90lXwIAuaZDLFH3cIawqqSFd8D5IhfQkjP12MiZ+jgLLfymuxxHfScx+RwO7vkQlIN8UtxU2DpII7UdPnneTd47rkl9LgWoA8ZoR51NFDtWNZ7x2XSL39QbU97JI0gvPuccsr1p1/AZHSE2x2TS7leMSiPU40= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785743173; c=relaxed/simple; bh=k6GFI5ufxHsFdwE6+cnAcbRXprsUSlhWGJuXPDB54rI=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=IdsXgoPt4O6Mpk8m72aPdWfJ3ebxmrp78zSxKIpaOQQOd6IiMYqFdOgd4XkfCm9Rq+c6qY0wE6z3Tp3bREG3UPtWjrgUqaF1pEdajv4rKVxo/Jt0lWP1qmyeZRjGihtYDKVXXWqRx2YcPly12GYmVeP9WKjBWZJSF9WwQnU5S1c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=L4rxjS9l; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="L4rxjS9l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA86F1F000E9; Mon, 3 Aug 2026 07:46:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785743172; bh=n+a3AaSWuqxbjv9Ky++6rdkhgJLQbuwaNSpxDI5Tj1s=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=L4rxjS9lcJCuwNJdInBtJPlQHcX7PC2mcE0PsM+NYtux8wpSO8rW89R/2xv6ajC++ 8MCKEWKdUr9QtqvDuVDNtPB5tnAhnEsQ2Imy08ZBvu+cDayp2d0/EUOnBL5UAik0PO akMEzFEwjoOskuCrSEo9SUNzCdZEWbuThHyZ/T2gmbHAhWro9/WnVnsUb+DClmgw9b pEl8AgngbK2YmWaPN8m8i6x/PHjKVuJ9Lkpcr6doGcs74nnp+zEJsGxaXU6hHLnHjU 1ry39SDE+75kDGo+wYYiF44qAKjjpG1skg/HnoMmtVikiKyZ1jDjx8F+8Kr29bZ3XK oeCn+0O2PewNQ== Message-ID: <23ec02b1-aff7-40f2-80be-7cb904cb9acb@kernel.org> Date: Mon, 3 Aug 2026 15:46:08 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, Daeho Jeong Subject: Re: [f2fs-dev] [PATCH] fsck.f2fs: sanitize invalid segment type during block update To: Daeho Jeong , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com References: <20260723200218.2528887-1-daeho43@gmail.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260723200218.2528887-1-daeho43@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/24/26 04:02, Daeho Jeong wrote: > From: Daeho Jeong > > If an invalid segment type (type < 0 || type >= NO_CHECK_TYPE) is read > from SIT during block update, update_block() now validates the type, > reports corruption, and falls back to a valid active curseg type when > fix_on is enabled. find_next_free_block() also validates want_type to > prevent out-of-bounds accesses. > > Signed-off-by: Daeho Jeong > --- > fsck/mount.c | 5 +++++ > fsck/segment.c | 14 ++++++++++++++ > 2 files changed, 19 insertions(+) > > diff --git a/fsck/mount.c b/fsck/mount.c > index 85ed404..ce96a44 100644 > --- a/fsck/mount.c > +++ b/fsck/mount.c > @@ -3059,6 +3059,11 @@ int find_next_free_block(struct f2fs_sb_info *sbi, u64 *to, int left, > u64 end_blkaddr = (get_sb(segment_count_main) << > get_sb(log_blocks_per_seg)) + get_sb(main_blkaddr); > > + if (want_type < 0 || want_type >= NO_CHECK_TYPE) { > + ERR_MSG("Invalid segment type %d for block allocation\n", want_type); Use ASSERT_MSG() instead? it can set c.bug_on. > + return -EINVAL; > + } > + > if (c.zoned_model == F2FS_ZONED_HM && !new_sec) { > struct curseg_info *curseg = CURSEG_I(sbi, want_type); > unsigned int segs_per_zone = sbi->segs_per_sec * sbi->secs_per_zone; > diff --git a/fsck/segment.c b/fsck/segment.c > index 46dc747..1ae90bf 100644 > --- a/fsck/segment.c > +++ b/fsck/segment.c > @@ -779,6 +779,20 @@ int update_block(struct f2fs_sb_info *sbi, void *buf, u32 *blkaddr, > se = get_seg_entry(sbi, GET_SEGNO(sbi, old_blkaddr)); > offset = OFFSET_IN_SEG(sbi, old_blkaddr); > type = se->type; > + if (type < 0 || type >= NO_CHECK_TYPE) { > + MSG(0, "[FSCK] Invalid SIT segment type %d at blkaddr 0x%"PRIx64"\n", > + type, old_blkaddr); > + c.bug_on = 1; Ditto, > + > + if (!c.fix_on) > + return -EINVAL; > + > + int fixed_type = IS_NODESEG(type) ? CURSEG_HOT_NODE : CURSEG_HOT_DATA; > + > + FIX_MSG("Correct invalid segment type %d -> %d for blkaddr 0x%"PRIx64"\n", > + type, fixed_type, old_blkaddr); > + type = fixed_type; How about fixing se->type directly, otherwise we may fix this in local stack repeatly whenever encounter this buggy se->type. Please refer to fix_section_type(). Thanks, > + } > se->valid_blocks--; > f2fs_clear_bit(offset, (char *)se->cur_valid_map); > if (need_fsync_data_record(sbi))