From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Matthias Goergens <matthias.goergens@gmail.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: Re: [PATCH 2/2] hfsplus: bound the wrapper and partition-table hops in hfsplus_read_wrapper()
Date: Mon, 28 Sep 2026 14:00:07 -0700 [thread overview]
Message-ID: <c2d61b16570fb6dd6b0c4130fe4bfc707e2334b1.camel@dubeyko.com> (raw)
In-Reply-To: <20260926084010.569552-3-matthias.goergens@gmail.com>
On Sat, 2026-09-26 at 16:40 +0800, Matthias Goergens wrote:
> 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))
Ditto. We need to have a proper sanity check in hfsplus_read_mdb().
> 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))
Ditto. We need to have a proper sanity check in hfs_part_find().
Thanks,
Slava.
> goto out_free_backup_vhdr;
> + part_hop_done = true;
> goto reread;
> }
>
prev parent reply other threads:[~2026-09-28 21:00 UTC|newest]
Thread overview: 5+ 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-28 20:57 ` Viacheslav Dubeyko
2026-09-26 8:40 ` [PATCH 2/2] hfsplus: bound the wrapper and partition-table hops in hfsplus_read_wrapper() Matthias Goergens
2026-09-28 21:00 ` Viacheslav Dubeyko [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=c2d61b16570fb6dd6b0c4130fe4bfc707e2334b1.camel@dubeyko.com \
--to=slava@dubeyko.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=matthias.goergens@gmail.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®