From: Greg Kroah-Hartman Date: Fri, 20 Oct 2023 18:03:55 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.14.328~85 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9edba4eda68023119c038c0f2d76d66ad2053732;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: drm-i915-retry-gtt-fault-when-out-of-fence-registers.patch nvmet-tcp-fix-a-possible-uaf-in-queue-intialization-setup.patch --- diff --git a/queue-5.10/drm-i915-retry-gtt-fault-when-out-of-fence-registers.patch b/queue-5.10/drm-i915-retry-gtt-fault-when-out-of-fence-registers.patch new file mode 100644 index 00000000000..be47ecbbf9a --- /dev/null +++ b/queue-5.10/drm-i915-retry-gtt-fault-when-out-of-fence-registers.patch @@ -0,0 +1,52 @@ +From e339c6d628fe66c9b64bf31040a55770952aec57 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +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ä + +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ä +Link: https://patchwork.freedesktop.org/patch/msgid/20231012132801.16292-1-ville.syrjala@linux.intel.com +Reviewed-by: Andi Shyti +(cherry picked from commit 7f403caabe811b88ab0de3811ff3f4782c415761) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman +--- + 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: diff --git a/queue-5.10/nvmet-tcp-fix-a-possible-uaf-in-queue-intialization-setup.patch b/queue-5.10/nvmet-tcp-fix-a-possible-uaf-in-queue-intialization-setup.patch new file mode 100644 index 00000000000..20f2fb68809 --- /dev/null +++ b/queue-5.10/nvmet-tcp-fix-a-possible-uaf-in-queue-intialization-setup.patch @@ -0,0 +1,61 @@ +From d920abd1e7c4884f9ecd0749d1921b7ab19ddfbd Mon Sep 17 00:00:00 2001 +From: Sagi Grimberg +Date: Mon, 2 Oct 2023 13:54:28 +0300 +Subject: nvmet-tcp: Fix a possible UAF in queue intialization setup + +From: Sagi Grimberg + +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 +Tested-by: Alon Zahavi +Signed-off-by: Sagi Grimberg +Reviewed-by: Christoph Hellwig +Reviewed-by: Chaitanya Kulkarni +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.10/series b/queue-5.10/series index d8091c131e2..386142c3faa 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -104,3 +104,5 @@ x86-sev-check-iobm-for-ioio-exceptions-from-user-space.patch x86-sev-check-for-user-space-ioio-pointing-to-kernel-space.patch tcp-check-mptcp-level-constraints-for-backlog-coalescing.patch netfilter-nft_payload-fix-wrong-mac-header-matching.patch +nvmet-tcp-fix-a-possible-uaf-in-queue-intialization-setup.patch +drm-i915-retry-gtt-fault-when-out-of-fence-registers.patch