--- /dev/null
+From foo@baz Mon Jan 21 09:11:47 CET 2019
+From: Eric Dumazet <edumazet@google.com>
+Date: Tue, 8 Jan 2019 04:06:14 -0800
+Subject: ipv6: fix kernel-infoleak in ipv6_local_error()
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit 7d033c9f6a7fd3821af75620a0257db87c2b552a ]
+
+This patch makes sure the flow label in the IPv6 header
+forged in ipv6_local_error() is initialized.
+
+BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
+CPU: 1 PID: 24675 Comm: syz-executor1 Not tainted 4.20.0-rc7+ #4
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0x173/0x1d0 lib/dump_stack.c:113
+ kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
+ kmsan_internal_check_memory+0x455/0xb00 mm/kmsan/kmsan.c:675
+ kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
+ _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
+ copy_to_user include/linux/uaccess.h:177 [inline]
+ move_addr_to_user+0x2e9/0x4f0 net/socket.c:227
+ ___sys_recvmsg+0x5d7/0x1140 net/socket.c:2284
+ __sys_recvmsg net/socket.c:2327 [inline]
+ __do_sys_recvmsg net/socket.c:2337 [inline]
+ __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
+ __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
+ do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
+ entry_SYSCALL_64_after_hwframe+0x63/0xe7
+RIP: 0033:0x457ec9
+Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
+RSP: 002b:00007f8750c06c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
+RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457ec9
+RDX: 0000000000002000 RSI: 0000000020000400 RDI: 0000000000000005
+RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8750c076d4
+R13: 00000000004c4a60 R14: 00000000004d8140 R15: 00000000ffffffff
+
+Uninit was stored to memory at:
+ kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
+ kmsan_save_stack mm/kmsan/kmsan.c:219 [inline]
+ kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:439
+ __msan_chain_origin+0x70/0xe0 mm/kmsan/kmsan_instr.c:200
+ ipv6_recv_error+0x1e3f/0x1eb0 net/ipv6/datagram.c:475
+ udpv6_recvmsg+0x398/0x2ab0 net/ipv6/udp.c:335
+ inet_recvmsg+0x4fb/0x600 net/ipv4/af_inet.c:830
+ sock_recvmsg_nosec net/socket.c:794 [inline]
+ sock_recvmsg+0x1d1/0x230 net/socket.c:801
+ ___sys_recvmsg+0x4d5/0x1140 net/socket.c:2278
+ __sys_recvmsg net/socket.c:2327 [inline]
+ __do_sys_recvmsg net/socket.c:2337 [inline]
+ __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
+ __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
+ do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
+ entry_SYSCALL_64_after_hwframe+0x63/0xe7
+
+Uninit was created at:
+ kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
+ kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158
+ kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176
+ kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185
+ slab_post_alloc_hook mm/slab.h:446 [inline]
+ slab_alloc_node mm/slub.c:2759 [inline]
+ __kmalloc_node_track_caller+0xe18/0x1030 mm/slub.c:4383
+ __kmalloc_reserve net/core/skbuff.c:137 [inline]
+ __alloc_skb+0x309/0xa20 net/core/skbuff.c:205
+ alloc_skb include/linux/skbuff.h:998 [inline]
+ ipv6_local_error+0x1a7/0x9e0 net/ipv6/datagram.c:334
+ __ip6_append_data+0x129f/0x4fd0 net/ipv6/ip6_output.c:1311
+ ip6_make_skb+0x6cc/0xcf0 net/ipv6/ip6_output.c:1775
+ udpv6_sendmsg+0x3f8e/0x45d0 net/ipv6/udp.c:1384
+ inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
+ sock_sendmsg_nosec net/socket.c:621 [inline]
+ sock_sendmsg net/socket.c:631 [inline]
+ __sys_sendto+0x8c4/0xac0 net/socket.c:1788
+ __do_sys_sendto net/socket.c:1800 [inline]
+ __se_sys_sendto+0x107/0x130 net/socket.c:1796
+ __x64_sys_sendto+0x6e/0x90 net/socket.c:1796
+ do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
+ entry_SYSCALL_64_after_hwframe+0x63/0xe7
+
+Bytes 4-7 of 28 are uninitialized
+Memory access of size 28 starts at ffff8881937bfce0
+Data copied to user address 0000000020000000
+
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/datagram.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/ipv6/datagram.c
++++ b/net/ipv6/datagram.c
+@@ -287,6 +287,7 @@ void ipv6_local_error(struct sock *sk, i
+ skb_reset_network_header(skb);
+ iph = ipv6_hdr(skb);
+ iph->daddr = fl6->daddr;
++ ip6_flow_hdr(iph, 0, 0);
+
+ serr = SKB_EXT_ERR(skb);
+ serr->ee.ee_errno = err;
--- /dev/null
+From foo@baz Mon Jan 21 09:11:47 CET 2019
+From: JianJhen Chen <kchen@synology.com>
+Date: Sun, 6 Jan 2019 11:28:13 +0800
+Subject: net: bridge: fix a bug on using a neighbour cache entry without checking its state
+
+From: JianJhen Chen <kchen@synology.com>
+
+[ Upstream commit 4c84edc11b76590859b1e45dd676074c59602dc4 ]
+
+When handling DNAT'ed packets on a bridge device, the neighbour cache entry
+from lookup was used without checking its state. It means that a cache entry
+in the NUD_STALE state will be used directly instead of entering the NUD_DELAY
+state to confirm the reachability of the neighbor.
+
+This problem becomes worse after commit 2724680bceee ("neigh: Keep neighbour
+cache entries if number of them is small enough."), since all neighbour cache
+entries in the NUD_STALE state will be kept in the neighbour table as long as
+the number of cache entries does not exceed the value specified in gc_thresh1.
+
+This commit validates the state of a neighbour cache entry before using
+the entry.
+
+Signed-off-by: JianJhen Chen <kchen@synology.com>
+Reviewed-by: JinLin Chen <jlchen@synology.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bridge/br_netfilter.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/bridge/br_netfilter.c
++++ b/net/bridge/br_netfilter.c
+@@ -287,7 +287,7 @@ static int br_nf_pre_routing_finish_brid
+ if (neigh) {
+ int ret;
+
+- if (neigh->hh.hh_len) {
++ if ((neigh->nud_state & NUD_CONNECTED) && neigh->hh.hh_len) {
+ neigh_hh_bridge(&neigh->hh, skb);
+ skb->dev = nf_bridge->physindev;
+ ret = br_handle_frame_finish(skb);
--- /dev/null
+From foo@baz Mon Jan 21 09:11:47 CET 2019
+From: Jason Gunthorpe <jgg@mellanox.com>
+Date: Tue, 8 Jan 2019 23:27:06 +0000
+Subject: packet: Do not leak dev refcounts on error exit
+
+From: Jason Gunthorpe <jgg@mellanox.com>
+
+[ Upstream commit d972f3dce8d161e2142da0ab1ef25df00e2f21a9 ]
+
+'dev' is non NULL when the addr_len check triggers so it must goto a label
+that does the dev_put otherwise dev will have a leaked refcount.
+
+This bug causes the ib_ipoib module to become unloadable when using
+systemd-network as it triggers this check on InfiniBand links.
+
+Fixes: 99137b7888f4 ("packet: validate address length")
+Reported-by: Leon Romanovsky <leonro@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Acked-by: Willem de Bruijn <willemb@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/packet/af_packet.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/packet/af_packet.c
++++ b/net/packet/af_packet.c
+@@ -2276,7 +2276,7 @@ static int tpacket_snd(struct packet_soc
+ addr = saddr->sll_halen ? saddr->sll_addr : NULL;
+ dev = dev_get_by_index(sock_net(&po->sk), saddr->sll_ifindex);
+ if (addr && dev && saddr->sll_halen < dev->addr_len)
+- goto out;
++ goto out_put;
+ }
+
+ err = -ENXIO;
+@@ -2439,7 +2439,7 @@ static int packet_snd(struct socket *soc
+ addr = saddr->sll_halen ? saddr->sll_addr : NULL;
+ dev = dev_get_by_index(sock_net(sk), saddr->sll_ifindex);
+ if (addr && dev && saddr->sll_halen < dev->addr_len)
+- goto out;
++ goto out_unlock;
+ }
+
+ err = -ENXIO;