Bug 210241
| Summary: | Crashes after unplugging Apple Trackpad 2 - KASAN reports errors | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Felix Hädicke (felixhaedicke) |
| Component: | Input Devices | Assignee: | drivers_input-devices |
| Status: | NEW --- | ||
| Severity: | normal | CC: | andrenbrandao, auxsvr, goetzchrist, jkosina, jose.exposito89, marek.wyborski, mike.osipov, n.sherlock, satur9nine, shahar.evron, toni |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 5.9.8 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
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 |
||
Created attachment 293707 [details]
Used kernel configuration
Works when unloading / blacklisting the "hid-generic" driver, too. The problem only occurs when both driver modules, hid-generic and hid-magicmouse are loaded. 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... 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... 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! Please let me know if I can do something else to help resolve this, e.g. testing with a different kernel version/config. I'm experiencing the same bug, detected by KASAN, with Proxmox kernel 5.4.78-2-pve (based on Ubuntu Focal's kernel). 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.
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. Created attachment 296239 [details]
add debug output: print call trace for every usbhid_stop() call
Created attachment 296241 [details] dmesg output with kernel 5.12-rc6 with more debug information dmesg with debug information (see attachment 296239 [details]). 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
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. Looks like your path was applied and is on v5.13 https://github.com/torvalds/linux/commit/4fb125192563670e820991de48f8db495ecc7ff7 |
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.