--- /dev/null
+From e339c6d628fe66c9b64bf31040a55770952aec57 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Thu, 12 Oct 2023 16:28:01 +0300
+Subject: drm/i915: Retry gtt fault when out of fence registers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit e339c6d628fe66c9b64bf31040a55770952aec57 upstream.
+
+If we can't find a free fence register to handle a fault in the GMADR
+range just return VM_FAULT_NOPAGE without populating the PTE so that
+userspace will retry the access and trigger another fault. Eventually
+we should find a free fence and the fault will get properly handled.
+
+A further improvement idea might be to reserve a fence (or one per CPU?)
+for the express purpose of handling faults without having to retry. But
+that would require some additional work.
+
+Looks like this may have gotten broken originally by
+commit 39965b376601 ("drm/i915: don't trash the gtt when running out of fences")
+as that changed the errno to -EDEADLK which wasn't handle by the gtt
+fault code either. But later in commit 2feeb52859fc ("drm/i915/gt: Fix
+-EDEADLK handling regression") I changed it again to -ENOBUFS as -EDEADLK
+was now getting used for the ww mutex dance. So this fix only makes
+sense after that last commit.
+
+Cc: stable@vger.kernel.org
+Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9479
+Fixes: 2feeb52859fc ("drm/i915/gt: Fix -EDEADLK handling regression")
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20231012132801.16292-1-ville.syrjala@linux.intel.com
+Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
+(cherry picked from commit 7f403caabe811b88ab0de3811ff3f4782c415761)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
++++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+@@ -222,6 +222,7 @@ static vm_fault_t i915_error_to_vmf_faul
+ case 0:
+ case -EAGAIN:
+ case -ENOSPC: /* transient failure to evict? */
++ case -ENOBUFS: /* temporarily out of fences? */
+ case -ERESTARTSYS:
+ case -EINTR:
+ case -EBUSY:
--- /dev/null
+From d920abd1e7c4884f9ecd0749d1921b7ab19ddfbd Mon Sep 17 00:00:00 2001
+From: Sagi Grimberg <sagi@grimberg.me>
+Date: Mon, 2 Oct 2023 13:54:28 +0300
+Subject: nvmet-tcp: Fix a possible UAF in queue intialization setup
+
+From: Sagi Grimberg <sagi@grimberg.me>
+
+commit d920abd1e7c4884f9ecd0749d1921b7ab19ddfbd upstream.
+
+From Alon:
+"Due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel,
+a malicious user can cause a UAF and a double free, which may lead to
+RCE (may also lead to an LPE in case the attacker already has local
+privileges)."
+
+Hence, when a queue initialization fails after the ahash requests are
+allocated, it is guaranteed that the queue removal async work will be
+called, hence leave the deallocation to the queue removal.
+
+Also, be extra careful not to continue processing the socket, so set
+queue rcv_state to NVMET_TCP_RECV_ERR upon a socket error.
+
+Cc: stable@vger.kernel.org
+Reported-by: Alon Zahavi <zahavi.alon@gmail.com>
+Tested-by: Alon Zahavi <zahavi.alon@gmail.com>
+Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/target/tcp.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/drivers/nvme/target/tcp.c
++++ b/drivers/nvme/target/tcp.c
+@@ -336,6 +336,7 @@ static void nvmet_tcp_fatal_error(struct
+
+ static void nvmet_tcp_socket_error(struct nvmet_tcp_queue *queue, int status)
+ {
++ queue->rcv_state = NVMET_TCP_RECV_ERR;
+ if (status == -EPIPE || status == -ECONNRESET)
+ kernel_sock_shutdown(queue->sock, SHUT_RDWR);
+ else
+@@ -882,15 +883,11 @@ static int nvmet_tcp_handle_icreq(struct
+ iov.iov_len = sizeof(*icresp);
+ ret = kernel_sendmsg(queue->sock, &msg, &iov, 1, iov.iov_len);
+ if (ret < 0)
+- goto free_crypto;
++ return ret; /* queue removal will cleanup */
+
+ queue->state = NVMET_TCP_Q_LIVE;
+ nvmet_prepare_receive_pdu(queue);
+ return 0;
+-free_crypto:
+- if (queue->hdr_digest || queue->data_digest)
+- nvmet_tcp_free_crypto(queue);
+- return ret;
+ }
+
+ static void nvmet_tcp_handle_req_failure(struct nvmet_tcp_queue *queue,
projects / thirdparty / kernel / stable-queue.git / commitdiff
