[Bug 513642] Fwd: Kernel panic when handing Motorola S305 headset

[Bao Liang]

just fyi, and added a correction to #3, it's 2.6.33-rc8


---------- Forwarded message ----------
From: Liang Bao <tim.bao at gmail.com>
Date: 2010/3/1
Subject: Re: Kernel panic when handing Motorola S305 headset
To: linux-bluetooth at vger.kernel.org


I'd like to continue the previous thread on that Motorola S305 causes
kernel panic because I did find some clue here. Sorry for misleading
guess one month ago if any.

Recap the problem here so that you don't to read the first long post.
The pattern to reproduce the issue is:
1. Pair the S305 headset from the phone or the PC( I am using a Ubuntu)
2. Remove pairing on the phone or PC
3. Power off and then power on S305.
4. The S305 will try to connect and since link key removed on this
side it will try to pair. Input 0000.
5. Kernel panic happens. This can be observed on kernel version
2.6.29(on the Droid phone, yes, it's a modified version),
2.6.31-19-generic on a Ubuntu and a pretty latest 2.6.33-020633rc8
from Ubuntu official RC release.

The exact kernel crash point is
            if (l2cap_check_security(sk)) {
                 if (bt_sk(sk)->defer_setup) {
                     struct sock *parent = bt_sk(sk)->parent;
                     rsp.result = cpu_to_le16(L2CAP_CR_PEND);
                     rsp.status = cpu_to_le16(L2CAP_CS_AUTHOR_PEND);
>>>                   parent->sk_data_ready(parent, 0)
                 } else {

After tracing the issue for a couple of weeks, I find the difference
between a normal flow and the panic one. If the user space process
accepts the L2CAP connection request before L2CAP_INFO_RSP received,
the following calls will be carried out:

l2cap_sock_accept-> bt_accept_dequeue->bt_accept_unlink(in the branch
bt_sk(parent)->defer_setup)-> set bt_sk(sk)->parent = NULL. Later when
L2CAP_INFO_RSP arrives, the l2cap_conn_start() will try to call the
marked line above and de-referring NULL happen.

To fix this, shall we consider checking if a pending socket can be
accepted in bt_accept_dequeue() prior to a pending L2CAP_INFO_REQ
responded? For example,  adding a check to BT_CONNECT2 in
af_bluetooth.c.

215         if (sk->sk_state == BT_CONNECTED || !newsock ||
216                         ( bt_sk(parent)->defer_setup &&
(sk->sk_state != BT_CONNECT2))) {

Again, I am not sure if this will bring a side-effect. Please advise
the most appropriate way. Thanks.

p.s: I attached partial trace files for those who're interested to the
traces.


** Attachment added: "s305-good-bad-trace.txt"
   http://launchpadlibrarian.net/39911753/s305-good-bad-trace.txt

-- 
Kernel panic when a Motorola S305 Stereo headset requests connection
https://bugs.launchpad.net/bugs/513642
You received this bug notification because you are a member of
Bluetooth, which is subscribed to bluez in ubuntu.