From: Greg Kroah-Hartman Date: Mon, 24 May 2021 09:58:52 +0000 (+0200) Subject: 5.12-stable patches X-Git-Tag: v4.4.270~46 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=837da37c07bc99ad528a28dd03373433c4c32617;p=thirdparty%2Fkernel%2Fstable-queue.git 5.12-stable patches added patches: alsa-usb-audio-configure-pioneer-djm-850-samplerate.patch alsa-usb-audio-djm-750-ensure-format-is-set.patch nvme-tcp-fix-possible-use-after-completion.patch platform-x86-ideapad-laptop-fix-method-name-typo.patch rapidio-handle-create_workqueue-failure.patch revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch uio-uio_pci_generic-fix-return-value-changed-in-refactoring.patch uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch uio_hv_generic-fix-another-memory-leak-in-error-handling-paths.patch x86-build-fix-location-of-plugin-opt-flags.patch x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch x86-sev-es-forward-page-faults-which-happen-during-emulation.patch x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch --- diff --git a/queue-5.12/alsa-usb-audio-configure-pioneer-djm-850-samplerate.patch b/queue-5.12/alsa-usb-audio-configure-pioneer-djm-850-samplerate.patch new file mode 100644 index 00000000000..f1f253c7e31 --- /dev/null +++ b/queue-5.12/alsa-usb-audio-configure-pioneer-djm-850-samplerate.patch @@ -0,0 +1,35 @@ +From 1a2a94a4392d5d1e5e25cc127573452f4c7fa9b8 Mon Sep 17 00:00:00 2001 +From: Nicolas MURE +Date: Mon, 1 Mar 2021 16:27:28 +0100 +Subject: ALSA: usb-audio: Configure Pioneer DJM-850 samplerate + +From: Nicolas MURE + +commit 1a2a94a4392d5d1e5e25cc127573452f4c7fa9b8 upstream. + +Send an `URB_CONTROL out` USB frame to the device to configure its +samplerate. This should be done before using the device for audio +streaming (capture or playback). + +See https://github.com/nm2107/Pioneer-DJM-850-driver-reverse-engineering/blob/172fb9a61055960c88c67b7c416fe5bf3609807b/doc/windows-dvs/framerate-setting/README.md + +Signed-off-by: Nicolas MURE +Link: https://lore.kernel.org/r/20210301152729.18094-4-nicolas.mure2019@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/sound/usb/quirks.c ++++ b/sound/usb/quirks.c +@@ -1511,6 +1511,9 @@ void snd_usb_set_format_quirk(struct snd + case USB_ID(0x2b73, 0x0013): /* Pioneer DJM-450 */ + pioneer_djm_set_format_quirk(subs, 0x0082); + break; ++ case USB_ID(0x08e4, 0x0163): /* Pioneer DJM-850 */ ++ pioneer_djm_set_format_quirk(subs, 0x0086); ++ break; + } + } + diff --git a/queue-5.12/alsa-usb-audio-djm-750-ensure-format-is-set.patch b/queue-5.12/alsa-usb-audio-djm-750-ensure-format-is-set.patch new file mode 100644 index 00000000000..133f9acfe8a --- /dev/null +++ b/queue-5.12/alsa-usb-audio-djm-750-ensure-format-is-set.patch @@ -0,0 +1,32 @@ +From e7df7df5a3809d733888db6ce6592a644acaac19 Mon Sep 17 00:00:00 2001 +From: Olivia Mackintosh +Date: Sun, 18 Apr 2021 17:59:01 +0100 +Subject: ALSA: usb-audio: DJM-750: ensure format is set + +From: Olivia Mackintosh + +commit e7df7df5a3809d733888db6ce6592a644acaac19 upstream. + +Add case statement to set sample-rate for the DJM-750 Pioneer +mixer. This was included as part of another patch but I think it has +been archived on Patchwork and hasn't been merged. + +Signed-off-by: Olivia Mackintosh +Cc: +Link: https://lore.kernel.org/r/20210418165901.25776-1-livvy@base.nu +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/usb/quirks.c ++++ b/sound/usb/quirks.c +@@ -1511,6 +1511,7 @@ void snd_usb_set_format_quirk(struct snd + case USB_ID(0x2b73, 0x0013): /* Pioneer DJM-450 */ + pioneer_djm_set_format_quirk(subs, 0x0082); + break; ++ case USB_ID(0x08e4, 0x017f): /* Pioneer DJM-750 */ + case USB_ID(0x08e4, 0x0163): /* Pioneer DJM-850 */ + pioneer_djm_set_format_quirk(subs, 0x0086); + break; diff --git a/queue-5.12/nvme-tcp-fix-possible-use-after-completion.patch b/queue-5.12/nvme-tcp-fix-possible-use-after-completion.patch new file mode 100644 index 00000000000..c026346f163 --- /dev/null +++ b/queue-5.12/nvme-tcp-fix-possible-use-after-completion.patch @@ -0,0 +1,79 @@ +From 825619b09ad351894d2c6fb6705f5b3711d145c7 Mon Sep 17 00:00:00 2001 +From: Sagi Grimberg +Date: Mon, 17 May 2021 14:07:45 -0700 +Subject: nvme-tcp: fix possible use-after-completion + +From: Sagi Grimberg + +commit 825619b09ad351894d2c6fb6705f5b3711d145c7 upstream. + +Commit db5ad6b7f8cd ("nvme-tcp: try to send request in queue_rq +context") added a second context that may perform a network send. +This means that now RX and TX are not serialized in nvme_tcp_io_work +and can run concurrently. + +While there is correct mutual exclusion in the TX path (where +the send_mutex protect the queue socket send activity) RX activity, +and more specifically request completion may run concurrently. + +This means we must guarantee that any mutation of the request state +related to its lifetime, bytes sent must not be accessed when a completion +may have possibly arrived back (and processed). + +The race may trigger when a request completion arrives, processed +_and_ reused as a fresh new request, exactly in the (relatively short) +window between the last data payload sent and before the request iov_iter +is advanced. + +Consider the following race: +1. 16K write request is queued +2. The nvme command and the data is sent to the controller (in-capsule + or solicited by r2t) +3. After the last payload is sent but before the req.iter is advanced, + the controller sends back a completion. +4. The completion is processed, the request is completed, and reused + to transfer a new request (write or read) +5. The new request is queued, and the driver reset the request parameters + (nvme_tcp_setup_cmd_pdu). +6. Now context in (2) resumes execution and advances the req.iter + +==> use-after-completion as this is already a new request. + +Fix this by making sure the request is not advanced after the last +data payload send, knowing that a completion may have arrived already. + +An alternative solution would have been to delay the request completion +or state change waiting for reference counting on the TX path, but besides +adding atomic operations to the hot-path, it may present challenges in +multi-stage R2T scenarios where a r2t handler needs to be deferred to +an async execution. + +Reported-by: Narayan Ayalasomayajula +Tested-by: Anil Mishra +Reviewed-by: Keith Busch +Cc: stable@vger.kernel.org # v5.8+ +Signed-off-by: Sagi Grimberg +Signed-off-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/tcp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/nvme/host/tcp.c ++++ b/drivers/nvme/host/tcp.c +@@ -940,7 +940,6 @@ static int nvme_tcp_try_send_data(struct + if (ret <= 0) + return ret; + +- nvme_tcp_advance_req(req, ret); + if (queue->data_digest) + nvme_tcp_ddgst_update(queue->snd_hash, page, + offset, ret); +@@ -957,6 +956,7 @@ static int nvme_tcp_try_send_data(struct + } + return 1; + } ++ nvme_tcp_advance_req(req, ret); + } + return -EAGAIN; + } diff --git a/queue-5.12/platform-x86-ideapad-laptop-fix-method-name-typo.patch b/queue-5.12/platform-x86-ideapad-laptop-fix-method-name-typo.patch new file mode 100644 index 00000000000..96fb7599b21 --- /dev/null +++ b/queue-5.12/platform-x86-ideapad-laptop-fix-method-name-typo.patch @@ -0,0 +1,64 @@ +From b09aaa3f2c0edeeed670cd29961a0e35bddc78cf Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Barnab=C3=A1s=20P=C5=91cze?= +Date: Fri, 7 May 2021 23:53:44 +0000 +Subject: platform/x86: ideapad-laptop: fix method name typo +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Barnabás Pőcze + +commit b09aaa3f2c0edeeed670cd29961a0e35bddc78cf upstream. + +"smbc" should be "sbmc". `eval_smbc()` incorrectly called +the SMBC ACPI method instead of SBMC. This resulted in +partial loss of functionality. Rectify that by calling +the correct ACPI method (SBMC), and also rename +methods and constants. + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212985 +Fixes: 0b765671cb80 ("platform/x86: ideapad-laptop: group and separate (un)related constants into enums") +Fixes: ff36b0d953dc ("platform/x86: ideapad-laptop: rework and create new ACPI helpers") +Cc: stable@vger.kernel.org # 5.12 +Signed-off-by: Barnabás Pőcze +Link: https://lore.kernel.org/r/20210507235333.286505-1-pobrn@protonmail.com +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/ideapad-laptop.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/platform/x86/ideapad-laptop.c ++++ b/drivers/platform/x86/ideapad-laptop.c +@@ -57,8 +57,8 @@ enum { + }; + + enum { +- SMBC_CONSERVATION_ON = 3, +- SMBC_CONSERVATION_OFF = 5, ++ SBMC_CONSERVATION_ON = 3, ++ SBMC_CONSERVATION_OFF = 5, + }; + + enum { +@@ -182,9 +182,9 @@ static int eval_gbmd(acpi_handle handle, + return eval_int(handle, "GBMD", res); + } + +-static int exec_smbc(acpi_handle handle, unsigned long arg) ++static int exec_sbmc(acpi_handle handle, unsigned long arg) + { +- return exec_simple_method(handle, "SMBC", arg); ++ return exec_simple_method(handle, "SBMC", arg); + } + + static int eval_hals(acpi_handle handle, unsigned long *res) +@@ -477,7 +477,7 @@ static ssize_t conservation_mode_store(s + if (err) + return err; + +- err = exec_smbc(priv->adev->handle, state ? SMBC_CONSERVATION_ON : SMBC_CONSERVATION_OFF); ++ err = exec_sbmc(priv->adev->handle, state ? SBMC_CONSERVATION_ON : SBMC_CONSERVATION_OFF); + if (err) + return err; + diff --git a/queue-5.12/rapidio-handle-create_workqueue-failure.patch b/queue-5.12/rapidio-handle-create_workqueue-failure.patch new file mode 100644 index 00000000000..a447a114008 --- /dev/null +++ b/queue-5.12/rapidio-handle-create_workqueue-failure.patch @@ -0,0 +1,51 @@ +From 69ce3ae36dcb03cdf416b0862a45369ddbf50fdf Mon Sep 17 00:00:00 2001 +From: Anirudh Rayabharam +Date: Mon, 3 May 2021 13:57:12 +0200 +Subject: rapidio: handle create_workqueue() failure + +From: Anirudh Rayabharam + +commit 69ce3ae36dcb03cdf416b0862a45369ddbf50fdf upstream. + +In case create_workqueue() fails, release all resources and return -ENOMEM +to caller to avoid potential NULL pointer deref later. Move up the +create_workequeue() call to return early and avoid unwinding the call to +riocm_rx_fill(). + +Cc: Alexandre Bounine +Cc: Matt Porter +Cc: Andrew Morton +Cc: Linus Torvalds +Cc: stable +Signed-off-by: Anirudh Rayabharam +Link: https://lore.kernel.org/r/20210503115736.2104747-46-gregkh@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/rapidio/rio_cm.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/rapidio/rio_cm.c ++++ b/drivers/rapidio/rio_cm.c +@@ -2127,6 +2127,14 @@ static int riocm_add_mport(struct device + return -ENODEV; + } + ++ cm->rx_wq = create_workqueue(DRV_NAME "/rxq"); ++ if (!cm->rx_wq) { ++ rio_release_inb_mbox(mport, cmbox); ++ rio_release_outb_mbox(mport, cmbox); ++ kfree(cm); ++ return -ENOMEM; ++ } ++ + /* + * Allocate and register inbound messaging buffers to be ready + * to receive channel and system management requests +@@ -2137,7 +2145,6 @@ static int riocm_add_mport(struct device + cm->rx_slots = RIOCM_RX_RING_SIZE; + mutex_init(&cm->rx_lock); + riocm_rx_fill(cm, RIOCM_RX_RING_SIZE); +- cm->rx_wq = create_workqueue(DRV_NAME "/rxq"); + INIT_WORK(&cm->rx_work, rio_ibmsg_handler); + + cm->tx_slot = 0; diff --git a/queue-5.12/revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch b/queue-5.12/revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch new file mode 100644 index 00000000000..0f32d25ea89 --- /dev/null +++ b/queue-5.12/revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch @@ -0,0 +1,57 @@ +From 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Mon, 3 May 2021 13:57:11 +0200 +Subject: Revert "rapidio: fix a NULL pointer dereference when create_workqueue() fails" + +From: Greg Kroah-Hartman + +commit 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb upstream. + +This reverts commit 23015b22e47c5409620b1726a677d69e5cd032ba. + +Because of recent interactions with developers from @umn.edu, all +commits from them have been recently re-reviewed to ensure if they were +correct or not. + +Upon review, this commit was found to be incorrect for the reasons +below, so it must be reverted. It will be fixed up "correctly" in a +later kernel change. + +The original commit has a memory leak on the error path here, it does +not clean up everything properly. + +Cc: Kangjie Lu +Cc: Alexandre Bounine +Cc: Matt Porter +Cc: Andrew Morton +Cc: Linus Torvalds +Fixes: 23015b22e47c ("rapidio: fix a NULL pointer dereference when create_workqueue() fails") +Cc: stable +Link: https://lore.kernel.org/r/20210503115736.2104747-45-gregkh@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/rapidio/rio_cm.c | 8 -------- + 1 file changed, 8 deletions(-) + +diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c +index 50ec53d67a4c..e6c16f04f2b4 100644 +--- a/drivers/rapidio/rio_cm.c ++++ b/drivers/rapidio/rio_cm.c +@@ -2138,14 +2138,6 @@ static int riocm_add_mport(struct device *dev, + mutex_init(&cm->rx_lock); + riocm_rx_fill(cm, RIOCM_RX_RING_SIZE); + cm->rx_wq = create_workqueue(DRV_NAME "/rxq"); +- if (!cm->rx_wq) { +- riocm_error("failed to allocate IBMBOX_%d on %s", +- cmbox, mport->name); +- rio_release_outb_mbox(mport, cmbox); +- kfree(cm); +- return -ENOMEM; +- } +- + INIT_WORK(&cm->rx_work, rio_ibmsg_handler); + + cm->tx_slot = 0; +-- +2.31.1 + diff --git a/queue-5.12/revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch b/queue-5.12/revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch new file mode 100644 index 00000000000..bb01d7b6724 --- /dev/null +++ b/queue-5.12/revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch @@ -0,0 +1,41 @@ +From 754f39158441f4c0d7a8255209dd9a939f08ce80 Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Mon, 3 May 2021 13:56:32 +0200 +Subject: Revert "serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference" + +From: Greg Kroah-Hartman + +commit 754f39158441f4c0d7a8255209dd9a939f08ce80 upstream. + +This reverts commit 32f47179833b63de72427131169809065db6745e. + +Because of recent interactions with developers from @umn.edu, all +commits from them have been recently re-reviewed to ensure if they were +correct or not. + +Upon review, this commit was found to be not be needed at all as the +change was useless because this function can only be called when +of_match_device matched on something. So it should be reverted. + +Cc: Aditya Pakki +Cc: stable +Fixes: 32f47179833b ("serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference") +Acked-by: Jiri Slaby +Link: https://lore.kernel.org/r/20210503115736.2104747-6-gregkh@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/mvebu-uart.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/drivers/tty/serial/mvebu-uart.c ++++ b/drivers/tty/serial/mvebu-uart.c +@@ -818,9 +818,6 @@ static int mvebu_uart_probe(struct platf + return -EINVAL; + } + +- if (!match) +- return -ENODEV; +- + /* Assume that all UART ports have a DT alias or none has */ + id = of_alias_get_id(pdev->dev.of_node, "serial"); + if (!pdev->dev.of_node || id < 0) diff --git a/queue-5.12/series b/queue-5.12/series index 7a5eb36e79f..190e9340a6a 100644 --- a/queue-5.12/series +++ b/queue-5.12/series @@ -55,3 +55,19 @@ alsa-hda-realtek-add-some-clove-ssids-of-alc293.patch alsa-hda-realtek-fix-silent-headphone-output-on-asus-ux430ua.patch alsa-hda-realtek-add-fixup-for-hp-omen-laptop.patch alsa-hda-realtek-add-fixup-for-hp-spectre-x360-15-df0xxx.patch +alsa-usb-audio-configure-pioneer-djm-850-samplerate.patch +alsa-usb-audio-djm-750-ensure-format-is-set.patch +uio-uio_pci_generic-fix-return-value-changed-in-refactoring.patch +uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch +uio_hv_generic-fix-another-memory-leak-in-error-handling-paths.patch +platform-x86-ideapad-laptop-fix-method-name-typo.patch +revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch +rapidio-handle-create_workqueue-failure.patch +revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch +nvme-tcp-fix-possible-use-after-completion.patch +x86-build-fix-location-of-plugin-opt-flags.patch +x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch +x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch +x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch +x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch +x86-sev-es-forward-page-faults-which-happen-during-emulation.patch diff --git a/queue-5.12/uio-uio_pci_generic-fix-return-value-changed-in-refactoring.patch b/queue-5.12/uio-uio_pci_generic-fix-return-value-changed-in-refactoring.patch new file mode 100644 index 00000000000..776c7a25b3a --- /dev/null +++ b/queue-5.12/uio-uio_pci_generic-fix-return-value-changed-in-refactoring.patch @@ -0,0 +1,40 @@ +From 156ed0215ef365604f2382d5164c36d3a1cfd98f Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Martin=20=C3=85gren?= +Date: Thu, 22 Apr 2021 21:22:40 +0200 +Subject: uio/uio_pci_generic: fix return value changed in refactoring +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Martin Ågren + +commit 156ed0215ef365604f2382d5164c36d3a1cfd98f upstream. + +Commit ef84928cff58 ("uio/uio_pci_generic: use device-managed function +equivalents") was able to simplify various error paths thanks to no +longer having to clean up on the way out. Some error paths were dropped, +others were simplified. In one of those simplifications, the return +value was accidentally changed from -ENODEV to -ENOMEM. Restore the old +return value. + +Fixes: ef84928cff58 ("uio/uio_pci_generic: use device-managed function equivalents") +Cc: stable +Acked-by: Michael S. Tsirkin +Signed-off-by: Martin Ågren +Link: https://lore.kernel.org/r/20210422192240.1136373-1-martin.agren@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/uio/uio_pci_generic.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/uio/uio_pci_generic.c ++++ b/drivers/uio/uio_pci_generic.c +@@ -82,7 +82,7 @@ static int probe(struct pci_dev *pdev, + } + + if (pdev->irq && !pci_intx_mask_supported(pdev)) +- return -ENOMEM; ++ return -ENODEV; + + gdev = devm_kzalloc(&pdev->dev, sizeof(struct uio_pci_generic_dev), GFP_KERNEL); + if (!gdev) diff --git a/queue-5.12/uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch b/queue-5.12/uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch new file mode 100644 index 00000000000..f02b54e3435 --- /dev/null +++ b/queue-5.12/uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch @@ -0,0 +1,50 @@ +From 3ee098f96b8b6c1a98f7f97915f8873164e6af9d Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Sun, 9 May 2021 09:13:03 +0200 +Subject: uio_hv_generic: Fix a memory leak in error handling paths + +From: Christophe JAILLET + +commit 3ee098f96b8b6c1a98f7f97915f8873164e6af9d upstream. + +If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be +updated and 'hv_uio_cleanup()' in the error handling path will not be +able to free the corresponding buffer. + +In such a case, we need to free the buffer explicitly. + +Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use") +Cc: stable +Signed-off-by: Christophe JAILLET +Link: https://lore.kernel.org/r/4fdaff557deef6f0475d02ba7922ddbaa1ab08a6.1620544055.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Greg Kroah-Hartman +--- + drivers/uio/uio_hv_generic.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/uio/uio_hv_generic.c ++++ b/drivers/uio/uio_hv_generic.c +@@ -296,8 +296,10 @@ hv_uio_probe(struct hv_device *dev, + + ret = vmbus_establish_gpadl(channel, pdata->recv_buf, + RECV_BUFFER_SIZE, &pdata->recv_gpadl); +- if (ret) ++ if (ret) { ++ vfree(pdata->recv_buf); + goto fail_close; ++ } + + /* put Global Physical Address Label in name */ + snprintf(pdata->recv_name, sizeof(pdata->recv_name), +@@ -316,8 +318,10 @@ hv_uio_probe(struct hv_device *dev, + + ret = vmbus_establish_gpadl(channel, pdata->send_buf, + SEND_BUFFER_SIZE, &pdata->send_gpadl); +- if (ret) ++ if (ret) { ++ vfree(pdata->send_buf); + goto fail_close; ++ } + + snprintf(pdata->send_name, sizeof(pdata->send_name), + "send:%u", pdata->send_gpadl); diff --git a/queue-5.12/uio_hv_generic-fix-another-memory-leak-in-error-handling-paths.patch b/queue-5.12/uio_hv_generic-fix-another-memory-leak-in-error-handling-paths.patch new file mode 100644 index 00000000000..d7dc4e891a4 --- /dev/null +++ b/queue-5.12/uio_hv_generic-fix-another-memory-leak-in-error-handling-paths.patch @@ -0,0 +1,45 @@ +From 0b0226be3a52dadd965644bc52a807961c2c26df Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Sun, 9 May 2021 09:13:12 +0200 +Subject: uio_hv_generic: Fix another memory leak in error handling paths + +From: Christophe JAILLET + +commit 0b0226be3a52dadd965644bc52a807961c2c26df upstream. + +Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe +function is never freed in the error handling path. + +Add the missing 'vmbus_free_ring()' call. + +Note that it is already freed in the .remove function. + +Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use") +Cc: stable +Signed-off-by: Christophe JAILLET +Link: https://lore.kernel.org/r/0d86027b8eeed8e6360bc3d52bcdb328ff9bdca1.1620544055.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Greg Kroah-Hartman +--- + drivers/uio/uio_hv_generic.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/uio/uio_hv_generic.c ++++ b/drivers/uio/uio_hv_generic.c +@@ -291,7 +291,7 @@ hv_uio_probe(struct hv_device *dev, + pdata->recv_buf = vzalloc(RECV_BUFFER_SIZE); + if (pdata->recv_buf == NULL) { + ret = -ENOMEM; +- goto fail_close; ++ goto fail_free_ring; + } + + ret = vmbus_establish_gpadl(channel, pdata->recv_buf, +@@ -351,6 +351,8 @@ hv_uio_probe(struct hv_device *dev, + + fail_close: + hv_uio_cleanup(dev, pdata); ++fail_free_ring: ++ vmbus_free_ring(dev->channel); + + return ret; + } diff --git a/queue-5.12/x86-build-fix-location-of-plugin-opt-flags.patch b/queue-5.12/x86-build-fix-location-of-plugin-opt-flags.patch new file mode 100644 index 00000000000..1a58a3af312 --- /dev/null +++ b/queue-5.12/x86-build-fix-location-of-plugin-opt-flags.patch @@ -0,0 +1,72 @@ +From 0024430e920f2900654ad83cd081cf52e02a3ef5 Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Tue, 18 May 2021 12:01:06 -0700 +Subject: x86/build: Fix location of '-plugin-opt=' flags + +From: Nathan Chancellor + +commit 0024430e920f2900654ad83cd081cf52e02a3ef5 upstream. + +Commit b33fff07e3e3 ("x86, build: allow LTO to be selected") added a +couple of '-plugin-opt=' flags to KBUILD_LDFLAGS because the code model +and stack alignment are not stored in LLVM bitcode. + +However, these flags were added to KBUILD_LDFLAGS prior to the +emulation flag assignment, which uses ':=', so they were overwritten +and never added to $(LD) invocations. + +The absence of these flags caused misalignment issues in the +AMDGPU driver when compiling with CONFIG_LTO_CLANG, resulting in +general protection faults. + +Shuffle the assignment below the initial one so that the flags are +properly passed along and all of the linker flags stay together. + +At the same time, avoid any future issues with clobbering flags by +changing the emulation flag assignment to '+=' since KBUILD_LDFLAGS is +already defined with ':=' in the main Makefile before being exported for +modification here as a result of commit: + + ce99d0bf312d ("kbuild: clear LDFLAGS in the top Makefile") + +Fixes: b33fff07e3e3 ("x86, build: allow LTO to be selected") +Reported-by: Anthony Ruhier +Signed-off-by: Nathan Chancellor +Signed-off-by: Ingo Molnar +Tested-by: Anthony Ruhier +Cc: stable@vger.kernel.org +Link: https://github.com/ClangBuiltLinux/linux/issues/1374 +Link: https://lore.kernel.org/r/20210518190106.60935-1-nathan@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/Makefile | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +--- a/arch/x86/Makefile ++++ b/arch/x86/Makefile +@@ -170,11 +170,6 @@ ifeq ($(ACCUMULATE_OUTGOING_ARGS), 1) + KBUILD_CFLAGS += $(call cc-option,-maccumulate-outgoing-args,) + endif + +-ifdef CONFIG_LTO_CLANG +-KBUILD_LDFLAGS += -plugin-opt=-code-model=kernel \ +- -plugin-opt=-stack-alignment=$(if $(CONFIG_X86_32),4,8) +-endif +- + # Workaround for a gcc prelease that unfortunately was shipped in a suse release + KBUILD_CFLAGS += -Wno-sign-compare + # +@@ -194,7 +189,12 @@ ifdef CONFIG_RETPOLINE + endif + endif + +-KBUILD_LDFLAGS := -m elf_$(UTS_MACHINE) ++KBUILD_LDFLAGS += -m elf_$(UTS_MACHINE) ++ ++ifdef CONFIG_LTO_CLANG ++KBUILD_LDFLAGS += -plugin-opt=-code-model=kernel \ ++ -plugin-opt=-stack-alignment=$(if $(CONFIG_X86_32),4,8) ++endif + + ifdef CONFIG_X86_NEED_RELOCS + LDFLAGS_vmlinux := --emit-relocs --discard-none diff --git a/queue-5.12/x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch b/queue-5.12/x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch new file mode 100644 index 00000000000..e71f62a42a7 --- /dev/null +++ b/queue-5.12/x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch @@ -0,0 +1,74 @@ +From b250f2f7792d15bcde98e0456781e2835556d5fa Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Wed, 19 May 2021 15:52:44 +0200 +Subject: x86/sev-es: Don't return NULL from sev_es_get_ghcb() + +From: Joerg Roedel + +commit b250f2f7792d15bcde98e0456781e2835556d5fa upstream. + +sev_es_get_ghcb() is called from several places but only one of them +checks the return value. The reaction to returning NULL is always the +same: calling panic() and kill the machine. + +Instead of adding checks to all call sites, move the panic() into the +function itself so that it will no longer return NULL. + +Fixes: 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler") +Signed-off-by: Joerg Roedel +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org # v5.10+ +Link: https://lkml.kernel.org/r/20210519135251.30093-2-joro@8bytes.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es.c | 25 ++++++++++++------------- + 1 file changed, 12 insertions(+), 13 deletions(-) + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -191,8 +191,18 @@ static __always_inline struct ghcb *sev_ + if (unlikely(data->ghcb_active)) { + /* GHCB is already in use - save its contents */ + +- if (unlikely(data->backup_ghcb_active)) +- return NULL; ++ if (unlikely(data->backup_ghcb_active)) { ++ /* ++ * Backup-GHCB is also already in use. There is no way ++ * to continue here so just kill the machine. To make ++ * panic() work, mark GHCBs inactive so that messages ++ * can be printed out. ++ */ ++ data->ghcb_active = false; ++ data->backup_ghcb_active = false; ++ ++ panic("Unable to handle #VC exception! GHCB and Backup GHCB are already in use"); ++ } + + /* Mark backup_ghcb active before writing to it */ + data->backup_ghcb_active = true; +@@ -1262,7 +1272,6 @@ static __always_inline bool on_vc_fallba + */ + DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication) + { +- struct sev_es_runtime_data *data = this_cpu_read(runtime_data); + irqentry_state_t irq_state; + struct ghcb_state state; + struct es_em_ctxt ctxt; +@@ -1288,16 +1297,6 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_co + */ + + ghcb = sev_es_get_ghcb(&state); +- if (!ghcb) { +- /* +- * Mark GHCBs inactive so that panic() is able to print the +- * message. +- */ +- data->ghcb_active = false; +- data->backup_ghcb_active = false; +- +- panic("Unable to handle #VC exception! GHCB and Backup GHCB are already in use"); +- } + + vc_ghcb_invalidate(ghcb); + result = vc_init_em_ctxt(&ctxt, regs, error_code); diff --git a/queue-5.12/x86-sev-es-forward-page-faults-which-happen-during-emulation.patch b/queue-5.12/x86-sev-es-forward-page-faults-which-happen-during-emulation.patch new file mode 100644 index 00000000000..13d02f3b7c6 --- /dev/null +++ b/queue-5.12/x86-sev-es-forward-page-faults-which-happen-during-emulation.patch @@ -0,0 +1,37 @@ +From c25bbdb564060adaad5c3a8a10765c13487ba6a3 Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Wed, 19 May 2021 15:52:45 +0200 +Subject: x86/sev-es: Forward page-faults which happen during emulation + +From: Joerg Roedel + +commit c25bbdb564060adaad5c3a8a10765c13487ba6a3 upstream. + +When emulating guest instructions for MMIO or IOIO accesses, the #VC +handler might get a page-fault and will not be able to complete. Forward +the page-fault in this case to the correct handler instead of killing +the machine. + +Fixes: 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler") +Signed-off-by: Joerg Roedel +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org # v5.10+ +Link: https://lkml.kernel.org/r/20210519135251.30093-3-joro@8bytes.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -1269,6 +1269,10 @@ static __always_inline void vc_forward_e + case X86_TRAP_UD: + exc_invalid_op(ctxt->regs); + break; ++ case X86_TRAP_PF: ++ write_cr2(ctxt->fi.cr2); ++ exc_page_fault(ctxt->regs, error_code); ++ break; + case X86_TRAP_AC: + exc_alignment_check(ctxt->regs, error_code); + break; diff --git a/queue-5.12/x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch b/queue-5.12/x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch new file mode 100644 index 00000000000..2f12e3612d8 --- /dev/null +++ b/queue-5.12/x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch @@ -0,0 +1,52 @@ +From a50c5bebc99c525e7fbc059988c6a5ab8680cb76 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +Date: Mon, 17 May 2021 12:42:33 -0500 +Subject: x86/sev-es: Invalidate the GHCB after completing VMGEXIT + +From: Tom Lendacky + +commit a50c5bebc99c525e7fbc059988c6a5ab8680cb76 upstream. + +Since the VMGEXIT instruction can be issued from userspace, invalidate +the GHCB after performing VMGEXIT processing in the kernel. + +Invalidation is only required after userspace is available, so call +vc_ghcb_invalidate() from sev_es_put_ghcb(). Update vc_ghcb_invalidate() +to additionally clear the GHCB exit code so that it is always presented +as 0 when VMGEXIT has been issued by anything else besides the kernel. + +Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler") +Signed-off-by: Tom Lendacky +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/5a8130462e4f0057ee1184509cd056eedd78742b.1621273353.git.thomas.lendacky@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es-shared.c | 1 + + arch/x86/kernel/sev-es.c | 5 +++++ + 2 files changed, 6 insertions(+) + +--- a/arch/x86/kernel/sev-es-shared.c ++++ b/arch/x86/kernel/sev-es-shared.c +@@ -63,6 +63,7 @@ static bool sev_es_negotiate_protocol(vo + + static __always_inline void vc_ghcb_invalidate(struct ghcb *ghcb) + { ++ ghcb->save.sw_exit_code = 0; + memset(ghcb->save.valid_bitmap, 0, sizeof(ghcb->save.valid_bitmap)); + } + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -430,6 +430,11 @@ static __always_inline void sev_es_put_g + data->backup_ghcb_active = false; + state->ghcb = NULL; + } else { ++ /* ++ * Invalidate the GHCB so a VMGEXIT instruction issued ++ * from userspace won't appear to be valid. ++ */ ++ vc_ghcb_invalidate(ghcb); + data->ghcb_active = false; + } + } diff --git a/queue-5.12/x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch b/queue-5.12/x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch new file mode 100644 index 00000000000..62bc8e2a618 --- /dev/null +++ b/queue-5.12/x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch @@ -0,0 +1,77 @@ +From fea63d54f7a3e74f8ab489a8b82413a29849a594 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +Date: Mon, 17 May 2021 12:42:32 -0500 +Subject: x86/sev-es: Move sev_es_put_ghcb() in prep for follow on patch + +From: Tom Lendacky + +commit fea63d54f7a3e74f8ab489a8b82413a29849a594 upstream. + +Move the location of sev_es_put_ghcb() in preparation for an update to it +in a follow-on patch. This will better highlight the changes being made +to the function. + +No functional change. + +Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler") +Signed-off-by: Tom Lendacky +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/8c07662ec17d3d82e5c53841a1d9e766d3bdbab6.1621273353.git.thomas.lendacky@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es.c | 36 ++++++++++++++++++------------------ + 1 file changed, 18 insertions(+), 18 deletions(-) + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -209,24 +209,6 @@ static __always_inline struct ghcb *sev_ + return ghcb; + } + +-static __always_inline void sev_es_put_ghcb(struct ghcb_state *state) +-{ +- struct sev_es_runtime_data *data; +- struct ghcb *ghcb; +- +- data = this_cpu_read(runtime_data); +- ghcb = &data->ghcb_page; +- +- if (state->ghcb) { +- /* Restore GHCB from Backup */ +- *ghcb = *state->ghcb; +- data->backup_ghcb_active = false; +- state->ghcb = NULL; +- } else { +- data->ghcb_active = false; +- } +-} +- + /* Needed in vc_early_forward_exception */ + void do_early_exception(struct pt_regs *regs, int trapnr); + +@@ -434,6 +416,24 @@ static enum es_result vc_slow_virt_to_ph + /* Include code shared with pre-decompression boot stage */ + #include "sev-es-shared.c" + ++static __always_inline void sev_es_put_ghcb(struct ghcb_state *state) ++{ ++ struct sev_es_runtime_data *data; ++ struct ghcb *ghcb; ++ ++ data = this_cpu_read(runtime_data); ++ ghcb = &data->ghcb_page; ++ ++ if (state->ghcb) { ++ /* Restore GHCB from Backup */ ++ *ghcb = *state->ghcb; ++ data->backup_ghcb_active = false; ++ state->ghcb = NULL; ++ } else { ++ data->ghcb_active = false; ++ } ++} ++ + void noinstr __sev_es_nmi_complete(void) + { + struct ghcb_state state; diff --git a/queue-5.12/x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch b/queue-5.12/x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch new file mode 100644 index 00000000000..caf75f85fc0 --- /dev/null +++ b/queue-5.12/x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch @@ -0,0 +1,159 @@ +From 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Wed, 19 May 2021 15:52:46 +0200 +Subject: x86/sev-es: Use __put_user()/__get_user() for data accesses + +From: Joerg Roedel + +commit 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 upstream. + +The put_user() and get_user() functions do checks on the address which is +passed to them. They check whether the address is actually a user-space +address and whether its fine to access it. They also call might_fault() +to indicate that they could fault and possibly sleep. + +All of these checks are neither wanted nor needed in the #VC exception +handler, which can be invoked from almost any context and also for MMIO +instructions from kernel space on kernel memory. All the #VC handler +wants to know is whether a fault happened when the access was tried. + +This is provided by __put_user()/__get_user(), which just do the access +no matter what. Also add comments explaining why __get_user() and +__put_user() are the best choice here and why it is safe to use them +in this context. Also explain why copy_to/from_user can't be used. + +In addition, also revert commit + + 7024f60d6552 ("x86/sev-es: Handle string port IO to kernel memory properly") + +because using __get_user()/__put_user() fixes the same problem while +the above commit introduced several problems: + + 1) It uses access_ok() which is only allowed in task context. + + 2) It uses memcpy() which has no fault handling at all and is + thus unsafe to use here. + + [ bp: Fix up commit ID of the reverted commit above. ] + +Fixes: f980f9c31a92 ("x86/sev-es: Compile early handler code into kernel image") +Signed-off-by: Joerg Roedel +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org # v5.10+ +Link: https://lkml.kernel.org/r/20210519135251.30093-4-joro@8bytes.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es.c | 66 ++++++++++++++++++++++++++++++++--------------- + 1 file changed, 46 insertions(+), 20 deletions(-) + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -288,31 +288,44 @@ static enum es_result vc_write_mem(struc + u16 d2; + u8 d1; + +- /* If instruction ran in kernel mode and the I/O buffer is in kernel space */ +- if (!user_mode(ctxt->regs) && !access_ok(target, size)) { +- memcpy(dst, buf, size); +- return ES_OK; +- } +- ++ /* ++ * This function uses __put_user() independent of whether kernel or user ++ * memory is accessed. This works fine because __put_user() does no ++ * sanity checks of the pointer being accessed. All that it does is ++ * to report when the access failed. ++ * ++ * Also, this function runs in atomic context, so __put_user() is not ++ * allowed to sleep. The page-fault handler detects that it is running ++ * in atomic context and will not try to take mmap_sem and handle the ++ * fault, so additional pagefault_enable()/disable() calls are not ++ * needed. ++ * ++ * The access can't be done via copy_to_user() here because ++ * vc_write_mem() must not use string instructions to access unsafe ++ * memory. The reason is that MOVS is emulated by the #VC handler by ++ * splitting the move up into a read and a write and taking a nested #VC ++ * exception on whatever of them is the MMIO access. Using string ++ * instructions here would cause infinite nesting. ++ */ + switch (size) { + case 1: + memcpy(&d1, buf, 1); +- if (put_user(d1, target)) ++ if (__put_user(d1, target)) + goto fault; + break; + case 2: + memcpy(&d2, buf, 2); +- if (put_user(d2, target)) ++ if (__put_user(d2, target)) + goto fault; + break; + case 4: + memcpy(&d4, buf, 4); +- if (put_user(d4, target)) ++ if (__put_user(d4, target)) + goto fault; + break; + case 8: + memcpy(&d8, buf, 8); +- if (put_user(d8, target)) ++ if (__put_user(d8, target)) + goto fault; + break; + default: +@@ -343,30 +356,43 @@ static enum es_result vc_read_mem(struct + u16 d2; + u8 d1; + +- /* If instruction ran in kernel mode and the I/O buffer is in kernel space */ +- if (!user_mode(ctxt->regs) && !access_ok(s, size)) { +- memcpy(buf, src, size); +- return ES_OK; +- } +- ++ /* ++ * This function uses __get_user() independent of whether kernel or user ++ * memory is accessed. This works fine because __get_user() does no ++ * sanity checks of the pointer being accessed. All that it does is ++ * to report when the access failed. ++ * ++ * Also, this function runs in atomic context, so __get_user() is not ++ * allowed to sleep. The page-fault handler detects that it is running ++ * in atomic context and will not try to take mmap_sem and handle the ++ * fault, so additional pagefault_enable()/disable() calls are not ++ * needed. ++ * ++ * The access can't be done via copy_from_user() here because ++ * vc_read_mem() must not use string instructions to access unsafe ++ * memory. The reason is that MOVS is emulated by the #VC handler by ++ * splitting the move up into a read and a write and taking a nested #VC ++ * exception on whatever of them is the MMIO access. Using string ++ * instructions here would cause infinite nesting. ++ */ + switch (size) { + case 1: +- if (get_user(d1, s)) ++ if (__get_user(d1, s)) + goto fault; + memcpy(buf, &d1, 1); + break; + case 2: +- if (get_user(d2, s)) ++ if (__get_user(d2, s)) + goto fault; + memcpy(buf, &d2, 2); + break; + case 4: +- if (get_user(d4, s)) ++ if (__get_user(d4, s)) + goto fault; + memcpy(buf, &d4, 4); + break; + case 8: +- if (get_user(d8, s)) ++ if (__get_user(d8, s)) + goto fault; + memcpy(buf, &d8, 8); + break;