linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
To: "contact@gvernon.com" <contact@gvernon.com>,
	"penguin-kernel@I-love.SAKURA.ne.jp"
	<penguin-kernel@I-love.SAKURA.ne.jp>
Cc: "frank.li@vivo.com" <frank.li@vivo.com>,
	"linux-kernel-mentees@lists.linux.dev"
	<linux-kernel-mentees@lists.linux.dev>,
	"slava@dubeyko.com" <slava@dubeyko.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com"
	<syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com>,
	"skhan@linuxfoundation.org" <skhan@linuxfoundation.org>,
	"glaubitz@physik.fu-berlin.de" <glaubitz@physik.fu-berlin.de>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: RE: [PATCH v2 2/2] hfs: Update sanity check of the root record
Date: Fri, 14 Nov 2025 21:00:41 +0000	[thread overview]
Message-ID: <1bdcb4caa7cd51b56cdbfa418324196f41fd38f3.camel@ibm.com> (raw)
In-Reply-To: <d8cc277f-c14c-4aee-ac0b-cce2938232d8@I-love.SAKURA.ne.jp>

On Fri, 2025-11-14 at 23:18 +0900, Tetsuo Handa wrote:
> On 2025/11/12 7:56, Viacheslav Dubeyko wrote:
> > The file system is mounted only if hfs_fill_super() created root node and return
> > 0 [1]. However, if hfs_iget() return bad inode [2] and we will call
> > is_bad_inode() here [3]:
> > 
> > 	root_inode = hfs_iget(sb, &fd.search_key->cat, &rec);
> > 	hfs_find_exit(&fd);
> > 	if (!root_inode || is_bad_inode(root_inode)) <-- call will be here
> > 		goto bail_no_root;
> > 
> > then, mount will fail. So, no successful mount will happen because
> > is_valid_cnid() will manage the check in hfs_read_inode().
> 
> Do you admit that mounting (and optionally fuzzing on) a bad inode (an inode
> which was subjected to make_bad_inode()) is useless?
> 

Mount will fail in the case of bad root inode. I don't see any issue here.

> Adding is_bad_inode() check without corresponding iput() in error path causes
> an inode leak bug. Also, error code will differ (my patch returns -EIO while
> your approach will return -EINVAL).
> 

I don't see any problem to add iput(root_inode) as part of failure management in
hfs_fill_super(). And we can return any proper error code for the case of bad
root inode.

> Honestly speaking, I don't like use of make_bad_inode(). make_bad_inode() might
> change file type.
> 

If Catalog File's entry is corrupted, then we cannot assume which particular
file type is correct one. And nobody will operate by bad inode. So, it doesn't
matter which type bad inode has.

>  Also, I worry that make_bad_inode() causes a subtle race bug
> like https://syzkaller.appspot.com/bug?extid=b7c3ba8cdc2f6cf83c21   which has not
> come to a conclusion.
> 

Frankly speaking, I don't see how this issue is related to the HFS mount
operation.

> Why can't we remove make_bad_inode() usage from hfs_read_inode() and return non-0 value
> (so that inode_insert5() will return NULL and iget5_locked() will call destroy_inode()
> and return NULL) when hfs_read_inode() encountered an invalid entry?

Bunch of other file systems use the make_bad_inode() and in fill_super() call
too. I don't see what is wrong with calling make_bad_inode().

Thanks,
Slava.

      reply	other threads:[~2025-11-14 21:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-03  2:45 [PATCH] hfs: Validate CNIDs in hfs_read_inode George Anthony Vernon
2025-10-03 22:40 ` Viacheslav Dubeyko
2025-10-04  1:25   ` George Anthony Vernon
2025-10-07 13:40     ` Viacheslav Dubeyko
2025-10-09 12:57       ` Tetsuo Handa
2025-10-29  3:20         ` George Anthony Vernon
2025-10-29 10:06           ` Tetsuo Handa
2025-11-04  1:47             ` [PATCH v2 0/2] hfs: Validate CNIDs read from filesystem George Anthony Vernon
2025-11-04  1:47             ` [PATCH v2 1/2] hfs: Validate CNIDs in hfs_read_inode George Anthony Vernon
2025-11-04 22:34               ` Viacheslav Dubeyko
2025-11-11  0:00                 ` George Anthony Vernon
2025-11-11  0:48                   ` Viacheslav Dubeyko
2025-11-11 14:39               ` Tetsuo Handa
2025-11-11 22:42                 ` Viacheslav Dubeyko
2025-11-04  1:47             ` [PATCH v2 2/2] hfs: Update sanity check of the root record George Anthony Vernon
2025-11-04 23:01               ` Viacheslav Dubeyko
2025-11-10 23:03                 ` George Anthony Vernon
2025-11-10 23:34                   ` Viacheslav Dubeyko
2025-11-11  0:23                     ` George Anthony Vernon
2025-11-11  0:34                       ` Viacheslav Dubeyko
2025-11-11 14:26                       ` Tetsuo Handa
2025-11-11 22:56                         ` Viacheslav Dubeyko
2025-11-14 14:18                           ` Tetsuo Handa
2025-11-14 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=1bdcb4caa7cd51b56cdbfa418324196f41fd38f3.camel@ibm.com \
    --to=slava.dubeyko@ibm.com \
    --cc=contact@gvernon.com \
    --cc=frank.li@vivo.com \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=skhan@linuxfoundation.org \
    --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;
as well as URLs for NNTP newsgroup(s).