From nobody Sun Feb 8 01:31:09 2026 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 EE4361AA1C1 for ; Fri, 17 Jan 2025 22:09:58 +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=1737151799; cv=none; b=c24K+Vo6+EVsePXzEWR9RAjjetiym043EH6lDjCQa6JO4Y2piGHotdZngMtkLgztUkowsJlMrJFL8KAYu+ERboMgzfUv99h6Wkx+eWGUVSwGP/KLYZyFstNMMimA7L+a8ITUuhwSlR1jJSmVHj0Y5iEpU42rb18TDXD86WrCVLA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737151799; c=relaxed/simple; bh=6kwFPoW5Q3/lJJtdP7PXibA49Ojd6NyYhUfsuy/O3yU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=hNFL5EAIfPsl33U0INh3ZwTBwkeCauv5IWCH3vVAxl2w2nDw2gEG0YSYqf1EjoV2Or6sNRyLtZ2CVF5Bs1nJyYOcw8YqAmbrOXXxyhhso3jz/c8EtWxd0NoEM/ArxEWWwDDGk1CfD/32zfiWz5SKoh0+S8X8atEnUVNrWsUybwk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CxTp6Rlh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CxTp6Rlh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AB6EC4CEDD; Fri, 17 Jan 2025 22:09:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737151798; bh=6kwFPoW5Q3/lJJtdP7PXibA49Ojd6NyYhUfsuy/O3yU=; h=From:To:Cc:Subject:Date:From; b=CxTp6Rlh1IISITakubsmYhzSmS0QSrHW0D+H52FbQ9ZBs+r0dyx6khNZgvgheHCgJ MiMN1eBGYWXRfdl/kgXETtLi80tGcHsS4X9evPTq+7uiRUMdqRV8zTBtCRjQP8BM5G eV2kW5FS26N1PAhALDDvZro6tUihsHcLCtiKGSmlmnq5doWQKHGm5DJolqVGeCRy9Z 2UMhas3cua7fJqEhi+kC9PDi6dlwZAiv8bSFzz2CF26cCfZH9GgF5MBZWKUHCSGuKY K48oRi6nBAsTKZAaUto0S+apgksJVbf3s7IcojdKcj8541G5BHdetHg0HsLL2XH6xL TvpHMNUSGvquA== From: Jaegeuk Kim To: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Cc: Jaegeuk Kim Subject: [PATCH] f2fs: avoid trying to get invalid block address Date: Fri, 17 Jan 2025 22:09:55 +0000 Message-ID: <20250117220955.2482817-1-jaegeuk@kernel.org> X-Mailer: git-send-email 2.48.0.rc2.279.g1de40edade-goog Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In f2fs_new_inode(), if we fail to get a new inode, we go iput(), followed = by f2fs_evict_inode(). If the inode is not marked as bad, it'll try to call f2fs_remove_inode_page() which tries to read the inode block given node id. But, there's no block address allocated yet, which gives a chance to access a wrong block address, if the block device has some garbage data in NAT tab= le. We need to make sure NAT table should have zero data for all the unallocated node ids, but also would be better to take this unnecessary path as well. Let's mark the faild inode as bad. Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu --- fs/f2fs/namei.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 57d46e1439de..a278c7da8177 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -341,6 +341,7 @@ static struct inode *f2fs_new_inode(struct mnt_idmap *i= dmap, trace_f2fs_new_inode(inode, err); dquot_drop(inode); inode->i_flags |=3D S_NOQUOTA; + make_bad_inode(inode); if (nid_free) set_inode_flag(inode, FI_FREE_NID); clear_nlink(inode); --=20 2.48.0.rc2.279.g1de40edade-goog