LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* 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).