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 EF1D12F7AAB for ; Tue, 26 May 2026 02:19:51 +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=1779761993; cv=none; b=TE8l2ZWli2bg0Ep6Y6fINb48Yok3YIKD2m3zeP2ahlP4JZXDWPLXBlTwX5TsfCvbQjddeNhV0FirM4OGKdWg79wLvudCvMz8WBORWzfOASGP8zdw0ICkKxePtOn3a/fHJrWkuVbqJjbpohSrH/XU/GdO0InK6aQeVaIb9ZZwM0E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779761993; c=relaxed/simple; bh=Jetp82OYqXjVhoairCTHTmQiV94zQ80UEtFhj4GcW5g=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=L0LEDH5My3nqRpgAfLRd80XGcMCYxRYkL24up10dC0hUzsvGxdiyj41pSvRK4RDTRs6XWfoCKtXFsmNz9UPZweU6OepSy8RfsQ8UNCpETa2Uu/+tIm9SpxUNBAdOwGmnADmXsgNOu8aEd4SkedDRLnXxlANxJqZAODNpm+LvzYo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VjCCO9PQ; 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="VjCCO9PQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E1B31F000E9; Tue, 26 May 2026 02:19:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779761991; bh=BKpEdmsuhVEwihwghwAM1HMmKXBWA3sbZTpWp49l25M=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=VjCCO9PQJJyT6Wj1Z3TiGcXhxEVRv4p0J4VKlSAyJgv2z34EuC6PGcLoDU6qrAbuX 2kPSsoVIDoI3O0+NWrUIianeQqlh4lNXaCiZTrrXo8Ie0bV9B+E2cRHmNlCOEj57wm V2SbQtwUwTypCQOxqECQ5ksVMcK5LU7J2+UMMhfgviXVm4GwEZjyIQ5yn7MvKDOKQF z39ERwh7sK2cwmCFg7MjklvsTiLtyvpvVEdI5psXfWtYQ/0oUJyy2F9fY83yd5RolV 7ZDu7YaF88yvZD5tSgI2f7UZbQYDaXte/ICdGb+T+FDrjLenAEJiEB67zKB4XC8Lke S2IetpFjW7s9g== Message-ID: <86c2f79d-ee26-4009-8051-82d25abf6d7b@kernel.org> Date: Tue, 26 May 2026 10:19:48 +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, 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 , jaegeuk@kernel.org References: <20260525114621.571845-1-qiwenjie@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260525114621.571845-1-qiwenjie@xiaomi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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);