Re: [BUG] general protection fault in input_unregister_device

[Xianying Wang <wangxianying546@gmail.com>]

Hi Dmitry,

Here is the trimmed reproducer. If it still doesn't work, please feel
free to contact me anytime.

C reproducer :https://pastebin.com/raw/NkJX5AfA

Best regards,
Xianying

Dmitry Torokhov <dmitry.torokhov@gmail.com> 于2025年5月28日周三 05:02写道：
>
> Hi Xianying,
>
> On Tue, May 27, 2025 at 04:21:40PM +0800, Xianying Wang wrote:
> > Hi,
> >
> > I discovered a kernel crash described as "general protection fault in
> > input_unregister_device." The crash occurs in the input subsystem,
> > specifically in the function input_unregister_device
> > (drivers/input/input.c:2500), due to dereferencing a non-canonical
> > address, resulting in a general protection fault.
> >
> > According to the crash report, the faulting address is
> > 0xdffffc00000000a4, which corresponds to a KASAN shadow memory region.
> > The crash is triggered when mac_hid_toggle_emumouse calls
> > mac_hid_stop_emulation, which in turn invokes
> > mac_hid_destroy_emumouse, eventually leading to a call to
> > input_unregister_device with an invalid or uninitialized input_dev
> > pointer.
> >
> > The report indicates that a corrupted or NULL input_dev structure was
> > passed into input_unregister_device, possibly due to a use-after-free,
> > double unregister, or incomplete initialization in the emumouse path
> > in mac_hid.
> >
> > This can be reproduced on:
> >
> > HEAD commit:
> >
> > commit adc218676eef25575469234709c2d87185ca223a
> >
> > report: https://pastebin.com/raw/4TeX6E8M
> >
> > console output : https://pastebin.com/raw/ZE2AZ1Gq
> >
> > kernel config : https://pastebin.com/raw/BpCtvUt2
> >
> > C reproducer :
> >
> > part1：https://pastebin.com/raw/jhU9v99k
> >
> > part2：https://pastebin.com/raw/dcaKCHZ1
> >
> > part3：https://pastebin.com/raw/CzgGBb7C
> >
> > part4：https://pastebin.com/raw/MnwtYcjd
> >
> > part5：https://pastebin.com/raw/VE8xNmHT
>
> Could you try to trim the reproducer to something more manageable? There
> are really too many things going on to make sense of it...
>
> I guess we are ending calling mac_hid_stop_emulation() with NULL input
> device, but I can;t see how this happens unless we manage to overwrite
> sysctl table memory with some garbae earlier....
>
> Thanks.
>
> --
> Dmitry