some confusions about the design of some bluetooth function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,  
  Here're my confusions about some bluetooth function.
  1.Why does kernel handle the HCI_COMPLETE_EVENT packet firstly and check whether the command packet is the last sent packet after that? 
    As the following figure shows, kernel check whether the packet is the last sent packet after handle the packet. Why not revert the work in hci_cc_xx()  if the completed command is not equal to the last one or just move the judgement before kernel do the work in hci_cc_xx()?
    Here follows the process figure:
+-------------+     +------------------+     +----------------------+
| hci_rx_work | --> | hci_event_packet | --> | hci_cmd_complete_evt |
+-------------+     +------------------+     +----------------------+
                                               |
                                               | switch case
                                               v
                                             +----------------------+
                                             |     hci_cc_xx      |
                                             +----------------------+
                                               |
                                               | command completed
                                               v
                                             +----------------------+  the completed command != the last one   +-------------------+
                                          +- | hci_req_cmd_complete | <--------------------------------------- | hci_sent_cmd_data | <+
                                          |  +----------------------+                                          +-------------------+  |
                                          |    ^                                                                 |                    |
                                          |    |                                                                 | else               |
                                          |    |                                                                 v                    |
                                          |    |                                                               +-------------------+  |
                                          |    +-------------------------------------------------------------- |        xxx        |  |
                                          |                                                                    +-------------------+  |
                                          |                                                                                           |
                                          +-------------------------------------------------------------------------------------------+
Otherwise, malicious controllers may send malformed HCI_COMPLETE_EVENT packet to make kernel change states even the kernel does not mean to. 


  2.Why does kernel only check some status flag in few function of a state?I conclude flags kernel need to verify in the responding to most packets of INIT state.For example. kernel need to verify the HCI_SETUP and HCI_CONFIG flag before handling HCI_COMPLETE_EVENT packet of HCI_OP_READ_LOCAL_VERSION opcode, while it does not do any check for the HCI_COMPLETE_EVENT of HCI_OP_READ_LOCAL_FEATURES.There is more examples in the attachment.

  3.Kernel does not verify the packet orderly. For example, in bredr_init() stage of INIT state, kernel should process packet like following: HCI_OP_READ_LOCAL_FEATURES -> HCI_OP_READ_LOCAL_VERSION -> HCI_OP_READ_BD_ADDR. But it does not check whether HCI_OP_READ_LOCAL_FEATURES packet is responded before it processes the responding of HCI_OP_READ_LOCAL_VERSION packet in hci_cmd_complete_evt() function.

  Above are my puzzles after reading the source code of linux bluetooth subsystem.I think some of them may lead to security issues.
  I'd appreciate a lot if you can solve my confusions. Thanks a lot!

Best regards.




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux