kernel oops on unplugged USB device

[thomasjfox]

Hello,

when you unplug an idle USB ISDN device (hfcsusb) and later on try to use it,
this will lead to a kernel oops:

Oct 4 20:30:01 mail kernel: BUG: unable to handle kernel NULL pointer dereference at 00000028
Oct 4 20:30:01 mail kernel: IP: [] _raw_spin_lock_irqsave+0xc/0x30
Oct 4 20:30:01 mail kernel: *pdpt = 000000002d876001 *pde = 0000000000000000
Oct 4 20:30:01 mail kernel: Oops: 0002 [#1] SMP
Oct 4 20:30:01 mail kernel: Modules linked in: xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo nf_conntrack_netlink aesni_intel ablk_helper cryptd lrw xts gf128mul aes_i586 capi kernelcapi isdn hfcsusb(O) mISDNisar(O) mISDNipac(O) mISDN_core(O) ppp_deflate zlib_deflate bsd_comp ppp_generic slhc iptable_raw iptable_mangle ipt_MASQUERADE xt_nat xt_REDIRECT xt_mark iptable_nat nf_nat_ipv4 xt_nfacct xt_TCPMSS ipt_REJECT xt_LOG xt_limit nf_conntrack_ipv4 nf_defrag_ipv4 xt_tcpudp xt_condition xt_policy xt_connmark xt_owner xt_recent xt_conntrack nfnetlink_acct nfnetlink iptable_filter ip_tables x_tables nf_nat_tftp nf_nat_irc nf_nat_pptp nf_nat_proto_gre nf_nat_ftp nf_nat nf_conntrack_tftp nf_conntrack_socks nf_conntrack_irc nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_ftp nf_conntrack dm_mirror dm_region_hash dm_log tg3 sg libphy ptp rtc_cmos hpwdt pps_core hwmon button ext4 jbd2 mbcache crc16 ahci libahci libata uhci_hcd ehci_pci xhci_hcd ehci_hcd dm_mod microcode
Oct 4 20:30:01 mail kernel: CPU: 1 PID: 3224 Comm: mISDNcapid Tainted: G O 3.14.79-7.i2n.i686.PAE #1
Oct 4 20:30:01 mail kernel: Hardware name: HP ProLiant DL320e Gen8 v2, BIOS P80 03/28/2014
Oct 4 20:30:01 mail kernel: task: e99b5aa0 ti: e8c08000 task.ti: e8c08000
Oct 4 20:30:01 mail kernel: EIP: 0060:[] EFLAGS: 00010086 CPU: 1
Oct 4 20:30:01 mail kernel: EIP is at _raw_spin_lock_irqsave+0xc/0x30
Oct 4 20:30:01 mail kernel: EAX: 00000028 EBX: 00000286 ECX: f72a6918 EDX: 00000100
Oct 4 20:30:01 mail kernel: ESI: 00000028 EDI: f72a6900 EBP: e8c09d98 ESP: e8c09d94
Oct 4 20:30:01 mail kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Oct 4 20:30:01 mail kernel: CR0: 80050033 CR2: 00000028 CR3: 2d862000 CR4: 001407f0
Oct 4 20:30:01 mail kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Oct 4 20:30:01 mail kernel: DR6: fffe0ff0 DR7: 00000400
Oct 4 20:30:01 mail kernel: Stack:
Oct 4 20:30:01 mail kernel: 0000001c e8c09dac c12b6eff 00000000 e841b200 f72a6900 e8c09dd0 f895f64c
Oct 4 20:30:01 mail kernel: 00000021 e8c09dd0 c1190b41 e9c75ee5 e8c09eac e841b200 e8c09eac e8c09e08
Oct 4 20:30:01 mail kernel: f895d930 ffffffff f38b2940 01289bd8 00000000 ee508c80 e8c09e44 f72a6918
Oct 4 20:30:01 mail kernel: Call Trace:
Oct 4 20:30:01 mail kernel: [] skb_queue_tail+0x1f/0x50
Oct 4 20:30:01 mail kernel: [] mISDN_queue_message+0x1c/0x80 [mISDN_core]
Oct 4 20:30:01 mail kernel: [] ? memcpy_fromiovec+0x41/0x60
Oct 4 20:30:01 mail kernel: [] mISDN_sock_sendmsg+0x190/0x1d0 [mISDN_core]
Oct 4 20:30:01 mail kernel: [] sock_sendmsg+0x5f/0x90
Oct 4 20:30:01 mail kernel: [] ? core_sys_select+0x167/0x220
Oct 4 20:30:01 mail kernel: [] SyS_sendto+0x115/0x150
Oct 4 20:30:01 mail kernel: [] ? mISDN_open+0xb0/0xb0 [mISDN_core]
Oct 4 20:30:01 mail kernel: [] ? do_vfs_ioctl+0x72/0x590
Oct 4 20:30:01 mail kernel: [] ? fsnotify+0x179/0x260
Oct 4 20:30:01 mail kernel: [] SyS_socketcall+0x1cd/0x2d0
Oct 4 20:30:01 mail kernel: [] sysenter_do_call+0x12/0x12
Oct 4 20:30:01 mail kernel: Code: e9 08 38 d1 75 04 5d c3 f3 90 0f b6 10 38 d1 75 f7 5d c3 8d b6 00 00 00 00 8d bf 00 00 00 00 55 89 e5 53 9c 5b fa ba 00 01 00 00 66 0f c1 10 89 d1 66 c1 e9 08 38 d1 75 07 89 d8 5b 5d c3 f3
Oct 4 20:30:01 mail kernel: EIP: [] _raw_spin_lock_irqsave+0xc/0x30 SS:ESP 0068:e8c09d94
Oct 4 20:30:01 mail kernel: CR2: 0000000000000028
Oct 4 20:30:01 mail kernel: ---[ end trace 5bc75324607e4152 ]---

The used mISDN code is at the current git HEAD a460993 from 2017-08-28.

Noticed the issue while working on a server next to our ISDN box and unplugged the ISDN TA by accident :D I consider this issue low priority, still the kernel probably shouldn't oops and block on reboot.

[kkeil]

Agreed this should not lead to an oops.
One question for reproduction: You did unplug it, an then you tried a connection without replugging it, didn't you ?
Or did you plug it again before the connection was tried ?

[thomasjfox]

On Friday, 13 October 2017 20:15:47 CEST Karsten Keil wrote: Agreed this should not lead to an oops. One question for reproduction: You did unplug it, an then you tried a connection without replugging it, didn't you ? Or did you plug it again before the connection was tried ?

yes, the first scenario happened: Cable got unplugged and our daily automatic fax system test tried to send an outgoing fax while it was still unplugged. Since the fix didn't arrive, the nagios monitoring system paged me. Plugging the cable back in didn't help. The kernel was already in a bad state and didn't even reboot properly anymore. I had to power off by force.