Thread (2 messages) flat view 2 messages, 2 authors, 2021-06-02

Re: [syzbot] general protection fault in mac80211_hwsim_tx_frame_nl

From: Benjamin Beichler <hidden>
Date: 2021-06-02 16:08:47
Also in: lkml, netdev

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/

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help