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

[Anastasia Belova]

04/07/25 13:07, 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.

Этот бэкпорт повторяет бэкпорт b3cec8a42fcd11d05313c724f27e01b1db77522c 
для 5.15.
Туда e4412654e260842e1a94ffe0d4026e8a6fd34246 не был затянут. Предлагаю 
все же
для соответствия с международной веткой 5.15 оставить адаптацию такой. Если
комментарий к разрешению конфликта нужен обязательно, могу сформировать
вторую версию.