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 6724A3F871C for ; Wed, 10 Jun 2026 11:04:39 +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=1781089481; cv=none; b=GUnLiIUtH2xTUWBompTM14EkvZoahysWLPLgZAYET4NVP3KRk9JrlAiiQrjAWYIn8mQNErnwi2SO4V5AbT7BPcNnxt/pPHzSApuvIYjW//zuTv4TNSeGQIeRYJV1c3qmlVT5K6BZ8RzSS7vZNeFHSMqMXRfPRu8J1EnXxikLcf0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781089481; c=relaxed/simple; bh=apyUGQ9++5jBeJUzmNNmYlBaBNUPMPWCsm8Che8zgn4=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=qg+sW1BmSrPSrmAh4AhR5+dFtemItuUw6c+Y6xYNyBrAulVgyRLRYlU8dVR6RXq3n/d/n+bMI4+MUIsmYooXAUT1U3un/4hwnmoYUjUsenyeZpUy1lwDKp9nQo8q3nFdKdQ+CdDuhK3RgP/hcGjnIEW26KsPCgAUlTb5VJcOMlo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O+CvwWUz; 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="O+CvwWUz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2542E1F00893; Wed, 10 Jun 2026 11:04:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781089478; bh=qDnEYmAdmlpsmH2sm4DrOO0rKrq9gD2IC9aUjhiNxEE=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=O+CvwWUzum3RKmzSmuTI4aemkK+cbprnF2SbVMUOjtWocIA7D2+wcodX7arJnKBp3 9gEG+AZwuF+P5pmQhqTyrO25BolDdMj0VfeqXkfFme10GoBZo2v9Ib6OLDEjEUSld5 vkKdrT67ed9oKvsTOUJLH4YmyWyK428PEJq0ve8nrTSjCo0wep++R5HrP7rIDiDTH0 IjX85oaZxD/FIxIvpvQ1s9riOHvgUASuQIM4INn8K0guyeIRUgar/KRMBvHABwkCJc vywMLJPX6vkRbFb47Ft4CwShL63Mqjip2R65ftZ7DUhU9mXtnIzch2j86HlAXD8PJ7 ALU7DvvVTko7Q== Message-ID: Date: Wed, 10 Jun 2026 19:04:35 +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, stable@kernel.org, qiwenjie@xiaomi.com Subject: Re: [PATCH v2] f2fs: validate orphan inode entry count To: Wenjie Qi , jaegeuk@kernel.org References: <20260526053557.1096229-1-qiwenjie@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260526053557.1096229-1-qiwenjie@xiaomi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/26/26 13:35, 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. > > Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be > recorded in the superblock s_errors[] field. This gives fsck a persistent > hint even though mount-time orphan recovery failure may leave no chance to > persist SBI_NEED_FSCK through a checkpoint. > > Fixes: 127e670abfa7 ("f2fs: add checkpoint operations") > Cc: stable@kernel.org > Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Thanks,