• Kiran K's avatar
    Bluetooth: Fix race condition in handling NOP command · ecb71f25
    Kiran K authored
    For NOP command, need to cancel work scheduled on cmd_timer,
    on receiving command status or commmand complete event.
    
    Below use case might lead to race condition multiple when NOP
    commands are queued sequentially:
    
    hci_cmd_work() {
       if (atomic_read(&hdev->cmd_cnt) {
                .
                .
                .
          atomic_dec(&hdev->cmd_cnt);
          hci_send_frame(hdev,...);
          schedule_delayed_work(&hdev->cmd_timer,...);
       }
    }
    
    On receiving event for first NOP, the work scheduled on hdev->cmd_timer
    is not cancelled and second NOP is dequeued and sent to controller.
    
    While waiting for an event for second NOP command, work scheduled on
    cmd_timer for the first NOP can get scheduled, resulting in sending third
    NOP command (sending back to back NOP commands). This might
    cause issues at controller side (like memory overrun, controller going
    unresponsive) resulting in hci tx timeouts, hardware errors etc.
    
    The fix to this issue is to cancel the delayed work scheduled on
    cmd_timer on receiving command status or command complete event for
    NOP command (this patch handles NOP command same as any other SIG
    command).
    Signed-off-by: default avatarKiran K <kiran.k@intel.com>
    Reviewed-by: default avatarChethan T N <chethan.tumkur.narayan@intel.com>
    Reviewed-by: default avatarSrivatsa Ravishankar <ravishankar.srivatsa@intel.com>
    Acked-by: default avatarManish Mandlik <mmandlik@google.com>
    Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
    ecb71f25
hci_event.c 156 KB