* 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).