public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: George Anthony Vernon <contact@gvernon.com>
To: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Cc: "glaubitz@physik.fu-berlin.de" <glaubitz@physik.fu-berlin.de>,
	"slava@dubeyko.com" <slava@dubeyko.com>,
	"frank.li@vivo.com" <frank.li@vivo.com>,
	"penguin-kernel@i-love.sakura.ne.jp"
	<penguin-kernel@i-love.sakura.ne.jp>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com"
	<syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com>
Subject: Re: [PATCH v3] hfs: Validate CNIDs in hfs_read_inode
Date: Wed, 11 Mar 2026 20:31:38 +0000	[thread overview]
Message-ID: <abHRKnUIqMxTmcWH@Bertha> (raw)
In-Reply-To: <fe598b9b8686708d5145fee8963abbfb726fbdfd.camel@ibm.com>

On Tue, Mar 10, 2026 at 09:28:53PM +0000, Viacheslav Dubeyko wrote:
> On Tue, 2026-03-10 at 00:08 +0000, George Anthony Vernon wrote:
> > hfs_read_inode previously did not validate CNIDs read from disk, thereby
> > allowing inodes to be constructed with disallowed CNIDs and placed on
> > the dirty list, eventually hitting a bug on writeback.
> > 
> > Validate reserved CNIDs as specified for HFS according to
> > "Inside Macintosh: Files."
> > 
> > This issue was discussed at length on LKML previously, the discussion
> > is linked below.
> > 
> > Syzbot tested this patch on mainline and the bug did not replicate.
> > This patch was regression tested by issuing various system calls on a
> > mounted HFS filesystem and validating that file creation, deletion,
> > reads and writes all work.
> > 
> > Link: https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_all_427fcb57-2D8424-2D4e52-2D9f21-2D7041b2c4ae5b-40&d=DwIDAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=q5bIm4AXMzc8NJu1_RGmnQ2fMWKq4Y4RAkElvUgSs00&m=AzLgd6KhZfr8AykzDg76T-sDUALdUDSC68BUfheUxxhq-KIglGTX6mtAci6dTupM&s=nuXDj9Z8fvUpvnJIyDsfPIi-YuBzvbXxQUhypXeaheU&e= 
> > I-love.SAKURA.ne.jp/T/
> > Reported-by: syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com
> > Closes: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_bug-3Fextid-3D97e301b4b82ae803d21b&d=DwIDAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=q5bIm4AXMzc8NJu1_RGmnQ2fMWKq4Y4RAkElvUgSs00&m=AzLgd6KhZfr8AykzDg76T-sDUALdUDSC68BUfheUxxhq-KIglGTX6mtAci6dTupM&s=lGn13lU4-Np727qrFQB17Y-qYKD4fRkJ3gSkQYQH8cg&e= 
> > Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> > Tested-by: syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com
> > Signed-off-by: George Anthony Vernon <contact@gvernon.com>
> > ---
> > 
> > Sorry there was a long wait for V3! I have now reviewed the feedback
> > given in response to V2, which I very greatly appreciate.
> > 
> > Most of the changes here are directly implementing changes requested. I
> > disagree that CNID 5 should be considered valid and have added some
> > comments referencing the documentation. This is linked to the change
> > from is_valid_cnid() -> is_valid_catalog_record(). I believe it is now
> > semantically correct, because CNID 5 is a valid CNID, but it can not
> > belong to a catalog record.
> > 
> > Thanks,
> > 
> > George
> > 
> > Changes from V2->V3:
> > - Use HFS-specific references in preference to TN1150
> > - Remove Tetsuo's additional superblock check from patch series
> > - Rename is_valid_cnid() -> is_valid_catalog_record()
> > - Add static inline hfs_inode_type() helper function
> > - Do not BUG() on detected bad inode, use pr_warn()
> > 
> > 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
> > 
> >  fs/hfs/inode.c | 76 ++++++++++++++++++++++++++++++++++++++++----------
> >  1 file changed, 62 insertions(+), 14 deletions(-)
> > 
> > diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
> > index 878535db64d6..db31b9840371 100644
> > --- a/fs/hfs/inode.c
> > +++ b/fs/hfs/inode.c
> > @@ -340,6 +340,42 @@ static int hfs_test_inode(struct inode *inode, void *data)
> >  	}
> >  }
> >  
> > +/*
> > + * is_valid_catalog_record
> > + *
> > + * Validate the CNID of a catalog record
> > + */
> > +static inline
> > +bool is_valid_catalog_record(u32 cnid, u8 type)
> > +{
> > +	if (likely(cnid >= HFS_FIRSTUSER_CNID))
> > +		return true;
> > +
> > +	switch (cnid) {
> > +	case HFS_ROOT_CNID:
> > +		return type == HFS_CDR_DIR;
> > +	case HFS_EXT_CNID:
> > +	case HFS_CAT_CNID:
> > +		return type == HFS_CDR_FIL;
> > +	case HFS_POR_CNID:
> 
> If we don't process this ID, then default case will be completely enough. We
> don't need to introduce this as a special case.
> 
Okay, I've removed it. It was an intentional style choice, the purpose
was to provide some explanation.

> > +		/* No valid record with this CNID */
> > +		break;
> > +	case HFS_BAD_CNID:
> > +		/*
> > +		 * Bad block file "doesn't have a file record in the catalog" as per TN1150 (HFS+).
> > +		 * Inside Macintosh: Files chapter 5-8 tells us for plain old HFS:
> > +		 * "... the bad block sparing algorithm does not create any new
> > +		 * entries in the volume's catalog file".
> > +		 */
> 
> Yes, HFS driver (bad block sparing algorithm) will not create this file because
> this file could be created by mkfs tool. And the bad block sparing algorithm
> could simply read this file and add new items (bad sectors). This CNID could be
> in Catalog File because it could be created by mkfs tool.
> 
> Anyway, I think that probability to have the Bad block file is really low. If
> you really insist not to process this CNID, then I suggest completely remove
> this case and comments.
> 
Ditto here, I thought the comments were useful explanation, I've removed
them. I really think it is correct not to parse this CNID. I think mkfs
would be violating the HFS standard if it created a CNID with that
inode.
> > +		break;
> > +	default:
> > +		/* Invalid reserved CNID */
> > +		break;
> > +	}
> > +
> > +	return false;
> > +}
> > +
> >  /*
> >   * hfs_read_inode
> >   */
> > @@ -369,6 +405,8 @@ static int hfs_read_inode(struct inode *inode, void *data)
> >  	rec = idata->rec;
> >  	switch (rec->type) {
> >  	case HFS_CDR_FIL:
> > +		if (!is_valid_catalog_record(rec->file.FlNum, HFS_CDR_FIL))
> > +			goto make_bad_inode;
> 
> I think to use the rec->type is better here than HFS_CDR_FIL.
> 
Thanks for pointing this out, after rewriting it the way you suggested I saw a further improvement to let the helper take a single hfs_cat_rec pointer.

> 
> >  		inode->i_ino = be32_to_cpu(rec->dir.DirID);
> >  		inode->i_size = be16_to_cpu(rec->dir.Val) + 2;
> >  		HFS_I(inode)->fs_blocks = 0;
> > @@ -399,8 +439,13 @@ static int hfs_read_inode(struct inode *inode, void *data)
> >  		inode->i_op = &hfs_dir_inode_operations;
> >  		inode->i_fop = &hfs_dir_operations;
> >  		break;
> > +	make_bad_inode:
> > +		pr_warn("Invalid cnid %lu\n", inode->i_ino);
> > +		pr_warn("Volume is probably corrupted, try performing fsck.\n");
> > +		fallthrough;
> >  	default:
> >  		make_bad_inode(inode);
> > +		break;
> >  	}
> >  	return 0;
> >  }
> > @@ -448,6 +493,11 @@ void hfs_inode_write_fork(struct inode *inode, struct hfs_extent *ext,
> >  					 HFS_SB(inode->i_sb)->alloc_blksz);
> >  }
> >  
> > +static inline u8 hfs_inode_type(struct inode *inode)
> > +{
> > +	return S_ISDIR(inode->i_mode) ? HFS_CDR_DIR : HFS_CDR_FIL;
> > +}
> > +
> >  int hfs_write_inode(struct inode *inode, struct writeback_control *wbc)
> >  {
> >  	struct inode *main_inode = inode;
> > @@ -460,20 +510,18 @@ int hfs_write_inode(struct inode *inode, struct writeback_control *wbc)
> >  	if (res)
> >  		return res;
> >  
> > -	if (inode->i_ino < HFS_FIRSTUSER_CNID) {
> > -		switch (inode->i_ino) {
> > -		case HFS_ROOT_CNID:
> > -			break;
> > -		case HFS_EXT_CNID:
> > -			hfs_btree_write(HFS_SB(inode->i_sb)->ext_tree);
> > -			return 0;
> > -		case HFS_CAT_CNID:
> > -			hfs_btree_write(HFS_SB(inode->i_sb)->cat_tree);
> > -			return 0;
> > -		default:
> > -			BUG();
> > -			return -EIO;
> > -		}
> > +	if (!is_valid_catalog_record(inode->i_ino, hfs_inode_type(inode)))
> > +		return -EIO;
> > +
> > +	switch (inode->i_ino) {
> > +	case HFS_EXT_CNID:
> > +		hfs_btree_write(HFS_SB(inode->i_sb)->ext_tree);
> > +		return 0;
> > +	case HFS_CAT_CNID:
> > +		hfs_btree_write(HFS_SB(inode->i_sb)->cat_tree);
> > +		return 0;
> > +	default:
> > +		break;
> 
> Why this has been removed:
> 
> -		default:
> -			BUG();
> -			return -EIO;
> -		}
> 
> 
It hasn't been totally removed, the same logic has been absorbed into
is_valid_catalog_record(). The difference is now we just return -EIO
instead of throwing BUG() like you previously suggested, which I now
agree with.
> >  	}
> >  
> >  	if (HFS_IS_RSRC(inode))
> 
> 
> You completely missed the hfs_fill_super() logic:
> 
> 	root_inode = hfs_iget(sb, &fd.search_key->cat, &rec);
> 	hfs_find_exit(&fd);
> 	if (!root_inode)
> 		goto bail_no_root;
> 
> We need to process it specially now because we've created bad inode.
> 
> Thanks,
> Slava.

Sorry I did miss this. I agree that this change will be sufficient to
check the superblock, it's functionally equivalent to Tetsuo's patch.

Will follow up with new patch shortly.

Thanks again,

George

      reply	other threads:[~2026-03-11 20:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-10  0:08 [PATCH v3] hfs: Validate CNIDs in hfs_read_inode George Anthony Vernon
2026-03-10 10:41 ` Tetsuo Handa
2026-03-10 21:29   ` Viacheslav Dubeyko
2026-03-10 14:39 ` kernel test robot
2026-03-10 21:28 ` Viacheslav Dubeyko
2026-03-11 20:31   ` George Anthony Vernon [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=abHRKnUIqMxTmcWH@Bertha \
    --to=contact@gvernon.com \
    --cc=Slava.Dubeyko@ibm.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=penguin-kernel@i-love.sakura.ne.jp \
    --cc=slava@dubeyko.com \
    --cc=syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.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