[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+b1yx9cYAtedSv+D4utu+MF_3uJt5oKmcQs7qDBrPx2=w@mail.gmail.com>
Date: Wed, 6 Nov 2019 16:33:11 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Daniel Vetter <daniel@...ll.ch>
Cc: syzbot <syzbot+fb77e97ebf0612ee6914@...kaller.appspotmail.com>,
Dave Airlie <airlied@...ux.ie>,
Andrew Morton <akpm@...ux-foundation.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Kees Cook <keescook@...omium.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Sean Paul <sean@...rly.run>,
Stephen Rothwell <sfr@...b.auug.org.au>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: WARNING in drm_mode_createblob_ioctl
On Wed, Nov 6, 2019 at 4:28 PM Daniel Vetter <daniel@...ll.ch> wrote:
>
> On Wed, Nov 6, 2019 at 4:23 PM Daniel Vetter <daniel@...ll.ch> wrote:
> >
> > On Wed, Nov 6, 2019 at 4:20 PM syzbot
> > <syzbot+fb77e97ebf0612ee6914@...kaller.appspotmail.com> wrote:
> > >
> > > syzbot has bisected this bug to:
> > >
> > > commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
> > > Author: Kees Cook <keescook@...omium.org>
> > > Date: Mon Nov 4 22:57:23 2019 +0000
> > >
> > > uaccess: disallow > INT_MAX copy sizes
> >
> > Ah cool, this explains it.
> >
> > fwiw I never managed to get the WARNING in the backtrace to lign up
> > with any code. No idea what's been going on.
>
> Ok I think I have an idea, the above commit isn't in the linux-next I
> have here. Where is this from?
> -Daniel
You need to fetch tags to linux-next. syzbot started bisecting from
the commit where the crash happened, and it is now probably not the
current tag.
linux$ git show 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
Author: Kees Cook <keescook@...omium.org>
Date: Tue Nov 5 09:57:23 2019 +1100
uaccess: disallow > INT_MAX copy sizes
As we've done with VFS, string operations, etc, reject usercopy sizes
larger than INT_MAX, which would be nice to have for catching bugs related
to size calculation overflows[1].
This adds 10 bytes to x86_64 defconfig text and 1980 bytes to the data
section:
text data bss dec hex filename
19691167 5134320 1646664 26472151 193eed7 vmlinux.before
19691177 5136300 1646664 26474141 193f69d vmlinux.after
[1] https://marc.info/?l=linux-s390&m=156631939010493&w=2
Link: http://lkml.kernel.org/r/201908251612.F9902D7A@keescook
Signed-off-by: Kees Cook <keescook@...omium.org>
Suggested-by: Dan Carpenter <dan.carpenter@...cle.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@...b.auug.org.au>
diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
index 659a4400517b2..e93e249a4e9bf 100644
--- a/include/linux/thread_info.h
+++ b/include/linux/thread_info.h
@@ -147,6 +147,8 @@ check_copy_size(const void *addr, size_t bytes,
bool is_source)
__bad_copy_to();
return false;
}
+ if (WARN_ON_ONCE(bytes > INT_MAX))
+ return false;
check_object_size(addr, bytes, is_source);
return true;
}
> > I'll type a patch to paper over this.
> > -Daniel
> >
> > >
> > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=125fe6dce00000
> > > start commit: 51309b9d Add linux-next specific files for 20191105
> > > git tree: linux-next
> > > final crash: https://syzkaller.appspot.com/x/report.txt?x=115fe6dce00000
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=165fe6dce00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=a9b1a641c1f1fc52
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=fb77e97ebf0612ee6914
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1212dc3ae00000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145f604ae00000
> > >
> > > Reported-by: syzbot+fb77e97ebf0612ee6914@...kaller.appspotmail.com
> > > Fixes: 9e5a64c71b2f ("uaccess: disallow > INT_MAX copy sizes")
> > >
> > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Powered by blists - more mailing lists