All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Hawkins Jiawei <yin31149@gmail.com>
Cc: akpm@linux-foundation.org, anton@tuxera.com,
	chenxiaosong2@huawei.com, linux-kernel@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net,
	syzbot+5f8dcabe4a3b2c51c607@syzkaller.appspotmail.com,
	syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] ntfs: change check order in ntfs_attr_find
Date: Sat, 27 Aug 2022 13:58:42 +0300	[thread overview]
Message-ID: <20220827105842.GM2030@kadam> (raw)
In-Reply-To: <20220827090230.3287-1-yin31149@gmail.com>

On Sat, Aug 27, 2022 at 05:02:31PM +0800, Hawkins Jiawei wrote:
> On Sat, 27 Aug 2022 at 14:42, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >
> > On Fri, Aug 26, 2022 at 11:42:32PM +0800, Hawkins Jiawei wrote:
> > > On Fri, 26 Aug 2022 at 23:15, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > > >
> > > > On Fri, Aug 26, 2022 at 08:32:57PM +0800, Hawkins Jiawei wrote:
> > > > > > syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git     master
> > > > > >
> > > > > > Looks like it is improper check order that causes this bug.
> > > > >
> > > > > Sorry for wrong command.
> > > > > #syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git     master
> > > > >
> > > > > diff --git a/fs/ntfs/attrib.c b/fs/ntfs/attrib.c
> > > > > index 52615e6090e1..6480cd2d371d 100644
> > > > > --- a/fs/ntfs/attrib.c
> > > > > +++ b/fs/ntfs/attrib.c
> > > > > @@ -594,10 +594,11 @@ static int ntfs_attr_find(const ATTR_TYPE type, const ntfschar *name,
> > > > >       for (;; a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))) {
> > > > >               u8 *mrec_end = (u8 *)ctx->mrec +
> > > > >                              le32_to_cpu(ctx->mrec->bytes_allocated);
> > > > > +             if ((u8*)a < (u8*)ctx->mrec || (u8*)a > mrec_end)
> > > > > +                     break;
> > > >
> > > > This definitely seems like a bug.  But your code won't build.  Syzbot
> > > > must have -Werror turned off?
> > > Hi Dan,
> > > Did you mean we should put the variable declares at the beginning of the function?
> > > (Correct me if I understand anything wrong)
> >
> > You can declare it at the beginning of the block.
> OK, I will do like that.
> 
> >
> > >
> > > >
> > > > Btw, this was in the original code, but those casts are ugly.  Ideally
> > > > there would be some way to get rid of them.  But otherwise at least
> > > > put a space after the u8.  "(u8 *)a < (u8 *)ctx->mrec".
> > > >
> > > > >               u8 *name_end = (u8 *)a + le16_to_cpu(a->name_offset) +
> > > > >                              a->name_length * sizeof(ntfschar);
> > > > > -             if ((u8*)a < (u8*)ctx->mrec || (u8*)a > mrec_end ||
> > > > > -                 name_end > mrec_end)
> > > > > +             if (name_end > mrec_end)
> > > > >                       break;
> > > >
> > > > regards,
> > > > dan carpenter
> > > So maybe I can try to refactor these codes. But I wonder if this can be
> > > done in a seperate bug
> >
> > The kernel has a strict "one thing per patch rule".  Those rules are
> > for reviewers and easier backporting.  So the trick is to write the
> > commit message to persuade the reviewer that the way you've written the
> > patch is the easiest way to review it.  So here is how I would write the
> > commit message:
> >
> > [PATCH] ntfs: fix out of bounds read in ntfs_attr_find()
> >
> > This code deferences "a" to calculate "name_end" and then it checks to
> > ensure that "a" is within bounds.  Move the bounds checks earlier and
> > add some comments to make it more clear what they're doing.  Then
> > calculate "name_end" and check that.
> >
> > (Btw, are the wrap around checks really sufficient?  It seems like it
> > could wrap to something still within the ->mrec buffer but before the
> > current entry so it would end up in a forever loop or something?)
> I am not for sure, but it seems that it is OK before.
> As for the forever loop, there is a break when a->length is 0 in the loop,
> So I think it probably would not end up in a forever loop?(Correct me if
> I am wrong)
> 

Checking for zero is not sufficient because it can wrap on 32 bit
systems.  It needs something like:

			return -ENOENT;
		len = le32_to_cpu(a->length);
		if (!len ||
		    (void *)a + len < (void *)a ||
		    (void *)a + len > mrec_end)
			break;
		if (a->type != type)
			continue;

Sort of ugly, but hopefully it gives the idea of what I'm saying.

regards,
dan carpenter


  reply	other threads:[~2022-08-27 10:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25 18:25 [syzbot] KASAN: use-after-free Read in ntfs_attr_find syzbot
2022-08-25 18:32 ` Siddh Raman Pant
2022-08-25 18:34   ` Siddh Raman Pant
2022-08-26 12:27 ` [PATCH] ntfs: change check order " Hawkins Jiawei
2022-08-26 12:32   ` Hawkins Jiawei
2022-08-26 14:16     ` [syzbot] KASAN: use-after-free Read " syzbot
2022-08-26 15:15     ` [PATCH] ntfs: change check order " Dan Carpenter
2022-08-26 15:42       ` Hawkins Jiawei
2022-08-26 15:54         ` Hawkins Jiawei
2022-08-27  6:42         ` Dan Carpenter
2022-08-27  9:02           ` Hawkins Jiawei
2022-08-27 10:58             ` Dan Carpenter [this message]
2022-08-28 16:15               ` Hawkins Jiawei
2022-08-27  2:42     ` Andrew Morton
2022-08-27  8:38       ` Hawkins Jiawei
2022-08-27  1:28   ` chenxiaosong (A)
2022-08-27  7:51     ` Hawkins Jiawei
2022-08-27 14:49       ` Hawkins Jiawei
2022-08-29  9:51         ` Dan Carpenter

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=20220827105842.GM2030@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=anton@tuxera.com \
    --cc=chenxiaosong2@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=syzbot+5f8dcabe4a3b2c51c607@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=yin31149@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.