Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <46fee955-a5fa-fbd6-bcc4-d9344e6801d9@I-love.SAKURA.ne.jp>
Date:   Fri, 26 Aug 2022 10:35:43 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.1.2
Subject: Re: KMSAN: uninit-value in ath9k_htc_rx_msg
Content-Language: en-US
To:     Alexander Potapenko <glider@google.com>,
        ath9k-devel@qca.qualcomm.com
Cc:     phil@philpotter.co.uk, David Miller <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Kalle Valo <kvalo@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-wireless <linux-wireless@vger.kernel.org>,
        Networking <netdev@vger.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>
References: <000000000000c98a7f05ac744f53@google.com>
 <000000000000734fe705acb9f3a2@google.com>
 <a142d63c-7810-40ff-9c24-7160c63bafebn@googlegroups.com>
 <CAG_fn=U=Vfv3ymNM6W++sbivieQoUuXfAxsC9SsmdtQiTjSi8g@mail.gmail.com>
 <1a0b4d24-6903-464f-7af0-65c9788545af@I-love.SAKURA.ne.jp>
 <CAG_fn=Wq51FMbty4c_RwjBSFWS1oceL1rOAUzCyRnGEzajQRAg@mail.gmail.com>
From:   Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
In-Reply-To: <CAG_fn=Wq51FMbty4c_RwjBSFWS1oceL1rOAUzCyRnGEzajQRAg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2022/08/26 0:09, Alexander Potapenko wrote:
> On Thu, Aug 25, 2022 at 4:34 PM Tetsuo Handa
> <penguin-kernel@i-love.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...