* unregister_netdevice: waiting for DEV to become free @ 2018-04-19 14:52 syzbot 2018-04-19 14:53 ` Dmitry Vyukov 2018-04-20 23:59 ` syzbot 0 siblings, 2 replies; 8+ messages in thread From: syzbot @ 2018-04-19 14:52 UTC (permalink / raw) To: linux-kernel, syzkaller-bugs 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+2dfb68e639f0621b19fb@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 syzkaller@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: unregister_netdevice: waiting for DEV to become free 2018-04-19 14:52 unregister_netdevice: waiting for DEV to become free syzbot @ 2018-04-19 14:53 ` Dmitry Vyukov 2018-04-20 23:59 ` syzbot 1 sibling, 0 replies; 8+ messages in thread From: Dmitry Vyukov @ 2018-04-19 14:53 UTC (permalink / raw) To: syzbot; +Cc: LKML, syzkaller-bugs, netdev, Dan Streetman On Thu, Apr 19, 2018 at 4:52 PM, syzbot <syzbot+2dfb68e639f0621b19fb@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 > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+2dfb68e639f0621b19fb@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 syzkaller@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. > > -- > 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-bugs+unsubscribe@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: unregister_netdevice: waiting for DEV to become free 2018-04-19 14:52 unregister_netdevice: waiting for DEV to become free syzbot 2018-04-19 14:53 ` Dmitry Vyukov @ 2018-04-20 23:59 ` syzbot 2018-07-27 13:00 ` Tetsuo Handa 1 sibling, 1 reply; 8+ messages in thread From: syzbot @ 2018-04-20 23:59 UTC (permalink / raw) To: ddstreet, dvyukov, linux-kernel, netdev, syzkaller-bugs 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+2dfb68e639f0621b19fb@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 unregister_netdevice: waiting for lo to become free. Usage count = 3 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: unregister_netdevice: waiting for DEV to become free 2018-04-20 23:59 ` syzbot @ 2018-07-27 13:00 ` Tetsuo Handa 2018-07-31 11:16 ` Tetsuo Handa 0 siblings, 1 reply; 8+ messages in thread From: Tetsuo Handa @ 2018-07-27 13:00 UTC (permalink / raw) To: Steffen Klassert, Herbert Xu, David S. Miller Cc: syzbot, ddstreet, dvyukov, linux-kernel, netdev, syzkaller-bugs 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; } ---------------------------------------- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: unregister_netdevice: waiting for DEV to become free 2018-07-27 13:00 ` Tetsuo Handa @ 2018-07-31 11:16 ` Tetsuo Handa 2018-07-31 11:31 ` Steffen Klassert 0 siblings, 1 reply; 8+ messages in thread From: Tetsuo Handa @ 2018-07-31 11:16 UTC (permalink / raw) To: Steffen Klassert, Herbert Xu, David S. Miller Cc: syzbot, ddstreet, dvyukov, linux-kernel, netdev, syzkaller-bugs 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> On 2018/07/27 22:00, Tetsuo Handa wrote: > 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; > } > ---------------------------------------- > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: unregister_netdevice: waiting for DEV to become free 2018-07-31 11:16 ` Tetsuo Handa @ 2018-07-31 11:31 ` Steffen Klassert 2018-08-01 8:57 ` Steffen Klassert 0 siblings, 1 reply; 8+ messages in thread From: Steffen Klassert @ 2018-07-31 11:31 UTC (permalink / raw) To: Tetsuo Handa Cc: Herbert Xu, David S. Miller, syzbot, ddstreet, dvyukov, linux-kernel, netdev, syzkaller-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: unregister_netdevice: waiting for DEV to become free 2018-07-31 11:31 ` Steffen Klassert @ 2018-08-01 8:57 ` Steffen Klassert 2018-08-01 9:14 ` Dmitry Vyukov 0 siblings, 1 reply; 8+ messages in thread From: Steffen Klassert @ 2018-08-01 8:57 UTC (permalink / raw) To: Tetsuo Handa Cc: Herbert Xu, David S. Miller, syzbot, ddstreet, dvyukov, linux-kernel, netdev, syzkaller-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: unregister_netdevice: waiting for DEV to become free 2018-08-01 8:57 ` Steffen Klassert @ 2018-08-01 9:14 ` Dmitry Vyukov 0 siblings, 0 replies; 8+ messages in thread From: Dmitry Vyukov @ 2018-08-01 9:14 UTC (permalink / raw) To: Steffen Klassert Cc: Tetsuo Handa, Herbert Xu, David S. Miller, syzbot, Dan Streetman, LKML, netdev, syzkaller-bugs On Wed, Aug 1, 2018 at 10:57 AM, Steffen Klassert <steffen.klassert@secunet.com> wrote: > 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. Thanks, let's tell syzbot: #syz fix: xfrm: fix missing dst_release() after policy blocking lbcast and multicast ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-08-01 9:15 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-04-19 14:52 unregister_netdevice: waiting for DEV to become free syzbot 2018-04-19 14:53 ` Dmitry Vyukov 2018-04-20 23:59 ` syzbot 2018-07-27 13:00 ` Tetsuo Handa 2018-07-31 11:16 ` Tetsuo Handa 2018-07-31 11:31 ` Steffen Klassert 2018-08-01 8:57 ` Steffen Klassert 2018-08-01 9:14 ` Dmitry Vyukov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).