--- /dev/null
+From 825619b09ad351894d2c6fb6705f5b3711d145c7 Mon Sep 17 00:00:00 2001
+From: Sagi Grimberg <sagi@grimberg.me>
+Date: Mon, 17 May 2021 14:07:45 -0700
+Subject: nvme-tcp: fix possible use-after-completion
+
+From: Sagi Grimberg <sagi@grimberg.me>
+
+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 <narayan.ayalasomayajula@wdc.com>
+Tested-by: Anil Mishra <anil.mishra@wdc.com>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Cc: stable@vger.kernel.org # v5.8+
+Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 69ce3ae36dcb03cdf416b0862a45369ddbf50fdf Mon Sep 17 00:00:00 2001
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+Date: Mon, 3 May 2021 13:57:12 +0200
+Subject: rapidio: handle create_workqueue() failure
+
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+
+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 <alex.bou9@gmail.com>
+Cc: Matt Porter <mporter@kernel.crashing.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
+Link: https://lore.kernel.org/r/20210503115736.2104747-46-gregkh@linuxfoundation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+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 <gregkh@linuxfoundation.org>
+
+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 <kjlu@umn.edu>
+Cc: Alexandre Bounine <alex.bou9@gmail.com>
+Cc: Matt Porter <mporter@kernel.crashing.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Fixes: 23015b22e47c ("rapidio: fix a NULL pointer dereference when create_workqueue() fails")
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210503115736.2104747-45-gregkh@linuxfoundation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rapidio/rio_cm.c | 8 --------
+ 1 file changed, 8 deletions(-)
+
+--- a/drivers/rapidio/rio_cm.c
++++ b/drivers/rapidio/rio_cm.c
+@@ -2138,14 +2138,6 @@ static int riocm_add_mport(struct device
+ 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;
--- /dev/null
+From 754f39158441f4c0d7a8255209dd9a939f08ce80 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+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 <gregkh@linuxfoundation.org>
+
+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 <pakki001@umn.edu>
+Cc: stable <stable@vger.kernel.org>
+Fixes: 32f47179833b ("serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference")
+Acked-by: Jiri Slaby <jirislaby@kernel.org>
+Link: https://lore.kernel.org/r/20210503115736.2104747-6-gregkh@linuxfoundation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
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
+uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.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-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
--- /dev/null
+From 3ee098f96b8b6c1a98f7f97915f8873164e6af9d Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sun, 9 May 2021 09:13:03 +0200
+Subject: uio_hv_generic: Fix a memory leak in error handling paths
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Link: https://lore.kernel.org/r/4fdaff557deef6f0475d02ba7922ddbaa1ab08a6.1620544055.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From b250f2f7792d15bcde98e0456781e2835556d5fa Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+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 <jroedel@suse.de>
+
+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 <jroedel@suse.de>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+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 <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From c25bbdb564060adaad5c3a8a10765c13487ba6a3 Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Wed, 19 May 2021 15:52:45 +0200
+Subject: x86/sev-es: Forward page-faults which happen during emulation
+
+From: Joerg Roedel <jroedel@suse.de>
+
+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 <jroedel@suse.de>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+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 <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From a50c5bebc99c525e7fbc059988c6a5ab8680cb76 Mon Sep 17 00:00:00 2001
+From: Tom Lendacky <thomas.lendacky@amd.com>
+Date: Mon, 17 May 2021 12:42:33 -0500
+Subject: x86/sev-es: Invalidate the GHCB after completing VMGEXIT
+
+From: Tom Lendacky <thomas.lendacky@amd.com>
+
+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 <thomas.lendacky@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/5a8130462e4f0057ee1184509cd056eedd78742b.1621273353.git.thomas.lendacky@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+ }
--- /dev/null
+From fea63d54f7a3e74f8ab489a8b82413a29849a594 Mon Sep 17 00:00:00 2001
+From: Tom Lendacky <thomas.lendacky@amd.com>
+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 <thomas.lendacky@amd.com>
+
+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 <thomas.lendacky@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/8c07662ec17d3d82e5c53841a1d9e766d3bdbab6.1621273353.git.thomas.lendacky@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Wed, 19 May 2021 15:52:46 +0200
+Subject: x86/sev-es: Use __put_user()/__get_user() for data accesses
+
+From: Joerg Roedel <jroedel@suse.de>
+
+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 <jroedel@suse.de>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+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 <gregkh@linuxfoundation.org>
+---
+ 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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
