netdev - Re: [syzbot] upstream boot error: stack segment fault in __alloc

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

Message-ID: <9e81fbb3b994b1228e6cfb1c550fe35e11508adb.camel@sipsolutions.net>
Date:   Tue, 23 Aug 2022 09:49:32 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jakub Kicinski <kuba@...nel.org>,
        syzbot <syzbot+b8a1f71feb027c4e2f06@...kaller.appspotmail.com>
Cc:     davem@...emloft.net, edumazet@...gle.com,
        linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
        netdev@...r.kernel.org, pabeni@...hat.com,
        syzkaller-bugs@...glegroups.com, linux-wireless@...r.kernel.org
Subject: Re: [syzbot] upstream boot error: stack segment fault in __alloc_skb

Hi,

> Does mac80211 hwsim size something in the family based on user input 
> or such?

Hmm, maybe, but certainly not in this path?

> > mac80211_hwsim: initializing netlink
> > stack segment: 0000 [#1] PREEMPT SMP KASAN
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc1-syzkaller-00017-g3cc40a443a04 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
> > RIP: 0010:__kmalloc_node_track_caller+0x17a/0x3f0 mm/slub.c:4955
> > Code: 00 48 c1 e8 3a 44 39 f0 0f 85 24 01 00 00 49 8b 3c 24 40 f6 c7 0f 0f 85 73 02 00 00 45 84 c0 0f 84 6c 02 00 00 41 8b 44 24 28 <48> 8b 5c 05 00 48 8d 4a 08 48 89 e8 65 48 0f c7 0f 0f 94 c0 a8 01
> > RSP: 0000:ffffc90000067858 EFLAGS: 00010202
> > RAX: 0000000000000800 RBX: 0000000000082cc0 RCX: 0000000000000000
> > RDX: 0000000000003088 RSI: 0000000000082cc0 RDI: 000000000003d960
> > RBP: ffff000000000000 R08: dffffc0000000001 R09: fffffbfff1c4ade6
> > R10: fffffbfff1c4ade6 R11: 1ffffffff1c4ade5 R12: ffff888012042140
> > R13: 0000000000082cc0 R14: 00000000ffffffff R15: 0000000000001000
> > FS:  0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: ffff88823ffff000 CR3: 000000000ca8e000 CR4: 00000000003506f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> >  <TASK>
> >  kmalloc_reserve net/core/skbuff.c:358 [inline]
> >  __alloc_skb+0x11d/0x620 net/core/skbuff.c:430
> >  alloc_skb include/linux/skbuff.h:1257 [inline]
> >  nlmsg_new include/net/netlink.h:953 [inline]
> >  ctrl_build_mcgrp_msg net/netlink/genetlink.c:997 [inline]
> >  genl_ctrl_event+0x16f/0xc40 net/netlink/genetlink.c:1083
> >  genl_register_family+0x10df/0x1390 net/netlink/genetlink.c:432
> >  hwsim_init_netlink+0x21/0x9b drivers/net/wireless/mac80211_hwsim.c:4972
> >  init_mac80211_hwsim+0x185/0xa08 drivers/net/wireless/mac80211_hwsim.c:5285

It's just calling genl_register_family(), basically?

init_mac80211_hwsim() shouldn't have much of a stack frame,
neither does genl_register_family() nor any of the other functions here?

Strange.

But wait, this was reported against rc1, and we had a TON of syzbot
failures on rc1 because of the virtio patches - I was previously told to
mostly disregard them.

johannes