linux-kernel - Re: [syzbot] [kernel?] general protection fault in joydev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2023112308-manhandle-defection-c551@gregkh>
Date:   Thu, 23 Nov 2023 12:54:25 +0000
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     Aleksandr Nogikh <nogikh@...gle.com>
Cc:     xingwei lee <xrivendell7@...il.com>,
        "syzbot+786b124fe4ce4dc99357@...kaller.appspotmail.com" 
        <syzbot+786b124fe4ce4dc99357@...kaller.appspotmail.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Alexander Potapenko <glider@...gle.com>,
        Akinobu Mita <akinobu.mita@...il.com>
Subject: Re: [syzbot] [kernel?] general protection fault in joydev_connect

On Thu, Nov 23, 2023 at 01:42:26PM +0100, Aleksandr Nogikh wrote:
> On Thu, Nov 23, 2023 at 10:41 AM gregkh@...uxfoundation.org
> <gregkh@...uxfoundation.org> wrote:
> >
> > On Thu, Nov 23, 2023 at 10:32:26AM +0100, Aleksandr Nogikh wrote:
> > > On Thu, Nov 23, 2023 at 9:55 AM gregkh@...uxfoundation.org
> > > <gregkh@...uxfoundation.org> wrote:
> > > >
> > > > On Wed, Nov 22, 2023 at 07:55:50PM +0800, xingwei lee wrote:
> > > > > Hi. I have reproduced this bug with repro.txt and repro.c below:
> > > > >
> > > > > repro.txt
> > > > > r0 = openat$uinput(0xffffffffffffff9c, &(0x7f0000000500), 0x802, 0x0)
> > > > > ioctl$UI_DEV_SETUP(r0, 0x405c5503, &(0x7f0000000080)={{0x0, 0xffff,
> > > > > 0x3}, 'syz0\x00'})
> > > > > ioctl$UI_DEV_CREATE(r0, 0x5501) (fail_nth: 51)
> > > >
> > > > You are using fault injection, which, by it's very name, causes faults :)
> > >
> > > But those injected failures (that do not break the kernel, but just
> > > emulate an error returned from a function that should be expected to
> > > sometimes return an error) still should not lead to general protection
> > > fault panics, shouldn't they?
> >
> > It all depends on what exactly the fault is happening for.  Some
> > allocations in the kernel just "will not fail ever" so when you add
> > fault injection testing, you are doing things that really can not ever
> > happen.
> 
> Just in case - are you aware of any specific examples where fault
> injection injects failures that should never ever happen?

Yes, many places, it's come up in the past, but I can't find the
specifics as some of us get 1000+ emails a day :)

Search the archives?

> All
> automatic kernel testing would benefit by making it not do this then.

I agree, so take a look at the allocation paths and see the ones that
just can not fail and then do not cause a fault on them?  As an example,
any "small" allocation that can be done in a way that can sleep (i.e.
GFP_KERNEL) will never fail, right?  So don't add failures there.

Or any allocation at boot time, that's never going to fail as there's no
memory pressure yet.  Look at the system and make smart faults, don't
just blindly go poking at things and expect it all to work.

good luck!

greg k-h