--- /dev/null
+From foo@baz Sat Jan 13 15:16:15 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 9a00674213a3f00394f4e3221b88f2d21fc05789 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 29 Dec 2017 14:30:19 -0600
+Subject: crypto: algapi - fix NULL dereference in crypto_remove_spawns()
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 9a00674213a3f00394f4e3221b88f2d21fc05789 upstream.
+
+syzkaller triggered a NULL pointer dereference in crypto_remove_spawns()
+via a program that repeatedly and concurrently requests AEADs
+"authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)"
+through AF_ALG, where the hashes are requested as "untested"
+(CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this
+causes the template to be instantiated for every request).
+
+Although AF_ALG users really shouldn't be able to request an "untested"
+algorithm, the NULL pointer dereference is actually caused by a
+longstanding race condition where crypto_remove_spawns() can encounter
+an instance which has had spawn(s) "grabbed" but hasn't yet been
+registered, resulting in ->cra_users still being NULL.
+
+We probably should properly initialize ->cra_users earlier, but that
+would require updating many templates individually. For now just fix
+the bug in a simple way that can easily be backported: make
+crypto_remove_spawns() treat a NULL ->cra_users list as empty.
+
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/algapi.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/crypto/algapi.c
++++ b/crypto/algapi.c
+@@ -159,6 +159,18 @@ void crypto_remove_spawns(struct crypto_
+
+ spawn->alg = NULL;
+ spawns = &inst->alg.cra_users;
++
++ /*
++ * We may encounter an unregistered instance here, since
++ * an instance's spawns are set up prior to the instance
++ * being registered. An unregistered instance will have
++ * NULL ->cra_users.next, since ->cra_users isn't
++ * properly initialized until registration. But an
++ * unregistered instance cannot have any users, so treat
++ * it the same as ->cra_users being empty.
++ */
++ if (spawns->next == NULL)
++ break;
+ }
+ } while ((spawns = crypto_more_spawns(alg, &stack, &top,
+ &secondary_spawns)));
--- /dev/null
+From foo@baz Sat Jan 13 15:16:15 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
+@@ -277,8 +277,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
+@@ -678,6 +678,17 @@ static inline int phy_write_mmd(struct p
+ }
+
+ /**
++ * 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_write_mmd_indirect - writes data to the MMD registers
+ * @phydev: The PHY device
+ * @prtad: MMD Address
--- /dev/null
+From foo@baz Sat Jan 13 15:16:15 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
+@@ -516,6 +516,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 15:16:15 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
+@@ -866,6 +866,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;
alsa-aloop-fix-inconsistent-format-due-to-incomplete-rule.patch
alsa-aloop-fix-racy-hw-constraints-adjustment.patch
x86-acpi-reduce-code-duplication-in-mp_override_legacy_irq.patch
+8021q-fix-a-memory-leak-for-vlan-0-device.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
+crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch
+x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch
--- /dev/null
+From foo@baz Sat Jan 13 15:16:15 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
+@@ -2919,8 +2919,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 15:16:15 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
+@@ -2890,10 +2890,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;
--- /dev/null
+From b94b7373317164402ff7728d10f7023127a02b60 Mon Sep 17 00:00:00 2001
+From: Jia Zhang <qianyue.zj@alibaba-inc.com>
+Date: Mon, 1 Jan 2018 10:04:47 +0800
+Subject: x86/microcode/intel: Extend BDW late-loading with a revision check
+
+From: Jia Zhang <qianyue.zj@alibaba-inc.com>
+
+commit b94b7373317164402ff7728d10f7023127a02b60 upstream.
+
+Instead of blacklisting all model 79 CPUs when attempting a late
+microcode loading, limit that only to CPUs with microcode revisions <
+0x0b000021 because only on those late loading may cause a system hang.
+
+For such processors either:
+
+a) a BIOS update which might contain a newer microcode revision
+
+or
+
+b) the early microcode loading method
+
+should be considered.
+
+Processors with revisions 0x0b000021 or higher will not experience such
+hangs.
+
+For more details, see erratum BDF90 in document #334165 (Intel Xeon
+Processor E7-8800/4800 v4 Product Family Specification Update) from
+September 2017.
+
+[ bp: Heavily massage commit message and pr_* statements. ]
+
+Fixes: 723f2828a98c ("x86/microcode/intel: Disable late loading on model 79")
+Signed-off-by: Jia Zhang <qianyue.zj@alibaba-inc.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Tony Luck <tony.luck@intel.com>
+Cc: x86-ml <x86@kernel.org>
+Link: http://lkml.kernel.org/r/1514772287-92959-1-git-send-email-qianyue.zj@alibaba-inc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/microcode/intel.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/cpu/microcode/intel.c
++++ b/arch/x86/kernel/cpu/microcode/intel.c
+@@ -271,8 +271,17 @@ static bool is_blacklisted(unsigned int
+ {
+ struct cpuinfo_x86 *c = &cpu_data(cpu);
+
+- if (c->x86 == 6 && c->x86_model == 79) {
+- pr_err_once("late loading on model 79 is disabled.\n");
++ /*
++ * Late loading on model 79 with microcode revision less than 0x0b000021
++ * may result in a system hang. This behavior is documented in item
++ * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family).
++ */
++ if (c->x86 == 6 &&
++ c->x86_model == 79 &&
++ c->x86_mask == 0x01 &&
++ c->microcode < 0x0b000021) {
++ pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode);
++ pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n");
+ return true;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
