mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthias Goergens <matthias.goergens@gmail.com>
To: Viacheslav Dubeyko <slava@dubeyko.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Yangtao Li <frank.li@vivo.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] hfsplus: bound the wrapper and partition-table hops in hfsplus_read_wrapper()
Date: Sat, 26 Sep 2026 16:40:10 +0800	[thread overview]
Message-ID: <20260926084010.569552-3-matthias.goergens@gmail.com> (raw)
In-Reply-To: <20260926084010.569552-1-matthias.goergens@gmail.com>

hfsplus_read_wrapper() rereads the volume header through a bare "goto
reread", following an HFS wrapper's embedded-volume descriptor or, if
the header matches neither signature, the partition-table fallback it
shares with hfs, with no bound on either.  A descriptor or partition
entry with a zero offset leaves part_start where it was, and the mount
loops forever.

TN1150 ("HFS Plus Volume Format") requires a wrapper's embedded volume
to be HFS Plus: "When an HFS Plus volume is embedded, drEmbedSigWord
must be kHFSPlusSigWord ('H+')".  So there is at most one wrapper hop,
and Apple's hfs code, GRUB and 7-Zip all follow it once.  A partition
map sits at the start of the raw device (previous patch), so a
partition-table hop only makes sense before any wrapper hop.  Allow one
of each, in that order, and fail with -EINVAL otherwise.  A zero offset
is caught on the second pass.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
---
A wrapper whose embedded-volume descriptor points back at itself
hangs the mount forever without this patch and fails at once with it:

  img=hfsplus-wrapper-loop.img
  put() { printf "$2" | dd of=$img bs=1 seek=$1 conv=notrunc status=none; }
  truncate --size=64K $img
  put $((1024 + 0x00)) '\x42\x44'          # drSigWord 'BD'
  put $((1024 + 0x0a)) '\x82\x00'          # drAtrb: SLOCK | SPARED
  put $((1024 + 0x14)) '\x00\x00\x02\x00'  # drAlBlkSiz 512
  put $((1024 + 0x7c)) '\x48\x2b'          # drEmbedSigWord 'H+'
  put $((1024 + 0x7e)) '\x00\x00\x00\x64'  # drEmbedExtent: start 0, count 100
  mount -o ro,loop -t hfsplus $img /mnt

The same partition-table entry as the hfs patch hangs an hfsplus mount
the same way:

  img=hfsplus-partmap-loop.img
  put() { printf "$2" | dd of=$img bs=1 seek=$1 conv=notrunc status=none; }
  truncate --size=64K $img
  put $((512+0x00)) '\x50\x4d'          # pmSig 'PM'
  put $((512+0x04)) '\x00\x00\x00\x01'  # pmMapBlkCnt 1
  put $((512+0x08)) '\x00\x00\x00\x00'  # pmPyPartStart 0 (self)
  put $((512+0x0c)) '\x00\x00\x00\x64'  # pmPartBlkCnt 100
  put $((512+0x30)) 'Apple_HFS'         # pmPartType
  mount -o ro,loop -t hfsplus $img /mnt
---
 fs/hfsplus/wrapper.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/fs/hfsplus/wrapper.c b/fs/hfsplus/wrapper.c
index 30cf4fe78b3d..df8079a4d8f5 100644
--- a/fs/hfsplus/wrapper.c
+++ b/fs/hfsplus/wrapper.c
@@ -137,6 +137,7 @@ int hfsplus_read_wrapper(struct super_block *sb)
 	struct hfsplus_wd wd;
 	sector_t part_start, part_size;
 	u32 blocksize;
+	bool part_hop_done = false, wrapper_hop_done = false;
 	int error = 0;
 
 	error = -EINVAL;
@@ -172,21 +173,35 @@ int hfsplus_read_wrapper(struct super_block *sb)
 	case cpu_to_be16(HFSPLUS_VOLHEAD_SIG):
 		break;
 	case cpu_to_be16(HFSP_WRAP_MAGIC):
+		/*
+		 * The embedded volume must be HFS Plus (TN1150), so a
+		 * second wrapper is corrupt; a descriptor pointing at
+		 * itself would otherwise loop forever.
+		 */
+		if (wrapper_hop_done)
+			goto out_free_backup_vhdr;
 		if (!hfsplus_read_mdb(sbi->s_vhdr, &wd))
 			goto out_free_backup_vhdr;
 		wd.ablk_size >>= HFSPLUS_SECTOR_SHIFT;
 		part_start += (sector_t)wd.ablk_start +
 			       (sector_t)wd.embed_start * wd.ablk_size;
 		part_size = (sector_t)wd.embed_count * wd.ablk_size;
+		wrapper_hop_done = true;
 		goto reread;
 	default:
 		/*
 		 * Check for a partition block.
 		 *
 		 * (should do this only for cdrom/loop though)
+		 *
+		 * The partition map is at the start of the device: follow
+		 * it at most once, and not from inside a wrapper.
 		 */
+		if (part_hop_done || wrapper_hop_done)
+			goto out_free_backup_vhdr;
 		if (hfs_part_find(sb, &part_start, &part_size))
 			goto out_free_backup_vhdr;
+		part_hop_done = true;
 		goto reread;
 	}
 
-- 
2.55.0


      parent reply	other threads:[~2026-09-26  8:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-26  8:40 [PATCH 0/2] hfs, hfsplus: bound the partition-table and wrapper hops Matthias Goergens
2026-09-26  8:40 ` [PATCH 1/2] hfs: bound the partition-table hop in hfs_mdb_get() Matthias Goergens
2026-09-26  8:40 ` Matthias Goergens [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260926084010.569552-3-matthias.goergens@gmail.com \
    --to=matthias.goergens@gmail.com \
    --cc=frank.li@vivo.com \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=slava@dubeyko.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®