--- /dev/null
+From foo@baz Sat Jan 13 14:28:20 CET 2018
+From: Cong Wang <xiyou.wangcong@gmail.com>
+Date: Tue, 9 Jan 2018 13:40:41 -0800
+Subject: 8021q: fix a memory leak for VLAN 0 device
+
+From: Cong Wang <xiyou.wangcong@gmail.com>
+
+
+[ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ]
+
+A vlan device with vid 0 is allow to creat by not able to be fully
+cleaned up by unregister_vlan_dev() which checks for vlan_id!=0.
+
+Also, VLAN 0 is probably not a valid number and it is kinda
+"reserved" for HW accelerating devices, but it is probably too
+late to reject it from creation even if makes sense. Instead,
+just remove the check in unregister_vlan_dev().
+
+Reported-by: Dmitry Vyukov <dvyukov@google.com>
+Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
+Cc: Vlad Yasevich <vyasevich@gmail.com>
+Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/8021q/vlan.c | 7 +------
+ 1 file changed, 1 insertion(+), 6 deletions(-)
+
+--- a/net/8021q/vlan.c
++++ b/net/8021q/vlan.c
+@@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_devi
+ vlan_gvrp_uninit_applicant(real_dev);
+ }
+
+- /* Take it out of our own structures, but be sure to interlock with
+- * HW accelerating devices or SW vlan input packet processing if
+- * VLAN is not 0 (leave it there for 802.1p).
+- */
+- if (vlan_id)
+- vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
++ vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
+
+ /* Get rid of the vlan's reference to real_dev */
+ dev_put(real_dev);
--- /dev/null
+From foo@baz Sat Jan 13 14:28:20 CET 2018
+From: Eli Cooper <elicooper@gmx.com>
+Date: Mon, 25 Dec 2017 10:43:49 +0800
+Subject: ip6_tunnel: disable dst caching if tunnel is dual-stack
+
+From: Eli Cooper <elicooper@gmx.com>
+
+
+[ Upstream commit 23263ec86a5f44312d2899323872468752324107 ]
+
+When an ip6_tunnel is in mode 'any', where the transport layer
+protocol can be either 4 or 41, dst_cache must be disabled.
+
+This is because xfrm policies might apply to only one of the two
+protocols. Caching dst would cause xfrm policies for one protocol
+incorrectly used for the other.
+
+Signed-off-by: Eli Cooper <elicooper@gmx.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/ip6_tunnel.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/net/ipv6/ip6_tunnel.c
++++ b/net/ipv6/ip6_tunnel.c
+@@ -1083,10 +1083,11 @@ static int ip6_tnl_xmit2(struct sk_buff
+ memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr));
+ neigh_release(neigh);
+ }
+- } else if (!(t->parms.flags &
+- (IP6_TNL_F_USE_ORIG_TCLASS | IP6_TNL_F_USE_ORIG_FWMARK))) {
+- /* enable the cache only only if the routing decision does
+- * not depend on the current inner header value
++ } else if (t->parms.proto != 0 && !(t->parms.flags &
++ (IP6_TNL_F_USE_ORIG_TCLASS |
++ IP6_TNL_F_USE_ORIG_FWMARK))) {
++ /* enable the cache only if neither the outer protocol nor the
++ * routing decision depends on the current inner header value
+ */
+ use_cache = true;
+ }
--- /dev/null
+From foo@baz Sat Jan 13 14:28:20 CET 2018
+From: Eric Dumazet <edumazet@google.com>
+Date: Wed, 10 Jan 2018 03:45:49 -0800
+Subject: ipv6: fix possible mem leaks in ipv6_make_skb()
+
+From: Eric Dumazet <edumazet@google.com>
+
+
+[ Upstream commit 862c03ee1deb7e19e0f9931682e0294ecd1fcaf9 ]
+
+ip6_setup_cork() might return an error, while memory allocations have
+been done and must be rolled back.
+
+Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Cc: Vlad Yasevich <vyasevich@gmail.com>
+Reported-by: Mike Maloney <maloney@google.com>
+Acked-by: Mike Maloney <maloney@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/ip6_output.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/net/ipv6/ip6_output.c
++++ b/net/ipv6/ip6_output.c
+@@ -1785,8 +1785,10 @@ struct sk_buff *ip6_make_skb(struct sock
+ cork.base.opt = NULL;
+ v6_cork.opt = NULL;
+ err = ip6_setup_cork(sk, &cork, &v6_cork, hlimit, tclass, opt, rt, fl6);
+- if (err)
++ if (err) {
++ ip6_cork_release(&cork, &v6_cork);
+ return ERR_PTR(err);
++ }
+
+ if (dontfrag < 0)
+ dontfrag = inet6_sk(sk)->dontfrag;
--- /dev/null
+From foo@baz Sat Jan 13 14:28:20 CET 2018
+From: Andrii Vladyka <tulup@mail.ru>
+Date: Thu, 4 Jan 2018 13:09:17 +0200
+Subject: net: core: fix module type in sock_diag_bind
+
+From: Andrii Vladyka <tulup@mail.ru>
+
+
+[ Upstream commit b8fd0823e0770c2d5fdbd865bccf0d5e058e5287 ]
+
+Use AF_INET6 instead of AF_INET in IPv6-related code path
+
+Signed-off-by: Andrii Vladyka <tulup@mail.ru>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/sock_diag.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/core/sock_diag.c
++++ b/net/core/sock_diag.c
+@@ -289,7 +289,7 @@ static int sock_diag_bind(struct net *ne
+ case SKNLGRP_INET6_UDP_DESTROY:
+ if (!sock_diag_handlers[AF_INET6])
+ request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
+- NETLINK_SOCK_DIAG, AF_INET);
++ NETLINK_SOCK_DIAG, AF_INET6);
+ break;
+ }
+ return 0;
--- /dev/null
+From foo@baz Sat Jan 13 14:28:20 CET 2018
+From: Jerome Brunet <jbrunet@baylibre.com>
+Date: Wed, 3 Jan 2018 16:46:29 +0100
+Subject: net: stmmac: enable EEE in MII, GMII or RGMII only
+
+From: Jerome Brunet <jbrunet@baylibre.com>
+
+
+[ Upstream commit 879626e3a52630316d817cbda7cec9a5446d1d82 ]
+
+Note in the databook - Section 4.4 - EEE :
+" The EEE feature is not supported when the MAC is configured to use the
+TBI, RTBI, SMII, RMII or SGMII single PHY interface. Even if the MAC
+supports multiple PHY interfaces, you should activate the EEE mode only
+when the MAC is operating with GMII, MII, or RGMII interface."
+
+Applying this restriction solves a stability issue observed on Amlogic
+gxl platforms operating with RMII interface and the internal PHY.
+
+Fixes: 83bf79b6bb64 ("stmmac: disable at run-time the EEE if not supported")
+Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
+Tested-by: Arnaud Patard <arnaud.patard@rtp-net.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++++
+ include/linux/phy.h | 11 +++++++++++
+ 2 files changed, 17 insertions(+)
+
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+@@ -272,8 +272,14 @@ bool stmmac_eee_init(struct stmmac_priv
+ {
+ char *phy_bus_name = priv->plat->phy_bus_name;
+ unsigned long flags;
++ int interface = priv->plat->interface;
+ bool ret = false;
+
++ if ((interface != PHY_INTERFACE_MODE_MII) &&
++ (interface != PHY_INTERFACE_MODE_GMII) &&
++ !phy_interface_mode_is_rgmii(interface))
++ goto out;
++
+ /* Using PCS we cannot dial with the phy registers at this stage
+ * so we do not support extra feature like EEE.
+ */
+--- a/include/linux/phy.h
++++ b/include/linux/phy.h
+@@ -683,6 +683,17 @@ static inline bool phy_is_internal(struc
+ }
+
+ /**
++ * phy_interface_mode_is_rgmii - Convenience function for testing if a
++ * PHY interface mode is RGMII (all variants)
++ * @mode: the phy_interface_t enum
++ */
++static inline bool phy_interface_mode_is_rgmii(phy_interface_t mode)
++{
++ return mode >= PHY_INTERFACE_MODE_RGMII &&
++ mode <= PHY_INTERFACE_MODE_RGMII_TXID;
++};
++
++/**
+ * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
+ * is RGMII (all variants)
+ * @phydev: the phy_device struct
--- /dev/null
+From foo@baz Sat Jan 13 14:28:20 CET 2018
+From: Mohamed Ghannam <simo.ghannam@gmail.com>
+Date: Tue, 2 Jan 2018 19:44:34 +0000
+Subject: RDS: Heap OOB write in rds_message_alloc_sgs()
+
+From: Mohamed Ghannam <simo.ghannam@gmail.com>
+
+
+[ Upstream commit c095508770aebf1b9218e77026e48345d719b17c ]
+
+When args->nr_local is 0, nr_pages gets also 0 due some size
+calculation via rds_rm_size(), which is later used to allocate
+pages for DMA, this bug produces a heap Out-Of-Bound write access
+to a specific memory region.
+
+Signed-off-by: Mohamed Ghannam <simo.ghannam@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/rds/rdma.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/rds/rdma.c
++++ b/net/rds/rdma.c
+@@ -517,6 +517,9 @@ int rds_rdma_extra_size(struct rds_rdma_
+
+ local_vec = (struct rds_iovec __user *)(unsigned long) args->local_vec_addr;
+
++ if (args->nr_local == 0)
++ return -EINVAL;
++
+ /* figure out the number of pages in the vector */
+ for (i = 0; i < args->nr_local; i++) {
+ if (copy_from_user(&vec, &local_vec[i],
--- /dev/null
+From foo@baz Sat Jan 13 14:28:20 CET 2018
+From: Mohamed Ghannam <simo.ghannam@gmail.com>
+Date: Wed, 3 Jan 2018 21:06:06 +0000
+Subject: RDS: null pointer dereference in rds_atomic_free_op
+
+From: Mohamed Ghannam <simo.ghannam@gmail.com>
+
+
+[ Upstream commit 7d11f77f84b27cef452cee332f4e469503084737 ]
+
+set rm->atomic.op_active to 0 when rds_pin_pages() fails
+or the user supplied address is invalid,
+this prevents a NULL pointer usage in rds_atomic_free_op()
+
+Signed-off-by: Mohamed Ghannam <simo.ghannam@gmail.com>
+Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/rds/rdma.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/rds/rdma.c
++++ b/net/rds/rdma.c
+@@ -869,6 +869,7 @@ int rds_cmsg_atomic(struct rds_sock *rs,
+ err:
+ if (page)
+ put_page(page);
++ rm->atomic.op_active = 0;
+ kfree(rm->atomic.op_notifier);
+
+ return ret;
xhci-fix-ring-leak-in-failure-path-of-xhci_alloc_virt_device.patch
revert-userfaultfd-selftest-vm-allow-to-build-in-vm.patch
x86-pti-efi-broken-conversion-from-efi-to-kernel-page-table.patch
+8021q-fix-a-memory-leak-for-vlan-0-device.patch
+ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch
+net-core-fix-module-type-in-sock_diag_bind.patch
+rds-heap-oob-write-in-rds_message_alloc_sgs.patch
+rds-null-pointer-dereference-in-rds_atomic_free_op.patch
+sh_eth-fix-tsu-resource-handling.patch
+sh_eth-fix-sh7757-gether-initialization.patch
+net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch
+ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch
--- /dev/null
+From foo@baz Sat Jan 13 14:28:20 CET 2018
+From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+Date: Thu, 4 Jan 2018 21:06:49 +0300
+Subject: sh_eth: fix SH7757 GEther initialization
+
+From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+
+
+[ Upstream commit 5133550296d43236439494aa955bfb765a89f615 ]
+
+Renesas SH7757 has 2 Fast and 2 Gigabit Ether controllers, while the
+'sh_eth' driver can only reset and initialize TSU of the first controller
+pair. Shimoda-san tried to solve that adding the 'needs_init' member to the
+'struct sh_eth_plat_data', however the platform code still never sets this
+flag. I think that we can infer this information from the 'devno' variable
+(set to 'platform_device::id') and reset/init the Ether controller pair
+only for an even 'devno'; therefore 'sh_eth_plat_data::needs_init' can be
+removed...
+
+Fixes: 150647fb2c31 ("net: sh_eth: change the condition of initialization")
+Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/renesas/sh_eth.c | 4 ++--
+ include/linux/sh_eth.h | 1 -
+ 2 files changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/renesas/sh_eth.c
++++ b/drivers/net/ethernet/renesas/sh_eth.c
+@@ -3205,8 +3205,8 @@ static int sh_eth_drv_probe(struct platf
+ ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER;
+ }
+
+- /* initialize first or needed device */
+- if (!devno || pd->needs_init) {
++ /* Need to init only the first port of the two sharing a TSU */
++ if (devno % 2 == 0) {
+ if (mdp->cd->chip_reset)
+ mdp->cd->chip_reset(ndev);
+
+--- a/include/linux/sh_eth.h
++++ b/include/linux/sh_eth.h
+@@ -16,7 +16,6 @@ struct sh_eth_plat_data {
+ unsigned char mac_addr[ETH_ALEN];
+ unsigned no_ether_link:1;
+ unsigned ether_link_active_low:1;
+- unsigned needs_init:1;
+ };
+
+ #endif
--- /dev/null
+From foo@baz Sat Jan 13 14:28:20 CET 2018
+From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+Date: Wed, 3 Jan 2018 20:09:49 +0300
+Subject: sh_eth: fix TSU resource handling
+
+From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+
+
+[ Upstream commit dfe8266b8dd10e12a731c985b725fcf7f0e537f0 ]
+
+When switching the driver to the managed device API, I managed to break
+the case of a dual Ether devices sharing a single TSU: the 2nd Ether port
+wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy
+and he then dropped the ball...
+
+The solution is to limit calling devm_request_mem_region() to the first
+of the two ports sharing the same TSU, so devm_ioremap_resource() can't
+be used anymore for the TSU resource...
+
+Fixes: d5e07e69218f ("sh_eth: use managed device API")
+Reported-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
+Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/renesas/sh_eth.c | 25 ++++++++++++++++++++++---
+ 1 file changed, 22 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/renesas/sh_eth.c
++++ b/drivers/net/ethernet/renesas/sh_eth.c
+@@ -3176,10 +3176,29 @@ static int sh_eth_drv_probe(struct platf
+ /* ioremap the TSU registers */
+ if (mdp->cd->tsu) {
+ struct resource *rtsu;
++
+ rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+- mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu);
+- if (IS_ERR(mdp->tsu_addr)) {
+- ret = PTR_ERR(mdp->tsu_addr);
++ if (!rtsu) {
++ dev_err(&pdev->dev, "no TSU resource\n");
++ ret = -ENODEV;
++ goto out_release;
++ }
++ /* We can only request the TSU region for the first port
++ * of the two sharing this TSU for the probe to succeed...
++ */
++ if (devno % 2 == 0 &&
++ !devm_request_mem_region(&pdev->dev, rtsu->start,
++ resource_size(rtsu),
++ dev_name(&pdev->dev))) {
++ dev_err(&pdev->dev, "can't request TSU resource.\n");
++ ret = -EBUSY;
++ goto out_release;
++ }
++ mdp->tsu_addr = devm_ioremap(&pdev->dev, rtsu->start,
++ resource_size(rtsu));
++ if (!mdp->tsu_addr) {
++ dev_err(&pdev->dev, "TSU region ioremap() failed.\n");
++ ret = -ENOMEM;
+ goto out_release;
+ }
+ mdp->port = devno % 2;
projects / thirdparty / kernel / stable-queue.git / commitdiff
