linux-kernel - Re: KMSAN: uninit-value in ath9k_htc_rx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YwtHCDTRMtXe/VTt@equinox>
Date:   Sun, 28 Aug 2022 11:44:24 +0100
From:   Phillip Potter <phil@...lpotter.co.uk>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Alexander Potapenko <glider@...gle.com>,
        ath9k-devel@....qualcomm.com, David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Kalle Valo <kvalo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: KMSAN: uninit-value in ath9k_htc_rx_msg

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@...ove.sakura.ne.jp> 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@I-love.SAKURA.ne.jp .
> > 
> > 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