linux-kernel - Re: [BUG] general protection fault in input_unregister

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOU40uAurZLiPCiDNh8Gz3JaYOSRGTLkqQNddZi=kX3UdkP7Pw@mail.gmail.com>
Date: Wed, 28 May 2025 21:43:46 +0800
From: Xianying Wang <wangxianying546@...il.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] general protection fault in input_unregister_device

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@...il.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