unregister_netdevice: waiting for DEV to become free

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +0000)
Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=2dfb68e639f0621b19fb

So far this crash happened 5 times on upstream.
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5531107864870912
Kernel config:
https://syzkaller.appspot.com/x/.config?id=1808800213120130118
compiler: gcc (GCC) 8.0.1 20180413 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2dfb68...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.

connbytes_mt_check: 1 callbacks suppressed
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
unregister_netdevice: waiting for lo to become free. Usage count = 3
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
kernel msg: ebtables bug: please report to author: Entries_size never zero
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
nla_parse: 1 callbacks suppressed
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7
netlink: 17 bytes leftover after parsing attributes in process
`syz-executor6'.
xt_connbytes: cannot load conntrack support for proto=7


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.

[Dmitry Vyukov]

On Thu, Apr 19, 2018 at 4:52 PM, syzbot
<syzbot+2dfb68...@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +0000)
> Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=2dfb68e639f0621b19fb
>
> So far this crash happened 5 times on upstream.
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=5531107864870912
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=1808800213120130118
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)

There are 2 reproducers for these hangs (presumably for different bugs):

https://groups.google.com/d/msg/syzkaller/-06_laheMF0/4wfWs6ATBwAJ
https://groups.google.com/d/msg/syzkaller/-06_laheMF0/MxCjIiHkBwAJ

> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000d71bf6056a34b628%40google.com.
> For more options, visit https://groups.google.com/d/optout.

[syzbot]

syzbot has found reproducer for the following crash on
https://github.com/google/kmsan.git/master commit
48c6a2b0ab1b752451cdc40b5392471ed1a2a329 (Mon Apr 16 08:42:26 2018 +0000)
mm/kmsan: fix origin calculation in kmsan_internal_check_memory

syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=2dfb68e639f0621b19fb

So far this crash happened 180 times on
https://github.com/google/kmsan.git/master, net-next, upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4936564132020224
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5817131010621440
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6313498770407424
Kernel config:
https://syzkaller.appspot.com/x/.config?id=6627248707860932248
compiler: clang version 7.0.0 (trunk 329391)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2dfb68...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state

[Tetsuo Handa]

Hello.

Since this bug is top crasher (124264 times in 98 days is almost "every minute").
I made a simplified C reproducer based on the C reproducer provided by syzbot.
It seems that setsockopt(SOL_IPV6, IPV6_XFRM_POLICY) is involved to this trouble.

----------------------------------------
#define _GNU_SOURCE
#include <sched.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

/*
ip6tnl0: flags=128<NOARP> mtu 1452
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
*/
#define IP_DEVNAME "ip6tnl0"

int main(int argc, char *argv[])
{
struct sockaddr_in6 addr = { };
int fd;
if (unshare(CLONE_NEWNET))
return 1;
fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP);
if (system("ip link set dev " IP_DEVNAME " up"))
return 2;
setsockopt(fd, SOL_IPV6, IPV6_XFRM_POLICY, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\254\24\24\252\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0+\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\r5M&", 0xe8);
addr.sin6_family = AF_INET6;
inet_pton(AF_INET6, "fe80::bb", &addr.sin6_addr);
addr.sin6_scope_id = 9;
connect(fd, (struct sockaddr *) &addr, sizeof(addr));
return 0;
}
----------------------------------------

[Tetsuo Handa]

Steffen and Herbert,

Do you have any question? I think I provided enough information for debugging.

This problem occurs because two dev_put() calls are missing (compared with not
calling setsockopt(SOL_IPV6, IPV6_XFRM_POLICY)) because dst_release() is not
called via fib6_info_destroy_rcu() when we called xfrm_compile_policy() from
xfrm_user_policy() from setsockopt(SOL_IPV6, IPV6_XFRM_POLICY).

[ 39.981210] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted 4.18.0-rc6+ #457
[ 39.982879] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[ 39.985689] Call Trace:
[ 39.986269] <IRQ>
[ 39.986792] dump_stack+0x99/0xdc
[ 39.987601] dst_destroy_hook+0x29/0x2b
[ 39.988517] dst_release+0x28/0x70
[ 39.989481] fib6_info_destroy_rcu+0x8e/0x100
[ 39.990409] ? fib6_walk_continue+0x1c0/0x1c0
[ 39.991355] rcu_process_callbacks+0x2cb/0x870
[ 39.992376] ? rcu_process_callbacks+0x266/0x870
[ 39.993352] __do_softirq+0xcf/0x49b
[ 39.994119] irq_exit+0xc2/0xd0
[ 39.994819] smp_apic_timer_interrupt+0xa4/0x2d0
[ 39.995918] apic_timer_interrupt+0xf/0x20
[ 39.996883] </IRQ>

[Steffen Klassert]

On Tue, Jul 31, 2018 at 08:16:22PM +0900, Tetsuo Handa wrote:
> Steffen and Herbert,
>
> Do you have any question? I think I provided enough information for debugging.

It seems that I was not on Cc at the beginning of the threat,
so I had to search the web for some context.

I'm currently trying your reproducer (still with my .config) but I don't
hit the problem.

>
> This problem occurs because two dev_put() calls are missing (compared with not
> calling setsockopt(SOL_IPV6, IPV6_XFRM_POLICY)) because dst_release() is not
> called via fib6_info_destroy_rcu() when we called xfrm_compile_policy() from
> xfrm_user_policy() from setsockopt(SOL_IPV6, IPV6_XFRM_POLICY).

Thanks for the information! As said, I'm already working on it.

[Steffen Klassert]

On Tue, Jul 31, 2018 at 01:31:52PM +0200, Steffen Klassert wrote:
> On Tue, Jul 31, 2018 at 08:16:22PM +0900, Tetsuo Handa wrote:
> > Steffen and Herbert,
> >
> > Do you have any question? I think I provided enough information for debugging.
>
> It seems that I was not on Cc at the beginning of the threat,
> so I had to search the web for some context.
>
> I'm currently trying your reproducer (still with my .config) but I don't
> hit the problem.

Actually, I did not hit it because it is already fixed in my tree.

It is fixed by:

commit 8cc88773855f988d6a3bbf102bbd9dd9c828eb81
xfrm: fix missing dst_release() after policy blocking lbcast and multicast

This fix went to mainline on Monday.

[Dmitry Vyukov]

Thanks, let's tell syzbot:

#syz fix: