From: Greg Kroah-Hartman Date: Mon, 24 Dec 2018 11:57:49 +0000 (+0100) Subject: 3.18-stable patches X-Git-Tag: v4.19.13~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d4e8d7de1bcb24f3e0c8193852cf19b17a1ec2c7;p=thirdparty%2Fkernel%2Fstable-queue.git 3.18-stable patches added patches: drivers-hv-vmbus-return-einval-for-the-sys-files-for-unopened-channels.patch gpio-max7301-fix-driver-for-use-with-config_vmap_stack.patch mmc-core-reset-hpi-enabled-state-during-re-init-and-in-case-of-errors.patch mmc-omap_hsmmc-fix-dma-api-warning.patch x86-mtrr-don-t-copy-uninitialized-gentry-fields-back-to-userspace.patch --- diff --git a/queue-3.18/drivers-hv-vmbus-return-einval-for-the-sys-files-for-unopened-channels.patch b/queue-3.18/drivers-hv-vmbus-return-einval-for-the-sys-files-for-unopened-channels.patch new file mode 100644 index 00000000000..91f99c41823 --- /dev/null +++ b/queue-3.18/drivers-hv-vmbus-return-einval-for-the-sys-files-for-unopened-channels.patch @@ -0,0 +1,119 @@ +From fc96df16a1ce80cbb3c316ab7d4dc8cd5c2852ce Mon Sep 17 00:00:00 2001 +From: Dexuan Cui +Date: Thu, 13 Dec 2018 16:35:43 +0000 +Subject: Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels + +From: Dexuan Cui + +commit fc96df16a1ce80cbb3c316ab7d4dc8cd5c2852ce upstream. + +Before 98f4c651762c, we returned zeros for unopened channels. +With 98f4c651762c, we started to return random on-stack values. + +We'd better return -EINVAL instead. + +Fixes: 98f4c651762c ("hv: move ringbuffer bus attributes to dev_groups") +Cc: stable@vger.kernel.org +Cc: K. Y. Srinivasan +Cc: Haiyang Zhang +Cc: Stephen Hemminger +Signed-off-by: Dexuan Cui +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hv/vmbus_drv.c | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +--- a/drivers/hv/vmbus_drv.c ++++ b/drivers/hv/vmbus_drv.c +@@ -258,6 +258,8 @@ static ssize_t out_intr_mask_show(struct + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + return sprintf(buf, "%d\n", outbound.current_interrupt_mask); + } +@@ -271,6 +273,8 @@ static ssize_t out_read_index_show(struc + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + return sprintf(buf, "%d\n", outbound.current_read_index); + } +@@ -285,6 +289,8 @@ static ssize_t out_write_index_show(stru + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + return sprintf(buf, "%d\n", outbound.current_write_index); + } +@@ -299,6 +305,8 @@ static ssize_t out_read_bytes_avail_show + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + return sprintf(buf, "%d\n", outbound.bytes_avail_toread); + } +@@ -313,6 +321,8 @@ static ssize_t out_write_bytes_avail_sho + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + return sprintf(buf, "%d\n", outbound.bytes_avail_towrite); + } +@@ -326,6 +336,8 @@ static ssize_t in_intr_mask_show(struct + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + return sprintf(buf, "%d\n", inbound.current_interrupt_mask); + } +@@ -339,6 +351,8 @@ static ssize_t in_read_index_show(struct + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + return sprintf(buf, "%d\n", inbound.current_read_index); + } +@@ -352,6 +366,8 @@ static ssize_t in_write_index_show(struc + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + return sprintf(buf, "%d\n", inbound.current_write_index); + } +@@ -366,6 +382,8 @@ static ssize_t in_read_bytes_avail_show( + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + return sprintf(buf, "%d\n", inbound.bytes_avail_toread); + } +@@ -380,6 +398,8 @@ static ssize_t in_write_bytes_avail_show + + if (!hv_dev->channel) + return -ENODEV; ++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE) ++ return -EINVAL; + hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + return sprintf(buf, "%d\n", inbound.bytes_avail_towrite); + } diff --git a/queue-3.18/gpio-max7301-fix-driver-for-use-with-config_vmap_stack.patch b/queue-3.18/gpio-max7301-fix-driver-for-use-with-config_vmap_stack.patch new file mode 100644 index 00000000000..d859a75d776 --- /dev/null +++ b/queue-3.18/gpio-max7301-fix-driver-for-use-with-config_vmap_stack.patch @@ -0,0 +1,54 @@ +From abf221d2f51b8ce7b9959a8953f880a8b0a1400d Mon Sep 17 00:00:00 2001 +From: Christophe Leroy +Date: Fri, 7 Dec 2018 13:07:55 +0000 +Subject: gpio: max7301: fix driver for use with CONFIG_VMAP_STACK + +From: Christophe Leroy + +commit abf221d2f51b8ce7b9959a8953f880a8b0a1400d upstream. + +spi_read() and spi_write() require DMA-safe memory. When +CONFIG_VMAP_STACK is selected, those functions cannot be used +with buffers on stack. + +This patch replaces calls to spi_read() and spi_write() by +spi_write_then_read() which doesn't require DMA-safe buffers. + +Fixes: 0c36ec314735 ("gpio: gpio driver for max7301 SPI GPIO expander") +Cc: +Signed-off-by: Christophe Leroy +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpio-max7301.c | 12 +++--------- + 1 file changed, 3 insertions(+), 9 deletions(-) + +--- a/drivers/gpio/gpio-max7301.c ++++ b/drivers/gpio/gpio-max7301.c +@@ -25,7 +25,7 @@ static int max7301_spi_write(struct devi + struct spi_device *spi = to_spi_device(dev); + u16 word = ((reg & 0x7F) << 8) | (val & 0xFF); + +- return spi_write(spi, (const u8 *)&word, sizeof(word)); ++ return spi_write_then_read(spi, &word, sizeof(word), NULL, 0); + } + + /* A read from the MAX7301 means two transfers; here, one message each */ +@@ -37,14 +37,8 @@ static int max7301_spi_read(struct devic + struct spi_device *spi = to_spi_device(dev); + + word = 0x8000 | (reg << 8); +- ret = spi_write(spi, (const u8 *)&word, sizeof(word)); +- if (ret) +- return ret; +- /* +- * This relies on the fact, that a transfer with NULL tx_buf shifts out +- * zero bytes (=NOOP for MAX7301) +- */ +- ret = spi_read(spi, (u8 *)&word, sizeof(word)); ++ ret = spi_write_then_read(spi, &word, sizeof(word), &word, ++ sizeof(word)); + if (ret) + return ret; + return word & 0xff; diff --git a/queue-3.18/mmc-core-reset-hpi-enabled-state-during-re-init-and-in-case-of-errors.patch b/queue-3.18/mmc-core-reset-hpi-enabled-state-during-re-init-and-in-case-of-errors.patch new file mode 100644 index 00000000000..f24897cc5ae --- /dev/null +++ b/queue-3.18/mmc-core-reset-hpi-enabled-state-during-re-init-and-in-case-of-errors.patch @@ -0,0 +1,38 @@ +From a0741ba40a009f97c019ae7541dc61c1fdf41efb Mon Sep 17 00:00:00 2001 +From: Ulf Hansson +Date: Mon, 10 Dec 2018 17:52:36 +0100 +Subject: mmc: core: Reset HPI enabled state during re-init and in case of errors + +From: Ulf Hansson + +commit a0741ba40a009f97c019ae7541dc61c1fdf41efb upstream. + +During a re-initialization of the eMMC card, we may fail to re-enable HPI. +In these cases, that isn't properly reflected in the card->ext_csd.hpi_en +bit, as it keeps being set. This may cause following attempts to use HPI, +even if's not enabled. Let's fix this! + +Fixes: eb0d8f135b67 ("mmc: core: support HPI send command") +Cc: +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/mmc.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/mmc/core/mmc.c ++++ b/drivers/mmc/core/mmc.c +@@ -1485,9 +1485,11 @@ static int mmc_init_card(struct mmc_host + if (err) { + pr_warn("%s: Enabling HPI failed\n", + mmc_hostname(card->host)); ++ card->ext_csd.hpi_en = 0; + err = 0; +- } else ++ } else { + card->ext_csd.hpi_en = 1; ++ } + } + + /* diff --git a/queue-3.18/mmc-omap_hsmmc-fix-dma-api-warning.patch b/queue-3.18/mmc-omap_hsmmc-fix-dma-api-warning.patch new file mode 100644 index 00000000000..3a3716f9eb3 --- /dev/null +++ b/queue-3.18/mmc-omap_hsmmc-fix-dma-api-warning.patch @@ -0,0 +1,66 @@ +From 0b479790684192ab7024ce6a621f93f6d0a64d92 Mon Sep 17 00:00:00 2001 +From: Russell King +Date: Tue, 11 Dec 2018 14:41:31 +0000 +Subject: mmc: omap_hsmmc: fix DMA API warning + +From: Russell King + +commit 0b479790684192ab7024ce6a621f93f6d0a64d92 upstream. + +While booting with rootfs on MMC, the following warning is encountered +on OMAP4430: + +omap-dma-engine 4a056000.dma-controller: DMA-API: mapping sg segment longer than device claims to support [len=69632] [max=65536] + +This is because the DMA engine has a default maximum segment size of 64K +but HSMMC sets: + + mmc->max_blk_size = 512; /* Block Length at max can be 1024 */ + mmc->max_blk_count = 0xFFFF; /* No. of Blocks is 16 bits */ + mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count; + mmc->max_seg_size = mmc->max_req_size; + +which ends up telling the block layer that we support a maximum segment +size of 65535*512, which exceeds the advertised DMA engine capabilities. + +Fix this by clamping the maximum segment size to the lower of the +maximum request size and of the DMA engine device used for either DMA +channel. + +Signed-off-by: Russell King +Cc: +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/omap_hsmmc.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/drivers/mmc/host/omap_hsmmc.c ++++ b/drivers/mmc/host/omap_hsmmc.c +@@ -2141,7 +2141,6 @@ static int omap_hsmmc_probe(struct platf + mmc->max_blk_size = 512; /* Block Length at max can be 1024 */ + mmc->max_blk_count = 0xFFFF; /* No. of Blocks is 16 bits */ + mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count; +- mmc->max_seg_size = mmc->max_req_size; + + mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED | + MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_ERASE; +@@ -2198,6 +2197,17 @@ static int omap_hsmmc_probe(struct platf + goto err_irq; + } + ++ /* ++ * Limit the maximum segment size to the lower of the request size ++ * and the DMA engine device segment size limits. In reality, with ++ * 32-bit transfers, the DMA engine can do longer segments than this ++ * but there is no way to represent that in the DMA model - if we ++ * increase this figure here, we get warnings from the DMA API debug. ++ */ ++ mmc->max_seg_size = min3(mmc->max_req_size, ++ dma_get_max_seg_size(host->rx_chan->device->dev), ++ dma_get_max_seg_size(host->tx_chan->device->dev)); ++ + /* Request IRQ for MMC operations */ + ret = devm_request_irq(&pdev->dev, host->irq, omap_hsmmc_irq, 0, + mmc_hostname(mmc), host); diff --git a/queue-3.18/series b/queue-3.18/series index e539eee2397..0826bbeebdf 100644 --- a/queue-3.18/series +++ b/queue-3.18/series @@ -1,2 +1,7 @@ usb-hso-fix-oob-memory-access-in-hso_probe-hso_get_config_data.patch usb-serial-option-add-hp-lt4132.patch +mmc-core-reset-hpi-enabled-state-during-re-init-and-in-case-of-errors.patch +mmc-omap_hsmmc-fix-dma-api-warning.patch +gpio-max7301-fix-driver-for-use-with-config_vmap_stack.patch +drivers-hv-vmbus-return-einval-for-the-sys-files-for-unopened-channels.patch +x86-mtrr-don-t-copy-uninitialized-gentry-fields-back-to-userspace.patch diff --git a/queue-3.18/x86-mtrr-don-t-copy-uninitialized-gentry-fields-back-to-userspace.patch b/queue-3.18/x86-mtrr-don-t-copy-uninitialized-gentry-fields-back-to-userspace.patch new file mode 100644 index 00000000000..faaa21c1a8a --- /dev/null +++ b/queue-3.18/x86-mtrr-don-t-copy-uninitialized-gentry-fields-back-to-userspace.patch @@ -0,0 +1,41 @@ +From 32043fa065b51e0b1433e48d118821c71b5cd65d Mon Sep 17 00:00:00 2001 +From: Colin Ian King +Date: Tue, 18 Dec 2018 17:29:56 +0000 +Subject: x86/mtrr: Don't copy uninitialized gentry fields back to userspace + +From: Colin Ian King + +commit 32043fa065b51e0b1433e48d118821c71b5cd65d upstream. + +Currently the copy_to_user of data in the gentry struct is copying +uninitiaized data in field _pad from the stack to userspace. + +Fix this by explicitly memset'ing gentry to zero, this also will zero any +compiler added padding fields that may be in struct (currently there are +none). + +Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable") + +Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit ioctls") +Signed-off-by: Colin Ian King +Signed-off-by: Thomas Gleixner +Reviewed-by: Tyler Hicks +Cc: security@kernel.org +Link: https://lkml.kernel.org/r/20181218172956.1440-1-colin.king@canonical.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/mtrr/if.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/x86/kernel/cpu/mtrr/if.c ++++ b/arch/x86/kernel/cpu/mtrr/if.c +@@ -173,6 +173,8 @@ mtrr_ioctl(struct file *file, unsigned i + struct mtrr_gentry gentry; + void __user *arg = (void __user *) __arg; + ++ memset(&gentry, 0, sizeof(gentry)); ++ + switch (cmd) { + case MTRRIOC_ADD_ENTRY: + case MTRRIOC_SET_ENTRY: