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>,
"skhan@linuxfoundation.org" <skhan@linuxfoundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel-mentees@lists.linux.dev"
<linux-kernel-mentees@lists.linux.dev>,
"syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com"
<syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] hfs: Validate CNIDs in hfs_read_inode
Date: Sat, 4 Oct 2025 02:25:16 +0100 [thread overview]
Message-ID: <aOB3fME3Q4GfXu0O@Bertha> (raw)
In-Reply-To: <405569eb2e0ec4ce2afa9c331eb791941d0cf726.camel@ibm.com>
On Fri, Oct 03, 2025 at 10:40:16PM +0000, Viacheslav Dubeyko wrote:
> Let's pay respect to previous efforts. I am suggesting to add this line:
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>
> Are you OK with it?
I agree with paying respect to Tetsuo. The kernel docs indicate that the SoB tag
isn't used like that. Would the Suggested-by: tag be more appropriate?
> I think we can declare like this:
>
> static inline
> bool is_valid_cnid(unsigned long cnid, s8 type)
>
> Why cnid has unsigned long type? The u32 is pretty enough.
Because struct inode's inode number is an unsigned long.
>
> Why type has signed type (s8)? We don't expect negative values here. Let's use
> u8 type.
Because the type field of struct hfs_cat_rec is an s8. Is there anything to gain
by casting the s8 to a u8?
>
> > +{
> > + if (likely(cnid >= HFS_FIRSTUSER_CNID))
> > + return true;
> > +
> > + switch (cnid) {
> > + case HFS_POR_CNID:
> > + case HFS_ROOT_CNID:
> > + return type == HFS_CDR_DIR;
> > + case HFS_EXT_CNID:
> > + case HFS_CAT_CNID:
> > + case HFS_BAD_CNID:
> > + case HFS_EXCH_CNID:
> > + return type == HFS_CDR_FIL;
> > + default:
> > + return false;
>
> We can simply have default that is doing nothing:
>
> default:
> /* continue logic */
> break;
>
> > + }
>
> I believe that it will be better to return false by default here (after switch).
We can do that, but why would it be better, is it an optimisation? We don't have
any logic to continue.
> > + break;
> > + }
> > inode->i_size = be16_to_cpu(rec->dir.Val) + 2;
> > HFS_I(inode)->fs_blocks = 0;
> > inode->i_mode = S_IFDIR | (S_IRWXUGO & ~hsb->s_dir_umask);
>
> We have practically the same check for the case of hfs_write_inode():
>
> int hfs_write_inode(struct inode *inode, struct writeback_control *wbc)
> {
> struct inode *main_inode = inode;
> struct hfs_find_data fd;
> hfs_cat_rec rec;
> int res;
>
> hfs_dbg("ino %lu\n", inode->i_ino);
> res = hfs_ext_write_extent(inode);
> 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;
>
> I think we need to select something one here. :) I believe we need to remove
> BUG() and return -EIO, finally. What do you think?
I think that with validation of inodes in hfs_read_inode this code path should
no longer be reachable by poking the kernel interface from userspace. If it is
ever reached, it means kernel logic is broken, so it should be treated as a bug.
>
> }
> }
>
> <skipped>
> }
>
> What's about to use your check here too?
Let's do that, I'll include it in V2.
>
> Mostly, I like your approach but the patch needs some polishing yet. ;)
>
> Thanks,
> Slava.
Thank you for taking the time to give detailed feedback, I really appreciate it.
George
next prev parent reply other threads:[~2025-10-04 1:25 UTC|newest]
Thread overview: 7+ 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 [this message]
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
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=aOB3fME3Q4GfXu0O@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-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--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).