netdev - Re: 5.10.58 UBSAN from brcmf_sdio

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-next>] [day] [month] [year] [list]

Message-ID: <56ea3e65-62f4-2496-edd4-e454126abc66@broadcom.com>
Date:   Tue, 17 Aug 2021 10:17:55 +0200
From:   Arend van Spriel <arend.vanspriel@...adcom.com>
To:     Arend van Spriel <aspriel@...il.com>,
        Ryutaroh Matsumoto <ryutaroh@....e.titech.ac.jp>
Cc:     linux-rpi-kernel@...ts.infradead.org,
        linux-wireless@...r.kernel.org,
        brcm80211-dev-list.pdl@...adcom.com,
        SHA-cyfmac-dev-list@...ineon.com, franky.lin@...adcom.com,
        hante.meuleman@...adcom.com, chi-hsien.lin@...ineon.com,
        wright.feng@...ineon.com, chung-hsien.hsu@...ineon.com,
        netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: 5.10.58 UBSAN from brcmf_sdio_dpc+0xa50/0x128c [brcmfmac]

+netdev, +Dave

On 8/17/2021 7:42 AM, Arend van Spriel wrote:
> Using different email to avoid disclaimers...
> 
> 
> On August 17, 2021 2:39:56 AM Ryutaroh Matsumoto 
> <ryutaroh@....e.titech.ac.jp> wrote:
> 
>> Hi Arend, thank you for paying attention to this.
>>
>>> Line 2016 in skbuff.h is inline function __skb_queue_before() and as
>>> far as I can tell brcmfmac is not using that direct or indirect. Maybe
>>> I am reading the line info incorrectly?
>>
>> I am unsure of it. On the other hand, I have also seen somewhat similar
>> UBSAN from a header file "include/net/flow.h" as reported at
>> https://lore.kernel.org/netdev/20210813.081908.1574714532738245424.ryutaroh@ict.e.titech.ac.jp/ 
>>
>>
>> All UBSANs that I have seen come from *.h compiled with clang...
>>
>>> Would you be able to provide information as to what line
>>> brcmf_sdio_dpc+0xa50 refers to.
>>
>> I'd like to do, but I do not know how to let kernel UBSAN include a 
>> line number,
>> though I know it with user-space applications...
> 
> If you enable CONFIG_DEBUG_INFO in your kernel .config and recompile 
> brcmfmac you can load the module in gdb:
> 
> gdb> add-symbol-file brcmfmac.ko [address]
> gdb> l *brcmf_sdio_dpc+0xa50
> 
> The [address] is not very important so just fill in a nice value. The 
> 'l' command should provide the line number.

Hi Ryutaroh,

Meanwhile I did some digging in the brcmfmac driver and I think I found 
the location in brcmf_sdio_sendfromq() where we do a __skb_queue_tail(). 
So I looked at that and it does following:

static inline void __skb_queue_tail(struct sk_buff_head *list,
				   struct sk_buff *newsk)
{
	__skb_queue_before(list, (struct sk_buff *)list, newsk);
}

Your report seems to be coming from the cast that is done here, which is 
fine as long as sk_buff and sk_buff_head have the same members 'next' 
and 'prev' at the start, which is true today and hopefully forever ;-) I 
am inclined to say this is a false report.

Can you please confirm the stack trace indeed points to 
brcmf_sdio_sendfromq() in your report.

Regards,
Arend