On Fri, Aug 26, 2022 at 10:35:43AM +0900, Tetsuo Handa wrote: > On 2022/08/26 0:09, Alexander Potapenko wrote: > > On Thu, Aug 25, 2022 at 4:34 PM Tetsuo Handa > > <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > >> > >> Hello. > > Hi Tetsuo, > > > >> I found that your patch was applied. But since the reproducer tested only 0 byte > >> case, I think that rejecting only less than sizeof(struct htc_frame_hdr) bytes > >> is not sufficient. > >> > >> More complete patch with Ack from Toke is waiting at > >> https://lkml.kernel.org/r/7acfa1be-4b5c-b2ce-de43-95b0593fb3e5@xxxxxxxxxxxxxxxxxxx . > > > > Thanks for letting me know! I just checked that your patch indeed > > fixes the issue I am facing. > > If it is more complete, I think we'd indeed better use yours. > > I recognized that "ath9k: fix an uninit value use in ath9k_htc_rx_msg()" is > local to KMSAN tree. > https://github.com/google/kmsan/commit/d891e35583bf2e81ccc7a2ea548bf7cf47329f40 > > That patch needs to be dropped, for I confirmed that passing pad_len == 8 below > still triggers uninit value at ath9k_htc_fw_panic_report(). (My patch does not > trigger at ath9k_htc_fw_panic_report().) > > fd = syz_usb_connect_ath9k(3, 0x5a, 0x20000800, 0); > *(uint16_t*)0x20000880 = 0 + pad_len; > *(uint16_t*)0x20000882 = 0x4e00; > memmove((uint8_t*)0x20000884, "\x99\x11\x22\x33\x00\x00\x00\x00\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF", 16); > syz_usb_ep_write(fd, 0x82, 4 + pad_len, 0x20000880); > > > > Also, that patch has a skb leak bug; according to comment for ath9k_htc_rx_msg() > > * Service messages (Data, WMI) passed to the corresponding > * endpoint RX handlers, which have to free the SKB. > > , I think that this function is supposed to free skb if skb != NULL. > > If dev_kfree_skb_any(skb) needs to be used when epid is invalid and pipe_id != USB_REG_IN_PIPE, > why it is OK to use kfree_skb(skb) if epid == 0x99 and pipe_id != USB_REG_IN_PIPE ? > > We don't call kfree_skb(skb) if 0 < epid < ENDPOINT_MAX and endpoint->ep_callbacks.rx == NULL. > Why it is OK not to call kfree_skb(skb) in that case? > > Callers can't pass such combinations? I leave these questions to ath9k developers... > Hi Tetsuo, Thank you for this improved patch. My original one was somewhat naive attempt at a resolution. Regards, Phil
