--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Matteo Croce <mcroce@redhat.com>
+Date: Thu, 2 May 2019 10:51:05 +0200
+Subject: cls_matchall: avoid panic when receiving a packet before filter set
+
+From: Matteo Croce <mcroce@redhat.com>
+
+[ Upstream commit 25426043ec9e22b90c789407c28e40f32a9d1985 ]
+
+When a matchall classifier is added, there is a small time interval in
+which tp->root is NULL. If we receive a packet in this small time slice
+a NULL pointer dereference will happen, leading to a kernel panic:
+
+ # tc qdisc replace dev eth0 ingress
+ # tc filter add dev eth0 parent ffff: matchall action gact drop
+ Unable to handle kernel NULL pointer dereference at virtual address 0000000000000034
+ Mem abort info:
+ ESR = 0x96000005
+ Exception class = DABT (current EL), IL = 32 bits
+ SET = 0, FnV = 0
+ EA = 0, S1PTW = 0
+ Data abort info:
+ ISV = 0, ISS = 0x00000005
+ CM = 0, WnR = 0
+ user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000a623d530
+ [0000000000000034] pgd=0000000000000000, pud=0000000000000000
+ Internal error: Oops: 96000005 [#1] SMP
+ Modules linked in: cls_matchall sch_ingress nls_iso8859_1 nls_cp437 vfat fat m25p80 spi_nor mtd xhci_plat_hcd xhci_hcd phy_generic sfp mdio_i2c usbcore i2c_mv64xxx marvell10g mvpp2 usb_common spi_orion mvmdio i2c_core sbsa_gwdt phylink ip_tables x_tables autofs4
+ Process ksoftirqd/0 (pid: 9, stack limit = 0x0000000009de7d62)
+ CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.1.0-rc6 #21
+ Hardware name: Marvell 8040 MACCHIATOBin Double-shot (DT)
+ pstate: 40000005 (nZcv daif -PAN -UAO)
+ pc : mall_classify+0x28/0x78 [cls_matchall]
+ lr : tcf_classify+0x78/0x138
+ sp : ffffff80109db9d0
+ x29: ffffff80109db9d0 x28: ffffffc426058800
+ x27: 0000000000000000 x26: ffffffc425b0dd00
+ x25: 0000000020000000 x24: 0000000000000000
+ x23: ffffff80109dbac0 x22: 0000000000000001
+ x21: ffffffc428ab5100 x20: ffffffc425b0dd00
+ x19: ffffff80109dbac0 x18: 0000000000000000
+ x17: 0000000000000000 x16: 0000000000000000
+ x15: 0000000000000000 x14: 0000000000000000
+ x13: ffffffbf108ad288 x12: dead000000000200
+ x11: 00000000f0000000 x10: 0000000000000001
+ x9 : ffffffbf1089a220 x8 : 0000000000000001
+ x7 : ffffffbebffaa950 x6 : 0000000000000000
+ x5 : 000000442d6ba000 x4 : 0000000000000000
+ x3 : ffffff8008735ad8 x2 : ffffff80109dbac0
+ x1 : ffffffc425b0dd00 x0 : ffffff8010592078
+ Call trace:
+ mall_classify+0x28/0x78 [cls_matchall]
+ tcf_classify+0x78/0x138
+ __netif_receive_skb_core+0x29c/0xa20
+ __netif_receive_skb_one_core+0x34/0x60
+ __netif_receive_skb+0x28/0x78
+ netif_receive_skb_internal+0x2c/0xc0
+ napi_gro_receive+0x1a0/0x1d8
+ mvpp2_poll+0x928/0xb18 [mvpp2]
+ net_rx_action+0x108/0x378
+ __do_softirq+0x128/0x320
+ run_ksoftirqd+0x44/0x60
+ smpboot_thread_fn+0x168/0x1b0
+ kthread+0x12c/0x130
+ ret_from_fork+0x10/0x1c
+ Code: aa0203f3 aa1e03e0 d503201f f9400684 (b9403480)
+ ---[ end trace fc71e2ef7b8ab5a5 ]---
+ Kernel panic - not syncing: Fatal exception in interrupt
+ SMP: stopping secondary CPUs
+ Kernel Offset: disabled
+ CPU features: 0x002,00002000
+ Memory Limit: none
+ Rebooting in 1 seconds..
+
+Fix this by adding a NULL check in mall_classify().
+
+Fixes: ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex")
+Signed-off-by: Matteo Croce <mcroce@redhat.com>
+Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sched/cls_matchall.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/sched/cls_matchall.c
++++ b/net/sched/cls_matchall.c
+@@ -32,6 +32,9 @@ static int mall_classify(struct sk_buff
+ {
+ struct cls_mall_head *head = rcu_dereference_bh(tp->root);
+
++ if (unlikely(!head))
++ return -1;
++
+ if (tc_skip_sw(head->flags))
+ return -1;
+
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Vivien Didelot <vivien.didelot@gmail.com>
+Date: Mon, 3 Jun 2019 16:57:13 -0400
+Subject: ethtool: fix potential userspace buffer overflow
+
+From: Vivien Didelot <vivien.didelot@gmail.com>
+
+[ Upstream commit 0ee4e76937d69128a6a66861ba393ebdc2ffc8a2 ]
+
+ethtool_get_regs() allocates a buffer of size ops->get_regs_len(),
+and pass it to the kernel driver via ops->get_regs() for filling.
+
+There is no restriction about what the kernel drivers can or cannot do
+with the open ethtool_regs structure. They usually set regs->version
+and ignore regs->len or set it to the same size as ops->get_regs_len().
+
+But if userspace allocates a smaller buffer for the registers dump,
+we would cause a userspace buffer overflow in the final copy_to_user()
+call, which uses the regs.len value potentially reset by the driver.
+
+To fix this, make this case obvious and store regs.len before calling
+ops->get_regs(), to only copy as much data as requested by userspace,
+up to the value returned by ops->get_regs_len().
+
+While at it, remove the redundant check for non-null regbuf.
+
+Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
+Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/ethtool.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/net/core/ethtool.c
++++ b/net/core/ethtool.c
+@@ -1358,13 +1358,16 @@ static int ethtool_get_regs(struct net_d
+ if (!regbuf)
+ return -ENOMEM;
+
++ if (regs.len < reglen)
++ reglen = regs.len;
++
+ ops->get_regs(dev, ®s, regbuf);
+
+ ret = -EFAULT;
+ if (copy_to_user(useraddr, ®s, sizeof(regs)))
+ goto out;
+ useraddr += offsetof(struct ethtool_regs, data);
+- if (regbuf && copy_to_user(useraddr, regbuf, regs.len))
++ if (copy_to_user(useraddr, regbuf, reglen))
+ goto out;
+ ret = 0;
+
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Neil Horman <nhorman@tuxdriver.com>
+Date: Mon, 3 Jun 2019 16:32:59 -0400
+Subject: Fix memory leak in sctp_process_init
+
+From: Neil Horman <nhorman@tuxdriver.com>
+
+[ Upstream commit 0a8dd9f67cd0da7dc284f48b032ce00db1a68791 ]
+
+syzbot found the following leak in sctp_process_init
+BUG: memory leak
+unreferenced object 0xffff88810ef68400 (size 1024):
+ comm "syz-executor273", pid 7046, jiffies 4294945598 (age 28.770s)
+ hex dump (first 32 bytes):
+ 1d de 28 8d de 0b 1b e3 b5 c2 f9 68 fd 1a 97 25 ..(........h...%
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<00000000a02cebbd>] kmemleak_alloc_recursive include/linux/kmemleak.h:55
+[inline]
+ [<00000000a02cebbd>] slab_post_alloc_hook mm/slab.h:439 [inline]
+ [<00000000a02cebbd>] slab_alloc mm/slab.c:3326 [inline]
+ [<00000000a02cebbd>] __do_kmalloc mm/slab.c:3658 [inline]
+ [<00000000a02cebbd>] __kmalloc_track_caller+0x15d/0x2c0 mm/slab.c:3675
+ [<000000009e6245e6>] kmemdup+0x27/0x60 mm/util.c:119
+ [<00000000dfdc5d2d>] kmemdup include/linux/string.h:432 [inline]
+ [<00000000dfdc5d2d>] sctp_process_init+0xa7e/0xc20
+net/sctp/sm_make_chunk.c:2437
+ [<00000000b58b62f8>] sctp_cmd_process_init net/sctp/sm_sideeffect.c:682
+[inline]
+ [<00000000b58b62f8>] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1384
+[inline]
+ [<00000000b58b62f8>] sctp_side_effects net/sctp/sm_sideeffect.c:1194
+[inline]
+ [<00000000b58b62f8>] sctp_do_sm+0xbdc/0x1d60 net/sctp/sm_sideeffect.c:1165
+ [<0000000044e11f96>] sctp_assoc_bh_rcv+0x13c/0x200
+net/sctp/associola.c:1074
+ [<00000000ec43804d>] sctp_inq_push+0x7f/0xb0 net/sctp/inqueue.c:95
+ [<00000000726aa954>] sctp_backlog_rcv+0x5e/0x2a0 net/sctp/input.c:354
+ [<00000000d9e249a8>] sk_backlog_rcv include/net/sock.h:950 [inline]
+ [<00000000d9e249a8>] __release_sock+0xab/0x110 net/core/sock.c:2418
+ [<00000000acae44fa>] release_sock+0x37/0xd0 net/core/sock.c:2934
+ [<00000000963cc9ae>] sctp_sendmsg+0x2c0/0x990 net/sctp/socket.c:2122
+ [<00000000a7fc7565>] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802
+ [<00000000b732cbd3>] sock_sendmsg_nosec net/socket.c:652 [inline]
+ [<00000000b732cbd3>] sock_sendmsg+0x54/0x70 net/socket.c:671
+ [<00000000274c57ab>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2292
+ [<000000008252aedb>] __sys_sendmsg+0x80/0xf0 net/socket.c:2330
+ [<00000000f7bf23d1>] __do_sys_sendmsg net/socket.c:2339 [inline]
+ [<00000000f7bf23d1>] __se_sys_sendmsg net/socket.c:2337 [inline]
+ [<00000000f7bf23d1>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2337
+ [<00000000a8b4131f>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:3
+
+The problem was that the peer.cookie value points to an skb allocated
+area on the first pass through this function, at which point it is
+overwritten with a heap allocated value, but in certain cases, where a
+COOKIE_ECHO chunk is included in the packet, a second pass through
+sctp_process_init is made, where the cookie value is re-allocated,
+leaking the first allocation.
+
+Fix is to always allocate the cookie value, and free it when we are done
+using it.
+
+Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
+Reported-by: syzbot+f7e9153b037eac9b1df8@syzkaller.appspotmail.com
+CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
+CC: "David S. Miller" <davem@davemloft.net>
+CC: netdev@vger.kernel.org
+Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sctp/sm_make_chunk.c | 13 +++----------
+ net/sctp/sm_sideeffect.c | 5 +++++
+ 2 files changed, 8 insertions(+), 10 deletions(-)
+
+--- a/net/sctp/sm_make_chunk.c
++++ b/net/sctp/sm_make_chunk.c
+@@ -2329,7 +2329,6 @@ int sctp_process_init(struct sctp_associ
+ union sctp_addr addr;
+ struct sctp_af *af;
+ int src_match = 0;
+- char *cookie;
+
+ /* We must include the address that the INIT packet came from.
+ * This is the only address that matters for an INIT packet.
+@@ -2433,14 +2432,6 @@ int sctp_process_init(struct sctp_associ
+ /* Peer Rwnd : Current calculated value of the peer's rwnd. */
+ asoc->peer.rwnd = asoc->peer.i.a_rwnd;
+
+- /* Copy cookie in case we need to resend COOKIE-ECHO. */
+- cookie = asoc->peer.cookie;
+- if (cookie) {
+- asoc->peer.cookie = kmemdup(cookie, asoc->peer.cookie_len, gfp);
+- if (!asoc->peer.cookie)
+- goto clean_up;
+- }
+-
+ /* RFC 2960 7.2.1 The initial value of ssthresh MAY be arbitrarily
+ * high (for example, implementations MAY use the size of the receiver
+ * advertised window).
+@@ -2609,7 +2600,9 @@ do_addr_param:
+ case SCTP_PARAM_STATE_COOKIE:
+ asoc->peer.cookie_len =
+ ntohs(param.p->length) - sizeof(struct sctp_paramhdr);
+- asoc->peer.cookie = param.cookie->body;
++ asoc->peer.cookie = kmemdup(param.cookie->body, asoc->peer.cookie_len, gfp);
++ if (!asoc->peer.cookie)
++ retval = 0;
+ break;
+
+ case SCTP_PARAM_HEARTBEAT_INFO:
+--- a/net/sctp/sm_sideeffect.c
++++ b/net/sctp/sm_sideeffect.c
+@@ -898,6 +898,11 @@ static void sctp_cmd_new_state(struct sc
+ asoc->rto_initial;
+ }
+
++ if (sctp_state(asoc, ESTABLISHED)) {
++ kfree(asoc->peer.cookie);
++ asoc->peer.cookie = NULL;
++ }
++
+ if (sctp_state(asoc, ESTABLISHED) ||
+ sctp_state(asoc, CLOSED) ||
+ sctp_state(asoc, SHUTDOWN_RECEIVED)) {
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: David Ahern <dsahern@gmail.com>
+Date: Thu, 2 May 2019 15:14:15 -0700
+Subject: ipmr_base: Do not reset index in mr_table_dump
+
+From: David Ahern <dsahern@gmail.com>
+
+[ Upstream commit 7fcd1e033dacedd520abebc943c960dcf5add3ae ]
+
+e is the counter used to save the location of a dump when an
+skb is filled. Once the walk of the table is complete, mr_table_dump
+needs to return without resetting that index to 0. Dump of a specific
+table is looping because of the reset because there is no way to
+indicate the walk of the table is done.
+
+Move the reset to the caller so the dump of each table starts at 0,
+but the loop counter is maintained if a dump fills an skb.
+
+Fixes: e1cedae1ba6b0 ("ipmr: Refactor mr_rtm_dumproute")
+Signed-off-by: David Ahern <dsahern@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/ipmr_base.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/net/ipv4/ipmr_base.c
++++ b/net/ipv4/ipmr_base.c
+@@ -335,8 +335,6 @@ next_entry2:
+ }
+ spin_unlock_bh(lock);
+ err = 0;
+- e = 0;
+-
+ out:
+ cb->args[1] = e;
+ return err;
+@@ -374,6 +372,7 @@ int mr_rtm_dumproute(struct sk_buff *skb
+ err = mr_table_dump(mrt, skb, cb, fill, lock, filter);
+ if (err < 0)
+ break;
++ cb->args[1] = 0;
+ next_table:
+ t++;
+ }
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Xin Long <lucien.xin@gmail.com>
+Date: Sun, 2 Jun 2019 19:10:24 +0800
+Subject: ipv4: not do cache for local delivery if bc_forwarding is enabled
+
+From: Xin Long <lucien.xin@gmail.com>
+
+[ Upstream commit 0a90478b93a46bdcd56ba33c37566a993e455d54 ]
+
+With the topo:
+
+ h1 ---| rp1 |
+ | route rp3 |--- h3 (192.168.200.1)
+ h2 ---| rp2 |
+
+If rp1 bc_forwarding is set while rp2 bc_forwarding is not, after
+doing "ping 192.168.200.255" on h1, then ping 192.168.200.255 on
+h2, and the packets can still be forwared.
+
+This issue was caused by the input route cache. It should only do
+the cache for either bc forwarding or local delivery. Otherwise,
+local delivery can use the route cache for bc forwarding of other
+interfaces.
+
+This patch is to fix it by not doing cache for local delivery if
+all.bc_forwarding is enabled.
+
+Note that we don't fix it by checking route cache local flag after
+rt_cache_valid() in "local_input:" and "ip_mkroute_input", as the
+common route code shouldn't be touched for bc_forwarding.
+
+Fixes: 5cbf777cfdf6 ("route: add support for directed broadcast forwarding")
+Reported-by: Jianlin Shi <jishi@redhat.com>
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/route.c | 22 +++++++++++-----------
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+--- a/net/ipv4/route.c
++++ b/net/ipv4/route.c
+@@ -1954,7 +1954,7 @@ static int ip_route_input_slow(struct sk
+ u32 itag = 0;
+ struct rtable *rth;
+ struct flowi4 fl4;
+- bool do_cache;
++ bool do_cache = true;
+
+ /* IP on this device is disabled. */
+
+@@ -2031,6 +2031,9 @@ static int ip_route_input_slow(struct sk
+ if (res->type == RTN_BROADCAST) {
+ if (IN_DEV_BFORWARD(in_dev))
+ goto make_route;
++ /* not do cache if bc_forwarding is enabled */
++ if (IPV4_DEVCONF_ALL(net, BC_FORWARDING))
++ do_cache = false;
+ goto brd_input;
+ }
+
+@@ -2068,16 +2071,13 @@ brd_input:
+ RT_CACHE_STAT_INC(in_brd);
+
+ local_input:
+- do_cache = false;
+- if (res->fi) {
+- if (!itag) {
+- rth = rcu_dereference(FIB_RES_NH(*res).nh_rth_input);
+- if (rt_cache_valid(rth)) {
+- skb_dst_set_noref(skb, &rth->dst);
+- err = 0;
+- goto out;
+- }
+- do_cache = true;
++ do_cache &= res->fi && !itag;
++ if (do_cache) {
++ rth = rcu_dereference(FIB_RES_NH(*res).nh_rth_input);
++ if (rt_cache_valid(rth)) {
++ skb_dst_set_noref(skb, &rth->dst);
++ err = 0;
++ goto out;
+ }
+ }
+
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Olivier Matz <olivier.matz@6wind.com>
+Date: Thu, 6 Jun 2019 09:15:19 +0200
+Subject: ipv6: fix EFAULT on sendto with icmpv6 and hdrincl
+
+From: Olivier Matz <olivier.matz@6wind.com>
+
+[ Upstream commit b9aa52c4cb457e7416cc0c95f475e72ef4a61336 ]
+
+The following code returns EFAULT (Bad address):
+
+ s = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
+ setsockopt(s, SOL_IPV6, IPV6_HDRINCL, 1);
+ sendto(ipv6_icmp6_packet, addr); /* returns -1, errno = EFAULT */
+
+The IPv4 equivalent code works. A workaround is to use IPPROTO_RAW
+instead of IPPROTO_ICMPV6.
+
+The failure happens because 2 bytes are eaten from the msghdr by
+rawv6_probe_proto_opt() starting from commit 19e3c66b52ca ("ipv6
+equivalent of "ipv4: Avoid reading user iov twice after
+raw_probe_proto_opt""), but at that time it was not a problem because
+IPV6_HDRINCL was not yet introduced.
+
+Only eat these 2 bytes if hdrincl == 0.
+
+Fixes: 715f504b1189 ("ipv6: add IPV6_HDRINCL option for raw sockets")
+Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
+Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/raw.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/net/ipv6/raw.c
++++ b/net/ipv6/raw.c
+@@ -895,11 +895,14 @@ static int rawv6_sendmsg(struct sock *sk
+ opt = ipv6_fixup_options(&opt_space, opt);
+
+ fl6.flowi6_proto = proto;
+- rfv.msg = msg;
+- rfv.hlen = 0;
+- err = rawv6_probe_proto_opt(&rfv, &fl6);
+- if (err)
+- goto out;
++
++ if (!hdrincl) {
++ rfv.msg = msg;
++ rfv.hlen = 0;
++ err = rawv6_probe_proto_opt(&rfv, &fl6);
++ if (err)
++ goto out;
++ }
+
+ if (!ipv6_addr_any(daddr))
+ fl6.daddr = *daddr;
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Xin Long <lucien.xin@gmail.com>
+Date: Sun, 2 Jun 2019 19:10:46 +0800
+Subject: ipv6: fix the check before getting the cookie in rt6_get_cookie
+
+From: Xin Long <lucien.xin@gmail.com>
+
+[ Upstream commit b7999b07726c16974ba9ca3bb9fe98ecbec5f81c ]
+
+In Jianlin's testing, netperf was broken with 'Connection reset by peer',
+as the cookie check failed in rt6_check() and ip6_dst_check() always
+returned NULL.
+
+It's caused by Commit 93531c674315 ("net/ipv6: separate handling of FIB
+entries from dst based routes"), where the cookie can be got only when
+'c1'(see below) for setting dst_cookie whereas rt6_check() is called
+when !'c1' for checking dst_cookie, as we can see in ip6_dst_check().
+
+Since in ip6_dst_check() both rt6_dst_from_check() (c1) and rt6_check()
+(!c1) will check the 'from' cookie, this patch is to remove the c1 check
+in rt6_get_cookie(), so that the dst_cookie can always be set properly.
+
+c1:
+ (rt->rt6i_flags & RTF_PCPU || unlikely(!list_empty(&rt->rt6i_uncached)))
+
+Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
+Reported-by: Jianlin Shi <jishi@redhat.com>
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/ip6_fib.h | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/include/net/ip6_fib.h
++++ b/include/net/ip6_fib.h
+@@ -259,8 +259,7 @@ static inline u32 rt6_get_cookie(const s
+ rcu_read_lock();
+
+ from = rcu_dereference(rt->from);
+- if (from && (rt->rt6i_flags & RTF_PCPU ||
+- unlikely(!list_empty(&rt->rt6i_uncached))))
++ if (from)
+ fib6_get_cookie_safe(from, &cookie);
+
+ rcu_read_unlock();
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Olivier Matz <olivier.matz@6wind.com>
+Date: Thu, 6 Jun 2019 09:15:18 +0200
+Subject: ipv6: use READ_ONCE() for inet->hdrincl as in ipv4
+
+From: Olivier Matz <olivier.matz@6wind.com>
+
+[ Upstream commit 59e3e4b52663a9d97efbce7307f62e4bc5c9ce91 ]
+
+As it was done in commit 8f659a03a0ba ("net: ipv4: fix for a race
+condition in raw_sendmsg") and commit 20b50d79974e ("net: ipv4: emulate
+READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()") for ipv4, copy the
+value of inet->hdrincl in a local variable, to avoid introducing a race
+condition in the next commit.
+
+Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/raw.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/net/ipv6/raw.c
++++ b/net/ipv6/raw.c
+@@ -783,6 +783,7 @@ static int rawv6_sendmsg(struct sock *sk
+ struct flowi6 fl6;
+ struct ipcm6_cookie ipc6;
+ int addr_len = msg->msg_namelen;
++ int hdrincl;
+ u16 proto;
+ int err;
+
+@@ -796,6 +797,13 @@ static int rawv6_sendmsg(struct sock *sk
+ if (msg->msg_flags & MSG_OOB)
+ return -EOPNOTSUPP;
+
++ /* hdrincl should be READ_ONCE(inet->hdrincl)
++ * but READ_ONCE() doesn't work with bit fields.
++ * Doing this indirectly yields the same result.
++ */
++ hdrincl = inet->hdrincl;
++ hdrincl = READ_ONCE(hdrincl);
++
+ /*
+ * Get and verify the address.
+ */
+@@ -908,7 +916,7 @@ static int rawv6_sendmsg(struct sock *sk
+ fl6.flowi6_oif = np->ucast_oif;
+ security_sk_classify_flow(sk, flowi6_to_flowi(&fl6));
+
+- if (inet->hdrincl)
++ if (hdrincl)
+ fl6.flowi6_flags |= FLOWI_FLAG_KNOWN_NH;
+
+ if (ipc6.tclass < 0)
+@@ -931,7 +939,7 @@ static int rawv6_sendmsg(struct sock *sk
+ goto do_confirm;
+
+ back_from_confirm:
+- if (inet->hdrincl)
++ if (hdrincl)
+ err = rawv6_send_hdrinc(sk, msg, len, &fl6, &dst,
+ msg->msg_flags, &ipc6.sockc);
+ else {
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: David Ahern <dsahern@gmail.com>
+Date: Wed, 1 May 2019 18:18:42 -0700
+Subject: neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit
+
+From: David Ahern <dsahern@gmail.com>
+
+[ Upstream commit 4b2a2bfeb3f056461a90bd621e8bd7d03fa47f60 ]
+
+Commit cd9ff4de0107 changed the key for IFF_POINTOPOINT devices to
+INADDR_ANY but neigh_xmit which is used for MPLS encapsulations was not
+updated to use the altered key. The result is that every packet Tx does
+a lookup on the gateway address which does not find an entry, a new one
+is created only to find the existing one in the table right before the
+insert since arp_constructor was updated to reset the primary key. This
+is seen in the allocs and destroys counters:
+ ip -s -4 ntable show | head -10 | grep alloc
+
+which increase for each packet showing the unnecessary overhread.
+
+Fix by having neigh_xmit use __ipv4_neigh_lookup_noref for NEIGH_ARP_TABLE.
+
+Fixes: cd9ff4de0107 ("ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY")
+Reported-by: Alan Maguire <alan.maguire@oracle.com>
+Signed-off-by: David Ahern <dsahern@gmail.com>
+Tested-by: Alan Maguire <alan.maguire@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/neighbour.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/net/core/neighbour.c
++++ b/net/core/neighbour.c
+@@ -31,6 +31,7 @@
+ #include <linux/times.h>
+ #include <net/net_namespace.h>
+ #include <net/neighbour.h>
++#include <net/arp.h>
+ #include <net/dst.h>
+ #include <net/sock.h>
+ #include <net/netevent.h>
+@@ -2984,7 +2985,13 @@ int neigh_xmit(int index, struct net_dev
+ if (!tbl)
+ goto out;
+ rcu_read_lock_bh();
+- neigh = __neigh_lookup_noref(tbl, addr, dev);
++ if (index == NEIGH_ARP_TABLE) {
++ u32 key = *((u32 *)addr);
++
++ neigh = __ipv4_neigh_lookup_noref(dev, key);
++ } else {
++ neigh = __neigh_lookup_noref(tbl, addr, dev);
++ }
+ if (!neigh)
+ neigh = __neigh_create(tbl, addr, dev, false);
+ err = PTR_ERR(neigh);
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: David Ahern <dsahern@gmail.com>
+Date: Wed, 1 May 2019 18:08:34 -0700
+Subject: neighbor: Reset gc_entries counter if new entry is released before insert
+
+From: David Ahern <dsahern@gmail.com>
+
+[ Upstream commit 64c6f4bbca748c3b2101469a76d88b7cd1c00476 ]
+
+Ian and Alan both reported seeing overflows after upgrades to 5.x kernels:
+ neighbour: arp_cache: neighbor table overflow!
+
+Alan's mpls script helped get to the bottom of this bug. When a new entry
+is created the gc_entries counter is bumped in neigh_alloc to check if a
+new one is allowed to be created. ___neigh_create then searches for an
+existing entry before inserting the just allocated one. If an entry
+already exists, the new one is dropped in favor of the existing one. In
+this case the cleanup path needs to drop the gc_entries counter. There
+is no memory leak, only a counter leak.
+
+Fixes: 58956317c8d ("neighbor: Improve garbage collection")
+Reported-by: Ian Kumlien <ian.kumlien@gmail.com>
+Reported-by: Alan Maguire <alan.maguire@oracle.com>
+Signed-off-by: David Ahern <dsahern@gmail.com>
+Tested-by: Alan Maguire <alan.maguire@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/neighbour.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/core/neighbour.c
++++ b/net/core/neighbour.c
+@@ -663,6 +663,8 @@ out:
+ out_tbl_unlock:
+ write_unlock_bh(&tbl->lock);
+ out_neigh_release:
++ if (!exempt_from_gc)
++ atomic_dec(&tbl->gc_entries);
+ neigh_release(n);
+ goto out;
+ }
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Nikita Danilov <nikita.danilov@aquantia.com>
+Date: Tue, 4 Jun 2019 13:23:49 +0000
+Subject: net: aquantia: fix wol configuration not applied sometimes
+
+From: Nikita Danilov <nikita.danilov@aquantia.com>
+
+[ Upstream commit 930b9a0543385d4eb8ef887e88cf84d95a844577 ]
+
+WoL magic packet configuration sometimes does not work due to
+couple of leakages found.
+
+Mainly there was a regression introduced during readx_poll refactoring.
+
+Next, fw request waiting time was too small. Sometimes that
+caused sleep proxy config function to return with an error
+and to skip WoL configuration.
+At last, WoL data were passed to FW from not clean buffer.
+That could cause FW to accept garbage as a random configuration data.
+
+Fixes: 6a7f2277313b ("net: aquantia: replace AQ_HW_WAIT_FOR with readx_poll_timeout_atomic")
+Signed-off-by: Nikita Danilov <nikita.danilov@aquantia.com>
+Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c | 14 +++++-----
+ drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c | 4 ++
+ 2 files changed, 10 insertions(+), 8 deletions(-)
+
+--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
++++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+@@ -335,13 +335,13 @@ static int hw_atl_utils_fw_upload_dwords
+ {
+ u32 val;
+ int err = 0;
+- bool is_locked;
+
+- is_locked = hw_atl_sem_ram_get(self);
+- if (!is_locked) {
+- err = -ETIME;
++ err = readx_poll_timeout_atomic(hw_atl_sem_ram_get, self,
++ val, val == 1U,
++ 10U, 100000U);
++ if (err < 0)
+ goto err_exit;
+- }
++
+ if (IS_CHIP_FEATURE(REVISION_B1)) {
+ u32 offset = 0;
+
+@@ -353,8 +353,8 @@ static int hw_atl_utils_fw_upload_dwords
+ /* 1000 times by 10us = 10ms */
+ err = readx_poll_timeout_atomic(hw_atl_scrpad12_get,
+ self, val,
+- (val & 0xF0000000) ==
+- 0x80000000,
++ (val & 0xF0000000) !=
++ 0x80000000,
+ 10U, 10000U);
+ }
+ } else {
+--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
++++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
+@@ -349,7 +349,7 @@ static int aq_fw2x_set_sleep_proxy(struc
+ err = readx_poll_timeout_atomic(aq_fw2x_state2_get,
+ self, val,
+ val & HW_ATL_FW2X_CTRL_SLEEP_PROXY,
+- 1U, 10000U);
++ 1U, 100000U);
+
+ err_exit:
+ return err;
+@@ -369,6 +369,8 @@ static int aq_fw2x_set_wol_params(struct
+
+ msg = (struct fw2x_msg_wol *)rpc;
+
++ memset(msg, 0, sizeof(*msg));
++
+ msg->msg_id = HAL_ATLANTIC_UTILS_FW2X_MSG_WOL;
+ msg->magic_packet_enabled = true;
+ memcpy(msg->hw_addr, mac, ETH_ALEN);
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
+Date: Fri, 31 May 2019 16:47:25 +0300
+Subject: net: ethernet: ti: cpsw_ethtool: fix ethtool ring param set
+
+From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
+
+[ Upstream commit 09faf5a7d7c0bcb07faba072f611937af9dd5788 ]
+
+Fix ability to set RX descriptor number, the reason - initially
+"tx_max_pending" was set incorrectly, but the issue appears after
+adding sanity check, so fix is for "sanity" patch.
+
+Fixes: 37e2d99b59c476 ("ethtool: Ensure new ring parameters are within bounds during SRINGPARAM")
+Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
+Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/ti/cpsw.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/ethernet/ti/cpsw.c
++++ b/drivers/net/ethernet/ti/cpsw.c
+@@ -3130,6 +3130,7 @@ static void cpsw_get_ringparam(struct ne
+ struct cpsw_common *cpsw = priv->cpsw;
+
+ /* not supported */
++ ering->tx_max_pending = descs_pool_size - CPSW_MAX_QUEUES;
+ ering->tx_max_pending = 0;
+ ering->tx_pending = cpdma_get_num_tx_descs(cpsw->dma);
+ ering->rx_max_pending = descs_pool_size - CPSW_MAX_QUEUES;
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Erez Alfasi <ereza@mellanox.com>
+Date: Mon, 20 May 2019 17:42:52 +0300
+Subject: net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages query
+
+From: Erez Alfasi <ereza@mellanox.com>
+
+[ Upstream commit 135dd9594f127c8a82d141c3c8430e9e2143216a ]
+
+Querying EEPROM high pages data for SFP module is currently
+not supported by our driver but is still tried, resulting in
+invalid FW queries.
+
+Set the EEPROM ethtool data length to 256 for SFP module to
+limit the reading for page 0 only and prevent invalid FW queries.
+
+Fixes: 7202da8b7f71 ("ethtool, net/mlx4_en: Cable info, get_module_info/eeprom ethtool support")
+Signed-off-by: Erez Alfasi <ereza@mellanox.com>
+Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 4 +++-
+ drivers/net/ethernet/mellanox/mlx4/port.c | 5 -----
+ 2 files changed, 3 insertions(+), 6 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
++++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+@@ -2010,6 +2010,8 @@ static int mlx4_en_set_tunable(struct ne
+ return ret;
+ }
+
++#define MLX4_EEPROM_PAGE_LEN 256
++
+ static int mlx4_en_get_module_info(struct net_device *dev,
+ struct ethtool_modinfo *modinfo)
+ {
+@@ -2044,7 +2046,7 @@ static int mlx4_en_get_module_info(struc
+ break;
+ case MLX4_MODULE_ID_SFP:
+ modinfo->type = ETH_MODULE_SFF_8472;
+- modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
++ modinfo->eeprom_len = MLX4_EEPROM_PAGE_LEN;
+ break;
+ default:
+ return -EINVAL;
+--- a/drivers/net/ethernet/mellanox/mlx4/port.c
++++ b/drivers/net/ethernet/mellanox/mlx4/port.c
+@@ -2077,11 +2077,6 @@ int mlx4_get_module_info(struct mlx4_dev
+ size -= offset + size - I2C_PAGE_SIZE;
+
+ i2c_addr = I2C_ADDR_LOW;
+- if (offset >= I2C_PAGE_SIZE) {
+- /* Reset offset to high page */
+- i2c_addr = I2C_ADDR_HIGH;
+- offset -= I2C_PAGE_SIZE;
+- }
+
+ cable_info = (struct mlx4_cable_info *)inmad->data;
+ cable_info->dev_mem_address = cpu_to_be16(offset);
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Maxime Chevallier <maxime.chevallier@bootlin.com>
+Date: Thu, 6 Jun 2019 10:42:56 +0200
+Subject: net: mvpp2: Use strscpy to handle stat strings
+
+From: Maxime Chevallier <maxime.chevallier@bootlin.com>
+
+[ Upstream commit d37acd5aa99c57505b64913e0e2624ec3daed8c5 ]
+
+Use a safe strscpy call to copy the ethtool stat strings into the
+relevant buffers, instead of a memcpy that will be accessing
+out-of-bound data.
+
+Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics")
+Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
++++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+@@ -1304,8 +1304,8 @@ static void mvpp2_ethtool_get_strings(st
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
+- memcpy(data + i * ETH_GSTRING_LEN,
+- &mvpp2_ethtool_regs[i].string, ETH_GSTRING_LEN);
++ strscpy(data + i * ETH_GSTRING_LEN,
++ mvpp2_ethtool_regs[i].string, ETH_GSTRING_LEN);
+ }
+ }
+
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Zhu Yanjun <yanjun.zhu@oracle.com>
+Date: Thu, 6 Jun 2019 04:00:03 -0400
+Subject: net: rds: fix memory leak in rds_ib_flush_mr_pool
+
+From: Zhu Yanjun <yanjun.zhu@oracle.com>
+
+[ Upstream commit 85cb928787eab6a2f4ca9d2a798b6f3bed53ced1 ]
+
+When the following tests last for several hours, the problem will occur.
+
+Server:
+ rds-stress -r 1.1.1.16 -D 1M
+Client:
+ rds-stress -r 1.1.1.14 -s 1.1.1.16 -D 1M -T 30
+
+The following will occur.
+
+"
+Starting up....
+tsks tx/s rx/s tx+rx K/s mbi K/s mbo K/s tx us/c rtt us cpu
+%
+ 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
+ 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
+ 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
+ 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
+"
+>From vmcore, we can find that clean_list is NULL.
+
+>From the source code, rds_mr_flushd calls rds_ib_mr_pool_flush_worker.
+Then rds_ib_mr_pool_flush_worker calls
+"
+ rds_ib_flush_mr_pool(pool, 0, NULL);
+"
+Then in function
+"
+int rds_ib_flush_mr_pool(struct rds_ib_mr_pool *pool,
+ int free_all, struct rds_ib_mr **ibmr_ret)
+"
+ibmr_ret is NULL.
+
+In the source code,
+"
+...
+list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail);
+if (ibmr_ret)
+ *ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode);
+
+/* more than one entry in llist nodes */
+if (clean_nodes->next)
+ llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list);
+...
+"
+When ibmr_ret is NULL, llist_entry is not executed. clean_nodes->next
+instead of clean_nodes is added in clean_list.
+So clean_nodes is discarded. It can not be used again.
+The workqueue is executed periodically. So more and more clean_nodes are
+discarded. Finally the clean_list is NULL.
+Then this problem will occur.
+
+Fixes: 1bc144b62524 ("net, rds, Replace xlist in net/rds/xlist.h with llist")
+Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
+Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/rds/ib_rdma.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/net/rds/ib_rdma.c
++++ b/net/rds/ib_rdma.c
+@@ -428,12 +428,14 @@ int rds_ib_flush_mr_pool(struct rds_ib_m
+ wait_clean_list_grace();
+
+ list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail);
+- if (ibmr_ret)
++ if (ibmr_ret) {
+ *ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode);
+-
++ clean_nodes = clean_nodes->next;
++ }
+ /* more than one entry in llist nodes */
+- if (clean_nodes->next)
+- llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list);
++ if (clean_nodes)
++ llist_add_batch(clean_nodes, clean_tail,
++ &pool->clean_list);
+
+ }
+
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Russell King <rmk+kernel@armlinux.org.uk>
+Date: Sun, 2 Jun 2019 15:13:00 +0100
+Subject: net: sfp: read eeprom in maximum 16 byte increments
+
+From: Russell King <rmk+kernel@armlinux.org.uk>
+
+[ Upstream commit 28e74a7cfd6403f0d1c0f8b10b45d6fae37b227e ]
+
+Some SFP modules do not like reads longer than 16 bytes, so read the
+EEPROM in chunks of 16 bytes at a time. This behaviour is not specified
+in the SFP MSAs, which specifies:
+
+ "The serial interface uses the 2-wire serial CMOS E2PROM protocol
+ defined for the ATMEL AT24C01A/02/04 family of components."
+
+and
+
+ "As long as the SFP+ receives an acknowledge, it shall serially clock
+ out sequential data words. The sequence is terminated when the host
+ responds with a NACK and a STOP instead of an acknowledge."
+
+We must avoid breaking a read across a 16-bit quantity in the diagnostic
+page, thankfully all 16-bit quantities in that page are naturally
+aligned.
+
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+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/phy/sfp.c | 24 ++++++++++++++++++++----
+ 1 file changed, 20 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/phy/sfp.c
++++ b/drivers/net/phy/sfp.c
+@@ -281,6 +281,7 @@ static int sfp_i2c_read(struct sfp *sfp,
+ {
+ struct i2c_msg msgs[2];
+ u8 bus_addr = a2 ? 0x51 : 0x50;
++ size_t this_len;
+ int ret;
+
+ msgs[0].addr = bus_addr;
+@@ -292,11 +293,26 @@ static int sfp_i2c_read(struct sfp *sfp,
+ msgs[1].len = len;
+ msgs[1].buf = buf;
+
+- ret = i2c_transfer(sfp->i2c, msgs, ARRAY_SIZE(msgs));
+- if (ret < 0)
+- return ret;
++ while (len) {
++ this_len = len;
++ if (this_len > 16)
++ this_len = 16;
+
+- return ret == ARRAY_SIZE(msgs) ? len : 0;
++ msgs[1].len = this_len;
++
++ ret = i2c_transfer(sfp->i2c, msgs, ARRAY_SIZE(msgs));
++ if (ret < 0)
++ return ret;
++
++ if (ret != ARRAY_SIZE(msgs))
++ break;
++
++ msgs[1].buf += this_len;
++ dev_addr += this_len;
++ len -= this_len;
++ }
++
++ return msgs[1].buf - (u8 *)buf;
+ }
+
+ static int sfp_i2c_write(struct sfp *sfp, bool a2, u8 dev_addr, void *buf,
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Jakub Kicinski <jakub.kicinski@netronome.com>
+Date: Tue, 4 Jun 2019 12:00:12 -0700
+Subject: net/tls: replace the sleeping lock around RX resync with a bit lock
+
+From: Jakub Kicinski <jakub.kicinski@netronome.com>
+
+[ Upstream commit e52972c11d6b1262964db96d65934196db621685 ]
+
+Commit 38030d7cb779 ("net/tls: avoid NULL-deref on resync during device removal")
+tried to fix a potential NULL-dereference by taking the
+context rwsem. Unfortunately the RX resync may get called
+from soft IRQ, so we can't use the rwsem to protect from
+the device disappearing. Because we are guaranteed there
+can be only one resync at a time (it's called from strparser)
+use a bit to indicate resync is busy and make device
+removal wait for the bit to get cleared.
+
+Note that there is a leftover "flags" field in struct
+tls_context already.
+
+Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
+Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/tls.h | 4 ++++
+ net/tls/tls_device.c | 27 +++++++++++++++++++++------
+ 2 files changed, 25 insertions(+), 6 deletions(-)
+
+--- a/include/net/tls.h
++++ b/include/net/tls.h
+@@ -199,6 +199,10 @@ struct tls_offload_context_tx {
+ (ALIGN(sizeof(struct tls_offload_context_tx), sizeof(void *)) + \
+ TLS_DRIVER_STATE_SIZE)
+
++enum tls_context_flags {
++ TLS_RX_SYNC_RUNNING = 0,
++};
++
+ struct cipher_context {
+ char *iv;
+ char *rec_seq;
+--- a/net/tls/tls_device.c
++++ b/net/tls/tls_device.c
+@@ -570,10 +570,22 @@ void tls_device_write_space(struct sock
+ }
+ }
+
++static void tls_device_resync_rx(struct tls_context *tls_ctx,
++ struct sock *sk, u32 seq, u64 rcd_sn)
++{
++ struct net_device *netdev;
++
++ if (WARN_ON(test_and_set_bit(TLS_RX_SYNC_RUNNING, &tls_ctx->flags)))
++ return;
++ netdev = READ_ONCE(tls_ctx->netdev);
++ if (netdev)
++ netdev->tlsdev_ops->tls_dev_resync_rx(netdev, sk, seq, rcd_sn);
++ clear_bit_unlock(TLS_RX_SYNC_RUNNING, &tls_ctx->flags);
++}
++
+ void handle_device_resync(struct sock *sk, u32 seq, u64 rcd_sn)
+ {
+ struct tls_context *tls_ctx = tls_get_ctx(sk);
+- struct net_device *netdev = tls_ctx->netdev;
+ struct tls_offload_context_rx *rx_ctx;
+ u32 is_req_pending;
+ s64 resync_req;
+@@ -588,10 +600,10 @@ void handle_device_resync(struct sock *s
+ is_req_pending = resync_req;
+
+ if (unlikely(is_req_pending) && req_seq == seq &&
+- atomic64_try_cmpxchg(&rx_ctx->resync_req, &resync_req, 0))
+- netdev->tlsdev_ops->tls_dev_resync_rx(netdev, sk,
+- seq + TLS_HEADER_SIZE - 1,
+- rcd_sn);
++ atomic64_try_cmpxchg(&rx_ctx->resync_req, &resync_req, 0)) {
++ seq += TLS_HEADER_SIZE - 1;
++ tls_device_resync_rx(tls_ctx, sk, seq, rcd_sn);
++ }
+ }
+
+ static int tls_device_reencrypt(struct sock *sk, struct sk_buff *skb)
+@@ -981,7 +993,10 @@ static int tls_device_down(struct net_de
+ if (ctx->rx_conf == TLS_HW)
+ netdev->tlsdev_ops->tls_dev_del(netdev, ctx,
+ TLS_OFFLOAD_CTX_DIR_RX);
+- ctx->netdev = NULL;
++ WRITE_ONCE(ctx->netdev, NULL);
++ smp_mb__before_atomic(); /* pairs with test_and_set_bit() */
++ while (test_bit(TLS_RX_SYNC_RUNNING, &ctx->flags))
++ usleep_range(10, 200);
+ dev_put(netdev);
+ list_del_init(&ctx->list);
+
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Willem de Bruijn <willemb@google.com>
+Date: Fri, 31 May 2019 12:37:23 -0400
+Subject: packet: unconditionally free po->rollover
+
+From: Willem de Bruijn <willemb@google.com>
+
+[ Upstream commit afa0925c6fcc6a8f610e996ca09bc3215048033c ]
+
+Rollover used to use a complex RCU mechanism for assignment, which had
+a race condition. The below patch fixed the bug and greatly simplified
+the logic.
+
+The feature depends on fanout, but the state is private to the socket.
+Fanout_release returns f only when the last member leaves and the
+fanout struct is to be freed.
+
+Destroy rollover unconditionally, regardless of fanout state.
+
+Fixes: 57f015f5eccf2 ("packet: fix crash in fanout_demux_rollover()")
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Diagnosed-by: Dmitry Vyukov <dvyukov@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/packet/af_packet.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/packet/af_packet.c
++++ b/net/packet/af_packet.c
+@@ -3016,8 +3016,8 @@ static int packet_release(struct socket
+
+ synchronize_net();
+
++ kfree(po->rollover);
+ if (f) {
+- kfree(po->rollover);
+ fanout_release_data(f);
+ kfree(f);
+ }
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Thu, 6 Jun 2019 15:45:03 +0200
+Subject: pktgen: do not sleep with the thread lock held.
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+[ Upstream commit 720f1de4021f09898b8c8443f3b3e995991b6e3a ]
+
+Currently, the process issuing a "start" command on the pktgen procfs
+interface, acquires the pktgen thread lock and never release it, until
+all pktgen threads are completed. The above can blocks indefinitely any
+other pktgen command and any (even unrelated) netdevice removal - as
+the pktgen netdev notifier acquires the same lock.
+
+The issue is demonstrated by the following script, reported by Matteo:
+
+ip -b - <<'EOF'
+ link add type dummy
+ link add type veth
+ link set dummy0 up
+EOF
+modprobe pktgen
+echo reset >/proc/net/pktgen/pgctrl
+{
+ echo rem_device_all
+ echo add_device dummy0
+} >/proc/net/pktgen/kpktgend_0
+echo count 0 >/proc/net/pktgen/dummy0
+echo start >/proc/net/pktgen/pgctrl &
+sleep 1
+rmmod veth
+
+Fix the above releasing the thread lock around the sleep call.
+
+Additionally we must prevent racing with forcefull rmmod - as the
+thread lock no more protects from them. Instead, acquire a self-reference
+before waiting for any thread. As a side effect, running
+
+rmmod pktgen
+
+while some thread is running now fails with "module in use" error,
+before this patch such command hanged indefinitely.
+
+Note: the issue predates the commit reported in the fixes tag, but
+this fix can't be applied before the mentioned commit.
+
+v1 -> v2:
+ - no need to check for thread existence after flipping the lock,
+ pktgen threads are freed only at net exit time
+ -
+
+Fixes: 6146e6a43b35 ("[PKTGEN]: Removes thread_{un,}lock() macros.")
+Reported-and-tested-by: Matteo Croce <mcroce@redhat.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/pktgen.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/net/core/pktgen.c
++++ b/net/core/pktgen.c
+@@ -3066,7 +3066,13 @@ static int pktgen_wait_thread_run(struct
+ {
+ while (thread_is_running(t)) {
+
++ /* note: 't' will still be around even after the unlock/lock
++ * cycle because pktgen_thread threads are only cleared at
++ * net exit
++ */
++ mutex_unlock(&pktgen_thread_lock);
+ msleep_interruptible(100);
++ mutex_lock(&pktgen_thread_lock);
+
+ if (signal_pending(current))
+ goto signal;
+@@ -3081,6 +3087,10 @@ static int pktgen_wait_all_threads_run(s
+ struct pktgen_thread *t;
+ int sig = 1;
+
++ /* prevent from racing with rmmod */
++ if (!try_module_get(THIS_MODULE))
++ return sig;
++
+ mutex_lock(&pktgen_thread_lock);
+
+ list_for_each_entry(t, &pn->pktgen_threads, th_list) {
+@@ -3094,6 +3104,7 @@ static int pktgen_wait_all_threads_run(s
+ t->control |= (T_STOP);
+
+ mutex_unlock(&pktgen_thread_lock);
++ module_put(THIS_MODULE);
+ return sig;
+ }
+
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Hangbin Liu <liuhangbin@gmail.com>
+Date: Wed, 5 Jun 2019 12:27:14 +0800
+Subject: Revert "fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied"
+
+From: Hangbin Liu <liuhangbin@gmail.com>
+
+[ Upstream commit 4970b42d5c362bf873982db7d93245c5281e58f4 ]
+
+This reverts commit e9919a24d3022f72bcadc407e73a6ef17093a849.
+
+Nathan reported the new behaviour breaks Android, as Android just add
+new rules and delete old ones.
+
+If we return 0 without adding dup rules, Android will remove the new
+added rules and causing system to soft-reboot.
+
+Fixes: e9919a24d302 ("fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied")
+Reported-by: Nathan Chancellor <natechancellor@gmail.com>
+Reported-by: Yaro Slav <yaro330@gmail.com>
+Reported-by: Maciej Żenczykowski <zenczykowski@gmail.com>
+Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
+Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
+Tested-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/fib_rules.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/net/core/fib_rules.c
++++ b/net/core/fib_rules.c
+@@ -756,9 +756,9 @@ int fib_nl_newrule(struct sk_buff *skb,
+ if (err)
+ goto errout;
+
+- if (rule_exists(ops, frh, tb, rule)) {
+- if (nlh->nlmsg_flags & NLM_F_EXCL)
+- err = -EEXIST;
++ if ((nlh->nlmsg_flags & NLM_F_EXCL) &&
++ rule_exists(ops, frh, tb, rule)) {
++ err = -EEXIST;
+ goto errout_free;
+ }
+
--- /dev/null
+ethtool-fix-potential-userspace-buffer-overflow.patch
+fix-memory-leak-in-sctp_process_init.patch
+ipv4-not-do-cache-for-local-delivery-if-bc_forwarding-is-enabled.patch
+ipv6-fix-the-check-before-getting-the-cookie-in-rt6_get_cookie.patch
+net-ethernet-ti-cpsw_ethtool-fix-ethtool-ring-param-set.patch
+net-mvpp2-use-strscpy-to-handle-stat-strings.patch
+net-rds-fix-memory-leak-in-rds_ib_flush_mr_pool.patch
+net-sfp-read-eeprom-in-maximum-16-byte-increments.patch
+packet-unconditionally-free-po-rollover.patch
+pktgen-do-not-sleep-with-the-thread-lock-held.patch
+revert-fib_rules-return-0-directly-if-an-exactly-same-rule-exists-when-nlm_f_excl-not-supplied.patch
+udp-only-choose-unbound-udp-socket-for-multicast-when-not-in-a-vrf.patch
+ipv6-use-read_once-for-inet-hdrincl-as-in-ipv4.patch
+ipv6-fix-efault-on-sendto-with-icmpv6-and-hdrincl.patch
+net-aquantia-fix-wol-configuration-not-applied-sometimes.patch
+neighbor-reset-gc_entries-counter-if-new-entry-is-released-before-insert.patch
+neighbor-call-__ipv4_neigh_lookup_noref-in-neigh_xmit.patch
+cls_matchall-avoid-panic-when-receiving-a-packet-before-filter-set.patch
+ipmr_base-do-not-reset-index-in-mr_table_dump.patch
+net-mlx4_en-ethtool-remove-unsupported-sfp-eeprom-high-pages-query.patch
+net-tls-replace-the-sleeping-lock-around-rx-resync-with-a-bit-lock.patch
--- /dev/null
+From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST
+From: Tim Beale <timbeale@catalyst.net.nz>
+Date: Tue, 4 Jun 2019 13:56:23 +1200
+Subject: udp: only choose unbound UDP socket for multicast when not in a VRF
+
+From: Tim Beale <timbeale@catalyst.net.nz>
+
+[ Upstream commit 82ba25c6de200d7a9e9c970c998cdd6dfa8637ae ]
+
+By default, packets received in another VRF should not be passed to an
+unbound socket in the default VRF. This patch updates the IPv4 UDP
+multicast logic to match the unicast VRF logic (in compute_score()),
+as well as the IPv6 mcast logic (in __udp_v6_is_mcast_sock()).
+
+The particular case I noticed was DHCP discover packets going
+to the 255.255.255.255 address, which are handled by
+__udp4_lib_mcast_deliver(). The previous code meant that running
+multiple different DHCP server or relay agent instances across VRFs
+did not work correctly - any server/relay agent in the default VRF
+received DHCP discover packets for all other VRFs.
+
+Fixes: 6da5b0f027a8 ("net: ensure unbound datagram socket to be chosen when not in a VRF")
+Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
+Reviewed-by: David Ahern <dsahern@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/udp.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/net/ipv4/udp.c
++++ b/net/ipv4/udp.c
+@@ -538,8 +538,7 @@ static inline bool __udp_is_mcast_sock(s
+ (inet->inet_dport != rmt_port && inet->inet_dport) ||
+ (inet->inet_rcv_saddr && inet->inet_rcv_saddr != loc_addr) ||
+ ipv6_only_sock(sk) ||
+- (sk->sk_bound_dev_if && sk->sk_bound_dev_if != dif &&
+- sk->sk_bound_dev_if != sdif))
++ !udp_sk_bound_dev_eq(net, sk->sk_bound_dev_if, dif, sdif))
+ return false;
+ if (!ip_mc_sf_allow(sk, loc_addr, rmt_addr, dif, sdif))
+ return false;
projects / thirdparty / kernel / stable-queue.git / commitdiff
