[lvc-project] [PATCH 5.10] Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event

[Fedor Pchelkin]

On Thu, 03. Jul 18:56, Anastasia Belova wrote:
> From: Sean Wang <sean.wang at mediatek.com>
> 
> [ Upstream commit 0fab6361c4ba17d1b43a991bef4238a3c1754d35 ]
> 
> We should not access skb buffer data anymore after hci_recv_frame was
> called.
> 
> [   39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0
> [   39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker
> [   39.634962] Call trace:
> [   39.634974]  dump_backtrace+0x0/0x3b8
> [   39.634999]  show_stack+0x20/0x2c
> [   39.635016]  dump_stack_lvl+0x60/0x78
> [   39.635040]  print_address_description+0x70/0x2f0
> [   39.635062]  kasan_report+0x154/0x194
> [   39.635079]  __asan_report_load1_noabort+0x44/0x50
> [   39.635099]  btmtksdio_recv_event+0x1b0/0x1c4
> [   39.635129]  btmtksdio_txrx_work+0x6cc/0xac4
> [   39.635157]  process_one_work+0x560/0xc5c
> [   39.635177]  worker_thread+0x7ec/0xcc0
> [   39.635195]  kthread+0x2d0/0x3d0
> [   39.635215]  ret_from_fork+0x10/0x20
> [   39.635247] Allocated by task 0:
> [   39.635260] (stack is not available)
> [   39.635281] Freed by task 2392:
> [   39.635295]  kasan_save_stack+0x38/0x68
> [   39.635319]  kasan_set_track+0x28/0x3c
> [   39.635338]  kasan_set_free_info+0x28/0x4c
> [   39.635357]  ____kasan_slab_free+0x104/0x150
> [   39.635374]  __kasan_slab_free+0x18/0x28
> [   39.635391]  slab_free_freelist_hook+0x114/0x248
> [   39.635410]  kfree+0xf8/0x2b4
> [   39.635427]  skb_free_head+0x58/0x98
> [   39.635447]  skb_release_data+0x2f4/0x410
> [   39.635464]  skb_release_all+0x50/0x60
> [   39.635481]  kfree_skb+0xc8/0x25c
> [   39.635498]  hci_event_packet+0x894/0xca4 [bluetooth]
> [   39.635721]  hci_rx_work+0x1c8/0x68c [bluetooth]
> [   39.635925]  process_one_work+0x560/0xc5c
> [   39.635951]  worker_thread+0x7ec/0xcc0
> [   39.635970]  kthread+0x2d0/0x3d0
> [   39.635990]  ret_from_fork+0x10/0x20
> [   39.636021] The buggy address belongs to the object at ffffff80cf28a600
>                 which belongs to the cache kmalloc-512 of size 512
> [   39.636039] The buggy address is located 13 bytes inside of
>                 512-byte region [ffffff80cf28a600, ffffff80cf28a800)
> 
> Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices")
> Co-developed-by: Yake Yang <yake.yang at mediatek.com>
> Signed-off-by: Yake Yang <yake.yang at mediatek.com>
> Signed-off-by: Sean Wang <sean.wang at mediatek.com>
> Signed-off-by: Marcel Holtmann <marcel at holtmann.org>
> Signed-off-by: Sasha Levin <sashal at kernel.org>
> Signed-off-by: Anastasia Belova <abelova at astralinux.ru>
> ---
> Backport fix for CVE-2022-49470
>  drivers/bluetooth/btmtksdio.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> index c41560be39fb..6b31ee1a1dd9 100644
> --- a/drivers/bluetooth/btmtksdio.c
> +++ b/drivers/bluetooth/btmtksdio.c
> @@ -331,6 +331,7 @@ static int btmtksdio_recv_event(struct hci_dev *hdev, struct sk_buff *skb)
>  {
>  	struct btmtksdio_dev *bdev = hci_get_drvdata(hdev);
>  	struct hci_event_hdr *hdr = (void *)skb->data;
> +	u8 evt = hdr->evt;
>  	int err;
>  
>  	/* Fix up the vendor event id with 0xff for vendor specific instead

Здесь идёт фрагмент

	 * of 0xe4 so that event send via monitoring socket can be parsed
	 * properly.
	 */
	if (hdr->evt == 0xe4)
		hdr->evt = HCI_EV_VENDOR;

Таким образом, в evt на стеке может в этом случае храниться устаревшее
значение, с которым потом идёт сравнение.

Поэтому важно свою проводимую нетривиальную в большинстве случаев
адаптацию описывать: удобнее всего либо в комментарии бэкпортёра в
квадратных скобках над своей подписью (пойдет в гит-историю), либо в
зоне после ---. Если портируется серия патчей, то можно свои мысли
изложить в сопроводительном письме.

Это позволит другим людям составить представление о том, какие
дополнительные действия проводились по адаптации патча: важно, чтобы они
были сделаны не машинально на уровне "применилось/скомпилировалось, а
большего и не надо", а всё-таки был изучен контекст патча, суть конфликта
и т.п.

Все нюансы отражены в
https://portal.linuxtesting.ru/How-to-send-patches-to-kernel.html#Сопроводительное-письмо


Конфликт в контексте 5.10 растёт из-за отсутствия там коммита

commit e4412654e260842e1a94ffe0d4026e8a6fd34246
Author: Sean Wang <sean.wang at mediatek.com>
Date:   Wed Feb 9 02:17:41 2022 +0800

    Bluetooth: mediatek: fix the conflict between mtk and msft vendor event


Можно ознакомиться с его содержимым и основной целью. Не вижу серьёзных
причин не портировать его в 5.10.

> @@ -355,7 +356,7 @@ static int btmtksdio_recv_event(struct hci_dev *hdev, struct sk_buff *skb)
>  	if (err < 0)
>  		goto err_free_skb;
>  
> -	if (hdr->evt == HCI_EV_VENDOR) {
> +	if (evt == HCI_EV_VENDOR) {
>  		if (test_and_clear_bit(BTMTKSDIO_TX_WAIT_VND_EVT,
>  				       &bdev->tx_state)) {
>  			/* Barrier to sync with other CPUs */
> -- 
> 2.43.0