On Sun, Feb 27, 2011 at 5:30 AM, Andrei Warkentin <andreiw@xxxxxxxxxxxx> wrote: > On Fri, Feb 18, 2011 at 2:21 PM, Andrei Warkentin <andreiw@xxxxxxxxxxxx> wrote: >> On Mon, Feb 14, 2011 at 4:23 PM, Andrei Warkentin <andreiw@xxxxxxxxxxxx> wrote: >>> On Sat, Feb 12, 2011 at 12:47 AM, Andrei Warkentin <andreiw@xxxxxxxxxxxx> wrote: >>>> On Fri, Feb 11, 2011 at 5:07 PM, Andrei Warkentin <andreiw@xxxxxxxxxxxx> wrote: >>>>> Dear List, >>>>> >>>>> I've run into an interesting problem. Excuse me in advance if this was >>>>> already covered here, or for my explanations, since I'm not too >>>>> familiar with overall flow within BlueZ or Bluetooth specifics... >>>>> We've had some hardware config issues that resulted in garbage/malformed >>>>> messages arriving via H4 into the HCI layer. We've since resolved >>>>> these, but it got me thinking. The issues would result in certain HCI >>>>> messages being missed, including occasionally disconnect events being >>>>> missed, and a subsequent connect event would result in a double add. >>>>> >>>>> I was thinking about how to fix at the very least the crash. The sysfs >>>>> object is created as a last step after getting a "connection >>>>> completed" HCI message, I think. What I am unsure about is if it's >>>>> safe to just ignore the add if there is already a sysfs entry... >>>>> >>>>> So I would think the HCI core needs some resiliency against >>>>> bad/malignant bluetooth controllers, and perform error >>>>> recovery/resynchronization. Perhaps maybe there is room for a virtual >>>>> hci controller that just injects various message types to see how well >>>>> the core can cope? >>>>> >>>>> Thanks in advance, >>>>> A >>>> >>>> To further explain the issue, here is what was happening - >>>> >>>> 0) A BT device is paired. >>>> 1) Host goes into sleep mode. >>>> 2) BT device turns off. >>>> 3) Host wakes up due to BT waking the host. Due to UART resume issues, >>>> HCI message corrupted. hci_disconn_complete_evt never gets called. >>>> 4) BT device turns on. >>>> 5) devref gets incremented in hci_conn_complete_evt, and is now 2. >>>> 6) BT device turns off. hci_disconn_complete_evt is called, conn hash >>>> is deleted, but sysfs entry not cleaned up since >>>> atomic_dec_and_test(&conn->devref) != 0. >>>> 7) BT device turns on. sysfs add fails since it never was cleaned up. >>>> >>>> The attached patch takes care of that. I'm not too familiar with BlueZ >>>> (or bluetooth :-(), so I would like your feedback. In particular, I am >>>> unsure about sync connections. >>>> The primary issue overall is that HCI core doesn't handle HCI issues >>>> (whether caused by transport issues, or bad/malicious BT controller). >>>> I am curious if there are other ways to break the core. >>>> >>>> Thanks, >>>> A >>>> >>> >>> Anyone? >>> >> >> Anyone? Who should I talk to about HCI? >> > > Anyone pretty please :)? I'm positive what I'm doing isn't necessarily > right, but I do think this is a real issue in current BlueZ code that > needs work. HCI core should be more resilient to HCI transport issues, > after all, the BT HCI spec does mandate specific behavior. > > A > Anyone? I mean anyone can literally craft a malicious usb device that will act like a bluetooth controller and crash the OS... Nobody is at all interested? A -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
