[syzbot] WARNING in __dev_change_net_namespace

[syzbot] WARNING in __dev_change_net_namespace

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    512b7931ad05 Merge branch 'akpm' (patches from Andrew)
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15b45fb6b00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=99780e4a2873b273
dashboard link: https://syzkaller.appspot.com/bug?extid=5434727aa485c3203fed
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

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+5434727aa485c3203fed@syzkaller.appspotmail.com

RAX: ffffffffffffffda RBX: 00007f02bf014f60 RCX: 00007f02bef01ae9
RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
RBP: 00007f02bc4771d0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
R13: 00007ffcc2738d7f R14: 00007f02bc477300 R15: 0000000000022000
 </TASK>
------------[ cut here ]------------
WARNING: CPU: 0 PID: 4974 at net/core/dev.c:11254 __dev_change_net_namespace+0x1079/0x1330 net/core/dev.c:11254
Modules linked in:
CPU: 0 PID: 4974 Comm: syz-executor.2 Not tainted 5.15.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__dev_change_net_namespace+0x1079/0x1330 net/core/dev.c:11254
Code: c7 c7 80 9b 8c 8a c6 05 ba 0e 3b 06 01 e8 36 73 d5 01 0f 0b e9 69 f0 ff ff e8 e3 95 57 fa 0f 0b e9 60 fb ff ff e8 d7 95 57 fa <0f> 0b e9 2a fb ff ff 41 bd ea ff ff ff e9 62 f2 ff ff e8 f0 38 9e
RSP: 0018:ffffc900217aed70 EFLAGS: 00010246
RAX: 0000000000040000 RBX: 00000000fffffff4 RCX: ffffc9000b291000
RDX: 0000000000040000 RSI: ffffffff87202d59 RDI: 0000000000000003
RBP: ffff88815cbea000 R08: 0000000000000000 R09: ffff88815cbea64b
R10: ffffffff87202882 R11: 0000000000000000 R12: dffffc0000000000
R13: ffffffff8d0e3dc0 R14: ffff88815cbeac00 R15: ffffffff8d0e3f0c
FS:  00007f02bc477700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32027000 CR3: 0000000162d58000 CR4: 0000000000350ef0
Call Trace:
 <TASK>
 do_setlink+0x275/0x3970 net/core/rtnetlink.c:2624
 __rtnl_newlink+0xde6/0x1750 net/core/rtnetlink.c:3391
 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3506
 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2491
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x86d/0xda0 net/netlink/af_netlink.c:1916
 sock_sendmsg_nosec net/socket.c:704 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:724
 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f02bef01ae9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f02bc477188 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f02bf014f60 RCX: 00007f02bef01ae9
RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
RBP: 00007f02bc4771d0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
R13: 00007ffcc2738d7f R14: 00007f02bc477300 R15: 0000000000022000
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [syzbot] WARNING in __dev_change_net_namespace

[Johannes Berg]

On Thu, 2021-11-11 at 06:43 +0000, syzbot wrote:
> 
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b45fb6b00000

So we see that fault injection is triggering a memory allocation failure
deep within the device_rename():

int __dev_change_net_namespace(struct net_device *dev, struct net *net,
                               const char *pat, int new_ifindex)
{
...
        /* Fixup kobjects */
        err = device_rename(&dev->dev, dev->name);
        WARN_ON(err);


So we hit that WARN_ON().

I'm not really sure what to do about that though. Feels like we should
be able to cope with failures here, but clearly we don't, and it seems
like it would also be tricky to do after all the work already done at
this point.

Perhaps device_rename() could grow an API to preallocate all the
memories, but that would also be fairly involved, I imagine?

johannes

Re: [syzbot] WARNING in __dev_change_net_namespace

[Greg Kroah-Hartman]

On Thu, Nov 11, 2021 at 08:50:33AM +0100, Johannes Berg wrote:
> On Thu, 2021-11-11 at 06:43 +0000, syzbot wrote:
> > 
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15b45fb6b00000
> 
> So we see that fault injection is triggering a memory allocation failure
> deep within the device_rename():
> 
> int __dev_change_net_namespace(struct net_device *dev, struct net *net,
>                                const char *pat, int new_ifindex)
> {
> ...
>         /* Fixup kobjects */
>         err = device_rename(&dev->dev, dev->name);
>         WARN_ON(err);
> 
> 
> So we hit that WARN_ON().
> 
> I'm not really sure what to do about that though. Feels like we should
> be able to cope with failures here, but clearly we don't, and it seems
> like it would also be tricky to do after all the work already done at
> this point.
> 
> Perhaps device_rename() could grow an API to preallocate all the
> memories, but that would also be fairly involved, I imagine?

That would be a mess to unwind at times.  For fault-injection stuff like
this, that can not be hit in "real world operation", if the issue can
not be easily handled, I don't think it is worth worrying about.

We have some things like this in the tty layer at boot time, if a memory
failure happens then, we have bigger overall problems in the system than
trying to recover from minor stuff like this.

thanks,

greg k-h