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 CB27D29D29F for ; Tue, 26 May 2026 11:03:57 +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=1779793438; cv=none; b=sG3W93xv1SCMiI4p0/a+aPd9pvGbx8kAgdtpXFfQSXnD1v/1Q9vXIqUbDi/zsL22KYf+78xJL9F3fN5v6v3SGp+82c68GB3/dfX6yHtSPBRiBJXP8AnBM3GHwd4owRnrpKB+00AMm2PDpwvZUkEn4uIuqOYpPUsCzyDkbKISVug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779793438; c=relaxed/simple; bh=ywJEGogJ8NHyvaLIp/KFNc38yRIXk9MjS4FRUWCrkb0=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=md1GMjKIunI4cv0gEdWIREfAlMY94kG5lewSkfw1xabfyZA42YqhPT0HKtpzNrw4mJdoM8XJNxeHBrpJuFs9EgOJFgr3SMOgU3bXagHUG4pwk/u7kzL2JAZVhpsvQ4uM9C0s9bAsyv3yMlPA5cyq64b4Kluem5gzIreYkS8spr4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oFt3gYc+; 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="oFt3gYc+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 349C91F000E9; Tue, 26 May 2026 11:03:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779793437; bh=vAxUtDoM7RbTHTVpsx+YtE9nb7EE2N1eSnXuvU6KUtU=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=oFt3gYc+pgLyzuSVtuQC+HQHbHlseaOtrKBvHh4yTcTgsL9smYx+vxh9Z8Tz7C1ca xzHwNJfxF3MU2trQZP6+rYwufLaibYRi2eUvW02LF+d7S9Muj0m6wvvk758CWI0Kq2 HskH5WYILp2gXoq0NNHLU74vSeT19zqgnZh1AiS5Nst7DK9q7s/xLuhUDF/T91Ek2i cLSYmreZZmfoPK4Yf2Irj2f5MxQzGkDZE2Z2MP5croqYAudQ0HP84GggSpBoBh2FWR C3lI2zIP1Q9FrfMMW7TdHmTBjh6m+Zog3AGJKWK6k+0pa6xb2KVyO3e4lMjB3Nfaqm cBTmnddpuRNjQ== Message-ID: <534bc0fc-bb0f-4741-9156-11a66d47f1c3@kernel.org> Date: Tue, 26 May 2026 19:03:54 +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, jaegeuk@kernel.org, chur.lee@samsung.com, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, qiwenjie@xiaomi.com, stable@kernel.org Subject: Re: [PATCH] f2fs: validate orphan inode entry count To: Wenjie Qi References: <20260525114621.571845-1-qiwenjie@xiaomi.com> <86c2f79d-ee26-4009-8051-82d25abf6d7b@kernel.org> Content-Language: en-US From: Chao Yu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 5/26/26 13:38, Wenjie Qi wrote: > Agreed, SBI_NEED_FSCK may not be persisted at this stage. > > I sent v2 to add ERROR_INCONSISTENT_ORPHAN and call f2fs_handle_error() on > invalid orphan entry_count, so the corruption reason can be recorded in > s_errors[] as a persistent hint for fsck. So, it needs another patch to let fsck recognize the new flag? Thanks, > > https://lore.kernel.org/linux-f2fs-devel/20260526053557.1096229-1-qiwenjie@xiaomi.com/T/#u > > On Tue, May 26, 2026 at 10:19 AM Chao Yu wrote: >> >> On 5/25/26 19:46, Wenjie Qi wrote: >>> f2fs_recover_orphan_inodes() trusts the orphan block entry_count when >>> replaying orphan inodes from the checkpoint pack. A corrupted >>> entry_count larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop >>> read past the ino[] array and interpret footer or following data as >>> inode numbers. >>> >>> On a crafted image, mounting an unpatched kernel can drive orphan >>> recovery into f2fs_bug_on() and panic the kernel. Validate entry_count >>> before consuming entries so corrupted checkpoint data fails the mount >>> with -EFSCORRUPTED and requests fsck instead. >>> >>> Fixes: 127e670abfa7 ("f2fs: add checkpoint operations") >>> Cc: stable@kernel.org >>> Signed-off-by: Wenjie Qi >>> --- >>> fs/f2fs/checkpoint.c | 13 ++++++++++++- >>> 1 file changed, 12 insertions(+), 1 deletion(-) >>> >>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c >>> index c00a6b6ebcbd..fc72b69ff769 100644 >>> --- a/fs/f2fs/checkpoint.c >>> +++ b/fs/f2fs/checkpoint.c >>> @@ -943,6 +943,7 @@ int f2fs_recover_orphan_inodes(struct f2fs_sb_info *sbi) >>> for (i = 0; i < orphan_blocks; i++) { >>> struct folio *folio; >>> struct f2fs_orphan_block *orphan_blk; >>> + unsigned int entry_count; >>> >>> folio = f2fs_get_meta_folio(sbi, start_blk + i); >>> if (IS_ERR(folio)) { >>> @@ -951,7 +952,17 @@ int f2fs_recover_orphan_inodes(struct f2fs_sb_info *sbi) >>> } >>> >>> orphan_blk = folio_address(folio); >>> - for (j = 0; j < le32_to_cpu(orphan_blk->entry_count); j++) { >>> + entry_count = le32_to_cpu(orphan_blk->entry_count); >>> + if (entry_count > F2FS_ORPHANS_PER_BLOCK) { >>> + f2fs_err(sbi, "invalid orphan inode entry count %u", >>> + entry_count); >>> + set_sbi_flag(sbi, SBI_NEED_FSCK); >> >> Well, at this stage, I guess there is no chance to persist SBI_NEED_FSCK flag, >> what about introduce ERROR_INCONSISTENT_ORPHAN in enum f2fs_error, so that >> we can persist the new bit to provide hint to fsck? >> >> Thanks, >> >>> + err = -EFSCORRUPTED; >>> + f2fs_folio_put(folio, true); >>> + goto out; >>> + } >>> + >>> + for (j = 0; j < entry_count; j++) { >>> nid_t ino = le32_to_cpu(orphan_blk->ino[j]); >>> >>> err = recover_orphan_inode(sbi, ino); >>