From: Greg Kroah-Hartman Date: Sun, 9 Jun 2019 07:37:26 +0000 (+0200) Subject: 5.1-stable patches X-Git-Tag: v5.1.9~29 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8af540ce42452ec7e09e45026c8de8d826f497ee;p=thirdparty%2Fkernel%2Fstable-queue.git 5.1-stable patches added patches: cls_matchall-avoid-panic-when-receiving-a-packet-before-filter-set.patch ethtool-fix-potential-userspace-buffer-overflow.patch fix-memory-leak-in-sctp_process_init.patch ipmr_base-do-not-reset-index-in-mr_table_dump.patch ipv4-not-do-cache-for-local-delivery-if-bc_forwarding-is-enabled.patch ipv6-fix-efault-on-sendto-with-icmpv6-and-hdrincl.patch ipv6-fix-the-check-before-getting-the-cookie-in-rt6_get_cookie.patch ipv6-use-read_once-for-inet-hdrincl-as-in-ipv4.patch neighbor-call-__ipv4_neigh_lookup_noref-in-neigh_xmit.patch neighbor-reset-gc_entries-counter-if-new-entry-is-released-before-insert.patch net-aquantia-fix-wol-configuration-not-applied-sometimes.patch net-ethernet-ti-cpsw_ethtool-fix-ethtool-ring-param-set.patch net-mlx4_en-ethtool-remove-unsupported-sfp-eeprom-high-pages-query.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 net-tls-replace-the-sleeping-lock-around-rx-resync-with-a-bit-lock.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 --- diff --git a/queue-5.1/cls_matchall-avoid-panic-when-receiving-a-packet-before-filter-set.patch b/queue-5.1/cls_matchall-avoid-panic-when-receiving-a-packet-before-filter-set.patch new file mode 100644 index 00000000000..9003f22ddeb --- /dev/null +++ b/queue-5.1/cls_matchall-avoid-panic-when-receiving-a-packet-before-filter-set.patch @@ -0,0 +1,97 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Matteo Croce +Date: Thu, 2 May 2019 10:51:05 +0200 +Subject: cls_matchall: avoid panic when receiving a packet before filter set + +From: Matteo Croce + +[ 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 +Acked-by: Cong Wang +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-5.1/ethtool-fix-potential-userspace-buffer-overflow.patch b/queue-5.1/ethtool-fix-potential-userspace-buffer-overflow.patch new file mode 100644 index 00000000000..a436a08124d --- /dev/null +++ b/queue-5.1/ethtool-fix-potential-userspace-buffer-overflow.patch @@ -0,0 +1,54 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Vivien Didelot +Date: Mon, 3 Jun 2019 16:57:13 -0400 +Subject: ethtool: fix potential userspace buffer overflow + +From: Vivien Didelot + +[ 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 +Reviewed-by: Michal Kubecek +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-5.1/fix-memory-leak-in-sctp_process_init.patch b/queue-5.1/fix-memory-leak-in-sctp_process_init.patch new file mode 100644 index 00000000000..e7f176db51a --- /dev/null +++ b/queue-5.1/fix-memory-leak-in-sctp_process_init.patch @@ -0,0 +1,125 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Neil Horman +Date: Mon, 3 Jun 2019 16:32:59 -0400 +Subject: Fix memory leak in sctp_process_init + +From: Neil Horman + +[ 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 +Reported-by: syzbot+f7e9153b037eac9b1df8@syzkaller.appspotmail.com +CC: Marcelo Ricardo Leitner +CC: "David S. Miller" +CC: netdev@vger.kernel.org +Acked-by: Marcelo Ricardo Leitner +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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)) { diff --git a/queue-5.1/ipmr_base-do-not-reset-index-in-mr_table_dump.patch b/queue-5.1/ipmr_base-do-not-reset-index-in-mr_table_dump.patch new file mode 100644 index 00000000000..569af64444d --- /dev/null +++ b/queue-5.1/ipmr_base-do-not-reset-index-in-mr_table_dump.patch @@ -0,0 +1,45 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: David Ahern +Date: Thu, 2 May 2019 15:14:15 -0700 +Subject: ipmr_base: Do not reset index in mr_table_dump + +From: David Ahern + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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++; + } diff --git a/queue-5.1/ipv4-not-do-cache-for-local-delivery-if-bc_forwarding-is-enabled.patch b/queue-5.1/ipv4-not-do-cache-for-local-delivery-if-bc_forwarding-is-enabled.patch new file mode 100644 index 00000000000..3ed5be7e040 --- /dev/null +++ b/queue-5.1/ipv4-not-do-cache-for-local-delivery-if-bc_forwarding-is-enabled.patch @@ -0,0 +1,85 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Xin Long +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 + +[ 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 +Signed-off-by: Xin Long +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + } + diff --git a/queue-5.1/ipv6-fix-efault-on-sendto-with-icmpv6-and-hdrincl.patch b/queue-5.1/ipv6-fix-efault-on-sendto-with-icmpv6-and-hdrincl.patch new file mode 100644 index 00000000000..979837489b0 --- /dev/null +++ b/queue-5.1/ipv6-fix-efault-on-sendto-with-icmpv6-and-hdrincl.patch @@ -0,0 +1,57 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Olivier Matz +Date: Thu, 6 Jun 2019 09:15:19 +0200 +Subject: ipv6: fix EFAULT on sendto with icmpv6 and hdrincl + +From: Olivier Matz + +[ 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 +Acked-by: Nicolas Dichtel +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.1/ipv6-fix-the-check-before-getting-the-cookie-in-rt6_get_cookie.patch b/queue-5.1/ipv6-fix-the-check-before-getting-the-cookie-in-rt6_get_cookie.patch new file mode 100644 index 00000000000..4406807c7ee --- /dev/null +++ b/queue-5.1/ipv6-fix-the-check-before-getting-the-cookie-in-rt6_get_cookie.patch @@ -0,0 +1,46 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Xin Long +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 + +[ 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 +Signed-off-by: Xin Long +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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(); diff --git a/queue-5.1/ipv6-use-read_once-for-inet-hdrincl-as-in-ipv4.patch b/queue-5.1/ipv6-use-read_once-for-inet-hdrincl-as-in-ipv4.patch new file mode 100644 index 00000000000..789e918a3f8 --- /dev/null +++ b/queue-5.1/ipv6-use-read_once-for-inet-hdrincl-as-in-ipv4.patch @@ -0,0 +1,64 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Olivier Matz +Date: Thu, 6 Jun 2019 09:15:18 +0200 +Subject: ipv6: use READ_ONCE() for inet->hdrincl as in ipv4 + +From: Olivier Matz + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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 { diff --git a/queue-5.1/neighbor-call-__ipv4_neigh_lookup_noref-in-neigh_xmit.patch b/queue-5.1/neighbor-call-__ipv4_neigh_lookup_noref-in-neigh_xmit.patch new file mode 100644 index 00000000000..51fbc0e2787 --- /dev/null +++ b/queue-5.1/neighbor-call-__ipv4_neigh_lookup_noref-in-neigh_xmit.patch @@ -0,0 +1,57 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: David Ahern +Date: Wed, 1 May 2019 18:18:42 -0700 +Subject: neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit + +From: David Ahern + +[ 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 +Signed-off-by: David Ahern +Tested-by: Alan Maguire +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + #include + #include + #include +@@ -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); diff --git a/queue-5.1/neighbor-reset-gc_entries-counter-if-new-entry-is-released-before-insert.patch b/queue-5.1/neighbor-reset-gc_entries-counter-if-new-entry-is-released-before-insert.patch new file mode 100644 index 00000000000..a282f79a62a --- /dev/null +++ b/queue-5.1/neighbor-reset-gc_entries-counter-if-new-entry-is-released-before-insert.patch @@ -0,0 +1,42 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: David Ahern +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 + +[ 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 +Reported-by: Alan Maguire +Signed-off-by: David Ahern +Tested-by: Alan Maguire +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.1/net-aquantia-fix-wol-configuration-not-applied-sometimes.patch b/queue-5.1/net-aquantia-fix-wol-configuration-not-applied-sometimes.patch new file mode 100644 index 00000000000..e75767fcdc2 --- /dev/null +++ b/queue-5.1/net-aquantia-fix-wol-configuration-not-applied-sometimes.patch @@ -0,0 +1,82 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Nikita Danilov +Date: Tue, 4 Jun 2019 13:23:49 +0000 +Subject: net: aquantia: fix wol configuration not applied sometimes + +From: Nikita Danilov + +[ 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 +Signed-off-by: Igor Russkikh +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.1/net-ethernet-ti-cpsw_ethtool-fix-ethtool-ring-param-set.patch b/queue-5.1/net-ethernet-ti-cpsw_ethtool-fix-ethtool-ring-param-set.patch new file mode 100644 index 00000000000..3d41b173270 --- /dev/null +++ b/queue-5.1/net-ethernet-ti-cpsw_ethtool-fix-ethtool-ring-param-set.patch @@ -0,0 +1,32 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Ivan Khoronzhuk +Date: Fri, 31 May 2019 16:47:25 +0300 +Subject: net: ethernet: ti: cpsw_ethtool: fix ethtool ring param set + +From: Ivan Khoronzhuk + +[ 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 +Reviewed-by: Grygorii Strashko +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.1/net-mlx4_en-ethtool-remove-unsupported-sfp-eeprom-high-pages-query.patch b/queue-5.1/net-mlx4_en-ethtool-remove-unsupported-sfp-eeprom-high-pages-query.patch new file mode 100644 index 00000000000..8ab0f512368 --- /dev/null +++ b/queue-5.1/net-mlx4_en-ethtool-remove-unsupported-sfp-eeprom-high-pages-query.patch @@ -0,0 +1,60 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Erez Alfasi +Date: Mon, 20 May 2019 17:42:52 +0300 +Subject: net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages query + +From: Erez Alfasi + +[ 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 +Signed-off-by: Tariq Toukan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.1/net-mvpp2-use-strscpy-to-handle-stat-strings.patch b/queue-5.1/net-mvpp2-use-strscpy-to-handle-stat-strings.patch new file mode 100644 index 00000000000..f416efdbaf2 --- /dev/null +++ b/queue-5.1/net-mvpp2-use-strscpy-to-handle-stat-strings.patch @@ -0,0 +1,34 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Maxime Chevallier +Date: Thu, 6 Jun 2019 10:42:56 +0200 +Subject: net: mvpp2: Use strscpy to handle stat strings + +From: Maxime Chevallier + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + } + diff --git a/queue-5.1/net-rds-fix-memory-leak-in-rds_ib_flush_mr_pool.patch b/queue-5.1/net-rds-fix-memory-leak-in-rds_ib_flush_mr_pool.patch new file mode 100644 index 00000000000..a3e67474e5b --- /dev/null +++ b/queue-5.1/net-rds-fix-memory-leak-in-rds_ib_flush_mr_pool.patch @@ -0,0 +1,90 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Zhu Yanjun +Date: Thu, 6 Jun 2019 04:00:03 -0400 +Subject: net: rds: fix memory leak in rds_ib_flush_mr_pool + +From: Zhu Yanjun + +[ 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 +Acked-by: Santosh Shilimkar +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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); + + } + diff --git a/queue-5.1/net-sfp-read-eeprom-in-maximum-16-byte-increments.patch b/queue-5.1/net-sfp-read-eeprom-in-maximum-16-byte-increments.patch new file mode 100644 index 00000000000..915707b6609 --- /dev/null +++ b/queue-5.1/net-sfp-read-eeprom-in-maximum-16-byte-increments.patch @@ -0,0 +1,75 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Russell King +Date: Sun, 2 Jun 2019 15:13:00 +0100 +Subject: net: sfp: read eeprom in maximum 16 byte increments + +From: Russell King + +[ 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 +Reviewed-by: Andrew Lunn +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.1/net-tls-replace-the-sleeping-lock-around-rx-resync-with-a-bit-lock.patch b/queue-5.1/net-tls-replace-the-sleeping-lock-around-rx-resync-with-a-bit-lock.patch new file mode 100644 index 00000000000..3c6fbad6230 --- /dev/null +++ b/queue-5.1/net-tls-replace-the-sleeping-lock-around-rx-resync-with-a-bit-lock.patch @@ -0,0 +1,96 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Jakub Kicinski +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 + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-5.1/packet-unconditionally-free-po-rollover.patch b/queue-5.1/packet-unconditionally-free-po-rollover.patch new file mode 100644 index 00000000000..c8bfec7bd3a --- /dev/null +++ b/queue-5.1/packet-unconditionally-free-po-rollover.patch @@ -0,0 +1,41 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Willem de Bruijn +Date: Fri, 31 May 2019 12:37:23 -0400 +Subject: packet: unconditionally free po->rollover + +From: Willem de Bruijn + +[ 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 +Diagnosed-by: Dmitry Vyukov +Signed-off-by: Willem de Bruijn +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-5.1/pktgen-do-not-sleep-with-the-thread-lock-held.patch b/queue-5.1/pktgen-do-not-sleep-with-the-thread-lock-held.patch new file mode 100644 index 00000000000..695eb405be1 --- /dev/null +++ b/queue-5.1/pktgen-do-not-sleep-with-the-thread-lock-held.patch @@ -0,0 +1,96 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Paolo Abeni +Date: Thu, 6 Jun 2019 15:45:03 +0200 +Subject: pktgen: do not sleep with the thread lock held. + +From: Paolo Abeni + +[ 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 +Signed-off-by: Paolo Abeni +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-5.1/revert-fib_rules-return-0-directly-if-an-exactly-same-rule-exists-when-nlm_f_excl-not-supplied.patch b/queue-5.1/revert-fib_rules-return-0-directly-if-an-exactly-same-rule-exists-when-nlm_f_excl-not-supplied.patch new file mode 100644 index 00000000000..5fff8785902 --- /dev/null +++ b/queue-5.1/revert-fib_rules-return-0-directly-if-an-exactly-same-rule-exists-when-nlm_f_excl-not-supplied.patch @@ -0,0 +1,45 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Hangbin Liu +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 + +[ 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 +Reported-by: Yaro Slav +Reported-by: Maciej Å»enczykowski +Signed-off-by: Hangbin Liu +Reviewed-by: Nathan Chancellor +Tested-by: Nathan Chancellor +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-5.1/series b/queue-5.1/series new file mode 100644 index 00000000000..ad5401a9299 --- /dev/null +++ b/queue-5.1/series @@ -0,0 +1,21 @@ +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 diff --git a/queue-5.1/udp-only-choose-unbound-udp-socket-for-multicast-when-not-in-a-vrf.patch b/queue-5.1/udp-only-choose-unbound-udp-socket-for-multicast-when-not-in-a-vrf.patch new file mode 100644 index 00000000000..312ca9215a4 --- /dev/null +++ b/queue-5.1/udp-only-choose-unbound-udp-socket-for-multicast-when-not-in-a-vrf.patch @@ -0,0 +1,42 @@ +From foo@baz Sun 09 Jun 2019 09:24:16 AM CEST +From: Tim Beale +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 + +[ 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 +Reviewed-by: David Ahern +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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;