From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (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 F31A172614 for ; Tue, 4 Nov 2025 01:48:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762220931; cv=none; b=nkPv73WOAsw4UMzJnJeirVnR4aDUGpc3UMYSxUbk4ymNvNiTjD3NmzeVjRdGuQwoL/aeQ3stiuDjZGJAdSh3gfpckSCLeWMxHFt8KDeh2GzxZQ/X/ux+AoQXuKsaJ2SrCW/CIIscRmXRPppnjalbJ5fy7stibF+FV6Wjatxl2Go= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762220931; c=relaxed/simple; bh=8n7yRExyFgHYfUULPtG7ZIubacmLiDD6ZcsL4aI2anM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QG/z3rqP/g5MSHOmrHxnG5R9S/e6TDpayShnAvK+1g2gA/GiXhQcQRtP8g7JgqxZi4tkuFupTW77l/VQsXmzu7O205PwfIz+z5RTSyk1Tv/Pgf3HwGU9mL2QykVCZCBKMQTVg67GMtV8iZFYCRAr80+Upsl322GficZcs9y45zo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gvernon.com; spf=pass smtp.mailfrom=gvernon.com; dkim=pass (2048-bit key) header.d=gvernon.com header.i=@gvernon.com header.b=i1d9XUag; arc=none smtp.client-ip=91.218.175.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gvernon.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gvernon.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gvernon.com header.i=@gvernon.com header.b="i1d9XUag" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gvernon.com; s=key1; t=1762220927; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OeOQKsQrYLAJRjnO5Q4cmqKi/VkAf2NQPTMDZnSIUtg=; b=i1d9XUagKKoN86iEgNvJzl+vyvt85A0WdS3Q4XMKKTWF2KV5zGKKNNxZT+CoPX7e2Bunpz Amc7OcbtUwW2EOvIkLmEoetFvGeGzZPsOXWW14deax+VsHJx7bO+0R4q8pM430KaoqjomV UGTTXo0Ntf/+ophro8UJ0BI9qh5oiIaeeoQZSF1vHOHBcq+JnfFW1zdV7HRq8xIRhNuqkr lcX7xRRN4C4jwGvvtEAvAD/AvTqqFLW7NtLZm4XgfHTD7LHLAovUSwEY/vnB2kQbUmSybk pn3+2YNwUG3mpuQuPF0sw2zZ3JMvr0gkHb3NDFSrg4WSUuRxLxYYmfdl0Y0Wug== From: George Anthony Vernon To: slava@dubeyko.com, glaubitz@physik.fu-berlin.de, frank.li@vivo.com, linux-fsdevel@vger.kernel.org, skhan@linuxfoundation.org Cc: George Anthony Vernon , linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linux.dev, penguin-kernel@i-love.sakura.ne.jp Subject: [PATCH v2 0/2] hfs: Validate CNIDs read from filesystem Date: Tue, 4 Nov 2025 01:47:35 +0000 Message-ID: <20251104014738.131872-2-contact@gvernon.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel-mentees@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Changes from V1->V2: - is_valid_cnid prototype now takes u32 and u8 types - Add fsck advice in dmesg - Replace make_bad_inode calls in hfs_read_inode with gotos - Reuse same check in hfs_write_inode - Disallow HFS_POR_CNID, HFS_BAD_CNID, and HFS_EXCH_CNID - Add Tetsuo's patch to mine and make it a patch series This patch series contains two patches which work together to prevent bad catalog records from being read. Previously it was possible for a malformed HFS filesystem image to reach a BUG() in writeback. I propose to fix this by verifying that CNIDs are allowed ones when constructing an inode in hfs_read_inode(). Tetsuo Handa's additional check in hfs_fill_super makes sure the root inode's CNID is correct, handling an edge case where the records' directory CNID > 15. I think we should continue returning BUG() in hfs_write_inode() because it is a filesystem implementation error if we ever allow an inode to be constructed from a bad CNID. Now we properly guard our reads in hfs_read_inode(), records with bad CNIDs should not get so far as to initialise inodes which are queued for writeback. I'm suggesting to disallow HFS_POR_CNID because there is no 'real' record with that CNID or corresponding file, it doesn't make sense to present an inode for it to the VFS when it exists only as a dummy reference in our internal btree. Similarly I'm suggesting to disallow HFS_BAD_CNID and HFS_EXCH_CNID because not only are they for internal use, but we also do not implement bad blocks or exchange file functionality in the Linux driver. Thank you to Slava and Tetsuo for the feedback on V1. George Anthony Vernon (2): hfs: Validate CNIDs in hfs_read_inode hfs: Update sanity check of the root record fs/hfs/inode.c | 67 +++++++++++++++++++++++++++++++++++++++----------- fs/hfs/super.c | 2 +- 2 files changed, 54 insertions(+), 15 deletions(-) -- 2.50.1