--- /dev/null
+From fc96df16a1ce80cbb3c316ab7d4dc8cd5c2852ce Mon Sep 17 00:00:00 2001
+From: Dexuan Cui <decui@microsoft.com>
+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 <decui@microsoft.com>
+
+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 <kys@microsoft.com>
+Cc: Haiyang Zhang <haiyangz@microsoft.com>
+Cc: Stephen Hemminger <sthemmin@microsoft.com>
+Signed-off-by: Dexuan Cui <decui@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hv/vmbus_drv.c | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+--- a/drivers/hv/vmbus_drv.c
++++ b/drivers/hv/vmbus_drv.c
+@@ -300,6 +300,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);
+ }
+@@ -313,6 +315,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);
+ }
+@@ -327,6 +331,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);
+ }
+@@ -341,6 +347,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);
+ }
+@@ -355,6 +363,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);
+ }
+@@ -368,6 +378,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);
+ }
+@@ -381,6 +393,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);
+ }
+@@ -394,6 +408,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);
+ }
+@@ -408,6 +424,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);
+ }
+@@ -422,6 +440,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);
+ }
--- /dev/null
+From abf221d2f51b8ce7b9959a8953f880a8b0a1400d Mon Sep 17 00:00:00 2001
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+Date: Fri, 7 Dec 2018 13:07:55 +0000
+Subject: gpio: max7301: fix driver for use with CONFIG_VMAP_STACK
+
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+
+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: <stable@vger.kernel.org>
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From e59f5e08ece1060073d92c66ded52e1f2c43b5bb Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 28 Nov 2018 17:57:55 +0100
+Subject: gpiolib-acpi: Only defer request_irq for GpioInt ACPI event handlers
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit e59f5e08ece1060073d92c66ded52e1f2c43b5bb upstream.
+
+Commit 78d3a92edbfb ("gpiolib-acpi: Register GpioInt ACPI event handlers
+from a late_initcall") deferred the entire acpi_gpiochip_request_interrupt
+call for each event resource.
+
+This means it also delays the gpiochip_request_own_desc(..., "ACPI:Event")
+call. This is a problem if some AML code reads the GPIO pin before we
+run the deferred acpi_gpiochip_request_interrupt, because in that case
+acpi_gpio_adr_space_handler() will already have called
+gpiochip_request_own_desc(..., "ACPI:OpRegion") causing the call from
+acpi_gpiochip_request_interrupt to fail with -EBUSY and we will fail to
+register an event handler.
+
+acpi_gpio_adr_space_handler is prepared for acpi_gpiochip_request_interrupt
+already having claimed the pin, but the other way around does not work.
+
+One example of a problem this causes, is the event handler for the OTG
+ID pin on a Prowise PT301 tablet not registering, keeping the port stuck
+in whatever mode it was in during boot and e.g. only allowing charging
+after a reboot.
+
+This commit fixes this by only deferring the request_irq call and the
+initial run of edge-triggered IRQs instead of deferring all of
+acpi_gpiochip_request_interrupt.
+
+Cc: stable@vger.kernel.org
+Fixes: 78d3a92edbfb ("gpiolib-acpi: Register GpioInt ACPI event ...")
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib-acpi.c | 144 +++++++++++++++++++++++++-------------------
+ 1 file changed, 84 insertions(+), 60 deletions(-)
+
+--- a/drivers/gpio/gpiolib-acpi.c
++++ b/drivers/gpio/gpiolib-acpi.c
+@@ -23,11 +23,28 @@
+
+ #include "gpiolib.h"
+
++/**
++ * struct acpi_gpio_event - ACPI GPIO event handler data
++ *
++ * @node: list-entry of the events list of the struct acpi_gpio_chip
++ * @handle: handle of ACPI method to execute when the IRQ triggers
++ * @handler: irq_handler to pass to request_irq when requesting the IRQ
++ * @pin: GPIO pin number on the gpio_chip
++ * @irq: Linux IRQ number for the event, for request_ / free_irq
++ * @irqflags: flags to pass to request_irq when requesting the IRQ
++ * @irq_is_wake: If the ACPI flags indicate the IRQ is a wakeup source
++ * @is_requested: True if request_irq has been done
++ * @desc: gpio_desc for the GPIO pin for this event
++ */
+ struct acpi_gpio_event {
+ struct list_head node;
+ acpi_handle handle;
++ irq_handler_t handler;
+ unsigned int pin;
+ unsigned int irq;
++ unsigned long irqflags;
++ bool irq_is_wake;
++ bool irq_requested;
+ struct gpio_desc *desc;
+ };
+
+@@ -53,10 +70,10 @@ struct acpi_gpio_chip {
+
+ /*
+ * For gpiochips which call acpi_gpiochip_request_interrupts() before late_init
+- * (so builtin drivers) we register the ACPI GpioInt event handlers from a
++ * (so builtin drivers) we register the ACPI GpioInt IRQ handlers from a
+ * late_initcall_sync handler, so that other builtin drivers can register their
+ * OpRegions before the event handlers can run. This list contains gpiochips
+- * for which the acpi_gpiochip_request_interrupts() has been deferred.
++ * for which the acpi_gpiochip_request_irqs() call has been deferred.
+ */
+ static DEFINE_MUTEX(acpi_gpio_deferred_req_irqs_lock);
+ static LIST_HEAD(acpi_gpio_deferred_req_irqs_list);
+@@ -194,8 +211,42 @@ bool acpi_gpio_get_irq_resource(struct a
+ }
+ EXPORT_SYMBOL_GPL(acpi_gpio_get_irq_resource);
+
+-static acpi_status acpi_gpiochip_request_interrupt(struct acpi_resource *ares,
+- void *context)
++static void acpi_gpiochip_request_irq(struct acpi_gpio_chip *acpi_gpio,
++ struct acpi_gpio_event *event)
++{
++ int ret, value;
++
++ ret = request_threaded_irq(event->irq, NULL, event->handler,
++ event->irqflags, "ACPI:Event", event);
++ if (ret) {
++ dev_err(acpi_gpio->chip->parent,
++ "Failed to setup interrupt handler for %d\n",
++ event->irq);
++ return;
++ }
++
++ if (event->irq_is_wake)
++ enable_irq_wake(event->irq);
++
++ event->irq_requested = true;
++
++ /* Make sure we trigger the initial state of edge-triggered IRQs */
++ value = gpiod_get_raw_value_cansleep(event->desc);
++ if (((event->irqflags & IRQF_TRIGGER_RISING) && value == 1) ||
++ ((event->irqflags & IRQF_TRIGGER_FALLING) && value == 0))
++ event->handler(event->irq, event);
++}
++
++static void acpi_gpiochip_request_irqs(struct acpi_gpio_chip *acpi_gpio)
++{
++ struct acpi_gpio_event *event;
++
++ list_for_each_entry(event, &acpi_gpio->events, node)
++ acpi_gpiochip_request_irq(acpi_gpio, event);
++}
++
++static acpi_status acpi_gpiochip_alloc_event(struct acpi_resource *ares,
++ void *context)
+ {
+ struct acpi_gpio_chip *acpi_gpio = context;
+ struct gpio_chip *chip = acpi_gpio->chip;
+@@ -204,8 +255,7 @@ static acpi_status acpi_gpiochip_request
+ struct acpi_gpio_event *event;
+ irq_handler_t handler = NULL;
+ struct gpio_desc *desc;
+- unsigned long irqflags;
+- int ret, pin, irq, value;
++ int ret, pin, irq;
+
+ if (!acpi_gpio_get_irq_resource(ares, &agpio))
+ return AE_OK;
+@@ -240,8 +290,6 @@ static acpi_status acpi_gpiochip_request
+
+ gpiod_direction_input(desc);
+
+- value = gpiod_get_value_cansleep(desc);
+-
+ ret = gpiochip_lock_as_irq(chip, pin);
+ if (ret) {
+ dev_err(chip->parent, "Failed to lock GPIO as interrupt\n");
+@@ -254,64 +302,42 @@ static acpi_status acpi_gpiochip_request
+ goto fail_unlock_irq;
+ }
+
+- irqflags = IRQF_ONESHOT;
++ event = kzalloc(sizeof(*event), GFP_KERNEL);
++ if (!event)
++ goto fail_unlock_irq;
++
++ event->irqflags = IRQF_ONESHOT;
+ if (agpio->triggering == ACPI_LEVEL_SENSITIVE) {
+ if (agpio->polarity == ACPI_ACTIVE_HIGH)
+- irqflags |= IRQF_TRIGGER_HIGH;
++ event->irqflags |= IRQF_TRIGGER_HIGH;
+ else
+- irqflags |= IRQF_TRIGGER_LOW;
++ event->irqflags |= IRQF_TRIGGER_LOW;
+ } else {
+ switch (agpio->polarity) {
+ case ACPI_ACTIVE_HIGH:
+- irqflags |= IRQF_TRIGGER_RISING;
++ event->irqflags |= IRQF_TRIGGER_RISING;
+ break;
+ case ACPI_ACTIVE_LOW:
+- irqflags |= IRQF_TRIGGER_FALLING;
++ event->irqflags |= IRQF_TRIGGER_FALLING;
+ break;
+ default:
+- irqflags |= IRQF_TRIGGER_RISING |
+- IRQF_TRIGGER_FALLING;
++ event->irqflags |= IRQF_TRIGGER_RISING |
++ IRQF_TRIGGER_FALLING;
+ break;
+ }
+ }
+
+- event = kzalloc(sizeof(*event), GFP_KERNEL);
+- if (!event)
+- goto fail_unlock_irq;
+-
+ event->handle = evt_handle;
++ event->handler = handler;
+ event->irq = irq;
++ event->irq_is_wake = agpio->wake_capable == ACPI_WAKE_CAPABLE;
+ event->pin = pin;
+ event->desc = desc;
+
+- ret = request_threaded_irq(event->irq, NULL, handler, irqflags,
+- "ACPI:Event", event);
+- if (ret) {
+- dev_err(chip->parent,
+- "Failed to setup interrupt handler for %d\n",
+- event->irq);
+- goto fail_free_event;
+- }
+-
+- if (agpio->wake_capable == ACPI_WAKE_CAPABLE)
+- enable_irq_wake(irq);
+-
+ list_add_tail(&event->node, &acpi_gpio->events);
+
+- /*
+- * Make sure we trigger the initial state of the IRQ when using RISING
+- * or FALLING. Note we run the handlers on late_init, the AML code
+- * may refer to OperationRegions from other (builtin) drivers which
+- * may be probed after us.
+- */
+- if (((irqflags & IRQF_TRIGGER_RISING) && value == 1) ||
+- ((irqflags & IRQF_TRIGGER_FALLING) && value == 0))
+- handler(event->irq, event);
+-
+ return AE_OK;
+
+-fail_free_event:
+- kfree(event);
+ fail_unlock_irq:
+ gpiochip_unlock_as_irq(chip, pin);
+ fail_free_desc:
+@@ -348,6 +374,9 @@ void acpi_gpiochip_request_interrupts(st
+ if (ACPI_FAILURE(status))
+ return;
+
++ acpi_walk_resources(handle, "_AEI",
++ acpi_gpiochip_alloc_event, acpi_gpio);
++
+ mutex_lock(&acpi_gpio_deferred_req_irqs_lock);
+ defer = !acpi_gpio_deferred_req_irqs_done;
+ if (defer)
+@@ -358,8 +387,7 @@ void acpi_gpiochip_request_interrupts(st
+ if (defer)
+ return;
+
+- acpi_walk_resources(handle, "_AEI",
+- acpi_gpiochip_request_interrupt, acpi_gpio);
++ acpi_gpiochip_request_irqs(acpi_gpio);
+ }
+ EXPORT_SYMBOL_GPL(acpi_gpiochip_request_interrupts);
+
+@@ -396,10 +424,13 @@ void acpi_gpiochip_free_interrupts(struc
+ list_for_each_entry_safe_reverse(event, ep, &acpi_gpio->events, node) {
+ struct gpio_desc *desc;
+
+- if (irqd_is_wakeup_set(irq_get_irq_data(event->irq)))
+- disable_irq_wake(event->irq);
++ if (event->irq_requested) {
++ if (event->irq_is_wake)
++ disable_irq_wake(event->irq);
++
++ free_irq(event->irq, event);
++ }
+
+- free_irq(event->irq, event);
+ desc = event->desc;
+ if (WARN_ON(IS_ERR(desc)))
+ continue;
+@@ -1253,23 +1284,16 @@ bool acpi_can_fallback_to_crs(struct acp
+ return con_id == NULL;
+ }
+
+-/* Run deferred acpi_gpiochip_request_interrupts() */
+-static int acpi_gpio_handle_deferred_request_interrupts(void)
++/* Run deferred acpi_gpiochip_request_irqs() */
++static int acpi_gpio_handle_deferred_request_irqs(void)
+ {
+ struct acpi_gpio_chip *acpi_gpio, *tmp;
+
+ mutex_lock(&acpi_gpio_deferred_req_irqs_lock);
+ list_for_each_entry_safe(acpi_gpio, tmp,
+ &acpi_gpio_deferred_req_irqs_list,
+- deferred_req_irqs_list_entry) {
+- acpi_handle handle;
+-
+- handle = ACPI_HANDLE(acpi_gpio->chip->parent);
+- acpi_walk_resources(handle, "_AEI",
+- acpi_gpiochip_request_interrupt, acpi_gpio);
+-
+- list_del_init(&acpi_gpio->deferred_req_irqs_list_entry);
+- }
++ deferred_req_irqs_list_entry)
++ acpi_gpiochip_request_irqs(acpi_gpio);
+
+ acpi_gpio_deferred_req_irqs_done = true;
+ mutex_unlock(&acpi_gpio_deferred_req_irqs_lock);
+@@ -1277,4 +1301,4 @@ static int acpi_gpio_handle_deferred_req
+ return 0;
+ }
+ /* We must use _sync so that this runs after the first deferred_probe run */
+-late_initcall_sync(acpi_gpio_handle_deferred_request_interrupts);
++late_initcall_sync(acpi_gpio_handle_deferred_request_irqs);
--- /dev/null
+From c2dd5146e9fe1f22c77c1b011adf84eea0245806 Mon Sep 17 00:00:00 2001
+From: Cfir Cohen <cfir@google.com>
+Date: Tue, 18 Dec 2018 08:18:41 -0800
+Subject: KVM: Fix UAF in nested posted interrupt processing
+
+From: Cfir Cohen <cfir@google.com>
+
+commit c2dd5146e9fe1f22c77c1b011adf84eea0245806 upstream.
+
+nested_get_vmcs12_pages() processes the posted_intr address in vmcs12. It
+caches the kmap()ed page object and pointer, however, it doesn't handle
+errors correctly: it's possible to cache a valid pointer, then release
+the page and later dereference the dangling pointer.
+
+I was able to reproduce with the following steps:
+
+1. Call vmlaunch with valid posted_intr_desc_addr but an invalid
+MSR_EFER. This causes nested_get_vmcs12_pages() to cache the kmap()ed
+pi_desc_page and pi_desc. Later the invalid EFER value fails
+check_vmentry_postreqs() which fails the first vmlaunch.
+
+2. Call vmlanuch with a valid EFER but an invalid posted_intr_desc_addr
+(I set it to 2G - 0x80). The second time we call nested_get_vmcs12_pages
+pi_desc_page is unmapped and released and pi_desc_page is set to NULL
+(the "shouldn't happen" clause). Due to the invalid
+posted_intr_desc_addr, kvm_vcpu_gpa_to_page() fails and
+nested_get_vmcs12_pages() returns. It doesn't return an error value so
+vmlaunch proceeds. Note that at this time we have a dangling pointer in
+vmx->nested.pi_desc and POSTED_INTR_DESC_ADDR in L0's vmcs.
+
+3. Issue an IPI in L2 guest code. This triggers a call to
+vmx_complete_nested_posted_interrupt() and pi_test_and_clear_on() which
+dereferences the dangling pointer.
+
+Vulnerable code requires nested and enable_apicv variables to be set to
+true. The host CPU must also support posted interrupts.
+
+Fixes: 5e2f30b756a37 "KVM: nVMX: get rid of nested_get_page()"
+Cc: stable@vger.kernel.org
+Reviewed-by: Andy Honig <ahonig@google.com>
+Signed-off-by: Cfir Cohen <cfir@google.com>
+Reviewed-by: Liran Alon <liran.alon@oracle.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/vmx.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -10447,6 +10447,8 @@ static void nested_get_vmcs12_pages(stru
+ kunmap(vmx->nested.pi_desc_page);
+ kvm_release_page_dirty(vmx->nested.pi_desc_page);
+ vmx->nested.pi_desc_page = NULL;
++ vmx->nested.pi_desc = NULL;
++ vmcs_write64(POSTED_INTR_DESC_ADDR, -1ull);
+ }
+ page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->posted_intr_desc_addr);
+ if (is_error_page(page))
--- /dev/null
+From 0e1b869fff60c81b510c2d00602d778f8f59dd9a Mon Sep 17 00:00:00 2001
+From: Eduardo Habkost <ehabkost@redhat.com>
+Date: Mon, 17 Dec 2018 22:34:18 -0200
+Subject: kvm: x86: Add AMD's EX_CFG to the list of ignored MSRs
+
+From: Eduardo Habkost <ehabkost@redhat.com>
+
+commit 0e1b869fff60c81b510c2d00602d778f8f59dd9a upstream.
+
+Some guests OSes (including Windows 10) write to MSR 0xc001102c
+on some cases (possibly while trying to apply a CPU errata).
+Make KVM ignore reads and writes to that MSR, so the guest won't
+crash.
+
+The MSR is documented as "Execution Unit Configuration (EX_CFG)",
+at AMD's "BIOS and Kernel Developer's Guide (BKDG) for AMD Family
+15h Models 00h-0Fh Processors".
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/msr-index.h | 1 +
+ arch/x86/kvm/x86.c | 2 ++
+ 2 files changed, 3 insertions(+)
+
+--- a/arch/x86/include/asm/msr-index.h
++++ b/arch/x86/include/asm/msr-index.h
+@@ -372,6 +372,7 @@
+ #define MSR_F15H_NB_PERF_CTR 0xc0010241
+ #define MSR_F15H_PTSC 0xc0010280
+ #define MSR_F15H_IC_CFG 0xc0011021
++#define MSR_F15H_EX_CFG 0xc001102c
+
+ /* Fam 10h MSRs */
+ #define MSR_FAM10H_MMIO_CONF_BASE 0xc0010058
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -2227,6 +2227,7 @@ int kvm_set_msr_common(struct kvm_vcpu *
+ case MSR_AMD64_PATCH_LOADER:
+ case MSR_AMD64_BU_CFG2:
+ case MSR_AMD64_DC_CFG:
++ case MSR_F15H_EX_CFG:
+ break;
+
+ case MSR_IA32_UCODE_REV:
+@@ -2508,6 +2509,7 @@ int kvm_get_msr_common(struct kvm_vcpu *
+ case MSR_AMD64_BU_CFG2:
+ case MSR_IA32_PERF_CTL:
+ case MSR_AMD64_DC_CFG:
++ case MSR_F15H_EX_CFG:
+ msr_info->data = 0;
+ break;
+ case MSR_K7_EVNTSEL0 ... MSR_K7_EVNTSEL3:
--- /dev/null
+From ba9f39a785a9977e72233000711ef1eb48203551 Mon Sep 17 00:00:00 2001
+From: Ulf Hansson <ulf.hansson@linaro.org>
+Date: Mon, 10 Dec 2018 17:52:37 +0100
+Subject: mmc: core: Allow BKOPS and CACHE ctrl even if no HPI support
+
+From: Ulf Hansson <ulf.hansson@linaro.org>
+
+commit ba9f39a785a9977e72233000711ef1eb48203551 upstream.
+
+In commit 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC
+cards"), then intent was to prevent HPI from being used for some eMMC
+cards, which didn't properly support it. However, that went too far, as
+even BKOPS and CACHE ctrl became prevented. Let's restore those parts and
+allow BKOPS and CACHE ctrl even if HPI isn't supported.
+
+Fixes: 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC cards")
+Cc: Pratibhasagar V <pratibha@codeaurora.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/mmc.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/drivers/mmc/core/mmc.c
++++ b/drivers/mmc/core/mmc.c
+@@ -526,8 +526,7 @@ static int mmc_decode_ext_csd(struct mmc
+ card->cid.year += 16;
+
+ /* check whether the eMMC card supports BKOPS */
+- if (!mmc_card_broken_hpi(card) &&
+- ext_csd[EXT_CSD_BKOPS_SUPPORT] & 0x1) {
++ if (ext_csd[EXT_CSD_BKOPS_SUPPORT] & 0x1) {
+ card->ext_csd.bkops = 1;
+ card->ext_csd.man_bkops_en =
+ (ext_csd[EXT_CSD_BKOPS_EN] &
+@@ -1766,8 +1765,7 @@ static int mmc_init_card(struct mmc_host
+ * If cache size is higher than 0, this indicates
+ * the existence of cache and it can be turned on.
+ */
+- if (!mmc_card_broken_hpi(card) &&
+- card->ext_csd.cache_size > 0) {
++ if (card->ext_csd.cache_size > 0) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_CACHE_CTRL, 1,
+ card->ext_csd.generic_cmd6_time);
--- /dev/null
+From a0741ba40a009f97c019ae7541dc61c1fdf41efb Mon Sep 17 00:00:00 2001
+From: Ulf Hansson <ulf.hansson@linaro.org>
+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 <ulf.hansson@linaro.org>
+
+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: <stable@vger.kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1755,9 +1755,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;
++ }
+ }
+
+ /*
--- /dev/null
+From e3ae3401aa19432ee4943eb0bbc2ec704d07d793 Mon Sep 17 00:00:00 2001
+From: Ulf Hansson <ulf.hansson@linaro.org>
+Date: Mon, 10 Dec 2018 17:52:38 +0100
+Subject: mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl
+
+From: Ulf Hansson <ulf.hansson@linaro.org>
+
+commit e3ae3401aa19432ee4943eb0bbc2ec704d07d793 upstream.
+
+Some eMMCs from Micron have been reported to need ~800 ms timeout, while
+enabling the CACHE ctrl after running sudden power failure tests. The
+needed timeout is greater than what the card specifies as its generic CMD6
+timeout, through the EXT_CSD register, hence the problem.
+
+Normally we would introduce a card quirk to extend the timeout for these
+specific Micron cards. However, due to the rather complicated debug process
+needed to find out the error, let's simply use a minimum timeout of 1600ms,
+the double of what has been reported, for all cards when enabling CACHE
+ctrl.
+
+Reported-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
+Reported-by: Andreas Dannenberg <dannenberg@ti.com>
+Reported-by: Faiz Abbas <faiz_abbas@ti.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/mmc.c | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+--- a/drivers/mmc/core/mmc.c
++++ b/drivers/mmc/core/mmc.c
+@@ -30,6 +30,7 @@
+ #include "pwrseq.h"
+
+ #define DEFAULT_CMD6_TIMEOUT_MS 500
++#define MIN_CACHE_EN_TIMEOUT_MS 1600
+
+ static const unsigned int tran_exp[] = {
+ 10000, 100000, 1000000, 10000000,
+@@ -1762,13 +1763,18 @@ static int mmc_init_card(struct mmc_host
+ }
+
+ /*
+- * If cache size is higher than 0, this indicates
+- * the existence of cache and it can be turned on.
++ * If cache size is higher than 0, this indicates the existence of cache
++ * and it can be turned on. Note that some eMMCs from Micron has been
++ * reported to need ~800 ms timeout, while enabling the cache after
++ * sudden power failure tests. Let's extend the timeout to a minimum of
++ * DEFAULT_CACHE_EN_TIMEOUT_MS and do it for all cards.
+ */
+ if (card->ext_csd.cache_size > 0) {
++ unsigned int timeout_ms = MIN_CACHE_EN_TIMEOUT_MS;
++
++ timeout_ms = max(card->ext_csd.generic_cmd6_time, timeout_ms);
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+- EXT_CSD_CACHE_CTRL, 1,
+- card->ext_csd.generic_cmd6_time);
++ EXT_CSD_CACHE_CTRL, 1, timeout_ms);
+ if (err && err != -EBADMSG)
+ goto free_card;
+
--- /dev/null
+From 0b479790684192ab7024ce6a621f93f6d0a64d92 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@armlinux.org.uk>
+Date: Tue, 11 Dec 2018 14:41:31 +0000
+Subject: mmc: omap_hsmmc: fix DMA API warning
+
+From: Russell King <rmk+kernel@armlinux.org.uk>
+
+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 <rmk+kernel@armlinux.org.uk>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -2083,7 +2083,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 | MMC_CAP_CMD23;
+@@ -2113,6 +2112,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);
--- /dev/null
+From 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Mon, 17 Dec 2018 13:31:05 +0100
+Subject: posix-timers: Fix division by zero bug
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 upstream.
+
+The signal delivery path of posix-timers can try to rearm the timer even if
+the interval is zero. That's handled for the common case (hrtimer) but not
+for alarm timers. In that case the forwarding function raises a division by
+zero exception.
+
+The handling for hrtimer based posix timers is wrong because it marks the
+timer as active despite the fact that it is stopped.
+
+Move the check from common_hrtimer_rearm() to posixtimer_rearm() to cure
+both issues.
+
+Reported-by: syzbot+9d38bedac9cc77b8ad5e@syzkaller.appspotmail.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: sboyd@kernel.org
+Cc: stable@vger.kernel.org
+Cc: syzkaller-bugs@googlegroups.com
+Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1812171328050.1880@nanos.tec.linutronix.de
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/time/posix-timers.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/kernel/time/posix-timers.c
++++ b/kernel/time/posix-timers.c
+@@ -298,9 +298,6 @@ static void common_hrtimer_rearm(struct
+ {
+ struct hrtimer *timer = &timr->it.real.timer;
+
+- if (!timr->it_interval)
+- return;
+-
+ timr->it_overrun += hrtimer_forward(timer, timer->base->get_time(),
+ timr->it_interval);
+ hrtimer_restart(timer);
+@@ -326,7 +323,7 @@ void posixtimer_rearm(struct siginfo *in
+ if (!timr)
+ return;
+
+- if (timr->it_requeue_pending == info->si_sys_private) {
++ if (timr->it_interval && timr->it_requeue_pending == info->si_sys_private) {
+ timr->kclock->timer_rearm(timr);
+
+ timr->it_active = 1;
usb-serial-option-add-fibocom-nl668-series.patch
usb-serial-option-add-telit-ln940-series.patch
scsi-sd-use-mempool-for-discard-special-page.patch
+mmc-core-reset-hpi-enabled-state-during-re-init-and-in-case-of-errors.patch
+mmc-core-allow-bkops-and-cache-ctrl-even-if-no-hpi-support.patch
+mmc-core-use-a-minimum-1600ms-timeout-when-enabling-cache-ctrl.patch
+mmc-omap_hsmmc-fix-dma-api-warning.patch
+gpio-max7301-fix-driver-for-use-with-config_vmap_stack.patch
+gpiolib-acpi-only-defer-request_irq-for-gpioint-acpi-event-handlers.patch
+posix-timers-fix-division-by-zero-bug.patch
+kvm-x86-add-amd-s-ex_cfg-to-the-list-of-ignored-msrs.patch
+kvm-fix-uaf-in-nested-posted-interrupt-processing.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
--- /dev/null
+From 32043fa065b51e0b1433e48d118821c71b5cd65d Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@canonical.com>
+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 <colin.king@canonical.com>
+
+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 <colin.king@canonical.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
+Cc: security@kernel.org
+Link: https://lkml.kernel.org/r/20181218172956.1440-1-colin.king@canonical.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
projects / thirdparty / kernel / stable-queue.git / commitdiff
