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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2023112306-diner-jawline-c7dc@gregkh>
Date:   Thu, 23 Nov 2023 09:41:49 +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>
Subject: Re: [syzbot] [kernel?] general protection fault in joydev_connect

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.

So the proof is first on the reporter, prove that this type of fault
_can_ actually happen, and then, make a fix to properly handle it.
Don't expect us to make a fix for something that can not actually occur,
as that would be pointless (hint, we have been down this path before, it
doesn't work...)

thanks,

greg k-h