[ +CC: linux-usb, even if this does not look like a USB issue ] On Sat, Jun 09, 2018 at 11:50:34AM +0200, Udo van den Heuvel wrote: > Hello, > > My Holus GPSport 245 was used to download a gpx track. Afterwards I > turned the device off while it was attached to USB so it could charge. > Later I found these messages you can find below. > Is this an actual bug? Well, you've got some kind of corruption going on somewhere. > [223632.768623] usb 1-7: cp210x converter now attached to ttyUSB0 > [225389.048501] usb 1-7: USB disconnect, device number 6 > [225389.048758] cp210x ttyUSB0: cp210x converter now disconnected from > ttyUSB0 > [225389.048785] kernel tried to execute NX-protected page - exploit > attempt? (uid: 0) > [225389.048788] BUG: unable to handle kernel paging request at > ffffffffc08b64e0 > [225389.048797] IP: usb_serial_exit+0x35df/0xff [usbserial] > [225389.048799] PGD 2ea00c067 P4D 2ea00c067 PUD 2ea00e067 PMD 408590067 > PTE 8000000109510163 > [225389.048807] Oops: 0011 [#1] PREEMPT SMP NOPTI > [225389.048809] Modules linked in: cp210x usbserial it87(O) hwmon_vid First, please try and reproduce this after blacklisting this out-of-tree it87 module. > fuse ipt_REJECT nf_reject_ipv4 xt_u32 xt_multiport iptable_filter > ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 > nf_defrag_ipv4 nf_nat_ipv4 nf_nat cpufreq_userspace > nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT > nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack > msr nf_conntrack ip6table_filter ip6_tables eeprom uvcvideo > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_usb_audio videodev > snd_hwdep videobuf2_common cdc_acm snd_usbmidi_lib snd_rawmidi amdgpu > snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec > snd_hda_core snd_seq snd_seq_device snd_pcm chash snd_timer gpu_sched > backlight snd ttm i2c_piix4 evdev acpi_cpufreq k10temp nfsd auth_rpcgss > nfs_acl > [225389.048857] lockd grace sunrpc binfmt_misc ip_tables x_tables > hid_generic sr_mod cdrom usbhid i2c_dev autofs4 [last unloaded: hwmon_vid] > [225389.048871] CPU: 1 PID: 5717 Comm: kworker/1:2 Tainted: G > O 4.16.14 #5 > [225389.048873] Hardware name: Gigabyte Technology Co., Ltd. X470 AORUS > ULTRA GAMING/X470 AORUS ULTRA GAMING-CF, BIOS F3g 05/10/2018 > [225389.048880] Workqueue: usb_hub_wq hub_event > [225389.048886] RIP: 0010:usb_serial_exit+0x35df/0xff [usbserial] > [225389.048889] RSP: 0018:ffff90d3c8c27be8 EFLAGS: 00010282 > [225389.048892] RAX: ffffffffc08b64e0 RBX: ffff8bd5d2190ae8 RCX: > 0000000000000000 > [225389.048895] RDX: 0000000080000001 RSI: 0000000000000282 RDI: > ffff8bd5d2190ad8 > [225389.048897] RBP: ffff8bd5d2190ad8 R08: 0000000000000000 R09: > 0000000000000000 > [225389.048899] R10: 0000000000000000 R11: 0000000000000000 R12: > ffff8bd392029480 > [225389.048902] R13: ffff8bd64b4d4e00 R14: ffff8bd64d2fc030 R15: > ffff8bd64d2fc030 > [225389.048905] FS: 0000000000000000(0000) GS:ffff8bd65ee40000(0000) > knlGS:0000000000000000 > [225389.048908] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [225389.048910] CR2: ffffffffc08b64e0 CR3: 00000003f0b50000 CR4: > 00000000003406e0 > [225389.048912] Call Trace: > [225389.048918] ? device_release+0x39/0xa0 > [225389.048924] ? kobject_put+0xa1/0x1c0 > [225389.048929] ? usb_serial_put+0x4c/0xf0 [usbserial] > [225389.048933] ? usb_serial_disconnect+0xdd/0x100 [usbserial] > [225389.048938] ? usb_unbind_interface+0x66/0x1e0 > [225389.048942] ? device_release_driver_internal+0x17a/0x230 > [225389.048946] ? bus_remove_device+0xe0/0x150 > [225389.048950] ? device_del+0x129/0x330 > [225389.048954] ? usb_disable_device+0x8d/0x230 > [225389.048958] ? usb_disconnect+0xb1/0x270 > [225389.048962] ? hub_event+0x5f5/0x13b0 > [225389.048967] ? SyS_uname+0x11/0xa0 > [225389.048971] ? process_one_work+0x1a1/0x2f0 > [225389.048974] ? worker_thread+0x26/0x3f0 > [225389.048978] ? process_one_work+0x2f0/0x2f0 > [225389.048982] ? kthread+0x109/0x120 > [225389.048986] ? kthread_create_on_node+0x60/0x60 > [225389.048991] ? ret_from_fork+0x22/0x40 > [225389.048994] Code: ff ff ff 29 1a 8b c0 ff ff ff ff 50 73 8b c0 ff ff > ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 <e0> 34 8b c0 ff ff ff ff 00 00 00 00 00 00 00 00 00 65 8b c0 ff > [225389.049043] RIP: usb_serial_exit+0x35df/0xff [usbserial] RSP: > ffff90d3c8c27be8 > [225389.049045] CR2: ffffffffc08b64e0 > [225389.049048] ---[ end trace 43c4e5674b0ca81f ]--- This looks to me like you've got a struct device whose release pointer is pointing into a non-executable page. The IP symbol looks weird usb_serial_exit+0x35df/0xff but this could correspond with usb_serial_port_release (check /proc/kallsyms as root). Enabling dynamic debugging for usbserial might give some indication of how far you get in usb_serial_put(), but this smells like an x86/mem (or hardware?) issue. Did you say you could reproduce this easily? Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
