|Summary:||Crashes after unplugging Apple Trackpad 2 - KASAN reports errors|
|Product:||Drivers||Reporter:||Felix Hädicke (felixhaedicke)|
|Severity:||normal||CC:||andrenbrandao, goetzchrist, jkosina, jose.exposito89, marek.wyborski, mike.osipov, n.sherlock, satur9nine, shahar.evron, toni|
dmesg output - used decode_stacktrace script
Used kernel configuration
logs from machine that cannot boot with trackpad attached
add debug output: print call trace for every usbhid_stop() call
dmesg output with kernel 5.12-rc6 with more debug information
Description Felix Hädicke 2020-11-17 22:43:22 UTC
Created attachment 293705 [details] dmesg output - used decode_stacktrace script When using the Apple Trackpad 2 with the "hid-magicmouse" driver via USB, I get reproducible kernel crashes after unplugging the device. Sometimes, the computer hangs immediately, and even Magic SysRQ is not always possible in this state. But most of the times, the computer hangs during shutdown afterwards. The same problem appears when turning the device off, or unloading the hid-magicmouse module, instead of unplugging it. With enabled KASAN, I get reports like this when unplugging this device most of the time (but not always): BUG: KASAN: double-free or invalid-free in hid_free_buffers.isra.0 (drivers/hid/usbhid/hid-core.c:978) usbhid See attached dmesg output. The problem is not reproducible when the hid-magicmouse module is blacklisted. The device can still be used (fallback to hid-generic driver) without this driver, but with very limited functionality. Kernel built from unmodified 5.9.8 source code.
Comment 1 Felix Hädicke 2020-11-17 23:01:43 UTC
Created attachment 293707 [details] Used kernel configuration
Comment 2 Felix Hädicke 2020-11-19 07:44:08 UTC
Works when unloading / blacklisting the "hid-generic" driver, too. The problem only occurs when both driver modules, hid-generic and hid-magicmouse are loaded.
Comment 3 Felix Hädicke 2020-11-19 07:46:52 UTC
Adding the Apple Magic Trackpad 2 to the "hid_have_special_driver" list in hid-quirks.c solves the problem, too. Is this not the right thing to do anyway? I am going to send a patch...
Comment 4 Felix Hädicke 2020-11-24 21:34:47 UTC
Comment 5 Merlin Büge 2020-11-28 01:38:09 UTC
I may be experiencing the same bug: https://lists.archlinux.org/pipermail/arch-general/2020-November/048320.html I'm going to test your patch, building now...
Comment 6 Merlin Büge 2020-11-28 14:09:20 UTC
Tested with 5.9.11.arch1-1, your patch seems to fix the issue I had. Used kernel configuration: https://github.com/archlinux/svntogit-packages/blob/4e921e037821091f48659ce82394995ae3e7be08/trunk/config Regarding your comment earlier, I don't know if it's the right way to do it, but it seems to work (it's hard to say for sure since the issue appears somewhat random). Should I encounter any issues again I will report it back here. Thanks for looking into this!
Comment 7 Merlin Büge 2020-11-28 14:14:44 UTC
Please let me know if I can do something else to help resolve this, e.g. testing with a different kernel version/config.
Comment 8 Nicholas Sherlock 2021-01-15 09:46:29 UTC
I'm experiencing the same bug, detected by KASAN, with Proxmox kernel 5.4.78-2-pve (based on Ubuntu Focal's kernel).
Comment 9 Jacob Abrams 2021-01-22 06:16:25 UTC
Created attachment 294807 [details] logs from machine that cannot boot with trackpad attached My machine cannot boot with Apple magic trackpad 2 plugged in: Linux version 5.8.0-38-generic (buildd@lgw01-amd64-022) (gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0, GNU ld (GNU Binutils for Ubuntu) 2.35.1) #43-Ubuntu SMP Tue Jan 12 12:42:13 UTC 2021 I've attached logs.
Comment 10 Jacob Abrams 2021-02-04 21:25:13 UTC
From a security standpoint I'm curious if this could be exploited. I realize this would require physical access to exploit but Android phones run linux kernel and people often plug their phones into various usb outlets for charging purposes. If something pretends to be a Magic Trackpad I wonder how much such a device might be able to intrude into the kernel. This my affect priority of getting a fix.
Comment 11 Felix Hädicke 2021-04-05 18:13:40 UTC
Created attachment 296239 [details] add debug output: print call trace for every usbhid_stop() call
Comment 12 Felix Hädicke 2021-04-05 18:27:52 UTC
Created attachment 296241 [details] dmesg output with kernel 5.12-rc6 with more debug information dmesg with debug information (see attachment 296239 [details]).
Comment 13 Felix Hädicke 2021-04-05 18:32:47 UTC
The output from attachment 296241 [details] reveals that usbhid_stop() is called twice for the same hid_device instance. First call trace: [ 11.553097] usbhid_stop+0xb4/0x480 [usbhid] [ 11.553102] hid_device_remove+0xcb/0x200 [hid] [ 11.553110] device_release_driver_internal+0x1e5/0x4a0 [ 11.553114] ? __hid_register_driver+0x240/0x240 [hid] [ 11.553120] ? hid_destroy_device+0x140/0x140 [hid] [ 11.553125] device_reprobe+0x33/0x60 [ 11.553128] bus_for_each_dev+0x119/0x1a0 [ 11.553130] ? subsys_dev_iter_exit+0x20/0x20 [ 11.553132] ? klist_next+0x1b7/0x440 [ 11.553136] __hid_bus_driver_added+0x4b/0x80 [hid] [ 11.553142] bus_for_each_drv+0x11c/0x1c0 [ 11.553145] ? bus_rescan_devices+0x20/0x20 [ 11.553148] __hid_register_driver+0x174/0x240 [hid] [ 11.553156] ? 0xffffffffc28aa000 [ 11.553158] do_one_initcall+0x89/0x2c0 [ 11.553163] ? perf_trace_initcall_level+0x4a0/0x4a0 [ 11.553166] ? kasan_set_track+0x1c/0x40 [ 11.553169] ? kasan_unpoison+0x21/0x60 [ 11.553171] ? __kasan_slab_alloc+0x25/0x80 [ 11.553174] ? kasan_unpoison+0x21/0x60 [ 11.553177] do_init_module+0x1f2/0x720 [ 11.553181] load_module+0x86d4/0x9f20 [ 11.553186] ? module_frob_arch_sections+0x40/0x40 [ 11.553188] ? vma_set_page_prot+0x105/0x240 [ 11.553192] ? kernel_read_file+0x2f6/0x720 [ 11.553195] ? __x64_sys_fsconfig+0x6a0/0x6a0 [ 11.553197] ? security_mmap_file+0xcc/0x140 [ 11.553201] ? __do_sys_finit_module+0xff/0x180 [ 11.553203] __do_sys_finit_module+0xff/0x180 [ 11.553205] ? __ia32_sys_init_module+0xa0/0xa0 [ 11.553207] ? __fget_files+0x12f/0x1a0 [ 11.553211] do_syscall_64+0x33/0x80 [ 11.553213] entry_SYSCALL_64_after_hwframe+0x44/0xae Second call trace (the call which causes the double-free KASAN alert): [ 31.074729] Call Trace: [ 31.074733] dump_stack+0x9b/0xce [ 31.074741] usbhid_stop+0xb4/0x480 [usbhid] [ 31.074752] hid_device_remove+0xcb/0x200 [hid] [ 31.074767] device_release_driver_internal+0x1e5/0x4a0 [ 31.074774] bus_remove_device+0x292/0x560 [ 31.074779] device_del+0x4f8/0xca0 [ 31.074785] ? __device_link_del+0x340/0x340 [ 31.074791] ? _raw_spin_lock_irq+0x81/0xd1 [ 31.074796] ? _raw_spin_lock+0xe0/0xe0 [ 31.074801] hid_destroy_device+0xbf/0x140 [hid] [ 31.074814] usbhid_disconnect+0xa0/0xe0 [usbhid] [ 31.074823] usb_unbind_interface+0x160/0x860 [usbcore] [ 31.074860] ? mutex_unlock+0x1d/0x40 [ 31.074865] device_release_driver_internal+0x1e5/0x4a0 [ 31.074870] bus_remove_device+0x292/0x560 [ 31.074875] device_del+0x4f8/0xca0 [ 31.074881] ? __device_link_del+0x340/0x340 [ 31.074887] ? usb_remove_ep_devs+0x37/0x80 [usbcore] [ 31.074922] ? remove_intf_ep_devs+0xe3/0x180 [usbcore] [ 31.074956] usb_disable_device+0x1b0/0x560 [usbcore] [ 31.074991] usb_disconnect+0x22e/0x860 [usbcore] [ 31.075025] hub_event+0xa5d/0x3240 [usbcore] [ 31.075060] ? newidle_balance+0x8ba/0xd80 [ 31.075066] ? hub_port_debounce+0x280/0x280 [usbcore] [ 31.075099] ? update_load_avg+0x1c1/0x1c00 [ 31.075104] ? update_curr+0x321/0x5c0 [ 31.075107] ? run_rebalance_domains+0x100/0x100 [ 31.075112] ? dequeue_entity+0x27f/0x1240 [ 31.075117] ? pick_next_task_fair+0x9a/0xd60 [ 31.075122] ? __switch_to+0x3cc/0xba0 [ 31.075128] ? __schedule+0x9cc/0x1be0 [ 31.075132] ? read_word_at_a_time+0xe/0x20 [ 31.075137] ? strscpy+0x97/0x320 [ 31.075142] process_one_work+0x690/0x1000 [ 31.075148] worker_thread+0x87/0xb20 [ 31.075154] ? __kthread_parkme+0x8f/0x100 [ 31.075159] ? process_one_work+0x1000/0x1000 [ 31.075164] kthread+0x313/0x3e0 [ 31.075168] ? kthread_parkme+0x80/0x80 [ 31.075173] ret_from_fork+0x22/0x30
Comment 14 José Expósito 2021-05-14 08:22:34 UTC
Hi, I'm experimenting the same issue. The cause is a bug introduced in c0dc5582812dfaf122a6eb188b0cd8e5ae4b0387. I submitted a patch to fix it a few days ago: https://lore.kernel.org/patchwork/patch/1423070/ I hope it also work for you.
Comment 15 Götz 2021-07-15 13:46:28 UTC
Looks like your path was applied and is on v5.13 https://github.com/torvalds/linux/commit/4fb125192563670e820991de48f8db495ecc7ff7