From: Greg Kroah-Hartman Date: Thu, 15 Aug 2024 12:38:31 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v4.19.320~25 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2ff1d0cb2d9d7a95660f141d111f2689a43878a3;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: cgroup-move-rcu_head-up-near-the-top-of-cgroup_root.patch mm-debug_vm_pgtable-drop-random_orvalue-trick.patch revert-input-bcm5974-check-endpoint-type-before-starting-traffic.patch revert-jfs-fix-shift-out-of-bounds-in-dbjoin.patch --- diff --git a/queue-6.6/cgroup-move-rcu_head-up-near-the-top-of-cgroup_root.patch b/queue-6.6/cgroup-move-rcu_head-up-near-the-top-of-cgroup_root.patch new file mode 100644 index 00000000000..db86ffea8da --- /dev/null +++ b/queue-6.6/cgroup-move-rcu_head-up-near-the-top-of-cgroup_root.patch @@ -0,0 +1,66 @@ +From a7fb0423c201ba12815877a0b5a68a6a1710b23a Mon Sep 17 00:00:00 2001 +From: Waiman Long +Date: Thu, 7 Dec 2023 08:46:14 -0500 +Subject: cgroup: Move rcu_head up near the top of cgroup_root +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Waiman Long + +commit a7fb0423c201ba12815877a0b5a68a6a1710b23a upstream. + +Commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU +safe") adds a new rcu_head to the cgroup_root structure and kvfree_rcu() +for freeing the cgroup_root. + +The current implementation of kvfree_rcu(), however, has the limitation +that the offset of the rcu_head structure within the larger data +structure must be less than 4096 or the compilation will fail. See the +macro definition of __is_kvfree_rcu_offset() in include/linux/rcupdate.h +for more information. + +By putting rcu_head below the large cgroup structure, any change to the +cgroup structure that makes it larger run the risk of causing build +failure under certain configurations. Commit 77070eeb8821 ("cgroup: +Avoid false cacheline sharing of read mostly rstat_cpu") happens to be +the last straw that breaks it. Fix this problem by moving the rcu_head +structure up before the cgroup structure. + +Fixes: d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe") +Reported-by: Stephen Rothwell +Closes: https://lore.kernel.org/lkml/20231207143806.114e0a74@canb.auug.org.au/ +Signed-off-by: Waiman Long +Acked-by: Yafang Shao +Reviewed-by: Yosry Ahmed +Reviewed-by: Michal Koutný +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/cgroup-defs.h | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/include/linux/cgroup-defs.h ++++ b/include/linux/cgroup-defs.h +@@ -543,6 +543,10 @@ struct cgroup_root { + /* Unique id for this hierarchy. */ + int hierarchy_id; + ++ /* A list running through the active hierarchies */ ++ struct list_head root_list; ++ struct rcu_head rcu; /* Must be near the top */ ++ + /* + * The root cgroup. The containing cgroup_root will be destroyed on its + * release. cgrp->ancestors[0] will be used overflowing into the +@@ -556,10 +560,6 @@ struct cgroup_root { + /* Number of cgroups in the hierarchy, used only for /proc/cgroups */ + atomic_t nr_cgrps; + +- /* A list running through the active hierarchies */ +- struct list_head root_list; +- struct rcu_head rcu; +- + /* Hierarchy-specific flags */ + unsigned int flags; + diff --git a/queue-6.6/mm-debug_vm_pgtable-drop-random_orvalue-trick.patch b/queue-6.6/mm-debug_vm_pgtable-drop-random_orvalue-trick.patch new file mode 100644 index 00000000000..e546b77b026 --- /dev/null +++ b/queue-6.6/mm-debug_vm_pgtable-drop-random_orvalue-trick.patch @@ -0,0 +1,131 @@ +From 0b1ef4fde7a24909ff2afacffd0d6afa28b73652 Mon Sep 17 00:00:00 2001 +From: Peter Xu +Date: Thu, 23 May 2024 09:21:39 -0400 +Subject: mm/debug_vm_pgtable: drop RANDOM_ORVALUE trick + +From: Peter Xu + +commit 0b1ef4fde7a24909ff2afacffd0d6afa28b73652 upstream. + +Macro RANDOM_ORVALUE was used to make sure the pgtable entry will be +populated with !none data in clear tests. + +The RANDOM_ORVALUE tried to cover mostly all the bits in a pgtable entry, +even if there's no discussion on whether all the bits will be vaild. Both +S390 and PPC64 have their own masks to avoid touching some bits. Now it's +the turn for x86_64. + +The issue is there's a recent report from Mikhail Gavrilov showing that +this can cause a warning with the newly added pte set check in commit +8430557fc5 on writable v.s. userfaultfd-wp bit, even though the check +itself was valid, the random pte is not. We can choose to mask more bits +out. + +However the need to have such random bits setup is questionable, as now +it's already guaranteed to be true on below: + + - For pte level, the pgtable entry will be installed with value from + pfn_pte(), where pfn points to a valid page. Hence the pte will be + !none already if populated with pfn_pte(). + + - For upper-than-pte level, the pgtable entry should contain a directory + entry always, which is also !none. + +All the cases look like good enough to test a pxx_clear() helper. Instead +of extending the bitmask, drop the "set random bits" trick completely. Add +some warning guards to make sure the entries will be !none before clear(). + +Link: https://lkml.kernel.org/r/20240523132139.289719-1-peterx@redhat.com +Fixes: 8430557fc584 ("mm/page_table_check: support userfault wr-protect entries") +Signed-off-by: Peter Xu +Reported-by: Mikhail Gavrilov +Link: https://lore.kernel.org/r/CABXGCsMB9A8-X+Np_Q+fWLURYL_0t3Y-MdoNabDM-Lzk58-DGA@mail.gmail.com +Tested-by: Mikhail Gavrilov +Reviewed-by: Pasha Tatashin +Acked-by: David Hildenbrand +Cc: Aneesh Kumar K.V +Cc: Gavin Shan +Cc: Anshuman Khandual +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/debug_vm_pgtable.c | 31 +++++-------------------------- + 1 file changed, 5 insertions(+), 26 deletions(-) + +--- a/mm/debug_vm_pgtable.c ++++ b/mm/debug_vm_pgtable.c +@@ -39,22 +39,7 @@ + * Please refer Documentation/mm/arch_pgtable_helpers.rst for the semantics + * expectations that are being validated here. All future changes in here + * or the documentation need to be in sync. +- * +- * On s390 platform, the lower 4 bits are used to identify given page table +- * entry type. But these bits might affect the ability to clear entries with +- * pxx_clear() because of how dynamic page table folding works on s390. So +- * while loading up the entries do not change the lower 4 bits. It does not +- * have affect any other platform. Also avoid the 62nd bit on ppc64 that is +- * used to mark a pte entry. + */ +-#define S390_SKIP_MASK GENMASK(3, 0) +-#if __BITS_PER_LONG == 64 +-#define PPC64_SKIP_MASK GENMASK(62, 62) +-#else +-#define PPC64_SKIP_MASK 0x0 +-#endif +-#define ARCH_SKIP_MASK (S390_SKIP_MASK | PPC64_SKIP_MASK) +-#define RANDOM_ORVALUE (GENMASK(BITS_PER_LONG - 1, 0) & ~ARCH_SKIP_MASK) + #define RANDOM_NZVALUE GENMASK(7, 0) + + struct pgtable_debug_args { +@@ -510,8 +495,7 @@ static void __init pud_clear_tests(struc + return; + + pr_debug("Validating PUD clear\n"); +- pud = __pud(pud_val(pud) | RANDOM_ORVALUE); +- WRITE_ONCE(*args->pudp, pud); ++ WARN_ON(pud_none(pud)); + pud_clear(args->pudp); + pud = READ_ONCE(*args->pudp); + WARN_ON(!pud_none(pud)); +@@ -547,8 +531,7 @@ static void __init p4d_clear_tests(struc + return; + + pr_debug("Validating P4D clear\n"); +- p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE); +- WRITE_ONCE(*args->p4dp, p4d); ++ WARN_ON(p4d_none(p4d)); + p4d_clear(args->p4dp); + p4d = READ_ONCE(*args->p4dp); + WARN_ON(!p4d_none(p4d)); +@@ -581,8 +564,7 @@ static void __init pgd_clear_tests(struc + return; + + pr_debug("Validating PGD clear\n"); +- pgd = __pgd(pgd_val(pgd) | RANDOM_ORVALUE); +- WRITE_ONCE(*args->pgdp, pgd); ++ WARN_ON(pgd_none(pgd)); + pgd_clear(args->pgdp); + pgd = READ_ONCE(*args->pgdp); + WARN_ON(!pgd_none(pgd)); +@@ -633,10 +615,8 @@ static void __init pte_clear_tests(struc + if (WARN_ON(!args->ptep)) + return; + +-#ifndef CONFIG_RISCV +- pte = __pte(pte_val(pte) | RANDOM_ORVALUE); +-#endif + set_pte_at(args->mm, args->vaddr, args->ptep, pte); ++ WARN_ON(pte_none(pte)); + flush_dcache_page(page); + barrier(); + ptep_clear(args->mm, args->vaddr, args->ptep); +@@ -649,8 +629,7 @@ static void __init pmd_clear_tests(struc + pmd_t pmd = READ_ONCE(*args->pmdp); + + pr_debug("Validating PMD clear\n"); +- pmd = __pmd(pmd_val(pmd) | RANDOM_ORVALUE); +- WRITE_ONCE(*args->pmdp, pmd); ++ WARN_ON(pmd_none(pmd)); + pmd_clear(args->pmdp); + pmd = READ_ONCE(*args->pmdp); + WARN_ON(!pmd_none(pmd)); diff --git a/queue-6.6/revert-input-bcm5974-check-endpoint-type-before-starting-traffic.patch b/queue-6.6/revert-input-bcm5974-check-endpoint-type-before-starting-traffic.patch new file mode 100644 index 00000000000..8e3b03e7302 --- /dev/null +++ b/queue-6.6/revert-input-bcm5974-check-endpoint-type-before-starting-traffic.patch @@ -0,0 +1,95 @@ +From 7105e92c60c9cc4112c782d69c172e96b69a43dc Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Tue, 5 Mar 2024 08:49:21 +0100 +Subject: Revert "Input: bcm5974 - check endpoint type before starting traffic" + +From: Javier Carrasco + +commit 7105e92c60c9cc4112c782d69c172e96b69a43dc upstream. + +This patch intended to fix an well-knonw issue in old drivers where the +endpoint type is taken for granted, which is often triggered by fuzzers. + +That was the case for this driver [1], and although the fix seems to be +correct, it uncovered another issue that leads to a regression [2], if +the endpoints of the current interface are checked. + +The driver makes use of endpoints that belong to a different interface +rather than the one it binds (it binds to the third interface, but also +accesses an endpoint from a different one). The driver should claim the +interfaces it requires, but that is still not the case. + +Given that the regression is more severe than the issue found by +syzkaller, the best approach is reverting the patch that causes the +regression, and trying to fix the underlying problem before checking +the endpoint types again. + +Note that reverting this patch will probably trigger the syzkaller bug +at some point. + +This reverts commit 2b9c3eb32a699acdd4784d6b93743271b4970899. + +Link: https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622 [1] +Link: https://lore.kernel.org/linux-input/87sf161jjc.wl-tiwai@suse.de/ [2] + +Fixes: 2b9c3eb32a69 ("Input: bcm5974 - check endpoint type before starting traffic") +Reported-by: Jacopo Radice +Closes: https://bugzilla.suse.com/show_bug.cgi?id=1220030 +Signed-off-by: Javier Carrasco +Link: https://lore.kernel.org/r/20240305-revert_bcm5974_ep_check-v3-1-527198cf6499@gmail.com +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/mouse/bcm5974.c | 20 -------------------- + 1 file changed, 20 deletions(-) + +--- a/drivers/input/mouse/bcm5974.c ++++ b/drivers/input/mouse/bcm5974.c +@@ -19,7 +19,6 @@ + * Copyright (C) 2006 Nicolas Boichat (nicolas@boichat.ch) + */ + +-#include "linux/usb.h" + #include + #include + #include +@@ -194,8 +193,6 @@ enum tp_type { + + /* list of device capability bits */ + #define HAS_INTEGRATED_BUTTON 1 +-/* maximum number of supported endpoints (currently trackpad and button) */ +-#define MAX_ENDPOINTS 2 + + /* trackpad finger data block size */ + #define FSIZE_TYPE1 (14 * sizeof(__le16)) +@@ -894,18 +891,6 @@ static int bcm5974_resume(struct usb_int + return error; + } + +-static bool bcm5974_check_endpoints(struct usb_interface *iface, +- const struct bcm5974_config *cfg) +-{ +- u8 ep_addr[MAX_ENDPOINTS + 1] = {0}; +- +- ep_addr[0] = cfg->tp_ep; +- if (cfg->tp_type == TYPE1) +- ep_addr[1] = cfg->bt_ep; +- +- return usb_check_int_endpoints(iface, ep_addr); +-} +- + static int bcm5974_probe(struct usb_interface *iface, + const struct usb_device_id *id) + { +@@ -918,11 +903,6 @@ static int bcm5974_probe(struct usb_inte + /* find the product index */ + cfg = bcm5974_get_config(udev); + +- if (!bcm5974_check_endpoints(iface, cfg)) { +- dev_err(&iface->dev, "Unexpected non-int endpoint\n"); +- return -ENODEV; +- } +- + /* allocate memory for our device state and initialize it */ + dev = kzalloc(sizeof(struct bcm5974), GFP_KERNEL); + input_dev = input_allocate_device(); diff --git a/queue-6.6/revert-jfs-fix-shift-out-of-bounds-in-dbjoin.patch b/queue-6.6/revert-jfs-fix-shift-out-of-bounds-in-dbjoin.patch new file mode 100644 index 00000000000..2886a77798f --- /dev/null +++ b/queue-6.6/revert-jfs-fix-shift-out-of-bounds-in-dbjoin.patch @@ -0,0 +1,44 @@ +From e42e29cc442395d62f1a8963ec2dfb700ba6a5d7 Mon Sep 17 00:00:00 2001 +From: Dave Kleikamp +Date: Mon, 29 Jan 2024 08:40:23 -0600 +Subject: Revert "jfs: fix shift-out-of-bounds in dbJoin" + +From: Dave Kleikamp + +commit e42e29cc442395d62f1a8963ec2dfb700ba6a5d7 upstream. + +This reverts commit cca974daeb6c43ea971f8ceff5a7080d7d49ee30. + +The added sanity check is incorrect. BUDMIN is not the wrong value and +is too small. + +Signed-off-by: Dave Kleikamp +Signed-off-by: Greg Kroah-Hartman +--- + fs/jfs/jfs_dmap.c | 8 +------- + 1 file changed, 1 insertion(+), 7 deletions(-) + +--- a/fs/jfs/jfs_dmap.c ++++ b/fs/jfs/jfs_dmap.c +@@ -2765,9 +2765,7 @@ static int dbBackSplit(dmtree_t *tp, int + * leafno - the number of the leaf to be updated. + * newval - the new value for the leaf. + * +- * RETURN VALUES: +- * 0 - success +- * -EIO - i/o error ++ * RETURN VALUES: none + */ + static int dbJoin(dmtree_t *tp, int leafno, int newval, bool is_ctl) + { +@@ -2794,10 +2792,6 @@ static int dbJoin(dmtree_t *tp, int leaf + * get the buddy size (number of words covered) of + * the new value. + */ +- +- if ((newval - tp->dmt_budmin) > BUDMIN) +- return -EIO; +- + budsz = BUDSIZE(newval, tp->dmt_budmin); + + /* try to join. diff --git a/queue-6.6/series b/queue-6.6/series index 4b7d7e0be22..18882180ab7 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -59,3 +59,7 @@ jfs-fix-shift-out-of-bounds-in-dbdiscardag.patch fs-ntfs3-do-copy_to_user-out-of-run_lock.patch alsa-usb-fix-ubsan-warning-in-parse_audio_unit.patch binfmt_flat-fix-corruption-when-not-offsetting-data-.patch +revert-jfs-fix-shift-out-of-bounds-in-dbjoin.patch +revert-input-bcm5974-check-endpoint-type-before-starting-traffic.patch +mm-debug_vm_pgtable-drop-random_orvalue-trick.patch +cgroup-move-rcu_head-up-near-the-top-of-cgroup_root.patch