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

[Aleksandr Nogikh]

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? All
automatic kernel testing would benefit by making it not do this then.

>From what I see in the code, fault injection already takes care of
avoiding such problems:
https://elixir.bootlin.com/linux/latest/source/mm/failslab.c#L25
https://elixir.bootlin.com/linux/latest/source/mm/fail_page_alloc.c#L30

>
> 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