From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 71E54399024 for ; Thu, 26 Feb 2026 09:12:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772097166; cv=none; b=NPkMfQsGUpPFY2IUYFaXbVHsEj5+6Hn+7dRHabZ7KKMg6VwTS2hCcqgKHPUHPn9I7f2IMCGOEoLrLQ3CAnKVksyY4xAv6S0x2aRJrwosy5J58g3BaVEfthXEIq9sKEnAiWVGciUJofefQUp8ykGzFmvhd8Inz9F8JlgUHvkuVBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772097166; c=relaxed/simple; bh=P9zHJf9hw6gJ90Fg9rBaSKXTKmeOIQaBE4keCcx0Khk=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=lWx/DGi7CRxIoaBnYJvrY52HvWZFxfxlpX031Wbqr6wxYZcvBC4uugavRWRcGnBCkaxIHP7ZZLhol1dr1PYNMaXG/0QpJQl1ZZteFgmL3zAepe55Ou1cnkX0b64tyS+mTBA3jH7mDxiBtTxERXFlx+xrOIJ1pfgx4xeoaL8uj2Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Sx06D2iU; arc=none smtp.client-ip=209.85.210.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Sx06D2iU" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-82310b74496so354077b3a.3 for ; Thu, 26 Feb 2026 01:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772097164; x=1772701964; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=d3xiZQpdXnuPlqMuEGUu9XiIu4NW4DeVOIeIkTCMbGI=; b=Sx06D2iUirtyCFzxIKFsyigU+GsTN8t3kP15926+TfyLnC/jNqRvu9wmSxRgklnWqH E1KwCmjo/Jh6CZZWxsPapmeIw3esmFOW3kKS+laPIquTpivrVbwFk8+BugnoXz9i4U2C sFa8/SDkC45R5Gd1e8XBK4hA/BbzoRmCP3ndoyhKPJ5j6gnqQ4xf6+5QtMgpRCdowLxM Sj/2ABfUI8I3a225T1F8zj7RpiCffkSUEGOdLL222aW7Ikb3IkuBM1HbnZk8zgPHIwEH Yx8HPKWot/rwjmSS4IFCDSi47jSLbuYsJnkAS5+KCE6HdgQ+70Z20WmenwE98ypZHBIT DX5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772097164; x=1772701964; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=d3xiZQpdXnuPlqMuEGUu9XiIu4NW4DeVOIeIkTCMbGI=; b=FMCG2xfyNkai1aKq8Um+lgVfu5zhpA48p5zWJoN4NZ0JwnMYCwZLWLtoYltouOVmcQ 2VhDSEOmoVla5V3dQ8dc2izJUEAej1l8royMEtQbUajE2359alCZUcYOM7wKNmOVHtLt 6zROt3ii29qNrwAmg5oA3RbQahdWq9mG3Fe7ujibMk2XFxxSNBqKDlvc69/qiL0xx1S+ PfShOIlf312I++rEqkKTzGMf4zimud3BXtZ64jRU0VNmqcr6GWkXLn7/r+G3JutMIVVk SFrBIocTaf9dJdfk5xFLYZqJ97FLRdevF4UcDe1M9g8ExG4l70ZkAE02UCWYAgsmGcaF Mnng== X-Forwarded-Encrypted: i=1; AJvYcCW++dbA4Ip0C3n1y0iiVYdLz7QVT1yNe7z65q6NzcIJAxiBbQPjr8mQnrSz7QS7vT1Y25kSRUSUCE+qwnI=@vger.kernel.org X-Gm-Message-State: AOJu0YzA7jj6kKVvQJW+ZvHVaAsEItcKxWJu5gs36ympKXh5ccr845PC vN20c9P5tflAqzuVtE4n7NCL91RPm/q1wekjeZb+3wAsYhP1Q2I487VC X-Gm-Gg: ATEYQzwltMFDTKS9XzS96VqKQ70QUwJc2Hx9bcmIma18uFRaq1PBk5XRFsPkobW0evd srjD/vXCSj0R0cIzfiEvg8aHcmPc0GdqNXNCLQP1sFs/p5igLJTdt2b97wGgEtLbEjsbMQueztw cwODJusClbLtFuKGNdB2BZcg16z0kG+ppUOc0n4yz5NOg1wwJxVz+nWid2Q+uFVA6R3aWnIY2vc fDBoD2mt5w7XBT9al2Bb53whu1JK1zQOlU9r3V6oYTpUlihdWlTl3N9VinScm5jJo0Cqocl9sam PlbXmfmPRiZ/gRIyQXk1u7aaY78wgP9Fg/COrO+yzk6sQ9JWJuKLiVSvB1JeW3NQakd0mUGe4v8 8Icc3TxJpp6EFzidGRiGdfd7BPpCWHowyNff7aqYlvXU2Y9CikxZM5SXFEGxSvXZ+4dxcXTNNAa CbCoimzJ7XwDBWqvdIkFyeoNk23d5BfYkCbY5tjBHtxrR5HWk= X-Received: by 2002:a05:6a21:6e04:b0:366:14af:9bbb with SMTP id adf61e73a8af0-39545fe2f9amr17549760637.69.1772097163597; Thu, 26 Feb 2026 01:12:43 -0800 (PST) Received: from localhost.localdomain ([223.185.37.137]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c70fa5e4aafsm1457484a12.4.2026.02.26.01.12.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 01:12:43 -0800 (PST) From: Shardul Bankar X-Google-Original-From: Shardul Bankar To: slava@dubeyko.com, glaubitz@physik.fu-berlin.de, frank.li@vivo.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Cc: janak@mpiricsoftware.com, janak@mpiric.us, shardulsb08@gmail.com, Shardul Bankar Subject: [PATCH v4 0/2] hfsplus: validate btree bitmap during mount and handle corruption gracefully Date: Thu, 26 Feb 2026 14:42:33 +0530 Message-Id: <20260226091235.927749-1-shardul.b@mpiricsoftware.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi, syzbot reported an issue with corrupted HFS+ images where the b-tree allocation bitmap indicates that the header node (Node 0) is free. Node 0 must always be allocated as it contains the b-tree header record and the allocation bitmap itself. Violating this invariant leads to allocator corruption, which cascades into kernel panics when the filesystem attempts to allocate blocks. This series prevents the kernel from trusting a corrupted state by validating the Node 0 bitmap at mount time, allowing the filesystem to safely fall back to read-only mode for data recovery. Patch 1 is a preparatory cleanup. It extracts the map-record traversal logic from hfs_bmap_alloc() into a generic helper. This deduplicates the code, introduces strict node-type validation to prevent misinterpreting corrupted nodes, and provides the abstraction needed for the mount-time check. Patch 2 implements the actual Syzkaller fix. It uses the new helper during hfs_btree_open() to verify that Node 0 is marked allocated. If it isn't, or if the map record itself is structurally invalid, it forces the superblock to SB_RDONLY. Link: https://lore.kernel.org/all/54dc9336b514fb10547e27c7d6e1b8b967ee2eda.camel@ibm.com/ v4: - Split the changes into a 2-patch series (Refactoring + Bug Fix). - Extracted map node traversal into a generic helper (hfs_bmap_get_map_page) as per Slava's feedback, replacing manual offset/page management. - Added node-type validation (HFS_NODE_HEADER vs HFS_NODE_MAP) inside the helper to defend against structurally corrupted linkages. - Replaced hardcoded values with named macros (HFSPLUS_BTREE_NODE0_BIT, etc). - Handled invalid map offsets/lengths as corruption, continuing the mount as SB_RDONLY instead of failing it completely to preserve data recovery. v3: - Moved validation logic inline into hfs_btree_open() to allow reporting the specific corrupted tree ID. - Replaced custom offset calculations with existing hfs_bnode_find() and hfs_brec_lenoff() infrastructure to handle node sizes and page boundaries correctly. - Removed temporary 'btree_bitmap_corrupted' superblock flag; setup SB_RDONLY directly upon detection. - Moved logging to hfs_btree_open() to include the specific tree ID in the warning message - Used explicit bitwise check (&) instead of test_bit() to ensure portability. test_bit() bit-numbering is architecture-dependent (e.g., bit 0 vs bit 7 can swap meanings on BE vs LE), whereas masking 0x80 consistently targets the MSB required by the HFS+ on-disk format. v2: - Fix compiler warning about comparing u16 bitmap_off with PAGE_SIZE which can exceed u16 maximum on some architectures - Cast bitmap_off to unsigned int for the PAGE_SIZE comparison to avoid tautological constant-out-of-range comparison warning. - Link: https://lore.kernel.org/oe-kbuild-all/202601251011.kJUhBF3P-lkp@intel.com/ Shardul Bankar (2): hfsplus: refactor b-tree map page access and add node-type validation hfsplus: validate b-tree node 0 bitmap at mount time fs/hfsplus/btree.c | 123 ++++++++++++++++++++++++++++++------- include/linux/hfs_common.h | 3 + 2 files changed, 104 insertions(+), 22 deletions(-) -- 2.34.1