KASAN: use-after-free Read in br_mdb_ip_get

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: ba6069759381 Merge tag 'mmc-v5.0-rc2' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17b342c4c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
dashboard link: https://syzkaller.appspot.com/bug?extid=bc5ab0af2dbf3b0ae897
compiler: gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+bc5ab0...@syzkaller.appspotmail.com

bridge0: port 2(bridge_slave_1) entered blocking state
bridge0: port 2(bridge_slave_1) entered forwarding state
bridge0: port 1(bridge_slave_0) entered blocking state
bridge0: port 1(bridge_slave_0) entered forwarding state
==================================================================
BUG: KASAN: use-after-free in memcmp+0xb3/0xc0 lib/string.c:862
Read of size 1 at addr ffff88809f1efe70 by task syz-executor1/8111

CPU: 0 PID: 8111 Comm: syz-executor1 Not tainted 5.0.0-rc3+ #43
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
8021q: adding VLAN 0 to HW filter on device bond0
__asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132
memcmp+0xb3/0xc0 lib/string.c:862
memcmp include/linux/string.h:393 [inline]
rhashtable_compare include/linux/rhashtable.h:473 [inline]
__rhashtable_lookup include/linux/rhashtable.h:498 [inline]
rhashtable_lookup include/linux/rhashtable.h:534 [inline]
br_mdb_ip_get+0x694/0xe30 net/bridge/br_multicast.c:97
IPv6: ADDRCONF(NETDEV_UP): veth0: link is not ready
br_multicast_new_group+0x77/0x200 net/bridge/br_multicast.c:467
IPv6: ADDRCONF(NETDEV_UP): team0: link is not ready
8021q: adding VLAN 0 to HW filter on device team0
br_multicast_add_group+0x4ce/0x7d0 net/bridge/br_multicast.c:552
br_ip6_multicast_add_group net/bridge/br_multicast.c:626 [inline]
br_ip6_multicast_mld2_report net/bridge/br_multicast.c:1043 [inline]
br_multicast_ipv6_rcv net/bridge/br_multicast.c:1667 [inline]
br_multicast_rcv+0x24aa/0x4270 net/bridge/br_multicast.c:1705
IPv6: ADDRCONF(NETDEV_UP): hsr0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): hsr0: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): vxcan1: link is not ready
br_dev_xmit+0x7f4/0x1780 net/bridge/br_device.c:93
8021q: adding VLAN 0 to HW filter on device batadv0
__netdev_start_xmit include/linux/netdevice.h:4382 [inline]
netdev_start_xmit include/linux/netdevice.h:4391 [inline]
xmit_one net/core/dev.c:3278 [inline]
dev_hard_start_xmit+0x261/0xc70 net/core/dev.c:3294
__dev_queue_xmit+0x2f8a/0x3a60 net/core/dev.c:3864
dev_queue_xmit+0x18/0x20 net/core/dev.c:3897
neigh_hh_output include/net/neighbour.h:498 [inline]
neigh_output include/net/neighbour.h:506 [inline]
ip6_finish_output2+0x141a/0x28e0 net/ipv6/ip6_output.c:120
ip6_finish_output+0x577/0xc30 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:278 [inline]
ip6_output+0x23c/0xa00 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
mld_sendpack+0xa44/0xfd0 net/ipv6/mcast.c:1683
mld_send_cr net/ipv6/mcast.c:1979 [inline]
mld_ifc_timer_expire+0x449/0x8a0 net/ipv6/mcast.c:2478
call_timer_fn+0x254/0x900 kernel/time/timer.c:1325
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers+0x6fc/0xd50 kernel/time/timer.c:1681
run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694
__do_softirq+0x30b/0xb11 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x180/0x1d0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x1b7/0x760 arch/x86/kernel/apic/apic.c:1062
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
</IRQ>
RIP: 0010:kasan_check_read+0x0/0x20 mm/kasan/common.c:99
Code: ef e9 14 eb ff ff 48 8b 73 58 89 c2 48 c7 c7 f0 c2 3c 89 f7 da e8 54
69 a2 ff e9 c4 f5 ff ff 90 90 90 90 90 90 90 90 90 90 90 <55> 89 f6 31 d2
48 89 e5 48 8b 4d 08 e8 ff 23 00 00 5d c3 0f 1f 00
IPVS: ftp: loaded support on port[0] = 21
RSP: 0018:ffff88809e937428 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000000 RBX: ffffffff8a318400 RCX: ffffffff8162f642
RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff8a318400
RBP: ffff88809e937530 R08: 1ffffffff1463080 R09: fffffbfff1463081
R10: fffffbfff1463080 R11: ffffffff8a318407 R12: ffff88809ac4c600
R13: ffff88809e937508 R14: dffffc0000000000 R15: ffffed1013d26e91
mutex_optimistic_spin kernel/locking/mutex.c:646 [inline]
__mutex_lock_common kernel/locking/mutex.c:928 [inline]
__mutex_lock+0x377/0x1670 kernel/locking/mutex.c:1072
IPVS: ftp: loaded support on port[0] = 21
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock net/core/rtnetlink.c:77 [inline]
rtnetlink_rcv_msg+0x425/0xc30 net/core/rtnetlink.c:5127
netlink_rcv_skb+0x17d/0x410 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5148
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x574/0x770 net/netlink/af_netlink.c:1336
netlink_sendmsg+0xa05/0xf90 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
__sys_sendto+0x387/0x5f0 net/socket.c:1788
__do_sys_sendto net/socket.c:1800 [inline]
__se_sys_sendto net/socket.c:1796 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x411fc3
Code: ff 0f 83 40 18 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
83 3d cd 42 64 00 00 75 17 49 89 ca b8 2c 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 0f 83 11 18 00 00 c3 48 83 ec 08 e8 87 fa ff ff
RSP: 002b:0000000000a4fb28 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000411fc3
RDX: 000000000000006c RSI: 0000000000a50070 RDI: 0000000000000003
RBP: 0000000000000003 R08: 0000000000a4fb30 R09: 000000000000000c
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000a4fef0
R13: 0000000000a4fbb8 R14: 0000000000a4fc80 R15: 00000000004bcf8a

Allocated by task 8111:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc mm/kasan/common.c:496 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609
kmalloc include/linux/slab.h:545 [inline]
kzalloc include/linux/slab.h:740 [inline]
br_multicast_new_group.part.0+0xdc/0x1a40 net/bridge/br_multicast.c:476
br_multicast_new_group+0x19d/0x200 net/bridge/br_multicast.c:471
br_multicast_add_group+0x4ce/0x7d0 net/bridge/br_multicast.c:552
br_ip6_multicast_add_group net/bridge/br_multicast.c:626 [inline]
br_ip6_multicast_mld2_report net/bridge/br_multicast.c:1043 [inline]
br_multicast_ipv6_rcv net/bridge/br_multicast.c:1667 [inline]
br_multicast_rcv+0x24aa/0x4270 net/bridge/br_multicast.c:1705
br_dev_xmit+0x7f4/0x1780 net/bridge/br_device.c:93
__netdev_start_xmit include/linux/netdevice.h:4382 [inline]
netdev_start_xmit include/linux/netdevice.h:4391 [inline]
xmit_one net/core/dev.c:3278 [inline]
dev_hard_start_xmit+0x261/0xc70 net/core/dev.c:3294
__dev_queue_xmit+0x2f8a/0x3a60 net/core/dev.c:3864
dev_queue_xmit+0x18/0x20 net/core/dev.c:3897
neigh_resolve_output net/core/neighbour.c:1476 [inline]
neigh_resolve_output+0x6a0/0xb30 net/core/neighbour.c:1456
neigh_output include/net/neighbour.h:508 [inline]
ip6_finish_output2+0xc56/0x28e0 net/ipv6/ip6_output.c:120
ip6_finish_output+0x577/0xc30 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:278 [inline]
ip6_output+0x23c/0xa00 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
mld_sendpack+0xa44/0xfd0 net/ipv6/mcast.c:1683
mld_send_cr net/ipv6/mcast.c:1979 [inline]
mld_ifc_timer_expire+0x449/0x8a0 net/ipv6/mcast.c:2478
call_timer_fn+0x254/0x900 kernel/time/timer.c:1325
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers+0x6fc/0xd50 kernel/time/timer.c:1681
run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694
__do_softirq+0x30b/0xb11 kernel/softirq.c:292

Freed by task 8111:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
__cache_free mm/slab.c:3487 [inline]
kfree+0xcf/0x230 mm/slab.c:3806
br_multicast_new_group.part.0+0x1489/0x1a40 net/bridge/br_multicast.c:486
br_multicast_new_group+0x19d/0x200 net/bridge/br_multicast.c:471
br_multicast_add_group+0x4ce/0x7d0 net/bridge/br_multicast.c:552
br_ip6_multicast_add_group net/bridge/br_multicast.c:626 [inline]
br_ip6_multicast_mld2_report net/bridge/br_multicast.c:1043 [inline]
br_multicast_ipv6_rcv net/bridge/br_multicast.c:1667 [inline]
br_multicast_rcv+0x24aa/0x4270 net/bridge/br_multicast.c:1705
br_dev_xmit+0x7f4/0x1780 net/bridge/br_device.c:93
__netdev_start_xmit include/linux/netdevice.h:4382 [inline]
netdev_start_xmit include/linux/netdevice.h:4391 [inline]
xmit_one net/core/dev.c:3278 [inline]
dev_hard_start_xmit+0x261/0xc70 net/core/dev.c:3294
__dev_queue_xmit+0x2f8a/0x3a60 net/core/dev.c:3864
dev_queue_xmit+0x18/0x20 net/core/dev.c:3897
neigh_resolve_output net/core/neighbour.c:1476 [inline]
neigh_resolve_output+0x6a0/0xb30 net/core/neighbour.c:1456
neigh_output include/net/neighbour.h:508 [inline]
ip6_finish_output2+0xc56/0x28e0 net/ipv6/ip6_output.c:120
ip6_finish_output+0x577/0xc30 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:278 [inline]
ip6_output+0x23c/0xa00 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
mld_sendpack+0xa44/0xfd0 net/ipv6/mcast.c:1683
mld_send_cr net/ipv6/mcast.c:1979 [inline]
mld_ifc_timer_expire+0x449/0x8a0 net/ipv6/mcast.c:2478
call_timer_fn+0x254/0x900 kernel/time/timer.c:1325
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers+0x6fc/0xd50 kernel/time/timer.c:1681
run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694
__do_softirq+0x30b/0xb11 kernel/softirq.c:292

The buggy address belongs to the object at ffff88809f1efe00
which belongs to the cache kmalloc-192 of size 192
The buggy address is located 112 bytes inside of
192-byte region [ffff88809f1efe00, ffff88809f1efec0)
The buggy address belongs to the page:
page:ffffea00027c7bc0 count:1 mapcount:0 mapping:ffff88812c3f0040 index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea00027df108 ffffea00027c7c48 ffff88812c3f0040
raw: 0000000000000000 ffff88809f1ef000 0000000100000010 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff88809f1efd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88809f1efd80: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88809f1efe00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88809f1efe80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff88809f1eff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


---
This bug 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 syzk...@googlegroups.com.

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

[Nikolay Aleksandrov]

On 27/01/2019 22:26, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:    ba6069759381 Merge tag 'mmc-v5.0-rc2' of git://git.kernel...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17b342c4c00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
> dashboard link: https://syzkaller.appspot.com/bug?extid=bc5ab0af2dbf3b0ae897
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+bc5ab0...@syzkaller.appspotmail.com
>
> bridge0: port 2(bridge_slave_1) entered blocking state
> bridge0: port 2(bridge_slave_1) entered forwarding state
> bridge0: port 1(bridge_slave_0) entered blocking state
> bridge0: port 1(bridge_slave_0) entered forwarding state
> ==================================================================
> BUG: KASAN: use-after-free in memcmp+0xb3/0xc0 lib/string.c:862
> Read of size 1 at addr ffff88809f1efe70 by task syz-executor1/8111
>

[snip]

Weird, this is the kfree() on the error path of br_multicast_new_group()
when rhashtable_lookup_insert_fast() fails, which means the entry should
not be linked in the rhashtable or the hlist.
All other frees are via kfree_rcu. I'll keep looking..

[Dmitry Vyukov]

On Sun, Jan 27, 2019 at 10:34 PM Nikolay Aleksandrov
<nik...@cumulusnetworks.com> wrote:
>
> On 27/01/2019 22:26, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: ba6069759381 Merge tag 'mmc-v5.0-rc2' of git://git.kernel...
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=17b342c4c00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
> > dashboard link: https://syzkaller.appspot.com/bug?extid=bc5ab0af2dbf3b0ae897
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >

> >Unfortunately,I don't have any reproducer for this crash yet.

Humm.... +rhashtable.c maintianers

The code in br_multicast_new_group is effectively:

mp = kzalloc(sizeof(*mp), GFP_ATOMIC);
err = rhashtable_lookup_insert_fast(&br->mdb_hash_tbl, &mp->rhnode,
br_mdb_rht_params);
if (err)
kfree(mp);

So it looks like rhashtable_lookup_insert_fast both returned an error
and left the new object linked in the table. Since it happened only
once, it may have something to do with concurrent resizing/shrinking.

> --
>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/3c44c1ff-2790-ec06-35c6-3572b92170c7%40cumulusnetworks.com.
> For more options, visit https://groups.google.com/d/optout.

[Herbert Xu]

On Mon, Jan 28, 2019 at 09:28:36AM +0100, Dmitry Vyukov wrote:
>
> > Weird, this is the kfree() on the error path of br_multicast_new_group()
> > when rhashtable_lookup_insert_fast() fails, which means the entry should
> > not be linked in the rhashtable or the hlist.
> > All other frees are via kfree_rcu. I'll keep looking..
>
> Humm.... +rhashtable.c maintianers
>
> The code in br_multicast_new_group is effectively:
>
> mp = kzalloc(sizeof(*mp), GFP_ATOMIC);
> err = rhashtable_lookup_insert_fast(&br->mdb_hash_tbl, &mp->rhnode,
> br_mdb_rht_params);
> if (err)
> kfree(mp);
>
> So it looks like rhashtable_lookup_insert_fast both returned an error
> and left the new object linked in the table. Since it happened only
> once, it may have something to do with concurrent resizing/shrinking.

I've looked through the rhashtable code in question and everything
looks OK. So I suspect some earlier corruption has occured to cause
this anomalous result. Is it possible to collect earlier alloc/free
stack traces on the object in question?

Cheers,
--
Email: Herbert Xu <her...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[Dmitry Vyukov]

On Wed, Feb 20, 2019 at 11:23 AM Herbert Xu <her...@gondor.apana.org.au> wrote:
>
> On Mon, Jan 28, 2019 at 09:28:36AM +0100, Dmitry Vyukov wrote:
> >
> > > Weird, this is the kfree() on the error path of br_multicast_new_group()
> > > when rhashtable_lookup_insert_fast() fails, which means the entry should
> > > not be linked in the rhashtable or the hlist.
> > > All other frees are via kfree_rcu. I'll keep looking..
> >
> > Humm.... +rhashtable.c maintianers
> >
> > The code in br_multicast_new_group is effectively:
> >
> > mp = kzalloc(sizeof(*mp), GFP_ATOMIC);
> > err = rhashtable_lookup_insert_fast(&br->mdb_hash_tbl, &mp->rhnode,
> > br_mdb_rht_params);
> > if (err)
> > kfree(mp);
> >
> > So it looks like rhashtable_lookup_insert_fast both returned an error
> > and left the new object linked in the table. Since it happened only
> > once, it may have something to do with concurrent resizing/shrinking.
>
> I've looked through the rhashtable code in question and everything
> looks OK. So I suspect some earlier corruption has occured to cause
> this anomalous result.

Taking into account that this still happened only once, I tend to
write it off onto a previous silent memory corruption (we have dozens
of known bugs that corrupt memory). So if several people already
looked at it and don't see the root cause, it's probably time to stop
spending time on this until we have more info.

Although, there was also this one:
https://groups.google.com/d/msg/syzkaller-bugs/QfCCSxdB1aM/y2cn9IZJCwAJ
I have not checked if it can be the root cause of this report, but it
points suspiciously close to this stack and when I looked at it, it
the report looked legit.

> Is it possible to collect earlier alloc/free stack traces on the object in question?

You mean even before the alloc/free of the current incarnation this
object? This looks challenging from memory consumption point of view.
Also how many of them will we print in reports? Also the page can go
through page_alloc and then tracking will be even more challenging.
And in the end the object can be corrupted by an out-of-bounds write
or a like. Heap object reuse quarantine should take care of the common
case, and I don't see a reasonable way to handle all possible corner
cases...

[Herbert Xu]

Hi Dmitry:

On Thu, Feb 21, 2019 at 11:54:42AM +0100, Dmitry Vyukov wrote:
>
> Taking into account that this still happened only once, I tend to
> write it off onto a previous silent memory corruption (we have dozens
> of known bugs that corrupt memory). So if several people already
> looked at it and don't see the root cause, it's probably time to stop
> spending time on this until we have more info.
>
> Although, there was also this one:
> https://groups.google.com/d/msg/syzkaller-bugs/QfCCSxdB1aM/y2cn9IZJCwAJ
> I have not checked if it can be the root cause of this report, but it
> points suspiciously close to this stack and when I looked at it, it
> the report looked legit.

Have you had any more reports of this kind coming from br_multicast?

It looks like

ommit 1515a63fc413f160d20574ab0894e7f1020c7be2
Author: Nikolay Aleksandrov <nik...@cumulusnetworks.com>
Date: Wed Apr 3 23:27:24 2019 +0300

net: bridge: always clear mcast matching struct on reports and leaves

may have at least fixed the uninitialised value error.

Thanks,

[Dmitry Vyukov]

On Wed, May 29, 2019 at 4:58 PM Herbert Xu <her...@gondor.apana.org.au> wrote:
>
> Hi Dmitry:
>
> On Thu, Feb 21, 2019 at 11:54:42AM +0100, Dmitry Vyukov wrote:
> >
> > Taking into account that this still happened only once, I tend to
> > write it off onto a previous silent memory corruption (we have dozens
> > of known bugs that corrupt memory). So if several people already
> > looked at it and don't see the root cause, it's probably time to stop
> > spending time on this until we have more info.
> >
> > Although, there was also this one:
> > https://groups.google.com/d/msg/syzkaller-bugs/QfCCSxdB1aM/y2cn9IZJCwAJ
> > I have not checked if it can be the root cause of this report, but it
> > points suspiciously close to this stack and when I looked at it, it
> > the report looked legit.
>
> Have you had any more reports of this kind coming from br_multicast?
>
> It looks like
>
> ommit 1515a63fc413f160d20574ab0894e7f1020c7be2
> Author: Nikolay Aleksandrov <nik...@cumulusnetworks.com>
> Date: Wed Apr 3 23:27:24 2019 +0300
>
> net: bridge: always clear mcast matching struct on reports and leaves
>
> may have at least fixed the uninitialised value error.

The most up-to-date info is always available here:

>> dashboard link: https://syzkaller.appspot.com/bug?extid=bc5ab0af2dbf3b0ae897

It says no new crashes happened besides the original one.

We now have the following choices:

1. Invalidate with "#syz invalid"
2. Mark as tentatively fixed by that commit (could it fix it?) with
"#syz fix: net: bridge: always clear mcast matching struct on reports
and leaves"
3. Do nothing, then syzbot will auto-close it soon (bugs without
reproducers that did not happen in the past 180 days)

[Herbert Xu]

On Wed, May 29, 2019 at 05:14:17PM +0200, Dmitry Vyukov wrote:
>
> > It looks like
> >
> > ommit 1515a63fc413f160d20574ab0894e7f1020c7be2
> > Author: Nikolay Aleksandrov <nik...@cumulusnetworks.com>
> > Date: Wed Apr 3 23:27:24 2019 +0300
> >
> > net: bridge: always clear mcast matching struct on reports and leaves
> >
> > may have at least fixed the uninitialised value error.
>
>
> The most up-to-date info is always available here:
>
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=bc5ab0af2dbf3b0ae897
>
> It says no new crashes happened besides the original one.
>
> We now have the following choices:
>
> 1. Invalidate with "#syz invalid"
> 2. Mark as tentatively fixed by that commit (could it fix it?) with
> "#syz fix: net: bridge: always clear mcast matching struct on reports
> and leaves"
> 3. Do nothing, then syzbot will auto-close it soon (bugs without
> reproducers that did not happen in the past 180 days)

I'm still not quite sure how this could cause the use-after-free,
but it certainly seems to be the cause for the second issue of
uninit-value:

https://syzkaller.appspot.com/bug?extid=8dfe5ee27aa6d2e396c2

And this one does seem to have occured again recently (two months
ago).

[Dmitry Vyukov]

On Wed, May 29, 2019 at 5:27 PM Herbert Xu <her...@gondor.apana.org.au> wrote:
>
> On Wed, May 29, 2019 at 05:14:17PM +0200, Dmitry Vyukov wrote:
> >
> > > It looks like
> > >
> > > ommit 1515a63fc413f160d20574ab0894e7f1020c7be2
> > > Author: Nikolay Aleksandrov <nik...@cumulusnetworks.com>
> > > Date: Wed Apr 3 23:27:24 2019 +0300
> > >
> > > net: bridge: always clear mcast matching struct on reports and leaves
> > >
> > > may have at least fixed the uninitialised value error.
> >
> >
> > The most up-to-date info is always available here:
> >
> > >> dashboard link: https://syzkaller.appspot.com/bug?extid=bc5ab0af2dbf3b0ae897
> >
> > It says no new crashes happened besides the original one.
> >
> > We now have the following choices:
> >
> > 1. Invalidate with "#syz invalid"
> > 2. Mark as tentatively fixed by that commit (could it fix it?) with
> > "#syz fix: net: bridge: always clear mcast matching struct on reports
> > and leaves"
> > 3. Do nothing, then syzbot will auto-close it soon (bugs without
> > reproducers that did not happen in the past 180 days)
>
> I'm still not quite sure how this could cause the use-after-free,
> but it certainly seems to be the cause for the second issue of
> uninit-value:
>
> https://syzkaller.appspot.com/bug?extid=8dfe5ee27aa6d2e396c2
>
> And this one does seem to have occured again recently (two months
> ago).

I've closed the KMSAN bug report with this commit.

And since the uninit value was used inside of the rhashtable (as
hash?) it could lead to any kind of inconsistencies, I guess we can
do:

#syz fix:
net: bridge: always clear mcast matching struct on reports and leaves

here too.

Thanks for bringing this up!