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

[Cengiz Can]

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