Re: [syzbot] [kernel?] general protection fault in joydev_connect

[gregkh@xxxxxxxxxxxxxxxxxxx]

On Thu, Nov 23, 2023 at 01:42:26PM +0100, Aleksandr Nogikh wrote:
> On Thu, Nov 23, 2023 at 10:41 AM gregkh@xxxxxxxxxxxxxxxxxxx
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, Nov 23, 2023 at 10:32:26AM +0100, Aleksandr Nogikh wrote:
> > > On Thu, Nov 23, 2023 at 9:55 AM gregkh@xxxxxxxxxxxxxxxxxxx
> > > <gregkh@xxxxxxxxxxxxxxxxxxx> 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