Fix an HCI race condition when transmitting a packet
There is a race condition when calling event_command_ready() -> transmit_fragment() -> hci_transmit() If right after hci_transmit() there is thread context switch and another thread executes filter_incoming_event() for the same command, the corresponding packet/command will be taken off the commands_pending_response list and free()-ed. However, after the execution on the first thread continues within transmit_fragment(), the execution logic will continue using the "packet" that was already free()-ed by the other thread. To prevent this from happening, the "commands_pending_response_mutex" within event_command_ready() has to protect the transmit_fragment() execution and the update_command_response_timer() function right after it. Also: * Changed the "commands_pending_response_mutex" to recursive_mutex * Added "commands_pending_response_mutex" protection in few other places where "commands_pending_response" itself is used. Bug: 36205494 Test: Running ASAN build Change-Id: I63677ad1f2b28683c321631e9e29e4f01628d269
Loading
Please register or sign in to comment