ACK: [SRU][N][PATCH 0/1] CVE-2024-53207

[Andrei Gherzan]

On 26/09/07 05:08PM, Cengiz Can via kernel-team wrote:
> https://ubuntu.com/security/CVE-2024-53207
> 
> [ Impact ]
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> Bluetooth: MGMT: Fix possible deadlocks
> 
> This fixes possible deadlocks like the following caused by hci_cmd_sync_dequeue
> causing the destroy function to run:
> 
> INFO: task kworker/u19:0:143 blocked for more than 120 seconds. Tainted: G W O
> 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1 "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:kworker/u19:0 state:D stack:0 pid:143 tgid:143 ppid:2 flags:0x00004000
> Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: <TASK>
> __schedule+0x374/0xaf0 schedule+0x3c/0xf0 schedule_preempt_disabled+0x1c/0x30
> __mutex_lock.constprop.0+0x3ef/0x7a0 __mutex_lock_slowpath+0x13/0x20
> mutex_lock+0x3c/0x50 mgmt_set_connectable_complete+0xa4/0x150 [bluetooth] ?
> kfree+0x211/0x2a0 hci_cmd_sync_dequeue+0xae/0x130 [bluetooth] ?
> __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth] cmd_complete_rsp+0x26/0x80
> [bluetooth] mgmt_pending_foreach+0x4d/0x70 [bluetooth]
> __mgmt_power_off+0x8d/0x180 [bluetooth] ? _raw_spin_unlock_irq+0x23/0x40
> hci_dev_close_sync+0x445/0x5b0 [bluetooth] hci_set_powered_sync+0x149/0x250
> [bluetooth] set_powered_sync+0x24/0x60 [bluetooth] hci_cmd_sync_work+0x90/0x150
> [bluetooth] process_one_work+0x13e/0x300 worker_thread+0x2f7/0x420 ?
> __pfx_worker_thread+0x10/0x10 kthread+0x107/0x140 ? __pfx_kthread+0x10/0x10
> ret_from_fork+0x3d/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
> </TASK>
> 
> The deadlock arises in the Bluetooth management (MGMT) layer when
> hci_cmd_sync_dequeue runs a command's destroy/completion callback in a context
> that already holds hdev->lock. The completion callbacks then attempt to take
> the same lock again, causing the hci_cmd_sync_work kworker to block
> indefinitely. This can occur during ordinary MGMT command sequences such as
> setting a device connectable and powering an adapter off.
> 
> [ Fix ]
> 
> noble/linux: backported from a66dfaf18fd6
> 
> The upstream fix makes the affected MGMT completion handlers detect the case
> where the command was cancelled or is no longer valid and return early instead
> of re-entering the locked completion path.
> 
> During the backport, the noble tree already handled the listed commands for
> the pending_find hunks via the refactored idiom
> "err == -ECANCELED || !mgmt_pending_valid(hdev, cmd)", which was kept. For
> set_default_phy_complete and read_local_oob_ext_data_complete the command uses
> mgmt_pending_new (never placed on the pending list), so
> mgmt_pending_valid/pending_find would always fail; a bare
> "if (err == -ECANCELED) return;" guard was added there, matching
> mgmt_remove_adv_monitor_complete's idiom.
> 
> [ Test Plan ]
> 
> Build and boot tested.
> 
> [ Where Problems Could Occur ]
> 
> A regression would most likely surface on systems that use a Bluetooth
> controller, affecting MGMT operations such as powering the adapter on or off,
> toggling connectable/discoverable mode, PHY configuration, or reading local
> out-of-band data; in the worst case a botched change could hang the
> hci_cmd_sync_work kworker or drop legitimate command completions. Systems
> without Bluetooth hardware, or that never bring up a Bluetooth adapter, are not
> affected.
> 
> [ Other Info ]
> 
> Kybele flow-v10-17-ge6719947. Reference: e4188fb1/v1

Acked-by: Andrei Gherzan <andrei.gherzan at canonical.com>

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260911/0a9d0126/attachment.sig>