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 for Android: free password hash cracker in your pocket

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

Message-ID: <j3gqh3iv7hsanemh3ctsrzcd3hljhsmdwe65vrnsjrygsz5dzx@7wvtrimqooim>
Date: Tue, 27 May 2025 14:02:13 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Xianying Wang <wangxianying546@...il.com>
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] general protection fault in input_unregister_device

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