From mboxrd@z Thu Jan 1 00:00:00 1970 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 959751D554; Thu, 2 Oct 2025 15:30:31 +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=1759419031; cv=none; b=eqI6gsOx7y5ofAICgK67pXz8+vKvhIfSdUp7Uj7HC3mZEZvedF7q9K/pTaahCxpMd4NvoxnMYRo0phdCCqMyXJ/9yew0+AGfVnRWiPyjPewNyVx1C/AaxyaHvKh2VGEmq3/TtNt8j2Xy5hjvxgkmsZpoF7Qmh2mogJPBsNPF4Eo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759419031; c=relaxed/simple; bh=C7yvcKYpn5ZCbdibL2RHGc/sXOK0wx6KVzxEnwpkyJc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=r/YohEitRiqMLEeV3QeOFBOKw3HX+eqe8M8536RwPt+WtbI47gTvBjTyeNT6Ee7EQPDZxpGR7zTSi0paSZh199BHQe6T6ZKO4AvQZupdIgvU9KtRSx2bs+bsMZKqkUEL4lb4yHvIS9DF+fs2F+tQBBl8HxxwpprMNM1/NZ7xGdU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G9jvvMmq; 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="G9jvvMmq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66C56C4CEF9; Thu, 2 Oct 2025 15:30:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759419031; bh=C7yvcKYpn5ZCbdibL2RHGc/sXOK0wx6KVzxEnwpkyJc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G9jvvMmqJf2rqPvkzvAFNxFRRIysU4iAh4ICtfr6nMBvttEt7VJO6rl8ghepikjKX 8cTvYYOehuCRuHlgMjUUGl5B97kmJqsRDUyG6940gTWSrdjCtGL352W2b6V5Xy7tYA PwzjO/1RwUlUgpEJKK0llixm22bzJaX8Mmh3I4zTWv34uM2DtTcMGkcxjaC2Nnxn0H th4CbREnLnM83EGY1CAX0PguScTigwd2mcHzZO1/WE+RGUK47xNSGIXGyJyl9zg8dX RuDTTVBnDrb1MWr/8eaJ2g5fhDrti9Ym79XXTg4lLDmnSSAIdTQ1b20QJOLYRoznET gb/f6FPDnECcw== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Yangtao Li , Viacheslav Dubeyko , Sasha Levin , linux-fsdevel@vger.kernel.org Subject: [PATCH AUTOSEL 6.17-5.4] hfsplus: return EIO when type of hidden directory mismatch in hfsplus_fill_super() Date: Thu, 2 Oct 2025 11:29:51 -0400 Message-ID: <20251002153025.2209281-4-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251002153025.2209281-1-sashal@kernel.org> References: <20251002153025.2209281-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Yangtao Li [ Upstream commit 9282bc905f0949fab8cf86c0f620ca988761254c ] If Catalog File contains corrupted record for the case of hidden directory's type, regard it as I/O error instead of Invalid argument. Signed-off-by: Yangtao Li Reviewed-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20250805165905.3390154-1-frank.li@vivo.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Based on my extensive analysis, here is my comprehensive assessment: ## Backport Status: YES ## Detailed Analysis ### 1. Historical Context Through git history analysis, I discovered that the `-EINVAL` error code was introduced in **2018 by Tetsuo Handa** (commit 7464726cb5998) to fix a critical syzbot-reported bug where `hfsplus_fill_super()` was returning 0 (success) when detecting invalid filesystem images, causing NULL pointer dereferences. The choice of `-EINVAL` was somewhat arbitrary—the primary goal was to return *any* error instead of 0. ### 2. What This Commit Fixes This commit corrects the error semantics at fs/hfsplus/super.c:527, changing from `-EINVAL` to `-EIO` when the hidden directory's catalog entry has an incorrect type (not `HFSPLUS_FOLDER`). This is filesystem metadata corruption, not invalid user input. ### 3. Code Pattern Analysis Examining the HFS+ codebase reveals a clear pattern: - **-EIO usage**: 27+ instances across super.c, btree.c, xattr.c, dir.c, catalog.c, etc., consistently used for on-disk corruption - **-EINVAL usage**: Used for invalid mount options (options.c) and invalid user-provided arguments - **Line 527 was the exception**: It incorrectly used `-EINVAL` for what is clearly filesystem corruption This pattern is consistent with other filesystems: NILFS2 extensively documents "`-EIO` - I/O error (including metadata corruption)" while reserving `-EINVAL` for invalid arguments. ### 4. Backport Suitability Assessment **Strongly Suitable:** - ✅ **Semantic correctness fix**: Aligns error handling with established kernel patterns - ✅ **Minimal risk**: Single-line change affecting only error code returned - ✅ **No functional changes**: Doesn't alter any logic, just error semantics - ✅ **Improves consistency**: Brings this code in line with rest of HFS+ subsystem - ✅ **Benefits users**: More accurate error reporting for corrupted filesystems - ✅ **Already reviewed**: Reviewed-by: Viacheslav Dubeyko (HFS+ maintainer) - ✅ **No architectural changes**: Confined to error handling - ✅ **No user-space dependencies**: Mount utilities don't depend on specific error codes ### 5. Evidence of Active Backporting The commit has **ALREADY been backported** to stable trees: - Commit 22017d3bff896 shows `[ Upstream commit 9282bc905f0949fab8cf86c0f620ca988761254c ]` - Signed-off-by: Sasha Levin for stable tree inclusion - CommitDate: Sep 30, 2025 (present in linux-autosel-6.17-2) ### 6. Context Within Broader HFS+ Hardening Recent HFS+ commits show active efforts to improve robustness against corrupted/malicious filesystem images: - Multiple KMSAN uninit-value fixes - Slab-out-of-bounds fixes - Removal of BUG_ON() in favor of graceful error handling - Validation improvements for record offsets This commit is part of that broader hardening effort. ### 7. Risk Assessment **Regression Risk: MINIMAL** - Only changes the errno value returned during mount failure - User-space tools (mount, fsck.hfsplus) display different error messages but behavior is unchanged - No security implications—both error codes indicate mount failure - Cannot affect successfully mounted filesystems **Recommendation:** This commit should be backported to all maintained stable kernels where the original `-EINVAL` code exists (approximately since Linux 2.6.x, but practically important for kernels 4.x+). fs/hfsplus/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index 2f215d1daf6d9..77ec048021a01 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -537,7 +537,7 @@ static int hfsplus_fill_super(struct super_block *sb, struct fs_context *fc) if (!hfs_brec_read(&fd, &entry, sizeof(entry))) { hfs_find_exit(&fd); if (entry.type != cpu_to_be16(HFSPLUS_FOLDER)) { - err = -EINVAL; + err = -EIO; goto out_put_root; } inode = hfsplus_iget(sb, be32_to_cpu(entry.folder.id)); -- 2.51.0