linux-kernel - Re: [PATCH v1] Bluetooth: hci_sync: Fix not clearing cmd_sync_work

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <hkjzyyrwhdybojyh335w7gl5bgifdml7l72bnxczizk4p2v4hj@76qh6frpcqcn>
Date: Mon, 19 Jan 2026 14:39:27 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Shuai Zhang <shuai.zhang@....qualcomm.com>
Cc: Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, cheng.jiang@....qualcomm.com,
        quic_chezhou@...cinc.com, wei.deng@....qualcomm.com
Subject: Re: [PATCH v1] Bluetooth: hci_sync: Fix not clearing
 cmd_sync_work_list on power off

On Tue, Dec 09, 2025 at 10:03:47PM +0800, Shuai Zhang wrote:
> When powering off the cmd_sync_work_list may contain items which shall
> be cleared during power off as they shouldn't be run during power off
> sequence.
> 
> Signed-off-by: Shuai Zhang <shuai.zhang@....qualcomm.com>
> ---
>  net/bluetooth/hci_sync.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> index a9f5b1a68..45b593ec7 100644
> --- a/net/bluetooth/hci_sync.c
> +++ b/net/bluetooth/hci_sync.c
> @@ -648,16 +648,22 @@ static void _hci_cmd_sync_cancel_entry(struct hci_dev *hdev,
>  	kfree(entry);
>  }
>  
> -void hci_cmd_sync_clear(struct hci_dev *hdev)
> +/* Clear remaining entries in cmd_sync_work_list */
> +static void hci_cmd_sync_list_clear(struct hci_dev *hdev)
>  {
>  	struct hci_cmd_sync_work_entry *entry, *tmp;
>  
> +	list_for_each_entry_safe(entry, tmp, &hdev->cmd_sync_work_list, list)
> +		_hci_cmd_sync_cancel_entry(hdev, entry, -ECANCELED);
> +}
> +
> +void hci_cmd_sync_clear(struct hci_dev *hdev)
> +{
>  	cancel_work_sync(&hdev->cmd_sync_work);
>  	cancel_work_sync(&hdev->reenable_adv_work);
>  
>  	mutex_lock(&hdev->cmd_sync_work_lock);
> -	list_for_each_entry_safe(entry, tmp, &hdev->cmd_sync_work_list, list)
> -		_hci_cmd_sync_cancel_entry(hdev, entry, -ECANCELED);
> +	hci_cmd_sync_list_clear(hdev);
>  	mutex_unlock(&hdev->cmd_sync_work_lock);
>  }
>  
> @@ -678,6 +684,7 @@ EXPORT_SYMBOL(hci_cmd_sync_cancel);
>   *
>   * - Set result and mark status to HCI_REQ_CANCELED
>   * - Wakeup command sync thread
> + * - Clear cmd_sync_work_list if the interface is down
>   */
>  void hci_cmd_sync_cancel_sync(struct hci_dev *hdev, int err)
>  {
> @@ -692,6 +699,9 @@ void hci_cmd_sync_cancel_sync(struct hci_dev *hdev, int err)
>  
>  		wake_up_interruptible(&hdev->req_wait_q);
>  	}
> +
> +	if (err == EHOSTDOWN || err == -EHOSTDOWN)

Which one? I suppose it can become only one of those.

> +		hci_cmd_sync_list_clear(hdev);

What will prevent ocncurrent modification of the cmd_sync_work_list?

>  }
>  EXPORT_SYMBOL(hci_cmd_sync_cancel_sync);
>  
> @@ -5260,14 +5270,14 @@ int hci_dev_close_sync(struct hci_dev *hdev)
>  		disable_delayed_work(&hdev->power_off);
>  		disable_delayed_work(&hdev->ncmd_timer);
>  		disable_delayed_work(&hdev->le_scan_disable);
> +		hci_cmd_sync_cancel_sync(hdev, ENODEV);
>  	} else {
>  		cancel_delayed_work(&hdev->power_off);
>  		cancel_delayed_work(&hdev->ncmd_timer);
>  		cancel_delayed_work(&hdev->le_scan_disable);
> +		hci_cmd_sync_cancel_sync(hdev, EHOSTDOWN);
>  	}
>  
> -	hci_cmd_sync_cancel_sync(hdev, ENODEV);
> -
>  	cancel_interleave_scan(hdev);
>  
>  	if (hdev->adv_instance_timeout) {
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry