Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Thu, 23 Nov 2023 09:41:49 +0000
From:   "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To:     Aleksandr Nogikh <nogikh@google.com>
Cc:     xingwei lee <xrivendell7@gmail.com>,
        "syzbot+786b124fe4ce4dc99357@syzkaller.appspotmail.com" 
        <syzbot+786b124fe4ce4dc99357@syzkaller.appspotmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "rafael@kernel.org" <rafael@kernel.org>,
        "syzkaller-bugs@googlegroups.com" <syzkaller-bugs@googlegroups.com>,
        Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [syzbot] [kernel?] general protection fault in joydev_connect
Message-ID: <2023112306-diner-jawline-c7dc@gregkh>
References: <CABOYnLyCRyK4qpS2X8ssA6yxCDtEWR3dSsee2Lm6VCQUyD07VQ@mail.gmail.com>
 <2023112332-award-fanciness-2bcf@gregkh>
 <CANp29Y6ge-AhM+Byt3imGOpctRsgWiqBN-reuKvOJAzxBsTYLw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CANp29Y6ge-AhM+Byt3imGOpctRsgWiqBN-reuKvOJAzxBsTYLw@mail.gmail.com>
Precedence: bulk

On Thu, Nov 23, 2023 at 10:32:26AM +0100, Aleksandr Nogikh wrote:
> On Thu, Nov 23, 2023 at 9:55 AM gregkh@linuxfoundation.org
> <gregkh@linuxfoundation.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