From: Greg Kroah-Hartman Date: Thu, 11 Jun 2020 09:55:31 +0000 (+0200) Subject: 5.6-stable patches X-Git-Tag: v5.4.47~148 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=76c9abe8d408887cbcf780e900b3671214a9e0ad;p=thirdparty%2Fkernel%2Fstable-queue.git 5.6-stable patches added patches: bridge-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch genetlink-fix-memory-leaks-in-genl_family_rcv_msg_dumpit.patch ipv6-fix-ipv6_addrform-operation-logic.patch mlxsw-core-use-different-get_trend-callbacks-for-different-thermal-zones.patch net-dsa-qca8k-fix-unexpected-gfp-kernel-exception.patch net-ena-xdp-update-napi-budget-for-drop-and-aborted.patch net-ena-xdp-xdp_tx-fix-memory-leak.patch net_failover-fixed-rollback-in-net_failover_open.patch tipc-fix-null-pointer-dereference-in-streaming.patch tun-correct-header-offsets-in-napi-frags-mode.patch vxlan-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch --- diff --git a/queue-5.6/bridge-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch b/queue-5.6/bridge-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch new file mode 100644 index 00000000000..e6b0a1b5af7 --- /dev/null +++ b/queue-5.6/bridge-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch @@ -0,0 +1,50 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Ido Schimmel +Date: Mon, 1 Jun 2020 15:58:54 +0300 +Subject: bridge: Avoid infinite loop when suppressing NS messages with invalid options + +From: Ido Schimmel + +[ Upstream commit 53fc685243bd6fb90d90305cea54598b78d3cbfc ] + +When neighbor suppression is enabled the bridge device might reply to +Neighbor Solicitation (NS) messages on behalf of remote hosts. + +In case the NS message includes the "Source link-layer address" option +[1], the bridge device will use the specified address as the link-layer +destination address in its reply. + +To avoid an infinite loop, break out of the options parsing loop when +encountering an option with length zero and disregard the NS message. + +This is consistent with the IPv6 ndisc code and RFC 4886 which states +that "Nodes MUST silently discard an ND packet that contains an option +with length zero" [2]. + +[1] https://tools.ietf.org/html/rfc4861#section-4.3 +[2] https://tools.ietf.org/html/rfc4861#section-4.6 + +Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports") +Signed-off-by: Ido Schimmel +Reported-by: Alla Segal +Tested-by: Alla Segal +Acked-by: Nikolay Aleksandrov +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/bridge/br_arp_nd_proxy.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/net/bridge/br_arp_nd_proxy.c ++++ b/net/bridge/br_arp_nd_proxy.c +@@ -276,6 +276,10 @@ static void br_nd_send(struct net_bridge + ns_olen = request->len - (skb_network_offset(request) + + sizeof(struct ipv6hdr)) - sizeof(*ns); + for (i = 0; i < ns_olen - 1; i += (ns->opt[i + 1] << 3)) { ++ if (!ns->opt[i + 1]) { ++ kfree_skb(reply); ++ return; ++ } + if (ns->opt[i] == ND_OPT_SOURCE_LL_ADDR) { + daddr = ns->opt + i + sizeof(struct nd_opt_hdr); + break; diff --git a/queue-5.6/genetlink-fix-memory-leaks-in-genl_family_rcv_msg_dumpit.patch b/queue-5.6/genetlink-fix-memory-leaks-in-genl_family_rcv_msg_dumpit.patch new file mode 100644 index 00000000000..a2817957739 --- /dev/null +++ b/queue-5.6/genetlink-fix-memory-leaks-in-genl_family_rcv_msg_dumpit.patch @@ -0,0 +1,190 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Cong Wang +Date: Tue, 2 Jun 2020 21:49:10 -0700 +Subject: genetlink: fix memory leaks in genl_family_rcv_msg_dumpit() + +From: Cong Wang + +[ Upstream commit c36f05559104b66bcd7f617e931e38c680227b74 ] + +There are two kinds of memory leaks in genl_family_rcv_msg_dumpit(): + +1. Before we call ops->start(), whenever an error happens, we forget + to free the memory allocated in genl_family_rcv_msg_dumpit(). + +2. When ops->start() fails, the 'info' has been already installed on + the per socket control block, so we should not free it here. More + importantly, nlk->cb_running is still false at this point, so + netlink_sock_destruct() cannot free it either. + +The first kind of memory leaks is easier to resolve, but the second +one requires some deeper thoughts. + +After reviewing how netfilter handles this, the most elegant solution +I find is just to use a similar way to allocate the memory, that is, +moving memory allocations from caller into ops->start(). With this, +we can solve both kinds of memory leaks: for 1), no memory allocation +happens before ops->start(); for 2), ops->start() handles its own +failures and 'info' is installed to the socket control block only +when success. The only ugliness here is we have to pass all local +variables on stack via a struct, but this is not hard to understand. + +Alternatively, we can introduce a ops->free() to solve this too, +but it is overkill as only genetlink has this problem so far. + +Fixes: 1927f41a22a0 ("net: genetlink: introduce dump info struct to be available during dumpit op") +Reported-by: syzbot+21f04f481f449c8db840@syzkaller.appspotmail.com +Cc: "Jason A. Donenfeld" +Cc: Florian Westphal +Cc: Pablo Neira Ayuso +Cc: Jiri Pirko +Cc: YueHaibing +Cc: Shaochun Chen +Signed-off-by: Cong Wang +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/netlink/genetlink.c | 94 +++++++++++++++++++++++++++++------------------- + 1 file changed, 58 insertions(+), 36 deletions(-) + +--- a/net/netlink/genetlink.c ++++ b/net/netlink/genetlink.c +@@ -513,15 +513,58 @@ static void genl_family_rcv_msg_attrs_fr + kfree(attrbuf); + } + +-static int genl_lock_start(struct netlink_callback *cb) ++struct genl_start_context { ++ const struct genl_family *family; ++ struct nlmsghdr *nlh; ++ struct netlink_ext_ack *extack; ++ const struct genl_ops *ops; ++ int hdrlen; ++}; ++ ++static int genl_start(struct netlink_callback *cb) + { +- const struct genl_ops *ops = genl_dumpit_info(cb)->ops; ++ struct genl_start_context *ctx = cb->data; ++ const struct genl_ops *ops = ctx->ops; ++ struct genl_dumpit_info *info; ++ struct nlattr **attrs = NULL; + int rc = 0; + ++ if (ops->validate & GENL_DONT_VALIDATE_DUMP) ++ goto no_attrs; ++ ++ if (ctx->nlh->nlmsg_len < nlmsg_msg_size(ctx->hdrlen)) ++ return -EINVAL; ++ ++ attrs = genl_family_rcv_msg_attrs_parse(ctx->family, ctx->nlh, ctx->extack, ++ ops, ctx->hdrlen, ++ GENL_DONT_VALIDATE_DUMP_STRICT, ++ true); ++ if (IS_ERR(attrs)) ++ return PTR_ERR(attrs); ++ ++no_attrs: ++ info = genl_dumpit_info_alloc(); ++ if (!info) { ++ kfree(attrs); ++ return -ENOMEM; ++ } ++ info->family = ctx->family; ++ info->ops = ops; ++ info->attrs = attrs; ++ ++ cb->data = info; + if (ops->start) { +- genl_lock(); ++ if (!ctx->family->parallel_ops) ++ genl_lock(); + rc = ops->start(cb); +- genl_unlock(); ++ if (!ctx->family->parallel_ops) ++ genl_unlock(); ++ } ++ ++ if (rc) { ++ kfree(attrs); ++ genl_dumpit_info_free(info); ++ cb->data = NULL; + } + return rc; + } +@@ -548,7 +591,7 @@ static int genl_lock_done(struct netlink + rc = ops->done(cb); + genl_unlock(); + } +- genl_family_rcv_msg_attrs_free(info->family, info->attrs, true); ++ genl_family_rcv_msg_attrs_free(info->family, info->attrs, false); + genl_dumpit_info_free(info); + return rc; + } +@@ -573,43 +616,23 @@ static int genl_family_rcv_msg_dumpit(co + const struct genl_ops *ops, + int hdrlen, struct net *net) + { +- struct genl_dumpit_info *info; +- struct nlattr **attrs = NULL; ++ struct genl_start_context ctx; + int err; + + if (!ops->dumpit) + return -EOPNOTSUPP; + +- if (ops->validate & GENL_DONT_VALIDATE_DUMP) +- goto no_attrs; +- +- if (nlh->nlmsg_len < nlmsg_msg_size(hdrlen)) +- return -EINVAL; +- +- attrs = genl_family_rcv_msg_attrs_parse(family, nlh, extack, +- ops, hdrlen, +- GENL_DONT_VALIDATE_DUMP_STRICT, +- true); +- if (IS_ERR(attrs)) +- return PTR_ERR(attrs); +- +-no_attrs: +- /* Allocate dumpit info. It is going to be freed by done() callback. */ +- info = genl_dumpit_info_alloc(); +- if (!info) { +- genl_family_rcv_msg_attrs_free(family, attrs, true); +- return -ENOMEM; +- } +- +- info->family = family; +- info->ops = ops; +- info->attrs = attrs; ++ ctx.family = family; ++ ctx.nlh = nlh; ++ ctx.extack = extack; ++ ctx.ops = ops; ++ ctx.hdrlen = hdrlen; + + if (!family->parallel_ops) { + struct netlink_dump_control c = { + .module = family->module, +- .data = info, +- .start = genl_lock_start, ++ .data = &ctx, ++ .start = genl_start, + .dump = genl_lock_dumpit, + .done = genl_lock_done, + }; +@@ -617,12 +640,11 @@ no_attrs: + genl_unlock(); + err = __netlink_dump_start(net->genl_sock, skb, nlh, &c); + genl_lock(); +- + } else { + struct netlink_dump_control c = { + .module = family->module, +- .data = info, +- .start = ops->start, ++ .data = &ctx, ++ .start = genl_start, + .dump = ops->dumpit, + .done = genl_parallel_done, + }; diff --git a/queue-5.6/ipv6-fix-ipv6_addrform-operation-logic.patch b/queue-5.6/ipv6-fix-ipv6_addrform-operation-logic.patch new file mode 100644 index 00000000000..7df29d5aa5d --- /dev/null +++ b/queue-5.6/ipv6-fix-ipv6_addrform-operation-logic.patch @@ -0,0 +1,77 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Hangbin Liu +Date: Mon, 1 Jun 2020 11:55:03 +0800 +Subject: ipv6: fix IPV6_ADDRFORM operation logic + +From: Hangbin Liu + +[ Upstream commit 79a1f0ccdbb4ad700590f61b00525b390cb53905 ] + +Socket option IPV6_ADDRFORM supports UDP/UDPLITE and TCP at present. +Previously the checking logic looks like: +if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) + do_some_check; +else if (sk->sk_protocol != IPPROTO_TCP) + break; + +After commit b6f6118901d1 ("ipv6: restrict IPV6_ADDRFORM operation"), TCP +was blocked as the logic changed to: +if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) + do_some_check; +else if (sk->sk_protocol == IPPROTO_TCP) + do_some_check; + break; +else + break; + +Then after commit 82c9ae440857 ("ipv6: fix restrict IPV6_ADDRFORM operation") +UDP/UDPLITE were blocked as the logic changed to: +if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) + do_some_check; +if (sk->sk_protocol == IPPROTO_TCP) + do_some_check; + +if (sk->sk_protocol != IPPROTO_TCP) + break; + +Fix it by using Eric's code and simply remove the break in TCP check, which +looks like: +if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) + do_some_check; +else if (sk->sk_protocol == IPPROTO_TCP) + do_some_check; +else + break; + +Fixes: 82c9ae440857 ("ipv6: fix restrict IPV6_ADDRFORM operation") +Signed-off-by: Hangbin Liu +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv6/ipv6_sockglue.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +--- a/net/ipv6/ipv6_sockglue.c ++++ b/net/ipv6/ipv6_sockglue.c +@@ -183,14 +183,15 @@ static int do_ipv6_setsockopt(struct soc + retv = -EBUSY; + break; + } +- } +- if (sk->sk_protocol == IPPROTO_TCP && +- sk->sk_prot != &tcpv6_prot) { +- retv = -EBUSY; ++ } else if (sk->sk_protocol == IPPROTO_TCP) { ++ if (sk->sk_prot != &tcpv6_prot) { ++ retv = -EBUSY; ++ break; ++ } ++ } else { + break; + } +- if (sk->sk_protocol != IPPROTO_TCP) +- break; ++ + if (sk->sk_state != TCP_ESTABLISHED) { + retv = -ENOTCONN; + break; diff --git a/queue-5.6/mlxsw-core-use-different-get_trend-callbacks-for-different-thermal-zones.patch b/queue-5.6/mlxsw-core-use-different-get_trend-callbacks-for-different-thermal-zones.patch new file mode 100644 index 00000000000..ea2f3e7ee45 --- /dev/null +++ b/queue-5.6/mlxsw-core-use-different-get_trend-callbacks-for-different-thermal-zones.patch @@ -0,0 +1,83 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Vadim Pasternak +Date: Sun, 7 Jun 2020 11:10:27 +0300 +Subject: mlxsw: core: Use different get_trend() callbacks for different thermal zones + +From: Vadim Pasternak + +[ Upstream commit 2dc2f760052da4925482ecdcdc5c94d4a599153c ] + +The driver registers three different types of thermal zones: For the +ASIC itself, for port modules and for gearboxes. + +Currently, all three types use the same get_trend() callback which does +not work correctly for the ASIC thermal zone. The callback assumes that +the device data is of type 'struct mlxsw_thermal_module', whereas for +the ASIC thermal zone 'struct mlxsw_thermal' is passed as device data. + +Fix this by using one get_trend() callback for the ASIC thermal zone and +another for the other two types. + +Fixes: 6f73862fabd9 ("mlxsw: core: Add the hottest thermal zone detection") +Signed-off-by: Vadim Pasternak +Reviewed-by: Jiri Pirko +Signed-off-by: Ido Schimmel +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/mellanox/mlxsw/core_thermal.c | 23 +++++++++++++++++---- + 1 file changed, 19 insertions(+), 4 deletions(-) + +--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c ++++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c +@@ -391,8 +391,7 @@ static int mlxsw_thermal_set_trip_hyst(s + static int mlxsw_thermal_trend_get(struct thermal_zone_device *tzdev, + int trip, enum thermal_trend *trend) + { +- struct mlxsw_thermal_module *tz = tzdev->devdata; +- struct mlxsw_thermal *thermal = tz->parent; ++ struct mlxsw_thermal *thermal = tzdev->devdata; + + if (trip < 0 || trip >= MLXSW_THERMAL_NUM_TRIPS) + return -EINVAL; +@@ -593,6 +592,22 @@ mlxsw_thermal_module_trip_hyst_set(struc + return 0; + } + ++static int mlxsw_thermal_module_trend_get(struct thermal_zone_device *tzdev, ++ int trip, enum thermal_trend *trend) ++{ ++ struct mlxsw_thermal_module *tz = tzdev->devdata; ++ struct mlxsw_thermal *thermal = tz->parent; ++ ++ if (trip < 0 || trip >= MLXSW_THERMAL_NUM_TRIPS) ++ return -EINVAL; ++ ++ if (tzdev == thermal->tz_highest_dev) ++ return 1; ++ ++ *trend = THERMAL_TREND_STABLE; ++ return 0; ++} ++ + static struct thermal_zone_device_ops mlxsw_thermal_module_ops = { + .bind = mlxsw_thermal_module_bind, + .unbind = mlxsw_thermal_module_unbind, +@@ -604,7 +619,7 @@ static struct thermal_zone_device_ops ml + .set_trip_temp = mlxsw_thermal_module_trip_temp_set, + .get_trip_hyst = mlxsw_thermal_module_trip_hyst_get, + .set_trip_hyst = mlxsw_thermal_module_trip_hyst_set, +- .get_trend = mlxsw_thermal_trend_get, ++ .get_trend = mlxsw_thermal_module_trend_get, + }; + + static int mlxsw_thermal_gearbox_temp_get(struct thermal_zone_device *tzdev, +@@ -643,7 +658,7 @@ static struct thermal_zone_device_ops ml + .set_trip_temp = mlxsw_thermal_module_trip_temp_set, + .get_trip_hyst = mlxsw_thermal_module_trip_hyst_get, + .set_trip_hyst = mlxsw_thermal_module_trip_hyst_set, +- .get_trend = mlxsw_thermal_trend_get, ++ .get_trend = mlxsw_thermal_module_trend_get, + }; + + static int mlxsw_thermal_get_max_state(struct thermal_cooling_device *cdev, diff --git a/queue-5.6/net-dsa-qca8k-fix-unexpected-gfp-kernel-exception.patch b/queue-5.6/net-dsa-qca8k-fix-unexpected-gfp-kernel-exception.patch new file mode 100644 index 00000000000..27e545a686f --- /dev/null +++ b/queue-5.6/net-dsa-qca8k-fix-unexpected-gfp-kernel-exception.patch @@ -0,0 +1,68 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: "Michal Vokáč" +Date: Wed, 3 Jun 2020 13:31:39 +0200 +Subject: net: dsa: qca8k: Fix "Unexpected gfp" kernel exception + +From: "Michal Vokáč" + +[ Upstream commit 67122a7910bf2135dc7f7ececfcf16a5bdb362c1 ] + +Commit 7e99e3470172 ("net: dsa: remove dsa_switch_alloc helper") +replaced the dsa_switch_alloc helper by devm_kzalloc in all DSA +drivers. Unfortunately it introduced a typo in qca8k.c driver and +wrong argument is passed to the devm_kzalloc function. + +This fix mitigates the following kernel exception: + + Unexpected gfp: 0x6 (__GFP_HIGHMEM|GFP_DMA32). Fixing up to gfp: 0x101 (GFP_DMA|__GFP_ZERO). Fix your code! + CPU: 1 PID: 44 Comm: kworker/1:1 Not tainted 5.5.9-yocto-ua #1 + Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) + Workqueue: events deferred_probe_work_func + [] (unwind_backtrace) from [] (show_stack+0x10/0x14) + [] (show_stack) from [] (dump_stack+0x90/0xa4) + [] (dump_stack) from [] (new_slab+0x20c/0x214) + [] (new_slab) from [] (___slab_alloc.constprop.0+0x1b8/0x540) + [] (___slab_alloc.constprop.0) from [] (__slab_alloc.constprop.0+0x1c/0x24) + [] (__slab_alloc.constprop.0) from [] (__kmalloc_track_caller+0x1b0/0x298) + [] (__kmalloc_track_caller) from [] (devm_kmalloc+0x24/0x70) + [] (devm_kmalloc) from [] (qca8k_sw_probe+0x94/0x1ac) + [] (qca8k_sw_probe) from [] (mdio_probe+0x30/0x54) + [] (mdio_probe) from [] (really_probe+0x1e0/0x348) + [] (really_probe) from [] (driver_probe_device+0x60/0x16c) + [] (driver_probe_device) from [] (bus_for_each_drv+0x70/0x94) + [] (bus_for_each_drv) from [] (__device_attach+0xb4/0x11c) + [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) + [] (bus_probe_device) from [] (deferred_probe_work_func+0x64/0x90) + [] (deferred_probe_work_func) from [] (process_one_work+0x1d4/0x41c) + [] (process_one_work) from [] (worker_thread+0x248/0x528) + [] (worker_thread) from [] (kthread+0x124/0x150) + [] (kthread) from [] (ret_from_fork+0x14/0x3c) + Exception stack(0xee1b5fb0 to 0xee1b5ff8) + 5fa0: 00000000 00000000 00000000 00000000 + 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 + 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 + qca8k 2188000.ethernet-1:0a: Using legacy PHYLIB callbacks. Please migrate to PHYLINK! + qca8k 2188000.ethernet-1:0a eth2 (uninitialized): PHY [2188000.ethernet-1:01] driver [Generic PHY] + qca8k 2188000.ethernet-1:0a eth1 (uninitialized): PHY [2188000.ethernet-1:02] driver [Generic PHY] + +Fixes: 7e99e3470172 ("net: dsa: remove dsa_switch_alloc helper") +Signed-off-by: Michal Vokáč +Reviewed-by: Andrew Lunn +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/dsa/qca8k.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/net/dsa/qca8k.c ++++ b/drivers/net/dsa/qca8k.c +@@ -1079,8 +1079,7 @@ qca8k_sw_probe(struct mdio_device *mdiod + if (id != QCA8K_ID_QCA8337) + return -ENODEV; + +- priv->ds = devm_kzalloc(&mdiodev->dev, sizeof(*priv->ds), +- QCA8K_NUM_PORTS); ++ priv->ds = devm_kzalloc(&mdiodev->dev, sizeof(*priv->ds), GFP_KERNEL); + if (!priv->ds) + return -ENOMEM; + diff --git a/queue-5.6/net-ena-xdp-update-napi-budget-for-drop-and-aborted.patch b/queue-5.6/net-ena-xdp-update-napi-budget-for-drop-and-aborted.patch new file mode 100644 index 00000000000..85daf2a89f2 --- /dev/null +++ b/queue-5.6/net-ena-xdp-update-napi-budget-for-drop-and-aborted.patch @@ -0,0 +1,55 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Sameeh Jubran +Date: Wed, 3 Jun 2020 08:50:23 +0000 +Subject: net: ena: xdp: update napi budget for DROP and ABORTED + +From: Sameeh Jubran + +[ Upstream commit 3921a81c31df6057183aeb7f7d204003bf699d6f ] + +This patch fixes two issues with XDP: + +1. If the XDP verdict is XDP_ABORTED we break the loop, which results in + us handling one buffer per napi cycle instead of the total budget + (usually 64). To overcome this simply change the xdp_verdict check to + != XDP_PASS. When the verdict is XDP_PASS, the skb is not expected to + be NULL. + +2. Update the residual budget for XDP_DROP and XDP_ABORTED, since + packets are handled in these cases. + +Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action") +Signed-off-by: Sameeh Jubran +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/amazon/ena/ena_netdev.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c ++++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c +@@ -1642,11 +1642,9 @@ static int ena_clean_rx_irq(struct ena_r + &next_to_clean); + + if (unlikely(!skb)) { +- if (xdp_verdict == XDP_TX) { ++ if (xdp_verdict == XDP_TX) + ena_free_rx_page(rx_ring, + &rx_ring->rx_buffer_info[rx_ring->ena_bufs[0].req_id]); +- res_budget--; +- } + for (i = 0; i < ena_rx_ctx.descs; i++) { + rx_ring->free_ids[next_to_clean] = + rx_ring->ena_bufs[i].req_id; +@@ -1654,8 +1652,10 @@ static int ena_clean_rx_irq(struct ena_r + ENA_RX_RING_IDX_NEXT(next_to_clean, + rx_ring->ring_size); + } +- if (xdp_verdict == XDP_TX || xdp_verdict == XDP_DROP) ++ if (xdp_verdict != XDP_PASS) { ++ res_budget--; + continue; ++ } + break; + } + diff --git a/queue-5.6/net-ena-xdp-xdp_tx-fix-memory-leak.patch b/queue-5.6/net-ena-xdp-xdp_tx-fix-memory-leak.patch new file mode 100644 index 00000000000..8218a042102 --- /dev/null +++ b/queue-5.6/net-ena-xdp-xdp_tx-fix-memory-leak.patch @@ -0,0 +1,35 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Sameeh Jubran +Date: Wed, 3 Jun 2020 08:50:22 +0000 +Subject: net: ena: xdp: XDP_TX: fix memory leak + +From: Sameeh Jubran + +[ Upstream commit cd07ecccba13b8bd5023ffe7be57363d07e3105f ] + +When sending very high packet rate, the XDP tx queues can get full and +start dropping packets. In this case we don't free the pages which +results in ena driver draining the system memory. + +Fix: +Simply free the pages when necessary. + +Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action") +Signed-off-by: Sameeh Jubran +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/amazon/ena/ena_netdev.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c ++++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c +@@ -358,7 +358,7 @@ error_unmap_dma: + ena_unmap_tx_buff(xdp_ring, tx_info); + tx_info->xdpf = NULL; + error_drop_packet: +- ++ __free_page(tx_info->xdp_rx_page); + return NETDEV_TX_OK; + } + diff --git a/queue-5.6/net_failover-fixed-rollback-in-net_failover_open.patch b/queue-5.6/net_failover-fixed-rollback-in-net_failover_open.patch new file mode 100644 index 00000000000..905409d17ff --- /dev/null +++ b/queue-5.6/net_failover-fixed-rollback-in-net_failover_open.patch @@ -0,0 +1,33 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Vasily Averin +Date: Tue, 2 Jun 2020 15:55:26 +0300 +Subject: net_failover: fixed rollback in net_failover_open() + +From: Vasily Averin + +[ Upstream commit e8224bfe77293494626f6eec1884fee7b87d0ced ] + +found by smatch: +drivers/net/net_failover.c:65 net_failover_open() error: + we previously assumed 'primary_dev' could be null (see line 43) + +Fixes: cfc80d9a1163 ("net: Introduce net_failover driver") +Signed-off-by: Vasily Averin +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/net_failover.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/net/net_failover.c ++++ b/drivers/net/net_failover.c +@@ -61,7 +61,8 @@ static int net_failover_open(struct net_ + return 0; + + err_standby_open: +- dev_close(primary_dev); ++ if (primary_dev) ++ dev_close(primary_dev); + err_primary_open: + netif_tx_disable(dev); + return err; diff --git a/queue-5.6/series b/queue-5.6/series new file mode 100644 index 00000000000..151a30ccf88 --- /dev/null +++ b/queue-5.6/series @@ -0,0 +1,11 @@ +ipv6-fix-ipv6_addrform-operation-logic.patch +mlxsw-core-use-different-get_trend-callbacks-for-different-thermal-zones.patch +net_failover-fixed-rollback-in-net_failover_open.patch +tun-correct-header-offsets-in-napi-frags-mode.patch +bridge-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch +vxlan-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch +net-ena-xdp-xdp_tx-fix-memory-leak.patch +net-ena-xdp-update-napi-budget-for-drop-and-aborted.patch +genetlink-fix-memory-leaks-in-genl_family_rcv_msg_dumpit.patch +net-dsa-qca8k-fix-unexpected-gfp-kernel-exception.patch +tipc-fix-null-pointer-dereference-in-streaming.patch diff --git a/queue-5.6/tipc-fix-null-pointer-dereference-in-streaming.patch b/queue-5.6/tipc-fix-null-pointer-dereference-in-streaming.patch new file mode 100644 index 00000000000..72568a88b65 --- /dev/null +++ b/queue-5.6/tipc-fix-null-pointer-dereference-in-streaming.patch @@ -0,0 +1,91 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Tuong Lien +Date: Wed, 3 Jun 2020 12:06:01 +0700 +Subject: tipc: fix NULL pointer dereference in streaming + +From: Tuong Lien + +[ Upstream commit 5e9eeccc58f3e6bcc99b929670665d2ce047e9c9 ] + +syzbot found the following crash: + +general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] PREEMPT SMP KASAN +KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf] +CPU: 1 PID: 7060 Comm: syz-executor394 Not tainted 5.7.0-rc6-syzkaller #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 +RIP: 0010:__tipc_sendstream+0xbde/0x11f0 net/tipc/socket.c:1591 +Code: 00 00 00 00 48 39 5c 24 28 48 0f 44 d8 e8 fa 3e db f9 48 b8 00 00 00 00 00 fc ff df 48 8d bb c8 00 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 e2 04 00 00 48 8b 9b c8 00 00 00 48 b8 00 00 00 +RSP: 0018:ffffc90003ef7818 EFLAGS: 00010202 +RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8797fd9d +RDX: 0000000000000019 RSI: ffffffff8797fde6 RDI: 00000000000000c8 +RBP: ffff888099848040 R08: ffff88809a5f6440 R09: fffffbfff1860b4c +R10: ffffffff8c305a5f R11: fffffbfff1860b4b R12: ffff88809984857e +R13: 0000000000000000 R14: ffff888086aa4000 R15: 0000000000000000 +FS: 00000000009b4880(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 0000000020000140 CR3: 00000000a7fdf000 CR4: 00000000001406e0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + tipc_sendstream+0x4c/0x70 net/tipc/socket.c:1533 + sock_sendmsg_nosec net/socket.c:652 [inline] + sock_sendmsg+0xcf/0x120 net/socket.c:672 + ____sys_sendmsg+0x32f/0x810 net/socket.c:2352 + ___sys_sendmsg+0x100/0x170 net/socket.c:2406 + __sys_sendmmsg+0x195/0x480 net/socket.c:2496 + __do_sys_sendmmsg net/socket.c:2525 [inline] + __se_sys_sendmmsg net/socket.c:2522 [inline] + __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2522 + do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 + entry_SYSCALL_64_after_hwframe+0x49/0xb3 +RIP: 0033:0x440199 +... + +This bug was bisected to commit 0a3e060f340d ("tipc: add test for Nagle +algorithm effectiveness"). However, it is not the case, the trouble was +from the base in the case of zero data length message sending, we would +unexpectedly make an empty 'txq' queue after the 'tipc_msg_append()' in +Nagle mode. + +A similar crash can be generated even without the bisected patch but at +the link layer when it accesses the empty queue. + +We solve the issues by building at least one buffer to go with socket's +header and an optional data section that may be empty like what we had +with the 'tipc_msg_build()'. + +Note: the previous commit 4c21daae3dbc ("tipc: Fix NULL pointer +dereference in __tipc_sendstream()") is obsoleted by this one since the +'txq' will be never empty and the check of 'skb != NULL' is unnecessary +but it is safe anyway. + +Reported-by: syzbot+8eac6d030e7807c21d32@syzkaller.appspotmail.com +Fixes: c0bceb97db9e ("tipc: add smart nagle feature") +Acked-by: Jon Maloy +Signed-off-by: Tuong Lien +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/tipc/msg.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/net/tipc/msg.c ++++ b/net/tipc/msg.c +@@ -221,7 +221,7 @@ int tipc_msg_append(struct tipc_msg *_hd + accounted = skb ? msg_blocks(buf_msg(skb)) : 0; + total = accounted; + +- while (rem) { ++ do { + if (!skb || skb->len >= mss) { + prev = skb; + skb = tipc_buf_acquire(mss, GFP_KERNEL); +@@ -249,7 +249,7 @@ int tipc_msg_append(struct tipc_msg *_hd + skb_put(skb, cpy); + rem -= cpy; + total += msg_blocks(hdr) - curr; +- } ++ } while (rem); + return total - accounted; + } + diff --git a/queue-5.6/tun-correct-header-offsets-in-napi-frags-mode.patch b/queue-5.6/tun-correct-header-offsets-in-napi-frags-mode.patch new file mode 100644 index 00000000000..9574a319846 --- /dev/null +++ b/queue-5.6/tun-correct-header-offsets-in-napi-frags-mode.patch @@ -0,0 +1,65 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Willem de Bruijn +Date: Sat, 30 May 2020 15:41:31 -0400 +Subject: tun: correct header offsets in napi frags mode + +From: Willem de Bruijn + +[ Upstream commit 96aa1b22bd6bb9fccf62f6261f390ed6f3e7967f ] + +Tun in IFF_NAPI_FRAGS mode calls napi_gro_frags. Unlike netif_rx and +netif_gro_receive, this expects skb->data to point to the mac layer. + +But skb_probe_transport_header, __skb_get_hash_symmetric, and +xdp_do_generic in tun_get_user need skb->data to point to the network +header. Flow dissection also needs skb->protocol set, so +eth_type_trans has to be called. + +Ensure the link layer header lies in linear as eth_type_trans pulls +ETH_HLEN. Then take the same code paths for frags as for not frags. +Push the link layer header back just before calling napi_gro_frags. + +By pulling up to ETH_HLEN from frag0 into linear, this disables the +frag0 optimization in the special case when IFF_NAPI_FRAGS is used +with zero length iov[0] (and thus empty skb->linear). + +Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver") +Signed-off-by: Willem de Bruijn +Acked-by: Petar Penkov +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/tun.c | 14 ++++++++++---- + 1 file changed, 10 insertions(+), 4 deletions(-) + +--- a/drivers/net/tun.c ++++ b/drivers/net/tun.c +@@ -1908,8 +1908,11 @@ drop: + skb->dev = tun->dev; + break; + case IFF_TAP: +- if (!frags) +- skb->protocol = eth_type_trans(skb, tun->dev); ++ if (frags && !pskb_may_pull(skb, ETH_HLEN)) { ++ err = -ENOMEM; ++ goto drop; ++ } ++ skb->protocol = eth_type_trans(skb, tun->dev); + break; + } + +@@ -1966,9 +1969,12 @@ drop: + } + + if (frags) { ++ u32 headlen; ++ + /* Exercise flow dissector code path. */ +- u32 headlen = eth_get_headlen(tun->dev, skb->data, +- skb_headlen(skb)); ++ skb_push(skb, ETH_HLEN); ++ headlen = eth_get_headlen(tun->dev, skb->data, ++ skb_headlen(skb)); + + if (unlikely(headlen > skb_headlen(skb))) { + this_cpu_inc(tun->pcpu_stats->rx_dropped); diff --git a/queue-5.6/vxlan-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch b/queue-5.6/vxlan-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch new file mode 100644 index 00000000000..5a1c80c6e05 --- /dev/null +++ b/queue-5.6/vxlan-avoid-infinite-loop-when-suppressing-ns-messages-with-invalid-options.patch @@ -0,0 +1,48 @@ +From foo@baz Thu 11 Jun 2020 11:54:52 AM CEST +From: Ido Schimmel +Date: Mon, 1 Jun 2020 15:58:55 +0300 +Subject: vxlan: Avoid infinite loop when suppressing NS messages with invalid options + +From: Ido Schimmel + +[ Upstream commit 8066e6b449e050675df48e7c4b16c29f00507ff0 ] + +When proxy mode is enabled the vxlan device might reply to Neighbor +Solicitation (NS) messages on behalf of remote hosts. + +In case the NS message includes the "Source link-layer address" option +[1], the vxlan device will use the specified address as the link-layer +destination address in its reply. + +To avoid an infinite loop, break out of the options parsing loop when +encountering an option with length zero and disregard the NS message. + +This is consistent with the IPv6 ndisc code and RFC 4886 which states +that "Nodes MUST silently discard an ND packet that contains an option +with length zero" [2]. + +[1] https://tools.ietf.org/html/rfc4861#section-4.3 +[2] https://tools.ietf.org/html/rfc4861#section-4.6 + +Fixes: 4b29dba9c085 ("vxlan: fix nonfunctional neigh_reduce()") +Signed-off-by: Ido Schimmel +Acked-by: Nikolay Aleksandrov +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/vxlan.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/net/vxlan.c ++++ b/drivers/net/vxlan.c +@@ -1924,6 +1924,10 @@ static struct sk_buff *vxlan_na_create(s + ns_olen = request->len - skb_network_offset(request) - + sizeof(struct ipv6hdr) - sizeof(*ns); + for (i = 0; i < ns_olen-1; i += (ns->opt[i+1]<<3)) { ++ if (!ns->opt[i + 1]) { ++ kfree_skb(reply); ++ return NULL; ++ } + if (ns->opt[i] == ND_OPT_SOURCE_LL_ADDR) { + daddr = ns->opt + i + sizeof(struct nd_opt_hdr); + break;