--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 CET 2019
+From: Willem de Bruijn <willemb@google.com>
+Date: Tue, 8 Jan 2019 12:32:42 -0500
+Subject: bonding: update nest level on unlink
+
+From: Willem de Bruijn <willemb@google.com>
+
+[ Upstream commit 001e465f09a18857443489a57e74314a3368c805 ]
+
+A network device stack with multiple layers of bonding devices can
+trigger a false positive lockdep warning. Adding lockdep nest levels
+fixes this. Update the level on both enslave and unlink, to avoid the
+following series of events ..
+
+ ip netns add test
+ ip netns exec test bash
+ ip link set dev lo addr 00:11:22:33:44:55
+ ip link set dev lo down
+
+ ip link add dev bond1 type bond
+ ip link add dev bond2 type bond
+
+ ip link set dev lo master bond1
+ ip link set dev bond1 master bond2
+
+ ip link set dev bond1 nomaster
+ ip link set dev bond2 master bond1
+
+.. from still generating a splat:
+
+ [ 193.652127] ======================================================
+ [ 193.658231] WARNING: possible circular locking dependency detected
+ [ 193.664350] 4.20.0 #8 Not tainted
+ [ 193.668310] ------------------------------------------------------
+ [ 193.674417] ip/15577 is trying to acquire lock:
+ [ 193.678897] 00000000a40e3b69 (&(&bond->stats_lock)->rlock#3/3){+.+.}, at: bond_get_stats+0x58/0x290
+ [ 193.687851]
+ but task is already holding lock:
+ [ 193.693625] 00000000807b9d9f (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0x58/0x290
+
+ [..]
+
+ [ 193.851092] lock_acquire+0xa7/0x190
+ [ 193.855138] _raw_spin_lock_nested+0x2d/0x40
+ [ 193.859878] bond_get_stats+0x58/0x290
+ [ 193.864093] dev_get_stats+0x5a/0xc0
+ [ 193.868140] bond_get_stats+0x105/0x290
+ [ 193.872444] dev_get_stats+0x5a/0xc0
+ [ 193.876493] rtnl_fill_stats+0x40/0x130
+ [ 193.880797] rtnl_fill_ifinfo+0x6c5/0xdc0
+ [ 193.885271] rtmsg_ifinfo_build_skb+0x86/0xe0
+ [ 193.890091] rtnetlink_event+0x5b/0xa0
+ [ 193.894320] raw_notifier_call_chain+0x43/0x60
+ [ 193.899225] netdev_change_features+0x50/0xa0
+ [ 193.904044] bond_compute_features.isra.46+0x1ab/0x270
+ [ 193.909640] bond_enslave+0x141d/0x15b0
+ [ 193.913946] do_set_master+0x89/0xa0
+ [ 193.918016] do_setlink+0x37c/0xda0
+ [ 193.921980] __rtnl_newlink+0x499/0x890
+ [ 193.926281] rtnl_newlink+0x48/0x70
+ [ 193.930238] rtnetlink_rcv_msg+0x171/0x4b0
+ [ 193.934801] netlink_rcv_skb+0xd1/0x110
+ [ 193.939103] rtnetlink_rcv+0x15/0x20
+ [ 193.943151] netlink_unicast+0x3b5/0x520
+ [ 193.947544] netlink_sendmsg+0x2fd/0x3f0
+ [ 193.951942] sock_sendmsg+0x38/0x50
+ [ 193.955899] ___sys_sendmsg+0x2ba/0x2d0
+ [ 193.960205] __x64_sys_sendmsg+0xad/0x100
+ [ 193.964687] do_syscall_64+0x5a/0x460
+ [ 193.968823] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Fixes: 7e2556e40026 ("bonding: avoid lockdep confusion in bond_get_stats()")
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-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>
+---
+ drivers/net/bonding/bond_main.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/bonding/bond_main.c
++++ b/drivers/net/bonding/bond_main.c
+@@ -1947,6 +1947,9 @@ static int __bond_release_one(struct net
+ if (!bond_has_slaves(bond)) {
+ bond_set_carrier(bond);
+ eth_hw_addr_random(bond_dev);
++ bond->nest_level = SINGLE_DEPTH_NESTING;
++ } else {
++ bond->nest_level = dev_get_nest_level(bond_dev) + 1;
+ }
+
+ unblock_netpoll_tx();
--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 CET 2019
+From: Willem de Bruijn <willemb@google.com>
+Date: Mon, 7 Jan 2019 16:47:33 -0500
+Subject: ip: on queued skb use skb_header_pointer instead of pskb_may_pull
+
+From: Willem de Bruijn <willemb@google.com>
+
+[ Upstream commit 4a06fa67c4da20148803525151845276cdb995c1 ]
+
+Commit 2efd4fca703a ("ip: in cmsg IP(V6)_ORIGDSTADDR call
+pskb_may_pull") avoided a read beyond the end of the skb linear
+segment by calling pskb_may_pull.
+
+That function can trigger a BUG_ON in pskb_expand_head if the skb is
+shared, which it is when when peeking. It can also return ENOMEM.
+
+Avoid both by switching to safer skb_header_pointer.
+
+Fixes: 2efd4fca703a ("ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull")
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Suggested-by: Eric Dumazet <edumazet@google.com>
+Signed-off-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/ipv4/ip_sockglue.c | 12 +++++-------
+ net/ipv6/datagram.c | 10 ++++------
+ 2 files changed, 9 insertions(+), 13 deletions(-)
+
+--- a/net/ipv4/ip_sockglue.c
++++ b/net/ipv4/ip_sockglue.c
+@@ -148,19 +148,17 @@ static void ip_cmsg_recv_security(struct
+
+ static void ip_cmsg_recv_dstaddr(struct msghdr *msg, struct sk_buff *skb)
+ {
++ __be16 _ports[2], *ports;
+ struct sockaddr_in sin;
+- __be16 *ports;
+- int end;
+-
+- end = skb_transport_offset(skb) + 4;
+- if (end > 0 && !pskb_may_pull(skb, end))
+- return;
+
+ /* All current transport protocols have the port numbers in the
+ * first four bytes of the transport header and this function is
+ * written with this assumption in mind.
+ */
+- ports = (__be16 *)skb_transport_header(skb);
++ ports = skb_header_pointer(skb, skb_transport_offset(skb),
++ sizeof(_ports), &_ports);
++ if (!ports)
++ return;
+
+ sin.sin_family = AF_INET;
+ sin.sin_addr.s_addr = ip_hdr(skb)->daddr;
+--- a/net/ipv6/datagram.c
++++ b/net/ipv6/datagram.c
+@@ -701,17 +701,15 @@ void ip6_datagram_recv_specific_ctl(stru
+ }
+ if (np->rxopt.bits.rxorigdstaddr) {
+ struct sockaddr_in6 sin6;
+- __be16 *ports;
+- int end;
++ __be16 _ports[2], *ports;
+
+- end = skb_transport_offset(skb) + 4;
+- if (end <= 0 || pskb_may_pull(skb, end)) {
++ ports = skb_header_pointer(skb, skb_transport_offset(skb),
++ sizeof(_ports), &_ports);
++ if (ports) {
+ /* All current transport protocols have the port numbers in the
+ * first four bytes of the transport header and this function is
+ * written with this assumption in mind.
+ */
+- ports = (__be16 *)skb_transport_header(skb);
+-
+ sin6.sin6_family = AF_INET6;
+ sin6.sin6_addr = ipv6_hdr(skb)->daddr;
+ sin6.sin6_port = ports[1];
--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 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
+@@ -341,6 +341,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 08:59:26 CET 2019
+From: Bryan Whitehead <Bryan.Whitehead@microchip.com>
+Date: Mon, 7 Jan 2019 14:00:09 -0500
+Subject: lan743x: Remove phy_read from link status change function
+
+From: Bryan Whitehead <Bryan.Whitehead@microchip.com>
+
+[ Upstream commit a0071840d2040ea1b27e5a008182b09b88defc15 ]
+
+It has been noticed that some phys do not have the registers
+required by the previous implementation.
+
+To fix this, instead of using phy_read, the required information
+is extracted from the phy_device structure.
+
+fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
+Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/microchip/lan743x_main.c | 11 ++++-------
+ 1 file changed, 4 insertions(+), 7 deletions(-)
+
+--- a/drivers/net/ethernet/microchip/lan743x_main.c
++++ b/drivers/net/ethernet/microchip/lan743x_main.c
+@@ -962,13 +962,10 @@ static void lan743x_phy_link_status_chan
+
+ memset(&ksettings, 0, sizeof(ksettings));
+ phy_ethtool_get_link_ksettings(netdev, &ksettings);
+- local_advertisement = phy_read(phydev, MII_ADVERTISE);
+- if (local_advertisement < 0)
+- return;
+-
+- remote_advertisement = phy_read(phydev, MII_LPA);
+- if (remote_advertisement < 0)
+- return;
++ local_advertisement =
++ ethtool_adv_to_mii_adv_t(phydev->advertising);
++ remote_advertisement =
++ ethtool_adv_to_mii_adv_t(phydev->lp_advertising);
+
+ lan743x_phy_update_flowcontrol(adapter,
+ ksettings.base.duplex,
--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 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_hooks.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/bridge/br_netfilter_hooks.c
++++ b/net/bridge/br_netfilter_hooks.c
+@@ -278,7 +278,7 @@ int br_nf_pre_routing_finish_bridge(stru
+ struct nf_bridge_info *nf_bridge = nf_bridge_info_get(skb);
+ 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(net, sk, skb);
--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 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
+@@ -2628,7 +2628,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;
+@@ -2828,7 +2828,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;
--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 CET 2019
+From: Heiner Kallweit <hkallweit1@gmail.com>
+Date: Sun, 6 Jan 2019 20:44:00 +0100
+Subject: r8169: don't try to read counters if chip is in a PCI power-save state
+
+From: Heiner Kallweit <hkallweit1@gmail.com>
+
+[ Upstream commit 10262b0b53666cbc506989b17a3ead1e9c3b43b4 ]
+
+Avoid log spam caused by trying to read counters from the chip whilst
+it is in a PCI power-save state.
+
+Reference: https://bugzilla.kernel.org/show_bug.cgi?id=107421
+
+Fixes: 1ef7286e7f36 ("r8169: Dereference MMIO address immediately before use")
+Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/realtek/r8169.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/realtek/r8169.c
++++ b/drivers/net/ethernet/realtek/r8169.c
+@@ -1730,11 +1730,13 @@ static bool rtl8169_reset_counters(struc
+
+ static bool rtl8169_update_counters(struct rtl8169_private *tp)
+ {
++ u8 val = RTL_R8(tp, ChipCmd);
++
+ /*
+ * Some chips are unable to dump tally counters when the receiver
+- * is disabled.
++ * is disabled. If 0xff chip may be in a PCI power-save state.
+ */
+- if ((RTL_R8(tp, ChipCmd) & CmdRxEnb) == 0)
++ if (!(val & CmdRxEnb) || val == 0xff)
+ return true;
+
+ return rtl8169_do_counters(tp, CounterDump);
--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 CET 2019
+From: Heiner Kallweit <hkallweit1@gmail.com>
+Date: Mon, 7 Jan 2019 21:49:09 +0100
+Subject: r8169: load Realtek PHY driver module before r8169
+
+From: Heiner Kallweit <hkallweit1@gmail.com>
+
+[ Upstream commit 11287b693d03830010356339e4ceddf47dee34fa ]
+
+This soft dependency works around an issue where sometimes the genphy
+driver is used instead of the dedicated PHY driver. The root cause of
+the issue isn't clear yet. People reported the unloading/re-loading
+module r8169 helps, and also configuring this soft dependency in
+the modprobe config files. Important just seems to be that the
+realtek module is loaded before r8169.
+
+Once this has been applied preliminary fix 38af4b903210 ("net: phy:
+add workaround for issue where PHY driver doesn't bind to the device")
+will be removed.
+
+Fixes: f1e911d5d0df ("r8169: add basic phylib support")
+Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/realtek/r8169.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/ethernet/realtek/r8169.c
++++ b/drivers/net/ethernet/realtek/r8169.c
+@@ -717,6 +717,7 @@ module_param(use_dac, int, 0);
+ MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot.");
+ module_param_named(debug, debug.msg_enable, int, 0);
+ MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
++MODULE_SOFTDEP("pre: realtek");
+ MODULE_LICENSE("GPL");
+ MODULE_FIRMWARE(FIRMWARE_8168D_1);
+ MODULE_FIRMWARE(FIRMWARE_8168D_2);
scsi-target-iscsi-cxgbit-fix-csk-leak-2.patch
arm64-kvm-consistently-handle-host-hcr_el2-flags.patch
arm64-don-t-trap-host-pointer-auth-use-to-el2.patch
+ipv6-fix-kernel-infoleak-in-ipv6_local_error.patch
+net-bridge-fix-a-bug-on-using-a-neighbour-cache-entry-without-checking-its-state.patch
+packet-do-not-leak-dev-refcounts-on-error-exit.patch
+tcp-change-txhash-on-syn-data-timeout.patch
+tun-publish-tfile-after-it-s-fully-initialized.patch
+lan743x-remove-phy_read-from-link-status-change-function.patch
+smc-move-unhash-as-early-as-possible-in-smc_release.patch
+r8169-don-t-try-to-read-counters-if-chip-is-in-a-pci-power-save-state.patch
+bonding-update-nest-level-on-unlink.patch
+ip-on-queued-skb-use-skb_header_pointer-instead-of-pskb_may_pull.patch
+r8169-load-realtek-phy-driver-module-before-r8169.patch
--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 CET 2019
+From: Cong Wang <xiyou.wangcong@gmail.com>
+Date: Sat, 5 Jan 2019 23:45:26 -0800
+Subject: smc: move unhash as early as possible in smc_release()
+
+From: Cong Wang <xiyou.wangcong@gmail.com>
+
+[ Upstream commit 26d92e951fe0a44ee4aec157cabb65a818cc8151 ]
+
+In smc_release() we release smc->clcsock before unhash the smc
+sock, but a parallel smc_diag_dump() may be still reading
+smc->clcsock, therefore this could cause a use-after-free as
+reported by syzbot.
+
+Reported-and-tested-by: syzbot+fbd1e5476e4c94c7b34e@syzkaller.appspotmail.com
+Fixes: 51f1de79ad8e ("net/smc: replace sock_put worker by socket refcounting")
+Cc: Ursula Braun <ubraun@linux.ibm.com>
+Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
+Reported-by: syzbot+0bf2e01269f1274b4b03@syzkaller.appspotmail.com
+Reported-by: syzbot+e3132895630f957306bc@syzkaller.appspotmail.com
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/smc/af_smc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/net/smc/af_smc.c
++++ b/net/smc/af_smc.c
+@@ -144,6 +144,9 @@ static int smc_release(struct socket *so
+ sock_set_flag(sk, SOCK_DEAD);
+ sk->sk_shutdown |= SHUTDOWN_MASK;
+ }
++
++ sk->sk_prot->unhash(sk);
++
+ if (smc->clcsock) {
+ if (smc->use_fallback && sk->sk_state == SMC_LISTEN) {
+ /* wake up clcsock accept */
+@@ -168,7 +171,6 @@ static int smc_release(struct socket *so
+ smc_conn_free(&smc->conn);
+ release_sock(sk);
+
+- sk->sk_prot->unhash(sk);
+ sock_put(sk); /* final sock_put */
+ out:
+ return rc;
--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 CET 2019
+From: Yuchung Cheng <ycheng@google.com>
+Date: Tue, 8 Jan 2019 18:14:28 -0800
+Subject: tcp: change txhash on SYN-data timeout
+
+From: Yuchung Cheng <ycheng@google.com>
+
+[ Upstream commit c5715b8fabfca0ef85903f8bad2189940ed41cc8 ]
+
+Previously upon SYN timeouts the sender recomputes the txhash to
+try a different path. However this does not apply on the initial
+timeout of SYN-data (active Fast Open). Therefore an active IPv6
+Fast Open connection may incur one second RTO penalty to take on
+a new path after the second SYN retransmission uses a new flow label.
+
+This patch removes this undesirable behavior so Fast Open changes
+the flow label just like the regular connections. This also helps
+avoid falsely disabling Fast Open on the sender which triggers
+after two consecutive SYN timeouts on Fast Open.
+
+Signed-off-by: Yuchung Cheng <ycheng@google.com>
+Reviewed-by: Neal Cardwell <ncardwell@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/tcp_timer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ipv4/tcp_timer.c
++++ b/net/ipv4/tcp_timer.c
+@@ -224,7 +224,7 @@ static int tcp_write_timeout(struct sock
+ if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
+ if (icsk->icsk_retransmits) {
+ dst_negative_advice(sk);
+- } else if (!tp->syn_data && !tp->syn_fastopen) {
++ } else {
+ sk_rethink_txhash(sk);
+ }
+ retry_until = icsk->icsk_syn_retries ? : net->ipv4.sysctl_tcp_syn_retries;
--- /dev/null
+From foo@baz Mon Jan 21 08:59:26 CET 2019
+From: Stanislav Fomichev <sdf@google.com>
+Date: Mon, 7 Jan 2019 13:38:38 -0800
+Subject: tun: publish tfile after it's fully initialized
+
+From: Stanislav Fomichev <sdf@google.com>
+
+[ Upstream commit 0b7959b6257322f7693b08a459c505d4938646f2 ]
+
+BUG: unable to handle kernel NULL pointer dereference at 00000000000000d1
+Call Trace:
+ ? napi_gro_frags+0xa7/0x2c0
+ tun_get_user+0xb50/0xf20
+ tun_chr_write_iter+0x53/0x70
+ new_sync_write+0xff/0x160
+ vfs_write+0x191/0x1e0
+ __x64_sys_write+0x5e/0xd0
+ do_syscall_64+0x47/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+I think there is a subtle race between sending a packet via tap and
+attaching it:
+
+CPU0: CPU1:
+tun_chr_ioctl(TUNSETIFF)
+ tun_set_iff
+ tun_attach
+ rcu_assign_pointer(tfile->tun, tun);
+ tun_fops->write_iter()
+ tun_chr_write_iter
+ tun_napi_alloc_frags
+ napi_get_frags
+ napi->skb = napi_alloc_skb
+ tun_napi_init
+ netif_napi_add
+ napi->skb = NULL
+ napi->skb is NULL here
+ napi_gro_frags
+ napi_frags_skb
+ skb = napi->skb
+ skb_reset_mac_header(skb)
+ panic()
+
+Move rcu_assign_pointer(tfile->tun) and rcu_assign_pointer(tun->tfiles) to
+be the last thing we do in tun_attach(); this should guarantee that when we
+call tun_get() we always get an initialized object.
+
+v2 changes:
+* remove extra napi_mutex locks/unlocks for napi operations
+
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
+
+Signed-off-by: Stanislav Fomichev <sdf@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/tun.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/tun.c
++++ b/drivers/net/tun.c
+@@ -859,10 +859,6 @@ static int tun_attach(struct tun_struct
+ err = 0;
+ }
+
+- rcu_assign_pointer(tfile->tun, tun);
+- rcu_assign_pointer(tun->tfiles[tun->numqueues], tfile);
+- tun->numqueues++;
+-
+ if (tfile->detached) {
+ tun_enable_queue(tfile);
+ } else {
+@@ -876,6 +872,13 @@ static int tun_attach(struct tun_struct
+ * refcnt.
+ */
+
++ /* Publish tfile->tun and tun->tfiles only after we've fully
++ * initialized tfile; otherwise we risk using half-initialized
++ * object.
++ */
++ rcu_assign_pointer(tfile->tun, tun);
++ rcu_assign_pointer(tun->tfiles[tun->numqueues], tfile);
++ tun->numqueues++;
+ out:
+ return err;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
