From f3738d05582bc6be98c33de70421f2bfbd07598b Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 9 Sep 2023 22:54:48 +0100 Subject: [PATCH] 5.10-stable patches added patches: dccp-fix-out-of-bounds-access-in-dccp-error-handler.patch dlm-fix-plock-lookup-when-using-multiple-lockspaces.patch fsverity-skip-pkcs-7-parser-when-keyring-is-empty.patch net-handle-arphrd_ppp-in-dev_is_mac_header_xmit.patch pstore-ram-check-start-of-empty-przs-during-init.patch x.509-if-signature-is-unsupported-skip-validation.patch --- ...-bounds-access-in-dccp-error-handler.patch | 84 +++++++++++++++++++ ...ookup-when-using-multiple-lockspaces.patch | 57 +++++++++++++ ...-pkcs-7-parser-when-keyring-is-empty.patch | 52 ++++++++++++ ...arphrd_ppp-in-dev_is_mac_header_xmit.patch | 38 +++++++++ ...heck-start-of-empty-przs-during-init.patch | 60 +++++++++++++ queue-5.10/series | 6 ++ ...ature-is-unsupported-skip-validation.patch | 45 ++++++++++ 7 files changed, 342 insertions(+) create mode 100644 queue-5.10/dccp-fix-out-of-bounds-access-in-dccp-error-handler.patch create mode 100644 queue-5.10/dlm-fix-plock-lookup-when-using-multiple-lockspaces.patch create mode 100644 queue-5.10/fsverity-skip-pkcs-7-parser-when-keyring-is-empty.patch create mode 100644 queue-5.10/net-handle-arphrd_ppp-in-dev_is_mac_header_xmit.patch create mode 100644 queue-5.10/pstore-ram-check-start-of-empty-przs-during-init.patch create mode 100644 queue-5.10/x.509-if-signature-is-unsupported-skip-validation.patch diff --git a/queue-5.10/dccp-fix-out-of-bounds-access-in-dccp-error-handler.patch b/queue-5.10/dccp-fix-out-of-bounds-access-in-dccp-error-handler.patch new file mode 100644 index 00000000000..46138a3dc5e --- /dev/null +++ b/queue-5.10/dccp-fix-out-of-bounds-access-in-dccp-error-handler.patch @@ -0,0 +1,84 @@ +From 977ad86c2a1bcaf58f01ab98df5cc145083c489c Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Fri, 25 Aug 2023 15:32:41 +0200 +Subject: dccp: Fix out of bounds access in DCCP error handler + +From: Jann Horn + +commit 977ad86c2a1bcaf58f01ab98df5cc145083c489c upstream. + +There was a previous attempt to fix an out-of-bounds access in the DCCP +error handlers, but that fix assumed that the error handlers only want +to access the first 8 bytes of the DCCP header. Actually, they also look +at the DCCP sequence number, which is stored beyond 8 bytes, so an +explicit pskb_may_pull() is required. + +Fixes: 6706a97fec96 ("dccp: fix out of bound access in dccp_v4_err()") +Fixes: 1aa9d1a0e7ee ("ipv6: dccp: fix out of bound access in dccp_v6_err()") +Cc: stable@vger.kernel.org +Signed-off-by: Jann Horn +Reviewed-by: Kuniyuki Iwashima +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/dccp/ipv4.c | 13 +++++++++---- + net/dccp/ipv6.c | 15 ++++++++++----- + 2 files changed, 19 insertions(+), 9 deletions(-) + +--- a/net/dccp/ipv4.c ++++ b/net/dccp/ipv4.c +@@ -243,12 +243,17 @@ static int dccp_v4_err(struct sk_buff *s + int err; + struct net *net = dev_net(skb->dev); + +- /* Only need dccph_dport & dccph_sport which are the first +- * 4 bytes in dccp header. ++ /* For the first __dccp_basic_hdr_len() check, we only need dh->dccph_x, ++ * which is in byte 7 of the dccp header. + * Our caller (icmp_socket_deliver()) already pulled 8 bytes for us. ++ * ++ * Later on, we want to access the sequence number fields, which are ++ * beyond 8 bytes, so we have to pskb_may_pull() ourselves. + */ +- BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_sport) > 8); +- BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_dport) > 8); ++ dh = (struct dccp_hdr *)(skb->data + offset); ++ if (!pskb_may_pull(skb, offset + __dccp_basic_hdr_len(dh))) ++ return -EINVAL; ++ iph = (struct iphdr *)skb->data; + dh = (struct dccp_hdr *)(skb->data + offset); + + sk = __inet_lookup_established(net, &dccp_hashinfo, +--- a/net/dccp/ipv6.c ++++ b/net/dccp/ipv6.c +@@ -67,7 +67,7 @@ static inline __u64 dccp_v6_init_sequenc + static int dccp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt, + u8 type, u8 code, int offset, __be32 info) + { +- const struct ipv6hdr *hdr = (const struct ipv6hdr *)skb->data; ++ const struct ipv6hdr *hdr; + const struct dccp_hdr *dh; + struct dccp_sock *dp; + struct ipv6_pinfo *np; +@@ -76,12 +76,17 @@ static int dccp_v6_err(struct sk_buff *s + __u64 seq; + struct net *net = dev_net(skb->dev); + +- /* Only need dccph_dport & dccph_sport which are the first +- * 4 bytes in dccp header. ++ /* For the first __dccp_basic_hdr_len() check, we only need dh->dccph_x, ++ * which is in byte 7 of the dccp header. + * Our caller (icmpv6_notify()) already pulled 8 bytes for us. ++ * ++ * Later on, we want to access the sequence number fields, which are ++ * beyond 8 bytes, so we have to pskb_may_pull() ourselves. + */ +- BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_sport) > 8); +- BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_dport) > 8); ++ dh = (struct dccp_hdr *)(skb->data + offset); ++ if (!pskb_may_pull(skb, offset + __dccp_basic_hdr_len(dh))) ++ return -EINVAL; ++ hdr = (const struct ipv6hdr *)skb->data; + dh = (struct dccp_hdr *)(skb->data + offset); + + sk = __inet6_lookup_established(net, &dccp_hashinfo, diff --git a/queue-5.10/dlm-fix-plock-lookup-when-using-multiple-lockspaces.patch b/queue-5.10/dlm-fix-plock-lookup-when-using-multiple-lockspaces.patch new file mode 100644 index 00000000000..eeab1bfd7f5 --- /dev/null +++ b/queue-5.10/dlm-fix-plock-lookup-when-using-multiple-lockspaces.patch @@ -0,0 +1,57 @@ +From 7c53e847ff5e97f033fdd31f71949807633d506b Mon Sep 17 00:00:00 2001 +From: Alexander Aring +Date: Thu, 24 Aug 2023 16:51:42 -0400 +Subject: dlm: fix plock lookup when using multiple lockspaces + +From: Alexander Aring + +commit 7c53e847ff5e97f033fdd31f71949807633d506b upstream. + +All posix lock ops, for all lockspaces (gfs2 file systems) are +sent to userspace (dlm_controld) through a single misc device. +The dlm_controld daemon reads the ops from the misc device +and sends them to other cluster nodes using separate, per-lockspace +cluster api communication channels. The ops for a single lockspace +are ordered at this level, so that the results are received in +the same sequence that the requests were sent. When the results +are sent back to the kernel via the misc device, they are again +funneled through the single misc device for all lockspaces. When +the dlm code in the kernel processes the results from the misc +device, these results will be returned in the same sequence that +the requests were sent, on a per-lockspace basis. A recent change +in this request/reply matching code missed the "per-lockspace" +check (fsid comparison) when matching request and reply, so replies +could be incorrectly matched to requests from other lockspaces. + +Cc: stable@vger.kernel.org +Reported-by: Barry Marson +Fixes: 57e2c2f2d94c ("fs: dlm: fix mismatch of plock results from userspace") +Signed-off-by: Alexander Aring +Signed-off-by: David Teigland +Signed-off-by: Greg Kroah-Hartman +--- + fs/dlm/plock.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/fs/dlm/plock.c ++++ b/fs/dlm/plock.c +@@ -466,7 +466,8 @@ static ssize_t dev_write(struct file *fi + } + } else { + list_for_each_entry(iter, &recv_list, list) { +- if (!iter->info.wait) { ++ if (!iter->info.wait && ++ iter->info.fsid == info.fsid) { + op = iter; + break; + } +@@ -478,8 +479,7 @@ static ssize_t dev_write(struct file *fi + if (info.wait) + WARN_ON(op->info.optype != DLM_PLOCK_OP_LOCK); + else +- WARN_ON(op->info.fsid != info.fsid || +- op->info.number != info.number || ++ WARN_ON(op->info.number != info.number || + op->info.owner != info.owner || + op->info.optype != info.optype); + diff --git a/queue-5.10/fsverity-skip-pkcs-7-parser-when-keyring-is-empty.patch b/queue-5.10/fsverity-skip-pkcs-7-parser-when-keyring-is-empty.patch new file mode 100644 index 00000000000..73e47687c8d --- /dev/null +++ b/queue-5.10/fsverity-skip-pkcs-7-parser-when-keyring-is-empty.patch @@ -0,0 +1,52 @@ +From 919dc320956ea353a7fb2d84265195ad5ef525ac Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 1 Aug 2023 21:03:53 -0700 +Subject: fsverity: skip PKCS#7 parser when keyring is empty + +From: Eric Biggers + +commit 919dc320956ea353a7fb2d84265195ad5ef525ac upstream. + +If an fsverity builtin signature is given for a file but the +".fs-verity" keyring is empty, there's no real reason to run the PKCS#7 +parser. Skip this to avoid the PKCS#7 attack surface when builtin +signature support is configured into the kernel but is not being used. + +This is a hardening improvement, not a fix per se, but I've added +Fixes and Cc stable to get it out to more users. + +Fixes: 432434c9f8e1 ("fs-verity: support builtin file signatures") +Cc: stable@vger.kernel.org +Reviewed-by: Jarkko Sakkinen +Link: https://lore.kernel.org/r/20230820173237.2579-1-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + fs/verity/signature.c | 16 ++++++++++++++++ + 1 file changed, 16 insertions(+) + +--- a/fs/verity/signature.c ++++ b/fs/verity/signature.c +@@ -61,6 +61,22 @@ int fsverity_verify_signature(const stru + return -EBADMSG; + } + ++ if (fsverity_keyring->keys.nr_leaves_on_tree == 0) { ++ /* ++ * The ".fs-verity" keyring is empty, due to builtin signatures ++ * being supported by the kernel but not actually being used. ++ * In this case, verify_pkcs7_signature() would always return an ++ * error, usually ENOKEY. It could also be EBADMSG if the ++ * PKCS#7 is malformed, but that isn't very important to ++ * distinguish. So, just skip to ENOKEY to avoid the attack ++ * surface of the PKCS#7 parser, which would otherwise be ++ * reachable by any task able to execute FS_IOC_ENABLE_VERITY. ++ */ ++ fsverity_err(inode, ++ "fs-verity keyring is empty, rejecting signed file!"); ++ return -ENOKEY; ++ } ++ + d = kzalloc(sizeof(*d) + hash_alg->digest_size, GFP_KERNEL); + if (!d) + return -ENOMEM; diff --git a/queue-5.10/net-handle-arphrd_ppp-in-dev_is_mac_header_xmit.patch b/queue-5.10/net-handle-arphrd_ppp-in-dev_is_mac_header_xmit.patch new file mode 100644 index 00000000000..7a061a0765d --- /dev/null +++ b/queue-5.10/net-handle-arphrd_ppp-in-dev_is_mac_header_xmit.patch @@ -0,0 +1,38 @@ +From a4f39c9f14a634e4cd35fcd338c239d11fcc73fc Mon Sep 17 00:00:00 2001 +From: Nicolas Dichtel +Date: Wed, 23 Aug 2023 15:41:02 +0200 +Subject: net: handle ARPHRD_PPP in dev_is_mac_header_xmit() + +From: Nicolas Dichtel + +commit a4f39c9f14a634e4cd35fcd338c239d11fcc73fc upstream. + +The goal is to support a bpf_redirect() from an ethernet device (ingress) +to a ppp device (egress). +The l2 header is added automatically by the ppp driver, thus the ethernet +header should be removed. + +CC: stable@vger.kernel.org +Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper") +Signed-off-by: Nicolas Dichtel +Tested-by: Siwar Zitouni +Reviewed-by: Guillaume Nault +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/if_arp.h | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/include/linux/if_arp.h ++++ b/include/linux/if_arp.h +@@ -52,6 +52,10 @@ static inline bool dev_is_mac_header_xmi + case ARPHRD_NONE: + case ARPHRD_RAWIP: + case ARPHRD_PIMREG: ++ /* PPP adds its l2 header automatically in ppp_start_xmit(). ++ * This makes it look like an l3 device to __bpf_redirect() and tcf_mirred_init(). ++ */ ++ case ARPHRD_PPP: + return false; + default: + return true; diff --git a/queue-5.10/pstore-ram-check-start-of-empty-przs-during-init.patch b/queue-5.10/pstore-ram-check-start-of-empty-przs-during-init.patch new file mode 100644 index 00000000000..c7dcb9133b9 --- /dev/null +++ b/queue-5.10/pstore-ram-check-start-of-empty-przs-during-init.patch @@ -0,0 +1,60 @@ +From fe8c3623ab06603eb760444a032d426542212021 Mon Sep 17 00:00:00 2001 +From: Enlin Mu +Date: Tue, 1 Aug 2023 14:04:32 +0800 +Subject: pstore/ram: Check start of empty przs during init + +From: Enlin Mu + +commit fe8c3623ab06603eb760444a032d426542212021 upstream. + +After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as +valid"), initialization would assume a prz was valid after seeing that +the buffer_size is zero (regardless of the buffer start position). This +unchecked start value means it could be outside the bounds of the buffer, +leading to future access panics when written to: + + sysdump_panic_event+0x3b4/0x5b8 + atomic_notifier_call_chain+0x54/0x90 + panic+0x1c8/0x42c + die+0x29c/0x2a8 + die_kernel_fault+0x68/0x78 + __do_kernel_fault+0x1c4/0x1e0 + do_bad_area+0x40/0x100 + do_translation_fault+0x68/0x80 + do_mem_abort+0x68/0xf8 + el1_da+0x1c/0xc0 + __raw_writeb+0x38/0x174 + __memcpy_toio+0x40/0xac + persistent_ram_update+0x44/0x12c + persistent_ram_write+0x1a8/0x1b8 + ramoops_pstore_write+0x198/0x1e8 + pstore_console_write+0x94/0xe0 + ... + +To avoid this, also check if the prz start is 0 during the initialization +phase. If not, the next prz sanity check case will discover it (start > +size) and zap the buffer back to a sane state. + +Fixes: 30696378f68a ("pstore/ram: Do not treat empty buffers as valid") +Cc: Yunlong Xing +Cc: stable@vger.kernel.org +Signed-off-by: Enlin Mu +Link: https://lore.kernel.org/r/20230801060432.1307717-1-yunlong.xing@unisoc.com +[kees: update commit log with backtrace and clarifications] +Signed-off-by: Kees Cook +Signed-off-by: Greg Kroah-Hartman +--- + fs/pstore/ram_core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/pstore/ram_core.c ++++ b/fs/pstore/ram_core.c +@@ -504,7 +504,7 @@ static int persistent_ram_post_init(stru + sig ^= PERSISTENT_RAM_SIG; + + if (prz->buffer->sig == sig) { +- if (buffer_size(prz) == 0) { ++ if (buffer_size(prz) == 0 && buffer_start(prz) == 0) { + pr_debug("found existing empty buffer\n"); + return 0; + } diff --git a/queue-5.10/series b/queue-5.10/series index 4d56f30e2fa..d5f1e458869 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -294,3 +294,9 @@ revert-pci-mark-nvidia-t4-gpus-to-avoid-bus-reset.patch procfs-block-chmod-on-proc-thread-self-comm.patch parisc-fix-proc-cpuinfo-output-for-lscpu.patch bpf-fix-issue-in-verifying-allow_ptr_leaks.patch +dlm-fix-plock-lookup-when-using-multiple-lockspaces.patch +dccp-fix-out-of-bounds-access-in-dccp-error-handler.patch +x.509-if-signature-is-unsupported-skip-validation.patch +net-handle-arphrd_ppp-in-dev_is_mac_header_xmit.patch +fsverity-skip-pkcs-7-parser-when-keyring-is-empty.patch +pstore-ram-check-start-of-empty-przs-during-init.patch diff --git a/queue-5.10/x.509-if-signature-is-unsupported-skip-validation.patch b/queue-5.10/x.509-if-signature-is-unsupported-skip-validation.patch new file mode 100644 index 00000000000..f2e96a0947a --- /dev/null +++ b/queue-5.10/x.509-if-signature-is-unsupported-skip-validation.patch @@ -0,0 +1,45 @@ +From ef5b52a631f8c18353e80ccab8408b963305510c Mon Sep 17 00:00:00 2001 +From: Thore Sommer +Date: Tue, 15 Aug 2023 14:29:42 +0300 +Subject: X.509: if signature is unsupported skip validation + +From: Thore Sommer + +commit ef5b52a631f8c18353e80ccab8408b963305510c upstream. + +When the hash algorithm for the signature is not available the digest size +is 0 and the signature in the certificate is marked as unsupported. + +When validating a self-signed certificate, this needs to be checked, +because otherwise trying to validate the signature will fail with an +warning: + +Loading compiled-in X.509 certificates +WARNING: CPU: 0 PID: 1 at crypto/rsa-pkcs1pad.c:537 \ +pkcs1pad_verify+0x46/0x12c +... +Problem loading in-kernel X.509 certificate (-22) + +Signed-off-by: Thore Sommer +Cc: stable@vger.kernel.org # v4.7+ +Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier") +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + crypto/asymmetric_keys/x509_public_key.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/crypto/asymmetric_keys/x509_public_key.c ++++ b/crypto/asymmetric_keys/x509_public_key.c +@@ -132,6 +132,11 @@ int x509_check_for_self_signed(struct x5 + if (strcmp(cert->pub->pkey_algo, cert->sig->pkey_algo) != 0) + goto out; + ++ if (cert->unsupported_sig) { ++ ret = 0; ++ goto out; ++ } ++ + ret = public_key_verify_signature(cert->pub, cert->sig); + if (ret < 0) { + if (ret == -ENOPKG) { -- 2.47.3