From 18047bcfb51cba413f5ff91d769a655aa1c90661 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 3 Jun 2022 19:22:58 +0200 Subject: [PATCH] 5.10-stable patches added patches: bpf-enlarge-offset-check-value-to-int_max-in-bpf_skb_-load-store-_bytes.patch bpf-fix-potential-array-overflow-in-bpf_trampoline_get_progs.patch docs-submitting-patches-fix-crossref-to-the-canonical-patch-format.patch nfs-memory-allocation-failures-are-not-server-fatal-errors.patch nfsd-fix-possible-sleep-during-nfsd4_release_lockowner.patch --- ...nt_max-in-bpf_skb_-load-store-_bytes.patch | 44 +++++++++++ ...overflow-in-bpf_trampoline_get_progs.patch | 75 +++++++++++++++++++ ...ossref-to-the-canonical-patch-format.patch | 43 +++++++++++ ...failures-are-not-server-fatal-errors.patch | 32 ++++++++ ...sleep-during-nfsd4_release_lockowner.patch | 51 +++++++++++++ queue-5.10/series | 5 ++ 6 files changed, 250 insertions(+) create mode 100644 queue-5.10/bpf-enlarge-offset-check-value-to-int_max-in-bpf_skb_-load-store-_bytes.patch create mode 100644 queue-5.10/bpf-fix-potential-array-overflow-in-bpf_trampoline_get_progs.patch create mode 100644 queue-5.10/docs-submitting-patches-fix-crossref-to-the-canonical-patch-format.patch create mode 100644 queue-5.10/nfs-memory-allocation-failures-are-not-server-fatal-errors.patch create mode 100644 queue-5.10/nfsd-fix-possible-sleep-during-nfsd4_release_lockowner.patch diff --git a/queue-5.10/bpf-enlarge-offset-check-value-to-int_max-in-bpf_skb_-load-store-_bytes.patch b/queue-5.10/bpf-enlarge-offset-check-value-to-int_max-in-bpf_skb_-load-store-_bytes.patch new file mode 100644 index 00000000000..5c6eb7cc13e --- /dev/null +++ b/queue-5.10/bpf-enlarge-offset-check-value-to-int_max-in-bpf_skb_-load-store-_bytes.patch @@ -0,0 +1,44 @@ +From 45969b4152c1752089351cd6836a42a566d49bcf Mon Sep 17 00:00:00 2001 +From: Liu Jian +Date: Sat, 16 Apr 2022 18:57:59 +0800 +Subject: bpf: Enlarge offset check value to INT_MAX in bpf_skb_{load,store}_bytes + +From: Liu Jian + +commit 45969b4152c1752089351cd6836a42a566d49bcf upstream. + +The data length of skb frags + frag_list may be greater than 0xffff, and +skb_header_pointer can not handle negative offset. So, here INT_MAX is used +to check the validity of offset. Add the same change to the related function +skb_store_bytes. + +Fixes: 05c74e5e53f6 ("bpf: add bpf_skb_load_bytes helper") +Signed-off-by: Liu Jian +Signed-off-by: Daniel Borkmann +Acked-by: Song Liu +Link: https://lore.kernel.org/bpf/20220416105801.88708-2-liujian56@huawei.com +Signed-off-by: Greg Kroah-Hartman +--- + net/core/filter.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/net/core/filter.c ++++ b/net/core/filter.c +@@ -1687,7 +1687,7 @@ BPF_CALL_5(bpf_skb_store_bytes, struct s + + if (unlikely(flags & ~(BPF_F_RECOMPUTE_CSUM | BPF_F_INVALIDATE_HASH))) + return -EINVAL; +- if (unlikely(offset > 0xffff)) ++ if (unlikely(offset > INT_MAX)) + return -EFAULT; + if (unlikely(bpf_try_make_writable(skb, offset + len))) + return -EFAULT; +@@ -1722,7 +1722,7 @@ BPF_CALL_4(bpf_skb_load_bytes, const str + { + void *ptr; + +- if (unlikely(offset > 0xffff)) ++ if (unlikely(offset > INT_MAX)) + goto err_clear; + + ptr = skb_header_pointer(skb, offset, len, to); diff --git a/queue-5.10/bpf-fix-potential-array-overflow-in-bpf_trampoline_get_progs.patch b/queue-5.10/bpf-fix-potential-array-overflow-in-bpf_trampoline_get_progs.patch new file mode 100644 index 00000000000..e9c6d0b9f4f --- /dev/null +++ b/queue-5.10/bpf-fix-potential-array-overflow-in-bpf_trampoline_get_progs.patch @@ -0,0 +1,75 @@ +From a2aa95b71c9bbec793b5c5fa50f0a80d882b3e8d Mon Sep 17 00:00:00 2001 +From: Yuntao Wang +Date: Sat, 30 Apr 2022 21:08:03 +0800 +Subject: bpf: Fix potential array overflow in bpf_trampoline_get_progs() + +From: Yuntao Wang + +commit a2aa95b71c9bbec793b5c5fa50f0a80d882b3e8d upstream. + +The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does not +include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of +the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline +can exceed BPF_MAX_TRAMP_PROGS. + +When this happens, the assignment '*progs++ = aux->prog' in +bpf_trampoline_get_progs() will cause progs array overflow as the +progs field in the bpf_tramp_progs struct can only hold at most +BPF_MAX_TRAMP_PROGS bpf programs. + +Fixes: 88fd9e5352fe ("bpf: Refactor trampoline update code") +Signed-off-by: Yuntao Wang +Link: https://lore.kernel.org/r/20220430130803.210624-1-ytcoode@gmail.com +Signed-off-by: Alexei Starovoitov +Signed-off-by: Greg Kroah-Hartman +--- + kernel/bpf/trampoline.c | 18 ++++++++++++------ + 1 file changed, 12 insertions(+), 6 deletions(-) + +--- a/kernel/bpf/trampoline.c ++++ b/kernel/bpf/trampoline.c +@@ -378,7 +378,7 @@ int bpf_trampoline_link_prog(struct bpf_ + { + enum bpf_tramp_prog_type kind; + int err = 0; +- int cnt; ++ int cnt = 0, i; + + kind = bpf_attach_type_to_tramp(prog); + mutex_lock(&tr->mutex); +@@ -389,7 +389,10 @@ int bpf_trampoline_link_prog(struct bpf_ + err = -EBUSY; + goto out; + } +- cnt = tr->progs_cnt[BPF_TRAMP_FENTRY] + tr->progs_cnt[BPF_TRAMP_FEXIT]; ++ ++ for (i = 0; i < BPF_TRAMP_MAX; i++) ++ cnt += tr->progs_cnt[i]; ++ + if (kind == BPF_TRAMP_REPLACE) { + /* Cannot attach extension if fentry/fexit are in use. */ + if (cnt) { +@@ -467,16 +470,19 @@ out: + + void bpf_trampoline_put(struct bpf_trampoline *tr) + { ++ int i; ++ + if (!tr) + return; + mutex_lock(&trampoline_mutex); + if (!refcount_dec_and_test(&tr->refcnt)) + goto out; + WARN_ON_ONCE(mutex_is_locked(&tr->mutex)); +- if (WARN_ON_ONCE(!hlist_empty(&tr->progs_hlist[BPF_TRAMP_FENTRY]))) +- goto out; +- if (WARN_ON_ONCE(!hlist_empty(&tr->progs_hlist[BPF_TRAMP_FEXIT]))) +- goto out; ++ ++ for (i = 0; i < BPF_TRAMP_MAX; i++) ++ if (WARN_ON_ONCE(!hlist_empty(&tr->progs_hlist[i]))) ++ goto out; ++ + /* This code will be executed even when the last bpf_tramp_image + * is alive. All progs are detached from the trampoline and the + * trampoline image is patched with jmp into epilogue to skip diff --git a/queue-5.10/docs-submitting-patches-fix-crossref-to-the-canonical-patch-format.patch b/queue-5.10/docs-submitting-patches-fix-crossref-to-the-canonical-patch-format.patch new file mode 100644 index 00000000000..9854ae61dcb --- /dev/null +++ b/queue-5.10/docs-submitting-patches-fix-crossref-to-the-canonical-patch-format.patch @@ -0,0 +1,43 @@ +From 6d5aa418b3bd42cdccc36e94ee199af423ef7c84 Mon Sep 17 00:00:00 2001 +From: Akira Yokosawa +Date: Wed, 27 Apr 2022 18:28:39 +0900 +Subject: docs: submitting-patches: Fix crossref to 'The canonical patch format' + +From: Akira Yokosawa + +commit 6d5aa418b3bd42cdccc36e94ee199af423ef7c84 upstream. + +The reference to `explicit_in_reply_to` is pointless as when the +reference was added in the form of "#15" [1], Section 15) was "The +canonical patch format". +The reference of "#15" had not been properly updated in a couple of +reorganizations during the plain-text SubmittingPatches era. + +Fix it by using `the_canonical_patch_format`. + +[1]: 2ae19acaa50a ("Documentation: Add "how to write a good patch summary" to SubmittingPatches") + +Signed-off-by: Akira Yokosawa +Fixes: 5903019b2a5e ("Documentation/SubmittingPatches: convert it to ReST markup") +Fixes: 9b2c76777acc ("Documentation/SubmittingPatches: enrich the Sphinx output") +Cc: Jonathan Corbet +Cc: Mauro Carvalho Chehab +Cc: stable@vger.kernel.org # v4.9+ +Link: https://lore.kernel.org/r/64e105a5-50be-23f2-6cae-903a2ea98e18@gmail.com +Signed-off-by: Jonathan Corbet +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/process/submitting-patches.rst | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/Documentation/process/submitting-patches.rst ++++ b/Documentation/process/submitting-patches.rst +@@ -71,7 +71,7 @@ as you intend it to. + + The maintainer will thank you if you write your patch description in a + form which can be easily pulled into Linux's source code management +-system, ``git``, as a "commit log". See :ref:`explicit_in_reply_to`. ++system, ``git``, as a "commit log". See :ref:`the_canonical_patch_format`. + + Solve only one problem per patch. If your description starts to get + long, that's a sign that you probably need to split up your patch. diff --git a/queue-5.10/nfs-memory-allocation-failures-are-not-server-fatal-errors.patch b/queue-5.10/nfs-memory-allocation-failures-are-not-server-fatal-errors.patch new file mode 100644 index 00000000000..e3f20a545c9 --- /dev/null +++ b/queue-5.10/nfs-memory-allocation-failures-are-not-server-fatal-errors.patch @@ -0,0 +1,32 @@ +From 452284407c18d8a522c3039339b1860afa0025a8 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Sat, 14 May 2022 10:08:10 -0400 +Subject: NFS: Memory allocation failures are not server fatal errors + +From: Trond Myklebust + +commit 452284407c18d8a522c3039339b1860afa0025a8 upstream. + +We need to filter out ENOMEM in nfs_error_is_fatal_on_server(), because +running out of memory on our client is not a server error. + +Reported-by: Olga Kornievskaia +Fixes: 2dc23afffbca ("NFS: ENOMEM should also be a fatal error.") +Cc: stable@vger.kernel.org +Signed-off-by: Trond Myklebust +Signed-off-by: Anna Schumaker +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfs/internal.h | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/nfs/internal.h ++++ b/fs/nfs/internal.h +@@ -832,6 +832,7 @@ static inline bool nfs_error_is_fatal_on + case 0: + case -ERESTARTSYS: + case -EINTR: ++ case -ENOMEM: + return false; + } + return nfs_error_is_fatal(err); diff --git a/queue-5.10/nfsd-fix-possible-sleep-during-nfsd4_release_lockowner.patch b/queue-5.10/nfsd-fix-possible-sleep-during-nfsd4_release_lockowner.patch new file mode 100644 index 00000000000..1304a74f813 --- /dev/null +++ b/queue-5.10/nfsd-fix-possible-sleep-during-nfsd4_release_lockowner.patch @@ -0,0 +1,51 @@ +From ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b Mon Sep 17 00:00:00 2001 +From: Chuck Lever +Date: Sat, 21 May 2022 19:06:13 -0400 +Subject: NFSD: Fix possible sleep during nfsd4_release_lockowner() + +From: Chuck Lever + +commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b upstream. + +nfsd4_release_lockowner() holds clp->cl_lock when it calls +check_for_locks(). However, check_for_locks() calls nfsd_file_get() +/ nfsd_file_put() to access the backing inode's flc_posix list, and +nfsd_file_put() can sleep if the inode was recently removed. + +Let's instead rely on the stateowner's reference count to gate +whether the release is permitted. This should be a reliable +indication of locks-in-use since file lock operations and +->lm_get_owner take appropriate references, which are released +appropriately when file locks are removed. + +Reported-by: Dai Ngo +Signed-off-by: Chuck Lever +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfsd/nfs4state.c | 12 ++++-------- + 1 file changed, 4 insertions(+), 8 deletions(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -7122,16 +7122,12 @@ nfsd4_release_lockowner(struct svc_rqst + if (sop->so_is_open_owner || !same_owner_str(sop, owner)) + continue; + +- /* see if there are still any locks associated with it */ +- lo = lockowner(sop); +- list_for_each_entry(stp, &sop->so_stateids, st_perstateowner) { +- if (check_for_locks(stp->st_stid.sc_file, lo)) { +- status = nfserr_locks_held; +- spin_unlock(&clp->cl_lock); +- return status; +- } ++ if (atomic_read(&sop->so_count) != 1) { ++ spin_unlock(&clp->cl_lock); ++ return nfserr_locks_held; + } + ++ lo = lockowner(sop); + nfs4_get_stateowner(sop); + break; + } diff --git a/queue-5.10/series b/queue-5.10/series index 41309b77fca..edf5de90179 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -46,3 +46,8 @@ hid-multitouch-add-support-for-google-whiskers-touchpad.patch hid-multitouch-add-quirks-to-enable-lenovo-x12-trackpoint.patch tpm-fix-buffer-access-in-tpm2_get_tpm_pt.patch tpm-ibmvtpm-correct-the-return-value-in-tpm_ibmvtpm_probe.patch +docs-submitting-patches-fix-crossref-to-the-canonical-patch-format.patch +nfs-memory-allocation-failures-are-not-server-fatal-errors.patch +nfsd-fix-possible-sleep-during-nfsd4_release_lockowner.patch +bpf-fix-potential-array-overflow-in-bpf_trampoline_get_progs.patch +bpf-enlarge-offset-check-value-to-int_max-in-bpf_skb_-load-store-_bytes.patch -- 2.47.3