From: Greg Kroah-Hartman Date: Sat, 24 Sep 2022 09:10:51 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v4.9.330~72 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f8cfda12f51af99b21f7b7ad1e1e7ccb838aba12;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: arm64-topology-fix-possible-overflow-in-amu_fie_setup.patch can-flexcan-flexcan_mailbox_read-fix-return-value-for-drop-true.patch gpio-mockup-fix-null-pointer-dereference-when-removing-debugfs.patch gpio-mockup-fix-potential-resource-leakage-when-register-a-chip.patch gpiolib-cdev-set-lineevent_state-irq-after-irq-register-successfully.patch kasan-call-kasan_malloc-from-__kmalloc_-track_caller.patch kvm-x86-inject-ud-on-emulated-xsetbv-if-xsaves-isn-t-enabled.patch mm-slub-fix-flush_cpu_slab-__free_slab-invocations-in-task-context.patch mm-slub-fix-to-return-errno-if-kmalloc-fails.patch net-mana-add-rmb-after-checking-owner-bits.patch riscv-fix-a-nasty-sigreturn-bug.patch vmlinux.lds.h-cfi-reduce-alignment-of-jump-table-to-function-alignment.patch wifi-mt76-fix-reading-current-per-tid-starting-sequence-number-for-aggregation.patch --- diff --git a/queue-5.15/arm64-topology-fix-possible-overflow-in-amu_fie_setup.patch b/queue-5.15/arm64-topology-fix-possible-overflow-in-amu_fie_setup.patch new file mode 100644 index 00000000000..b9ca0cbe348 --- /dev/null +++ b/queue-5.15/arm64-topology-fix-possible-overflow-in-amu_fie_setup.patch @@ -0,0 +1,37 @@ +From d4955c0ad77dbc684fc716387070ac24801b8bca Mon Sep 17 00:00:00 2001 +From: Sergey Shtylyov +Date: Fri, 16 Sep 2022 23:17:07 +0300 +Subject: arm64: topology: fix possible overflow in amu_fie_setup() + +From: Sergey Shtylyov + +commit d4955c0ad77dbc684fc716387070ac24801b8bca upstream. + +cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*, +while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'. +Multiplying max frequency by 1000 can potentially result in overflow -- +multiplying by 1000ULL instead should avoid that... + +Found by Linux Verification Center (linuxtesting.org) with the SVACE static +analysis tool. + +Fixes: cd0ed03a8903 ("arm64: use activity monitors for frequency invariance") +Signed-off-by: Sergey Shtylyov +Link: https://lore.kernel.org/r/01493d64-2bce-d968-86dc-11a122a9c07d@omp.ru +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/topology.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/kernel/topology.c ++++ b/arch/arm64/kernel/topology.c +@@ -249,7 +249,7 @@ static void amu_fie_setup(const struct c + for_each_cpu(cpu, cpus) { + if (!freq_counters_valid(cpu) || + freq_inv_set_max_ratio(cpu, +- cpufreq_get_hw_max_freq(cpu) * 1000, ++ cpufreq_get_hw_max_freq(cpu) * 1000ULL, + arch_timer_get_rate())) + return; + } diff --git a/queue-5.15/can-flexcan-flexcan_mailbox_read-fix-return-value-for-drop-true.patch b/queue-5.15/can-flexcan-flexcan_mailbox_read-fix-return-value-for-drop-true.patch new file mode 100644 index 00000000000..2baa5e1ea9d --- /dev/null +++ b/queue-5.15/can-flexcan-flexcan_mailbox_read-fix-return-value-for-drop-true.patch @@ -0,0 +1,84 @@ +From a09721dd47c8468b3f2fdd73f40422699ffe26dd Mon Sep 17 00:00:00 2001 +From: Marc Kleine-Budde +Date: Thu, 11 Aug 2022 10:25:44 +0200 +Subject: can: flexcan: flexcan_mailbox_read() fix return value for drop = true +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Kleine-Budde + +commit a09721dd47c8468b3f2fdd73f40422699ffe26dd upstream. + +The following happened on an i.MX25 using flexcan with many packets on +the bus: + +The rx-offload queue reached a length more than skb_queue_len_max. In +can_rx_offload_offload_one() the drop variable was set to true which +made the call to .mailbox_read() (here: flexcan_mailbox_read()) to +_always_ return ERR_PTR(-ENOBUFS) and drop the rx'ed CAN frame. So +can_rx_offload_offload_one() returned ERR_PTR(-ENOBUFS), too. + +can_rx_offload_irq_offload_fifo() looks as follows: + +| while (1) { +| skb = can_rx_offload_offload_one(offload, 0); +| if (IS_ERR(skb)) +| continue; +| if (!skb) +| break; +| ... +| } + +The flexcan driver wrongly always returns ERR_PTR(-ENOBUFS) if drop is +requested, even if there is no CAN frame pending. As the i.MX25 is a +single core CPU, while the rx-offload processing is active, there is +no thread to process packets from the offload queue. So the queue +doesn't get any shorter and this results is a tight loop. + +Instead of always returning ERR_PTR(-ENOBUFS) if drop is requested, +return NULL if no CAN frame is pending. + +Changes since v1: https://lore.kernel.org/all/20220810144536.389237-1-u.kleine-koenig@pengutronix.de +- don't break in can_rx_offload_irq_offload_fifo() in case of an error, + return NULL in flexcan_mailbox_read() in case of no pending CAN frame + instead + +Fixes: 4e9c9484b085 ("can: rx-offload: Prepare for CAN FD support") +Link: https://lore.kernel.org/all/20220811094254.1864367-1-mkl@pengutronix.de +Cc: stable@vger.kernel.org # v5.5 +Suggested-by: Uwe Kleine-König +Reviewed-by: Uwe Kleine-König +Tested-by: Thorsten Scherer +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/flexcan.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/net/can/flexcan.c ++++ b/drivers/net/can/flexcan.c +@@ -1036,11 +1036,6 @@ static struct sk_buff *flexcan_mailbox_r + u32 reg_ctrl, reg_id, reg_iflag1; + int i; + +- if (unlikely(drop)) { +- skb = ERR_PTR(-ENOBUFS); +- goto mark_as_read; +- } +- + mb = flexcan_get_mb(priv, n); + + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_USE_RX_MAILBOX) { +@@ -1069,6 +1064,11 @@ static struct sk_buff *flexcan_mailbox_r + reg_ctrl = priv->read(&mb->can_ctrl); + } + ++ if (unlikely(drop)) { ++ skb = ERR_PTR(-ENOBUFS); ++ goto mark_as_read; ++ } ++ + if (reg_ctrl & FLEXCAN_MB_CNT_EDL) + skb = alloc_canfd_skb(offload->dev, &cfd); + else diff --git a/queue-5.15/gpio-mockup-fix-null-pointer-dereference-when-removing-debugfs.patch b/queue-5.15/gpio-mockup-fix-null-pointer-dereference-when-removing-debugfs.patch new file mode 100644 index 00000000000..61e091bd99f --- /dev/null +++ b/queue-5.15/gpio-mockup-fix-null-pointer-dereference-when-removing-debugfs.patch @@ -0,0 +1,36 @@ +From b7df41a6f79dfb18ba2203f8c5f0e9c0b9b57f68 Mon Sep 17 00:00:00 2001 +From: Bartosz Golaszewski +Date: Tue, 20 Sep 2022 09:18:41 +0200 +Subject: gpio: mockup: fix NULL pointer dereference when removing debugfs + +From: Bartosz Golaszewski + +commit b7df41a6f79dfb18ba2203f8c5f0e9c0b9b57f68 upstream. + +We now remove the device's debugfs entries when unbinding the driver. +This now causes a NULL-pointer dereference on module exit because the +platform devices are unregistered *after* the global debugfs directory +has been recursively removed. Fix it by unregistering the devices first. + +Fixes: 303e6da99429 ("gpio: mockup: remove gpio debugfs when remove device") +Cc: Wei Yongjun +Cc: stable@vger.kernel.org +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpio-mockup.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpio/gpio-mockup.c ++++ b/drivers/gpio/gpio-mockup.c +@@ -618,9 +618,9 @@ static int __init gpio_mockup_init(void) + + static void __exit gpio_mockup_exit(void) + { ++ gpio_mockup_unregister_pdevs(); + debugfs_remove_recursive(gpio_mockup_dbg_dir); + platform_driver_unregister(&gpio_mockup_driver); +- gpio_mockup_unregister_pdevs(); + } + + module_init(gpio_mockup_init); diff --git a/queue-5.15/gpio-mockup-fix-potential-resource-leakage-when-register-a-chip.patch b/queue-5.15/gpio-mockup-fix-potential-resource-leakage-when-register-a-chip.patch new file mode 100644 index 00000000000..8e5789b08c4 --- /dev/null +++ b/queue-5.15/gpio-mockup-fix-potential-resource-leakage-when-register-a-chip.patch @@ -0,0 +1,35 @@ +From 02743c4091ccfb246f5cdbbe3f44b152d5d12933 Mon Sep 17 00:00:00 2001 +From: Andy Shevchenko +Date: Tue, 20 Sep 2022 16:30:31 +0300 +Subject: gpio: mockup: Fix potential resource leakage when register a chip + +From: Andy Shevchenko + +commit 02743c4091ccfb246f5cdbbe3f44b152d5d12933 upstream. + +If creation of software node fails, the locally allocated string +array is left unfreed. Free it on error path. + +Fixes: 6fda593f3082 ("gpio: mockup: Convert to use software nodes") +Cc: stable@vger.kernel.org +Signed-off-by: Andy Shevchenko +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpio-mockup.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/gpio/gpio-mockup.c ++++ b/drivers/gpio/gpio-mockup.c +@@ -554,8 +554,10 @@ static int __init gpio_mockup_register_c + } + + fwnode = fwnode_create_software_node(properties, NULL); +- if (IS_ERR(fwnode)) ++ if (IS_ERR(fwnode)) { ++ kfree_strarray(line_names, ngpio); + return PTR_ERR(fwnode); ++ } + + pdevinfo.name = "gpio-mockup"; + pdevinfo.id = idx; diff --git a/queue-5.15/gpiolib-cdev-set-lineevent_state-irq-after-irq-register-successfully.patch b/queue-5.15/gpiolib-cdev-set-lineevent_state-irq-after-irq-register-successfully.patch new file mode 100644 index 00000000000..23f1b99598f --- /dev/null +++ b/queue-5.15/gpiolib-cdev-set-lineevent_state-irq-after-irq-register-successfully.patch @@ -0,0 +1,65 @@ +From 69bef19d6b9700e96285f4b4e28691cda3dcd0d1 Mon Sep 17 00:00:00 2001 +From: Meng Li +Date: Wed, 21 Sep 2022 11:20:20 +0800 +Subject: gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully + +From: Meng Li + +commit 69bef19d6b9700e96285f4b4e28691cda3dcd0d1 upstream. + +When running gpio test on nxp-ls1028 platform with below command +gpiomon --num-events=3 --rising-edge gpiochip1 25 +There will be a warning trace as below: +Call trace: +free_irq+0x204/0x360 +lineevent_free+0x64/0x70 +gpio_ioctl+0x598/0x6a0 +__arm64_sys_ioctl+0xb4/0x100 +invoke_syscall+0x5c/0x130 +...... +el0t_64_sync+0x1a0/0x1a4 +The reason of this issue is that calling request_threaded_irq() +function failed, and then lineevent_free() is invoked to release +the resource. Since the lineevent_state::irq was already set, so +the subsequent invocation of free_irq() would trigger the above +warning call trace. To fix this issue, set the lineevent_state::irq +after the IRQ register successfully. + +Fixes: 468242724143 ("gpiolib: cdev: refactor lineevent cleanup into lineevent_free") +Cc: stable@vger.kernel.org +Signed-off-by: Meng Li +Reviewed-by: Kent Gibson +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpiolib-cdev.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/gpio/gpiolib-cdev.c ++++ b/drivers/gpio/gpiolib-cdev.c +@@ -1784,7 +1784,6 @@ static int lineevent_create(struct gpio_ + ret = -ENODEV; + goto out_free_le; + } +- le->irq = irq; + + if (eflags & GPIOEVENT_REQUEST_RISING_EDGE) + irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ? +@@ -1798,7 +1797,7 @@ static int lineevent_create(struct gpio_ + init_waitqueue_head(&le->wait); + + /* Request a thread to read the events */ +- ret = request_threaded_irq(le->irq, ++ ret = request_threaded_irq(irq, + lineevent_irq_handler, + lineevent_irq_thread, + irqflags, +@@ -1807,6 +1806,8 @@ static int lineevent_create(struct gpio_ + if (ret) + goto out_free_le; + ++ le->irq = irq; ++ + fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC); + if (fd < 0) { + ret = fd; diff --git a/queue-5.15/kasan-call-kasan_malloc-from-__kmalloc_-track_caller.patch b/queue-5.15/kasan-call-kasan_malloc-from-__kmalloc_-track_caller.patch new file mode 100644 index 00000000000..d4e17708ada --- /dev/null +++ b/queue-5.15/kasan-call-kasan_malloc-from-__kmalloc_-track_caller.patch @@ -0,0 +1,42 @@ +From 5373b8a09d6e037ee0587cb5d9fe4cc09077deeb Mon Sep 17 00:00:00 2001 +From: Peter Collingbourne +Date: Tue, 13 Sep 2022 19:00:01 -0700 +Subject: kasan: call kasan_malloc() from __kmalloc_*track_caller() + +From: Peter Collingbourne + +commit 5373b8a09d6e037ee0587cb5d9fe4cc09077deeb upstream. + +We were failing to call kasan_malloc() from __kmalloc_*track_caller() +which was causing us to sometimes fail to produce KASAN error reports +for allocations made using e.g. devm_kcalloc(), as the KASAN poison was +not being initialized. Fix it. + +Signed-off-by: Peter Collingbourne +Cc: # 5.15 +Signed-off-by: Vlastimil Babka +Signed-off-by: Greg Kroah-Hartman +--- + mm/slub.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -4920,6 +4920,8 @@ void *__kmalloc_track_caller(size_t size + /* Honor the call site pointer we received. */ + trace_kmalloc(caller, ret, size, s->size, gfpflags); + ++ ret = kasan_kmalloc(s, ret, size, gfpflags); ++ + return ret; + } + EXPORT_SYMBOL(__kmalloc_track_caller); +@@ -4951,6 +4953,8 @@ void *__kmalloc_node_track_caller(size_t + /* Honor the call site pointer we received. */ + trace_kmalloc_node(caller, ret, size, s->size, gfpflags, node); + ++ ret = kasan_kmalloc(s, ret, size, gfpflags); ++ + return ret; + } + EXPORT_SYMBOL(__kmalloc_node_track_caller); diff --git a/queue-5.15/kvm-x86-inject-ud-on-emulated-xsetbv-if-xsaves-isn-t-enabled.patch b/queue-5.15/kvm-x86-inject-ud-on-emulated-xsetbv-if-xsaves-isn-t-enabled.patch new file mode 100644 index 00000000000..8f6c06632e0 --- /dev/null +++ b/queue-5.15/kvm-x86-inject-ud-on-emulated-xsetbv-if-xsaves-isn-t-enabled.patch @@ -0,0 +1,55 @@ +From 50b2d49bafa16e6311ab2da82f5aafc5f9ada99b Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 24 Aug 2022 03:30:57 +0000 +Subject: KVM: x86: Inject #UD on emulated XSETBV if XSAVES isn't enabled + +From: Sean Christopherson + +commit 50b2d49bafa16e6311ab2da82f5aafc5f9ada99b upstream. + +Inject #UD when emulating XSETBV if CR4.OSXSAVE is not set. This also +covers the "XSAVE not supported" check, as setting CR4.OSXSAVE=1 #GPs if +XSAVE is not supported (and userspace gets to keep the pieces if it +forces incoherent vCPU state). + +Add a comment to kvm_emulate_xsetbv() to call out that the CPU checks +CR4.OSXSAVE before checking for intercepts. AMD'S APM implies that #UD +has priority (says that intercepts are checked before #GP exceptions), +while Intel's SDM says nothing about interception priority. However, +testing on hardware shows that both AMD and Intel CPUs prioritize the #UD +over interception. + +Fixes: 02d4160fbd76 ("x86: KVM: add xsetbv to the emulator") +Cc: stable@vger.kernel.org +Cc: Vitaly Kuznetsov +Signed-off-by: Sean Christopherson +Message-Id: <20220824033057.3576315-4-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/emulate.c | 3 +++ + arch/x86/kvm/x86.c | 1 + + 2 files changed, 4 insertions(+) + +--- a/arch/x86/kvm/emulate.c ++++ b/arch/x86/kvm/emulate.c +@@ -4122,6 +4122,9 @@ static int em_xsetbv(struct x86_emulate_ + { + u32 eax, ecx, edx; + ++ if (!(ctxt->ops->get_cr(ctxt, 4) & X86_CR4_OSXSAVE)) ++ return emulate_ud(ctxt); ++ + eax = reg_read(ctxt, VCPU_REGS_RAX); + edx = reg_read(ctxt, VCPU_REGS_RDX); + ecx = reg_read(ctxt, VCPU_REGS_RCX); +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -1021,6 +1021,7 @@ static int __kvm_set_xcr(struct kvm_vcpu + + int kvm_emulate_xsetbv(struct kvm_vcpu *vcpu) + { ++ /* Note, #UD due to CR4.OSXSAVE=0 has priority over the intercept. */ + if (static_call(kvm_x86_get_cpl)(vcpu) != 0 || + __kvm_set_xcr(vcpu, kvm_rcx_read(vcpu), kvm_read_edx_eax(vcpu))) { + kvm_inject_gp(vcpu, 0); diff --git a/queue-5.15/mm-slub-fix-flush_cpu_slab-__free_slab-invocations-in-task-context.patch b/queue-5.15/mm-slub-fix-flush_cpu_slab-__free_slab-invocations-in-task-context.patch new file mode 100644 index 00000000000..dce6dc71092 --- /dev/null +++ b/queue-5.15/mm-slub-fix-flush_cpu_slab-__free_slab-invocations-in-task-context.patch @@ -0,0 +1,81 @@ +From e45cc288724f0cfd497bb5920bcfa60caa335729 Mon Sep 17 00:00:00 2001 +From: Maurizio Lombardi +Date: Mon, 19 Sep 2022 18:39:29 +0200 +Subject: mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context. + +From: Maurizio Lombardi + +commit e45cc288724f0cfd497bb5920bcfa60caa335729 upstream. + +Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations +__free_slab() invocations out of IRQ context") moved all flush_cpu_slab() +invocations to the global workqueue to avoid a problem related +with deactivate_slab()/__free_slab() being called from an IRQ context +on PREEMPT_RT kernels. + +When the flush_all_cpu_locked() function is called from a task context +it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up +flushing the global workqueue, this will cause a dependency issue. + + workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] + is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab + WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 + check_flush_dependency+0x10a/0x120 + Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core] + RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace: + __flush_work.isra.0+0xbf/0x220 + ? __queue_work+0x1dc/0x420 + flush_all_cpus_locked+0xfb/0x120 + __kmem_cache_shutdown+0x2b/0x320 + kmem_cache_destroy+0x49/0x100 + bioset_exit+0x143/0x190 + blk_release_queue+0xb9/0x100 + kobject_cleanup+0x37/0x130 + nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] + nvme_free_ctrl+0x1ac/0x2b0 [nvme_core] + +Fix this bug by creating a workqueue for the flush operation with +the WQ_MEM_RECLAIM bit set. + +Fixes: 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context") +Cc: +Signed-off-by: Maurizio Lombardi +Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> +Signed-off-by: Vlastimil Babka +Signed-off-by: Greg Kroah-Hartman +--- + mm/slub.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -308,6 +308,11 @@ static inline void stat(const struct kme + */ + static nodemask_t slab_nodes; + ++/* ++ * Workqueue used for flush_cpu_slab(). ++ */ ++static struct workqueue_struct *flushwq; ++ + /******************************************************************** + * Core slab cache functions + *******************************************************************/ +@@ -2688,7 +2693,7 @@ static void flush_all_cpus_locked(struct + INIT_WORK(&sfw->work, flush_cpu_slab); + sfw->skip = false; + sfw->s = s; +- schedule_work_on(cpu, &sfw->work); ++ queue_work_on(cpu, flushwq, &sfw->work); + } + + for_each_online_cpu(cpu) { +@@ -4850,6 +4855,8 @@ void __init kmem_cache_init(void) + + void __init kmem_cache_init_late(void) + { ++ flushwq = alloc_workqueue("slub_flushwq", WQ_MEM_RECLAIM, 0); ++ WARN_ON(!flushwq); + } + + struct kmem_cache * diff --git a/queue-5.15/mm-slub-fix-to-return-errno-if-kmalloc-fails.patch b/queue-5.15/mm-slub-fix-to-return-errno-if-kmalloc-fails.patch new file mode 100644 index 00000000000..903fe15debb --- /dev/null +++ b/queue-5.15/mm-slub-fix-to-return-errno-if-kmalloc-fails.patch @@ -0,0 +1,70 @@ +From 7e9c323c52b379d261a72dc7bd38120a761a93cd Mon Sep 17 00:00:00 2001 +From: Chao Yu +Date: Wed, 31 Aug 2022 22:54:54 +0800 +Subject: mm/slub: fix to return errno if kmalloc() fails + +From: Chao Yu + +commit 7e9c323c52b379d261a72dc7bd38120a761a93cd upstream. + +In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to +out-of-memory, if it fails, return errno correctly rather than +triggering panic via BUG_ON(); + +kernel BUG at mm/slub.c:5893! +Internal error: Oops - BUG: 0 [#1] PREEMPT SMP + +Call trace: + sysfs_slab_add+0x258/0x260 mm/slub.c:5973 + __kmem_cache_create+0x60/0x118 mm/slub.c:4899 + create_cache mm/slab_common.c:229 [inline] + kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 + kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 + f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] + f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 + f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 + mount_bdev+0x1b8/0x210 fs/super.c:1400 + f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 + legacy_get_tree+0x30/0x74 fs/fs_context.c:610 + vfs_get_tree+0x40/0x140 fs/super.c:1530 + do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 + path_mount+0x358/0x914 fs/namespace.c:3370 + do_mount fs/namespace.c:3383 [inline] + __do_sys_mount fs/namespace.c:3591 [inline] + __se_sys_mount fs/namespace.c:3568 [inline] + __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 + +Cc: +Fixes: 81819f0fc8285 ("SLUB core") +Reported-by: syzbot+81684812ea68216e08c5@syzkaller.appspotmail.com +Reviewed-by: Muchun Song +Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> +Signed-off-by: Chao Yu +Acked-by: David Rientjes +Signed-off-by: Vlastimil Babka +Signed-off-by: Greg Kroah-Hartman +--- + mm/slub.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -5869,7 +5869,8 @@ static char *create_unique_id(struct kme + char *name = kmalloc(ID_STR_LENGTH, GFP_KERNEL); + char *p = name; + +- BUG_ON(!name); ++ if (!name) ++ return ERR_PTR(-ENOMEM); + + *p++ = ':'; + /* +@@ -5927,6 +5928,8 @@ static int sysfs_slab_add(struct kmem_ca + * for the symlinks. + */ + name = create_unique_id(s); ++ if (IS_ERR(name)) ++ return PTR_ERR(name); + } + + s->kobj.kset = kset; diff --git a/queue-5.15/net-mana-add-rmb-after-checking-owner-bits.patch b/queue-5.15/net-mana-add-rmb-after-checking-owner-bits.patch new file mode 100644 index 00000000000..0c5a9128730 --- /dev/null +++ b/queue-5.15/net-mana-add-rmb-after-checking-owner-bits.patch @@ -0,0 +1,52 @@ +From 6fd2c68da55c552f86e401ebe40c4a619025ef69 Mon Sep 17 00:00:00 2001 +From: Haiyang Zhang +Date: Sun, 11 Sep 2022 13:40:05 -0700 +Subject: net: mana: Add rmb after checking owner bits + +From: Haiyang Zhang + +commit 6fd2c68da55c552f86e401ebe40c4a619025ef69 upstream. + +Per GDMA spec, rmb is necessary after checking owner_bits, before +reading EQ or CQ entries. + +Add rmb in these two places to comply with the specs. + +Cc: stable@vger.kernel.org +Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") +Reported-by: Sinan Kaya +Signed-off-by: Haiyang Zhang +Reviewed-by: Dexuan Cui +Link: https://lore.kernel.org/r/1662928805-15861-1-git-send-email-haiyangz@microsoft.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/microsoft/mana/gdma_main.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c ++++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c +@@ -368,6 +368,11 @@ static void mana_gd_process_eq_events(vo + break; + } + ++ /* Per GDMA spec, rmb is necessary after checking owner_bits, before ++ * reading eqe. ++ */ ++ rmb(); ++ + mana_gd_process_eqe(eq); + + eq->head++; +@@ -1096,6 +1101,11 @@ static int mana_gd_read_cqe(struct gdma_ + if (WARN_ON_ONCE(owner_bits != new_bits)) + return -1; + ++ /* Per GDMA spec, rmb is necessary after checking owner_bits, before ++ * reading completion info ++ */ ++ rmb(); ++ + comp->wq_num = cqe->cqe_info.wq_num; + comp->is_sq = cqe->cqe_info.is_sq; + memcpy(comp->cqe_data, cqe->cqe_data, GDMA_COMP_DATA_SIZE); diff --git a/queue-5.15/riscv-fix-a-nasty-sigreturn-bug.patch b/queue-5.15/riscv-fix-a-nasty-sigreturn-bug.patch new file mode 100644 index 00000000000..a8bdf72826f --- /dev/null +++ b/queue-5.15/riscv-fix-a-nasty-sigreturn-bug.patch @@ -0,0 +1,40 @@ +From 762df359aa5849e010ef04c3ed79d57588ce17d9 Mon Sep 17 00:00:00 2001 +From: Al Viro +Date: Fri, 24 Sep 2021 01:55:27 +0000 +Subject: riscv: fix a nasty sigreturn bug... + +From: Al Viro + +commit 762df359aa5849e010ef04c3ed79d57588ce17d9 upstream. + +riscv has an equivalent of arm bug fixed by 653d48b22166 ("arm: fix +really nasty sigreturn bug"); if signal gets caught by an interrupt that +hits when we have the right value in a0 (-513), *and* another signal +gets delivered upon sigreturn() (e.g. included into the blocked mask for +the first signal and posted while the handler had been running), the +syscall restart logics will see regs->cause equal to EXC_SYSCALL (we are +in a syscall, after all) and a0 already restored to its original value +(-513, which happens to be -ERESTARTNOINTR) and assume that we need to +apply the usual syscall restart logics. + +Signed-off-by: Al Viro +Fixes: e2c0cdfba7f6 ("RISC-V: User-facing API") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/YxJEiSq%2FCGaL6Gm9@ZenIV/ +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/kernel/signal.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/riscv/kernel/signal.c ++++ b/arch/riscv/kernel/signal.c +@@ -121,6 +121,8 @@ SYSCALL_DEFINE0(rt_sigreturn) + if (restore_altstack(&frame->uc.uc_stack)) + goto badframe; + ++ regs->cause = -1UL; ++ + return regs->a0; + + badframe: diff --git a/queue-5.15/series b/queue-5.15/series index cd1fc71c6b1..869694c0a14 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -39,3 +39,16 @@ usb-dwc3-core-leave-default-dma-if-the-controller-does-not-support-64-bit-dma.pa thunderbolt-add-support-for-intel-maple-ridge-single-port-controller.patch efi-x86-wipe-setup_data-on-pure-efi-boot.patch efi-libstub-check-shim-mode-using-moksbstatert.patch +wifi-mt76-fix-reading-current-per-tid-starting-sequence-number-for-aggregation.patch +gpio-mockup-fix-null-pointer-dereference-when-removing-debugfs.patch +gpio-mockup-fix-potential-resource-leakage-when-register-a-chip.patch +gpiolib-cdev-set-lineevent_state-irq-after-irq-register-successfully.patch +riscv-fix-a-nasty-sigreturn-bug.patch +kasan-call-kasan_malloc-from-__kmalloc_-track_caller.patch +can-flexcan-flexcan_mailbox_read-fix-return-value-for-drop-true.patch +net-mana-add-rmb-after-checking-owner-bits.patch +mm-slub-fix-to-return-errno-if-kmalloc-fails.patch +mm-slub-fix-flush_cpu_slab-__free_slab-invocations-in-task-context.patch +kvm-x86-inject-ud-on-emulated-xsetbv-if-xsaves-isn-t-enabled.patch +arm64-topology-fix-possible-overflow-in-amu_fie_setup.patch +vmlinux.lds.h-cfi-reduce-alignment-of-jump-table-to-function-alignment.patch diff --git a/queue-5.15/vmlinux.lds.h-cfi-reduce-alignment-of-jump-table-to-function-alignment.patch b/queue-5.15/vmlinux.lds.h-cfi-reduce-alignment-of-jump-table-to-function-alignment.patch new file mode 100644 index 00000000000..6152b2d8633 --- /dev/null +++ b/queue-5.15/vmlinux.lds.h-cfi-reduce-alignment-of-jump-table-to-function-alignment.patch @@ -0,0 +1,55 @@ +From 13b0566962914e167cb3238fbe29ced618f07a27 Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Thu, 22 Sep 2022 22:57:15 +0100 +Subject: vmlinux.lds.h: CFI: Reduce alignment of jump-table to function alignment + +From: Will Deacon + +commit 13b0566962914e167cb3238fbe29ced618f07a27 upstream. + +Due to undocumented, hysterical raisins on x86, the CFI jump-table +sections in .text are needlessly aligned to PMD_SIZE in the vmlinux +linker script. When compiling a CFI-enabled arm64 kernel with a 64KiB +page-size, a PMD maps 512MiB of virtual memory and so the .text section +increases to a whopping 940MiB and blows the final Image up to 960MiB. +Others report a link failure. + +Since the CFI jump-table requires only instruction alignment, reduce the +alignment directives to function alignment for parity with other parts +of the .text section. This reduces the size of the .text section for the +aforementioned 64KiB page size arm64 kernel to 19MiB for a much more +reasonable total Image size of 39MiB. + +Cc: Sami Tolvanen +Cc: Mark Rutland +Cc: "Mohan Rao .vanimina" +Cc: Kees Cook +Cc: Nathan Chancellor +Cc: +Link: https://lore.kernel.org/all/CAL_GTzigiNOMYkOPX1KDnagPhJtFNqSK=1USNbS0wUL4PW6-Uw@mail.gmail.com/ +Fixes: cf68fffb66d6 ("add support for Clang CFI") +Reviewed-by: Mark Rutland +Tested-by: Mark Rutland +Reviewed-by: Sami Tolvanen +Reviewed-by: Kees Cook +Link: https://lore.kernel.org/r/20220922215715.13345-1-will@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + include/asm-generic/vmlinux.lds.h | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/include/asm-generic/vmlinux.lds.h ++++ b/include/asm-generic/vmlinux.lds.h +@@ -549,10 +549,9 @@ + */ + #ifdef CONFIG_CFI_CLANG + #define TEXT_CFI_JT \ +- . = ALIGN(PMD_SIZE); \ ++ ALIGN_FUNCTION(); \ + __cfi_jt_start = .; \ + *(.text..L.cfi.jumptable .text..L.cfi.jumptable.*) \ +- . = ALIGN(PMD_SIZE); \ + __cfi_jt_end = .; + #else + #define TEXT_CFI_JT diff --git a/queue-5.15/wifi-mt76-fix-reading-current-per-tid-starting-sequence-number-for-aggregation.patch b/queue-5.15/wifi-mt76-fix-reading-current-per-tid-starting-sequence-number-for-aggregation.patch new file mode 100644 index 00000000000..808bd9420c0 --- /dev/null +++ b/queue-5.15/wifi-mt76-fix-reading-current-per-tid-starting-sequence-number-for-aggregation.patch @@ -0,0 +1,33 @@ +From c3a510e2b53785df31d882a773c4c0780b4c825f Mon Sep 17 00:00:00 2001 +From: Felix Fietkau +Date: Fri, 26 Aug 2022 20:23:29 +0200 +Subject: wifi: mt76: fix reading current per-tid starting sequence number for aggregation + +From: Felix Fietkau + +commit c3a510e2b53785df31d882a773c4c0780b4c825f upstream. + +The code was accidentally shifting register values down by tid % 32 instead of +(tid * field_size) % 32. + +Cc: stable@vger.kernel.org +Fixes: a28bef561a5c ("mt76: mt7615: re-enable offloading of sequence number assignment") +Signed-off-by: Felix Fietkau +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220826182329.18155-1-nbd@nbd.name +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c ++++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c +@@ -1038,7 +1038,7 @@ u32 mt7615_mac_get_sta_tid_sn(struct mt7 + offset %= 32; + + val = mt76_rr(dev, addr); +- val >>= (tid % 32); ++ val >>= offset; + + if (offset > 20) { + addr += 4;