From: Greg Kroah-Hartman Date: Thu, 9 Apr 2020 14:04:32 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v4.4.219~33 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=853a7bfa4ef46285e80719fbcd3b4be37f5aa265;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: ipv6-don-t-auto-add-link-local-address-to-lag-ports.patch mlxsw-spectrum_flower-do-not-stop-at-flow_action_vlan_mangle.patch net-dsa-bcm_sf2-do-not-register-slave-mdio-bus-with-of.patch net-dsa-bcm_sf2-ensure-correct-sub-node-is-parsed.patch net-phy-micrel-kszphy_resume-add-delay-after-genphy_resume-before-accessing-phy-registers.patch net-stmmac-dwmac1000-fix-out-of-bounds-mac-address-reg-setting.patch slcan-don-t-transmit-uninitialized-stack-data-in-padding.patch --- diff --git a/queue-4.19/ipv6-don-t-auto-add-link-local-address-to-lag-ports.patch b/queue-4.19/ipv6-don-t-auto-add-link-local-address-to-lag-ports.patch new file mode 100644 index 00000000000..707fc99145b --- /dev/null +++ b/queue-4.19/ipv6-don-t-auto-add-link-local-address-to-lag-ports.patch @@ -0,0 +1,91 @@ +From foo@baz Thu 09 Apr 2020 01:26:03 PM CEST +From: Jarod Wilson +Date: Mon, 30 Mar 2020 11:22:19 -0400 +Subject: ipv6: don't auto-add link-local address to lag ports + +From: Jarod Wilson + +[ Upstream commit 744fdc8233f6aa9582ce08a51ca06e59796a3196 ] + +Bonding slave and team port devices should not have link-local addresses +automatically added to them, as it can interfere with openvswitch being +able to properly add tc ingress. + +Basic reproducer, courtesy of Marcelo: + +$ ip link add name bond0 type bond +$ ip link set dev ens2f0np0 master bond0 +$ ip link set dev ens2f1np2 master bond0 +$ ip link set dev bond0 up +$ ip a s +1: lo: mtu 65536 qdisc noqueue state UNKNOWN +group default qlen 1000 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever +2: ens2f0np0: mtu 1500 qdisc +mq master bond0 state UP group default qlen 1000 + link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff +5: ens2f1np2: mtu 1500 qdisc +mq master bond0 state DOWN group default qlen 1000 + link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff +11: bond0: mtu 1500 qdisc +noqueue state UP group default qlen 1000 + link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff + inet6 fe80::20f:53ff:fe2f:ea40/64 scope link + valid_lft forever preferred_lft forever + +(above trimmed to relevant entries, obviously) + +$ sysctl net.ipv6.conf.ens2f0np0.addr_gen_mode=0 +net.ipv6.conf.ens2f0np0.addr_gen_mode = 0 +$ sysctl net.ipv6.conf.ens2f1np2.addr_gen_mode=0 +net.ipv6.conf.ens2f1np2.addr_gen_mode = 0 + +$ ip a l ens2f0np0 +2: ens2f0np0: mtu 1500 qdisc +mq master bond0 state UP group default qlen 1000 + link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff + inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative + valid_lft forever preferred_lft forever +$ ip a l ens2f1np2 +5: ens2f1np2: mtu 1500 qdisc +mq master bond0 state DOWN group default qlen 1000 + link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff + inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative + valid_lft forever preferred_lft forever + +Looks like addrconf_sysctl_addr_gen_mode() bypasses the original "is +this a slave interface?" check added by commit c2edacf80e15, and +results in an address getting added, while w/the proposed patch added, +no address gets added. This simply adds the same gating check to another +code path, and thus should prevent the same devices from erroneously +obtaining an ipv6 link-local address. + +Fixes: d35a00b8e33d ("net/ipv6: allow sysctl to change link-local address generation mode") +Reported-by: Moshe Levi +CC: Stephen Hemminger +CC: Marcelo Ricardo Leitner +CC: netdev@vger.kernel.org +Signed-off-by: Jarod Wilson +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv6/addrconf.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/net/ipv6/addrconf.c ++++ b/net/ipv6/addrconf.c +@@ -3241,6 +3241,10 @@ static void addrconf_addr_gen(struct ine + if (netif_is_l3_master(idev->dev)) + return; + ++ /* no link local addresses on devices flagged as slaves */ ++ if (idev->dev->flags & IFF_SLAVE) ++ return; ++ + ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0); + + switch (idev->cnf.addr_gen_mode) { diff --git a/queue-4.19/mlxsw-spectrum_flower-do-not-stop-at-flow_action_vlan_mangle.patch b/queue-4.19/mlxsw-spectrum_flower-do-not-stop-at-flow_action_vlan_mangle.patch new file mode 100644 index 00000000000..eb85af1fa6c --- /dev/null +++ b/queue-4.19/mlxsw-spectrum_flower-do-not-stop-at-flow_action_vlan_mangle.patch @@ -0,0 +1,41 @@ +From foo@baz Thu 09 Apr 2020 01:26:03 PM CEST +From: Petr Machata +Date: Sun, 5 Apr 2020 09:50:22 +0300 +Subject: mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLE + +From: Petr Machata + +[ Upstream commit ccfc569347f870830e7c7cf854679a06cf9c45b5 ] + +The handler for FLOW_ACTION_VLAN_MANGLE ends by returning whatever the +lower-level function that it calls returns. If there are more actions lined +up after this action, those are never offloaded. Fix by only bailing out +when the called function returns an error. + +Fixes: a150201a70da ("mlxsw: spectrum: Add support for vlan modify TC action") +Signed-off-by: Petr Machata +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/spectrum_flower.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_flower.c ++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_flower.c +@@ -98,9 +98,11 @@ static int mlxsw_sp_flower_parse_actions + u8 prio = tcf_vlan_push_prio(a); + u16 vid = tcf_vlan_push_vid(a); + +- return mlxsw_sp_acl_rulei_act_vlan(mlxsw_sp, rulei, +- action, vid, +- proto, prio, extack); ++ err = mlxsw_sp_acl_rulei_act_vlan(mlxsw_sp, rulei, ++ act->id, vid, ++ proto, prio, extack); ++ if (err) ++ return err; + } else { + NL_SET_ERR_MSG_MOD(extack, "Unsupported action"); + dev_err(mlxsw_sp->bus_info->dev, "Unsupported action\n"); diff --git a/queue-4.19/net-dsa-bcm_sf2-do-not-register-slave-mdio-bus-with-of.patch b/queue-4.19/net-dsa-bcm_sf2-do-not-register-slave-mdio-bus-with-of.patch new file mode 100644 index 00000000000..5ba69ef14d7 --- /dev/null +++ b/queue-4.19/net-dsa-bcm_sf2-do-not-register-slave-mdio-bus-with-of.patch @@ -0,0 +1,53 @@ +From foo@baz Thu 09 Apr 2020 01:26:03 PM CEST +From: Florian Fainelli +Date: Sat, 4 Apr 2020 14:35:17 -0700 +Subject: net: dsa: bcm_sf2: Do not register slave MDIO bus with OF + +From: Florian Fainelli + +[ Upstream commit 536fab5bf5826404534a6c271f622ad2930d9119 ] + +We were registering our slave MDIO bus with OF and doing so with +assigning the newly created slave_mii_bus of_node to the master MDIO bus +controller node. This is a bad thing to do for a number of reasons: + +- we are completely lying about the slave MII bus is arranged and yet we + still want to control which MDIO devices it probes. It was attempted + before to play tricks with the bus_mask to perform that: + https://www.spinics.net/lists/netdev/msg429420.html but the approach + was rightfully rejected + +- the device_node reference counting is messed up and we are effectively + doing a double probe on the devices we already probed using the + master, this messes up all resources reference counts (such as clocks) + +The proper fix for this as indicated by David in his reply to the +thread above is to use a platform data style registration so as to +control exactly which devices we probe: +https://www.spinics.net/lists/netdev/msg430083.html + +By using mdiobus_register(), our slave_mii_bus->phy_mask value is used +as intended, and all the PHY addresses that must be redirected towards +our slave MDIO bus is happening while other addresses get redirected +towards the master MDIO bus. + +Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus") +Signed-off-by: Florian Fainelli +Reviewed-by: Vivien Didelot +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/dsa/bcm_sf2.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/dsa/bcm_sf2.c ++++ b/drivers/net/dsa/bcm_sf2.c +@@ -461,7 +461,7 @@ static int bcm_sf2_mdio_register(struct + priv->slave_mii_bus->parent = ds->dev->parent; + priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask; + +- err = of_mdiobus_register(priv->slave_mii_bus, dn); ++ err = mdiobus_register(priv->slave_mii_bus); + if (err && dn) + of_node_put(dn); + diff --git a/queue-4.19/net-dsa-bcm_sf2-ensure-correct-sub-node-is-parsed.patch b/queue-4.19/net-dsa-bcm_sf2-ensure-correct-sub-node-is-parsed.patch new file mode 100644 index 00000000000..8ccc2af817a --- /dev/null +++ b/queue-4.19/net-dsa-bcm_sf2-ensure-correct-sub-node-is-parsed.patch @@ -0,0 +1,48 @@ +From foo@baz Thu 09 Apr 2020 01:26:03 PM CEST +From: Florian Fainelli +Date: Sun, 5 Apr 2020 13:00:30 -0700 +Subject: net: dsa: bcm_sf2: Ensure correct sub-node is parsed + +From: Florian Fainelli + +[ Upstream commit afa3b592953bfaecfb4f2f335ec5f935cff56804 ] + +When the bcm_sf2 was converted into a proper platform device driver and +used the new dsa_register_switch() interface, we would still be parsing +the legacy DSA node that contained all the port information since the +platform firmware has intentionally maintained backward and forward +compatibility to client programs. Ensure that we do parse the correct +node, which is "ports" per the revised DSA binding. + +Fixes: d9338023fb8e ("net: dsa: bcm_sf2: Make it a real platform device driver") +Signed-off-by: Florian Fainelli +Reviewed-by: Vivien Didelot +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/dsa/bcm_sf2.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/net/dsa/bcm_sf2.c ++++ b/drivers/net/dsa/bcm_sf2.c +@@ -1014,6 +1014,7 @@ static int bcm_sf2_sw_probe(struct platf + const struct bcm_sf2_of_data *data; + struct b53_platform_data *pdata; + struct dsa_switch_ops *ops; ++ struct device_node *ports; + struct bcm_sf2_priv *priv; + struct b53_device *dev; + struct dsa_switch *ds; +@@ -1077,7 +1078,11 @@ static int bcm_sf2_sw_probe(struct platf + set_bit(0, priv->cfp.used); + set_bit(0, priv->cfp.unique); + +- bcm_sf2_identify_ports(priv, dn->child); ++ ports = of_find_node_by_name(dn, "ports"); ++ if (ports) { ++ bcm_sf2_identify_ports(priv, ports); ++ of_node_put(ports); ++ } + + priv->irq0 = irq_of_parse_and_map(dn, 0); + priv->irq1 = irq_of_parse_and_map(dn, 1); diff --git a/queue-4.19/net-phy-micrel-kszphy_resume-add-delay-after-genphy_resume-before-accessing-phy-registers.patch b/queue-4.19/net-phy-micrel-kszphy_resume-add-delay-after-genphy_resume-before-accessing-phy-registers.patch new file mode 100644 index 00000000000..8c3ef9e2c6d --- /dev/null +++ b/queue-4.19/net-phy-micrel-kszphy_resume-add-delay-after-genphy_resume-before-accessing-phy-registers.patch @@ -0,0 +1,63 @@ +From foo@baz Thu 09 Apr 2020 01:26:03 PM CEST +From: Oleksij Rempel +Date: Fri, 3 Apr 2020 09:53:25 +0200 +Subject: net: phy: micrel: kszphy_resume(): add delay after genphy_resume() before accessing PHY registers + +From: Oleksij Rempel + +[ Upstream commit 6110dff776f7fa65c35850ef65b41d3b39e2fac2 ] + +After the power-down bit is cleared, the chip internally triggers a +global reset. According to the KSZ9031 documentation, we have to wait at +least 1ms for the reset to finish. + +If the chip is accessed during reset, read will return 0xffff, while +write will be ignored. Depending on the system performance and MDIO bus +speed, we may or may not run in to this issue. + +This bug was discovered on an iMX6QP system with KSZ9031 PHY and +attached PHY interrupt line. If IRQ was used, the link status update was +lost. In polling mode, the link status update was always correct. + +The investigation showed, that during a read-modify-write access, the +read returned 0xffff (while the chip was still in reset) and +corresponding write hit the chip _after_ reset and triggered (due to the +0xffff) another reset in an undocumented bit (register 0x1f, bit 1), +resulting in the next write being lost due to the new reset cycle. + +This patch fixes the issue by adding a 1...2 ms sleep after the +genphy_resume(). + +Fixes: 836384d2501d ("net: phy: micrel: Add specific suspend") +Signed-off-by: Oleksij Rempel +Reviewed-by: Andrew Lunn +Reviewed-by: Florian Fainelli +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/phy/micrel.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/net/phy/micrel.c ++++ b/drivers/net/phy/micrel.c +@@ -29,6 +29,7 @@ + #include + #include + #include ++#include + + /* Operation Mode Strap Override */ + #define MII_KSZPHY_OMSO 0x16 +@@ -738,6 +739,12 @@ static int kszphy_resume(struct phy_devi + + genphy_resume(phydev); + ++ /* After switching from power-down to normal mode, an internal global ++ * reset is automatically generated. Wait a minimum of 1 ms before ++ * read/write access to the PHY registers. ++ */ ++ usleep_range(1000, 2000); ++ + ret = kszphy_config_reset(phydev); + if (ret) + return ret; diff --git a/queue-4.19/net-stmmac-dwmac1000-fix-out-of-bounds-mac-address-reg-setting.patch b/queue-4.19/net-stmmac-dwmac1000-fix-out-of-bounds-mac-address-reg-setting.patch new file mode 100644 index 00000000000..6007990108c --- /dev/null +++ b/queue-4.19/net-stmmac-dwmac1000-fix-out-of-bounds-mac-address-reg-setting.patch @@ -0,0 +1,35 @@ +From foo@baz Thu 09 Apr 2020 01:26:03 PM CEST +From: Jisheng Zhang +Date: Fri, 3 Apr 2020 10:23:29 +0800 +Subject: net: stmmac: dwmac1000: fix out-of-bounds mac address reg setting + +From: Jisheng Zhang + +[ Upstream commit 3e1221acf6a8f8595b5ce354bab4327a69d54d18 ] + +Commit 9463c4455900 ("net: stmmac: dwmac1000: Clear unused address +entries") cleared the unused mac address entries, but introduced an +out-of bounds mac address register programming bug -- After setting +the secondary unicast mac addresses, the "reg" value has reached +netdev_uc_count() + 1, thus we should only clear address entries +if (addr < perfect_addr_number) + +Fixes: 9463c4455900 ("net: stmmac: dwmac1000: Clear unused address entries") +Signed-off-by: Jisheng Zhang +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c ++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c +@@ -218,7 +218,7 @@ static void dwmac1000_set_filter(struct + reg++; + } + +- while (reg <= perfect_addr_number) { ++ while (reg < perfect_addr_number) { + writel(0, ioaddr + GMAC_ADDR_HIGH(reg)); + writel(0, ioaddr + GMAC_ADDR_LOW(reg)); + reg++; diff --git a/queue-4.19/series b/queue-4.19/series index 390d05da7c9..06b1d41ca97 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -25,3 +25,10 @@ padata-always-acquire-cpu_hotplug_lock-before-pinst-lock.patch bitops-protect-variables-in-set_mask_bits-macro.patch include-linux-notifier.h-srcu-fix-ctags.patch mm-mempolicy-require-at-least-one-nodeid-for-mpol_preferred.patch +ipv6-don-t-auto-add-link-local-address-to-lag-ports.patch +net-dsa-bcm_sf2-do-not-register-slave-mdio-bus-with-of.patch +net-dsa-bcm_sf2-ensure-correct-sub-node-is-parsed.patch +net-phy-micrel-kszphy_resume-add-delay-after-genphy_resume-before-accessing-phy-registers.patch +net-stmmac-dwmac1000-fix-out-of-bounds-mac-address-reg-setting.patch +slcan-don-t-transmit-uninitialized-stack-data-in-padding.patch +mlxsw-spectrum_flower-do-not-stop-at-flow_action_vlan_mangle.patch diff --git a/queue-4.19/slcan-don-t-transmit-uninitialized-stack-data-in-padding.patch b/queue-4.19/slcan-don-t-transmit-uninitialized-stack-data-in-padding.patch new file mode 100644 index 00000000000..b6ddff301ff --- /dev/null +++ b/queue-4.19/slcan-don-t-transmit-uninitialized-stack-data-in-padding.patch @@ -0,0 +1,51 @@ +From foo@baz Thu 09 Apr 2020 01:26:03 PM CEST +From: Richard Palethorpe +Date: Wed, 1 Apr 2020 12:06:39 +0200 +Subject: slcan: Don't transmit uninitialized stack data in padding + +From: Richard Palethorpe + +[ Upstream commit b9258a2cece4ec1f020715fe3554bc2e360f6264 ] + +struct can_frame contains some padding which is not explicitly zeroed in +slc_bump. This uninitialized data will then be transmitted if the stack +initialization hardening feature is not enabled (CONFIG_INIT_STACK_ALL). + +This commit just zeroes the whole struct including the padding. + +Signed-off-by: Richard Palethorpe +Fixes: a1044e36e457 ("can: add slcan driver for serial/USB-serial CAN adapters") +Reviewed-by: Kees Cook +Cc: linux-can@vger.kernel.org +Cc: netdev@vger.kernel.org +Cc: security@kernel.org +Cc: wg@grandegger.com +Cc: mkl@pengutronix.de +Cc: davem@davemloft.net +Acked-by: Marc Kleine-Budde +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/slcan.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/drivers/net/can/slcan.c ++++ b/drivers/net/can/slcan.c +@@ -147,7 +147,7 @@ static void slc_bump(struct slcan *sl) + u32 tmpid; + char *cmd = sl->rbuff; + +- cf.can_id = 0; ++ memset(&cf, 0, sizeof(cf)); + + switch (*cmd) { + case 'r': +@@ -186,8 +186,6 @@ static void slc_bump(struct slcan *sl) + else + return; + +- *(u64 *) (&cf.data) = 0; /* clear payload */ +- + /* RTR frames may have a dlc > 0 but they never have any data bytes */ + if (!(cf.can_id & CAN_RTR_FLAG)) { + for (i = 0; i < cf.can_dlc; i++) {