[BUG] general protection fault in input_unregister_device

[BUG] general protection fault in input_unregister_device

[Xianying Wang]

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

Best regards,

Xianying

Re: [BUG] general protection fault in input_unregister_device

[Dmitry Torokhov]

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

Re: [BUG] general protection fault in input_unregister_device

[Xianying Wang]

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