--- /dev/null
+From ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 Mon Sep 17 00:00:00 2001
+From: Antoine Tenart <atenart@kernel.org>
+Date: Tue, 26 Mar 2024 12:33:59 +0100
+Subject: gro: fix ownership transfer
+
+From: Antoine Tenart <atenart@kernel.org>
+
+commit ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 upstream.
+
+If packets are GROed with fraglist they might be segmented later on and
+continue their journey in the stack. In skb_segment_list those skbs can
+be reused as-is. This is an issue as their destructor was removed in
+skb_gro_receive_list but not the reference to their socket, and then
+they can't be orphaned. Fix this by also removing the reference to the
+socket.
+
+For example this could be observed,
+
+ kernel BUG at include/linux/skbuff.h:3131! (skb_orphan)
+ RIP: 0010:ip6_rcv_core+0x11bc/0x19a0
+ Call Trace:
+ ipv6_list_rcv+0x250/0x3f0
+ __netif_receive_skb_list_core+0x49d/0x8f0
+ netif_receive_skb_list_internal+0x634/0xd40
+ napi_complete_done+0x1d2/0x7d0
+ gro_cell_poll+0x118/0x1f0
+
+A similar construction is found in skb_gro_receive, apply the same
+change there.
+
+Fixes: 5e10da5385d2 ("skbuff: allow 'slow_gro' for skb carring sock reference")
+Signed-off-by: Antoine Tenart <atenart@kernel.org>
+Reviewed-by: Willem de Bruijn <willemb@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+
+---
+ net/core/skbuff.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/net/core/skbuff.c
++++ b/net/core/skbuff.c
+@@ -3976,8 +3976,9 @@ int skb_gro_receive_list(struct sk_buff
+ NAPI_GRO_CB(p)->count++;
+ p->data_len += skb->len;
+
+- /* sk owenrship - if any - completely transferred to the aggregated packet */
++ /* sk ownership - if any - completely transferred to the aggregated packet */
+ skb->destructor = NULL;
++ skb->sk = NULL;
+ p->truesize += skb->truesize;
+ p->len += skb->len;
+
+@@ -4425,8 +4426,9 @@ int skb_gro_receive(struct sk_buff *p, s
+ }
+
+ merge:
+- /* sk owenrship - if any - completely transferred to the aggregated packet */
++ /* sk ownership - if any - completely transferred to the aggregated packet */
+ skb->destructor = NULL;
++ skb->sk = NULL;
+ delta_truesize = skb->truesize;
+ if (offset > headlen) {
+ unsigned int eat = offset - headlen;
--- /dev/null
+From 65291dcfcf8936e1b23cfd7718fdfde7cfaf7706 Mon Sep 17 00:00:00 2001
+From: David Hildenbrand <david@redhat.com>
+Date: Tue, 26 Mar 2024 15:32:08 +0100
+Subject: mm/secretmem: fix GUP-fast succeeding on secretmem folios
+
+From: David Hildenbrand <david@redhat.com>
+
+commit 65291dcfcf8936e1b23cfd7718fdfde7cfaf7706 upstream.
+
+folio_is_secretmem() currently relies on secretmem folios being LRU
+folios, to save some cycles.
+
+However, folios might reside in a folio batch without the LRU flag set, or
+temporarily have their LRU flag cleared. Consequently, the LRU flag is
+unreliable for this purpose.
+
+In particular, this is the case when secretmem_fault() allocates a fresh
+page and calls filemap_add_folio()->folio_add_lru(). The folio might be
+added to the per-cpu folio batch and won't get the LRU flag set until the
+batch was drained using e.g., lru_add_drain().
+
+Consequently, folio_is_secretmem() might not detect secretmem folios and
+GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel
+when we would later try reading/writing to the folio, because the folio
+has been unmapped from the directmap.
+
+Fix it by removing that unreliable check.
+
+Link: https://lkml.kernel.org/r/20240326143210.291116-2-david@redhat.com
+Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas")
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Reported-by: xingwei lee <xrivendell7@gmail.com>
+Reported-by: yue sun <samsun1006219@gmail.com>
+Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2rmz0HQ@mail.gmail.com/
+Debugged-by: Miklos Szeredi <miklos@szeredi.hu>
+Tested-by: Miklos Szeredi <mszeredi@redhat.com>
+Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org>
+Cc: Lorenzo Stoakes <lstoakes@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/secretmem.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/linux/secretmem.h
++++ b/include/linux/secretmem.h
+@@ -14,10 +14,10 @@ static inline bool page_is_secretmem(str
+ * Using page_mapping() is quite slow because of the actual call
+ * instruction and repeated compound_head(page) inside the
+ * page_mapping() function.
+- * We know that secretmem pages are not compound and LRU so we can
++ * We know that secretmem pages are not compound, so we can
+ * save a couple of cycles here.
+ */
+- if (PageCompound(page) || !PageLRU(page))
++ if (PageCompound(page))
+ return false;
+
+ mapping = (struct address_space *)
--- /dev/null
+From 31a5978243d24d77be4bacca56c78a0fbc43b00d Mon Sep 17 00:00:00 2001
+From: "min15.li" <min15.li@samsung.com>
+Date: Fri, 26 May 2023 17:06:56 +0000
+Subject: nvme: fix miss command type check
+
+From: min15.li <min15.li@samsung.com>
+
+commit 31a5978243d24d77be4bacca56c78a0fbc43b00d upstream.
+
+In the function nvme_passthru_end(), only the value of the command
+opcode is checked, without checking the command type (IO command or
+Admin command). When we send a Dataset Management command (The opcode
+of the Dataset Management command is the same as the Set Feature
+command), kernel thinks it is a set feature command, then sets the
+controller's keep alive interval, and calls nvme_keep_alive_work().
+
+Signed-off-by: min15.li <min15.li@samsung.com>
+Reviewed-by: Kanchan Joshi <joshi.k@samsung.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Fixes: b58da2d270db ("nvme: update keep alive interval when kato is modified")
+Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/host/core.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/nvme/host/core.c
++++ b/drivers/nvme/host/core.c
+@@ -1185,7 +1185,7 @@ static u32 nvme_passthru_start(struct nv
+ return effects;
+ }
+
+-static void nvme_passthru_end(struct nvme_ctrl *ctrl, u32 effects,
++static void nvme_passthru_end(struct nvme_ctrl *ctrl, struct nvme_ns *ns, u32 effects,
+ struct nvme_command *cmd, int status)
+ {
+ if (effects & NVME_CMD_EFFECTS_CSE_MASK) {
+@@ -1201,6 +1201,8 @@ static void nvme_passthru_end(struct nvm
+ nvme_queue_scan(ctrl);
+ flush_work(&ctrl->scan_work);
+ }
++ if (ns)
++ return;
+
+ switch (cmd->common.opcode) {
+ case nvme_admin_set_features:
+@@ -1235,7 +1237,7 @@ int nvme_execute_passthru_rq(struct requ
+ effects = nvme_passthru_start(ctrl, ns, cmd->common.opcode);
+ ret = nvme_execute_rq(disk, rq, false);
+ if (effects) /* nothing to be done for zero cmd effects */
+- nvme_passthru_end(ctrl, effects, cmd, ret);
++ nvme_passthru_end(ctrl, ns, effects, cmd, ret);
+
+ return ret;
+ }
x86-bugs-fix-the-srso-mitigation-on-zen3-4.patch
x86-retpoline-do-the-necessary-fixup-to-the-zen3-4-srso-return-thunk-for-srso.patch
mptcp-don-t-account-accept-of-non-mpc-client-as-fallback-to-tcp.patch
+mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.patch
+gro-fix-ownership-transfer.patch
+nvme-fix-miss-command-type-check.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
