From: Greg Kroah-Hartman Date: Mon, 8 Apr 2024 11:37:14 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v5.15.154~24 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=488378359a7dae1290defd005329f72288563f38;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: gro-fix-ownership-transfer.patch mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.patch nvme-fix-miss-command-type-check.patch --- diff --git a/queue-5.15/gro-fix-ownership-transfer.patch b/queue-5.15/gro-fix-ownership-transfer.patch new file mode 100644 index 00000000000..97e89abb10a --- /dev/null +++ b/queue-5.15/gro-fix-ownership-transfer.patch @@ -0,0 +1,65 @@ +From ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 Mon Sep 17 00:00:00 2001 +From: Antoine Tenart +Date: Tue, 26 Mar 2024 12:33:59 +0100 +Subject: gro: fix ownership transfer + +From: Antoine Tenart + +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 +Reviewed-by: Willem de Bruijn +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + +--- + 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; diff --git a/queue-5.15/mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.patch b/queue-5.15/mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.patch new file mode 100644 index 00000000000..c46ba573e97 --- /dev/null +++ b/queue-5.15/mm-secretmem-fix-gup-fast-succeeding-on-secretmem-folios.patch @@ -0,0 +1,61 @@ +From 65291dcfcf8936e1b23cfd7718fdfde7cfaf7706 Mon Sep 17 00:00:00 2001 +From: David Hildenbrand +Date: Tue, 26 Mar 2024 15:32:08 +0100 +Subject: mm/secretmem: fix GUP-fast succeeding on secretmem folios + +From: David Hildenbrand + +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 +Reported-by: xingwei lee +Reported-by: yue sun +Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2rmz0HQ@mail.gmail.com/ +Debugged-by: Miklos Szeredi +Tested-by: Miklos Szeredi +Reviewed-by: Mike Rapoport (IBM) +Cc: Lorenzo Stoakes +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: David Hildenbrand +Signed-off-by: Greg Kroah-Hartman +--- + 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 *) diff --git a/queue-5.15/nvme-fix-miss-command-type-check.patch b/queue-5.15/nvme-fix-miss-command-type-check.patch new file mode 100644 index 00000000000..b612339dc72 --- /dev/null +++ b/queue-5.15/nvme-fix-miss-command-type-check.patch @@ -0,0 +1,56 @@ +From 31a5978243d24d77be4bacca56c78a0fbc43b00d Mon Sep 17 00:00:00 2001 +From: "min15.li" +Date: Fri, 26 May 2023 17:06:56 +0000 +Subject: nvme: fix miss command type check + +From: min15.li + +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 +Reviewed-by: Kanchan Joshi +Reviewed-by: Christoph Hellwig +Signed-off-by: Keith Busch +Fixes: b58da2d270db ("nvme: update keep alive interval when kato is modified") +Signed-off-by: Tokunori Ikegami +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.15/series b/queue-5.15/series index 5e7032bc50e..86616597460 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -685,3 +685,6 @@ riscv-process-fix-kernel-gp-leakage.patch 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