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]
Date:   Wed, 18 Aug 2021 18:41:09 +0900 (JST)
From:   Ryutaroh Matsumoto <ryutaroh@....e.titech.ac.jp>
To:     arend.vanspriel@...adcom.com
Cc:     aspriel@...il.com, 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, davem@...emloft.net
Subject: Re: 5.10.58 UBSAN from brcmf_sdio_dpc+0xa50/0x128c [brcmfmac]

Hi Arend, sorry for my late response, partly because compilation takes 10 hours
on RPi4B...
I did the same thing with version 5.10.59 and CLang 11 and got the same
UBSAN. 

>> 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.

Summary: I confirm that the stack trace indeed points to
brcmf_sdio_sendfromq(). The detail follows (you don't have to read it if
you believe in me :-)
If kernel version 5.10.x or 5.13.x is compiled with gcc 10, I have never seen
UBSAN. I wonder if CLang 11/12 tends to generate falsely positive UBSAN.

(gdb) add-symbol-file  drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko 0x0
add symbol table from file "drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko" at
	.text_addr = 0x0
(y or n) y

(gdb)  l *brcmf_sdio_dpc+0xa50
warning: Could not find DWO CU drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.dwo(0x79060145b4b45807) referenced by CU at offset 0x394 [in module /usr/lib/debug/lib/modules/5.10.59-clang11debug/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko]
0x277a4 is at ./include/linux/skbuff.h:2016.
2011	./include/linux/skbuff.h: No such file or directory.

Line 2016 of skbuff.h is __skb_insert in the next inline function:
static inline void __skb_queue_before(struct sk_buff_head *list,
                                      struct sk_buff *next,
                                      struct sk_buff *newsk)
{
        __skb_insert(newsk, next->prev, next, list);
}

Then:
(gdb) l *brcmf_sdio_dpc+0xa43
0x27797 is at drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2346.
2341	drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: No such file or directory.

The line 2346 is in the function brcmf_sdio_sendfromq().

Best regards, Ryutaroh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ