Re: [syzbot] general protection fault in mac80211_hwsim_tx_frame_nl

[Benjamin Beichler <Benjamin.Beichler@uni-rostock.de>]

[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]

Hi Johannes,

I coincidentally picked up this one and had a quick look into it.

Am 02.06.2021 um 09:02 schrieb syzbot:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    05924717 bpf, tnums: Provably sound, faster, and more prec..
> git tree:       bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15a3b90bd00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=7b1a53f9a0b5a801
> dashboard link: https://syzkaller.appspot.com/bug?extid=3a2811a83af0f441ef5f
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+3a2811a83af0f441ef5f@syzkaller.appspotmail.com
>
> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> CPU: 0 PID: 31562 Comm: kworker/u4:6 Not tainted 5.12.0-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Workqueue: phy89 hw_scan_work
> RIP: 0010:mac80211_hwsim_tx_frame_nl+0x3fd/0xdb0 drivers/net/wireless/mac80211_hwsim.c:1315

Actually, the syzbot becomes more aggressive, and found more races. From
my understanding the error is triggered by a netlink message stuck in
tx_frame_nl, when in between the underlying hwsim interface is
deleted/changed (and therefore the channel or data ptr in 1315 becomes
stale).

The message "[ 2019.982886][ T5462] mac80211_hwsim: wmediumd released
netlink socket, switching to perfect channel medium" directly before the
bug, seems also very fishy.

This substantiate your last findings, about the inconsistent locking in
hwsim. The configuration of interfaces or state of the wmediumd hook
should not change while we are in tx_frame_nl. But of course tx_frame_nl
is on a hot path.

Maybe you already got this, but I wanted to throw in my thoughts,
although I'm currently not able to create fixes to this.

...

> Call Trace:
>  mac80211_hwsim_tx_frame+0x10d/0x1e0 drivers/net/wireless/mac80211_hwsim.c:1773
>  hw_scan_work+0x7be/0xc20 drivers/net/wireless/mac80211_hwsim.c:2331
>  process_one_work+0x98d/0x1600 kernel/workqueue.c:2275
>  worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
>  kthread+0x3b1/0x4a0 kernel/kthread.c:313
>  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
> Modules linked in:
> ---[ end trace bd7d02fa1bf956f5 ]---
>

-- 
M.Sc. Benjamin Beichler

Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik

University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE

Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany

phone: +49 (0) 381 498 - 7278
email: Benjamin.Beichler@uni-rostock.de
www: http://www.imd.uni-rostock.de/



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5328 bytes --]