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-next>] [day] [month] [year] [list]
Message-ID: <CANG1+n7Vp-FNCD=uCyHDDFiuCv+u3Ss1L-YUjUc83x7gUD6AkQ@mail.gmail.com>
Date:	Tue, 3 Jun 2014 16:54:41 -0700
From:	Prathmesh Prabhu <pprabhu@...gle.com>
To:	netdev@...r.kernel.org
Subject: Fwd: Kernel panic following bind failure in NCM driver

System info:
- A chromebook with kernel 3.10/3.14 from the ChromiumOS tree.

Steps to reproduce:
- stop modemmanager
- Connect an MBIM modem on an external USB port.
- echo 0 > /sys/bus/usb/devices/xxx/authorized && sleep 1 && echo 1 >
/sys/bus/usb/devices/xxx/authorized

Symptom:
- kernel panic

There is likely a firmware bug in the modem that I'm chasing in
parallel that causes a USB Disconnect after the usb re-authorization.
My concern here is the kernel panic, irrespective of the modem bug.

Attached log has some kernel debugging enabled along with some extra
messages I added. Smell:

<4>[  384.260677] PPP23: usb_authorize_device
...
<7>[  384.261969] bus: 'usb': driver_probe_device: matched device
1-1:2.0 with driver cdc_ncm
<7>[  384.261988] bus: 'usb': really_probe: probing driver cdc_ncm
with device 1-1:2.0
...
<4>[  384.337078] PPP23: something disconnect.
<6>[  384.337087] usb 1-1: USB disconnect, device number 18
<6>[  384.337213] usb 1-1: bind() failure
<7>[  384.337239] cdc_ncm: probe of 1-1:2.0 rejects match -19
...
<6>[  384.337794] usb 1-1: authorized to connect
...
<7>[  384.338142] bus: 'usb': remove device 1-1:2.3
<5>[  384.338162] Oops: 0000 [#1]

My reading so far is that the disconnect races with the ncm driver's
cdc_ncm_bind_common function. This eventually leads to a kernel worker
thread crash.

<5>[  384.341607] Call Trace:
<5>[  384.341616]  [<ffffffff8ea4bc10>] worker_thread+0x13c/0x26f
<5>[  384.341626]  [<ffffffff8ea4bad4>] ? manage_workers.isra.27+0x1d7/0x1d7
<4>[  384.341630] PPP23: trace: usb_remove_ep_devs
<7>[  384.341631] device: 'ep_00': device_unregister
<5>[  384.341646]  [<ffffffff8ea50a92>] kthread+0xae/0xb6
<7>[  384.341655] PM: Removing info for No Bus:ep_00
<5>[  384.341657]  [<ffffffff8ea509e4>] ? __kthread_parkme+0x65/0x65
<5>[  384.341664]  [<ffffffff8ef1471c>] ret_from_fork+0x7c/0xb0
<5>[  384.341668]  [<ffffffff8ea509e4>] ? __kthread_parkme+0x65/0x65

Notes:
- The crash itself is in (possibly related?) kernel worker thread.
- I have not yet figured out the actual crash site.
- This is highly reproducible following the steps above (> 60%
attempts). That's why I think this is indeed related to the ncm driver
/ net usb subsystem.

I'd appreciate any insights into what might be going wrong / precedent.

Thanks,
Prathmesh

Download attachment "kernel.kcrash" of type "application/octet-stream" (19005 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ