From: Greg Kroah-Hartman Date: Sat, 12 Jul 2025 14:27:16 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v5.15.188~59 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=729b9ab4a3daac5766327ed48981fa4d99e0f8fc;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: gre-fix-ipv6-multicast-route-creation.patch kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch kvm-x86-xen-allow-out-of-range-event-channel-ports-in-irq-routing-table.patch md-md-bitmap-fix-gpf-in-bitmap_get_stats.patch pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch wifi-prevent-a-msdu-attacks-in-mesh-networks.patch x86-mce-amd-add-default-names-for-mca-banks-and-blocks.patch x86-mce-amd-fix-threshold-limit-reset.patch x86-mce-don-t-remove-sysfs-if-thresholding-sysfs-init-fails.patch x86-mce-make-sure-cmci-banks-are-cleared-during-shutdown-on-intel.patch --- diff --git a/queue-6.6/gre-fix-ipv6-multicast-route-creation.patch b/queue-6.6/gre-fix-ipv6-multicast-route-creation.patch new file mode 100644 index 0000000000..b1010635eb --- /dev/null +++ b/queue-6.6/gre-fix-ipv6-multicast-route-creation.patch @@ -0,0 +1,67 @@ +From 4e914ef063de40397e25a025c70d9737a9e45a8c Mon Sep 17 00:00:00 2001 +From: Guillaume Nault +Date: Wed, 9 Jul 2025 16:30:10 +0200 +Subject: gre: Fix IPv6 multicast route creation. + +From: Guillaume Nault + +commit 4e914ef063de40397e25a025c70d9737a9e45a8c upstream. + +Use addrconf_add_dev() instead of ipv6_find_idev() in +addrconf_gre_config() so that we don't just get the inet6_dev, but also +install the default ff00::/8 multicast route. + +Before commit 3e6a0243ff00 ("gre: Fix again IPv6 link-local address +generation."), the multicast route was created at the end of the +function by addrconf_add_mroute(). But this code path is now only taken +in one particular case (gre devices not bound to a local IP address and +in EUI64 mode). For all other cases, the function exits early and +addrconf_add_mroute() is not called anymore. + +Using addrconf_add_dev() instead of ipv6_find_idev() in +addrconf_gre_config(), fixes the problem as it will create the default +multicast route for all gre devices. This also brings +addrconf_gre_config() a bit closer to the normal netdevice IPv6 +configuration code (addrconf_dev_config()). + +Cc: stable@vger.kernel.org +Fixes: 3e6a0243ff00 ("gre: Fix again IPv6 link-local address generation.") +Reported-by: Aiden Yang +Closes: https://lore.kernel.org/netdev/CANR=AhRM7YHHXVxJ4DmrTNMeuEOY87K2mLmo9KMed1JMr20p6g@mail.gmail.com/ +Reviewed-by: Gary Guo +Tested-by: Gary Guo +Signed-off-by: Guillaume Nault +Reviewed-by: Ido Schimmel +Link: https://patch.msgid.link/027a923dcb550ad115e6d93ee8bb7d310378bd01.1752070620.git.gnault@redhat.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv6/addrconf.c | 9 ++------- + 1 file changed, 2 insertions(+), 7 deletions(-) + +--- a/net/ipv6/addrconf.c ++++ b/net/ipv6/addrconf.c +@@ -3499,11 +3499,9 @@ static void addrconf_gre_config(struct n + + ASSERT_RTNL(); + +- idev = ipv6_find_idev(dev); +- if (IS_ERR(idev)) { +- pr_debug("%s: add_dev failed\n", __func__); ++ idev = addrconf_add_dev(dev); ++ if (IS_ERR(idev)) + return; +- } + + /* Generate the IPv6 link-local address using addrconf_addr_gen(), + * unless we have an IPv4 GRE device not bound to an IP address and +@@ -3517,9 +3515,6 @@ static void addrconf_gre_config(struct n + } + + add_v4_addrs(idev); +- +- if (dev->flags & IFF_POINTOPOINT) +- addrconf_add_mroute(dev); + } + #endif + diff --git a/queue-6.6/kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch b/queue-6.6/kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch new file mode 100644 index 0000000000..9158e8122f --- /dev/null +++ b/queue-6.6/kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch @@ -0,0 +1,112 @@ +From ecf371f8b02d5e31b9aa1da7f159f1b2107bdb01 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Mon, 2 Jun 2025 15:44:58 -0700 +Subject: KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight + +From: Sean Christopherson + +commit ecf371f8b02d5e31b9aa1da7f159f1b2107bdb01 upstream. + +Reject migration of SEV{-ES} state if either the source or destination VM +is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the +section between incrementing created_vcpus and online_vcpus. The bulk of +vCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUs +in parallel, and so sev_info.es_active can get toggled from false=>true in +the destination VM after (or during) svm_vcpu_create(), resulting in an +SEV{-ES} VM effectively having a non-SEV{-ES} vCPU. + +The issue manifests most visibly as a crash when trying to free a vCPU's +NULL VMSA page in an SEV-ES VM, but any number of things can go wrong. + + BUG: unable to handle page fault for address: ffffebde00000000 + #PF: supervisor read access in kernel mode + #PF: error_code(0x0000) - not-present page + PGD 0 P4D 0 + Oops: Oops: 0000 [#1] SMP KASAN NOPTI + CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE + Tainted: [U]=USER, [O]=OOT_MODULE + Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 + RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] + RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] + RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] + RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] + RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067 + Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 + RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 + RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 + RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 + RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 + R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 + R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 + FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 + DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 + DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 + Call Trace: + + sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 + svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 + kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 + kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] + kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 + kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 + kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 + kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 + __fput+0x3e4/0x9e0 fs/file_table.c:465 + task_work_run+0x1a9/0x220 kernel/task_work.c:227 + exit_task_work include/linux/task_work.h:40 [inline] + do_exit+0x7f0/0x25b0 kernel/exit.c:953 + do_group_exit+0x203/0x2d0 kernel/exit.c:1102 + get_signal+0x1357/0x1480 kernel/signal.c:3034 + arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 + exit_to_user_mode_loop kernel/entry/common.c:111 [inline] + exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] + __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] + syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 + do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 + entry_SYSCALL_64_after_hwframe+0x76/0x7e + RIP: 0033:0x7f87a898e969 + + Modules linked in: gq(O) + gsmi: Log Shutdown Reason 0x03 + CR2: ffffebde00000000 + ---[ end trace 0000000000000000 ]--- + +Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing +the host is likely desirable due to the VMSA being consumed by hardware. +E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a +bogus VMSA page. Accessing PFN 0 is "fine"-ish now that it's sequestered +away thanks to L1TF, but panicking in this scenario is preferable to +potentially running with corrupted state. + +Reported-by: Alexander Potapenko +Tested-by: Alexander Potapenko +Fixes: 0b020f5af092 ("KVM: SEV: Add support for SEV-ES intra host migration") +Fixes: b56639318bb2 ("KVM: SEV: Add support for SEV intra host migration") +Cc: stable@vger.kernel.org +Cc: James Houghton +Cc: Peter Gonda +Reviewed-by: Liam Merwick +Tested-by: Liam Merwick +Reviewed-by: James Houghton +Link: https://lore.kernel.org/r/20250602224459.41505-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/sev.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/x86/kvm/svm/sev.c ++++ b/arch/x86/kvm/svm/sev.c +@@ -1782,6 +1782,10 @@ static int sev_check_source_vcpus(struct + struct kvm_vcpu *src_vcpu; + unsigned long i; + ++ if (src->created_vcpus != atomic_read(&src->online_vcpus) || ++ dst->created_vcpus != atomic_read(&dst->online_vcpus)) ++ return -EBUSY; ++ + if (!sev_es_guest(src)) + return 0; + diff --git a/queue-6.6/kvm-x86-xen-allow-out-of-range-event-channel-ports-in-irq-routing-table.patch b/queue-6.6/kvm-x86-xen-allow-out-of-range-event-channel-ports-in-irq-routing-table.patch new file mode 100644 index 0000000000..ba6907bd68 --- /dev/null +++ b/queue-6.6/kvm-x86-xen-allow-out-of-range-event-channel-ports-in-irq-routing-table.patch @@ -0,0 +1,61 @@ +From a7f4dff21fd744d08fa956c243d2b1795f23cbf7 Mon Sep 17 00:00:00 2001 +From: David Woodhouse +Date: Thu, 8 May 2025 13:30:12 -0700 +Subject: KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table. + +From: David Woodhouse + +commit a7f4dff21fd744d08fa956c243d2b1795f23cbf7 upstream. + +To avoid imposing an ordering constraint on userspace, allow 'invalid' +event channel targets to be configured in the IRQ routing table. + +This is the same as accepting interrupts targeted at vCPUs which don't +exist yet, which is already the case for both Xen event channels *and* +for MSIs (which don't do any filtering of permitted APIC ID targets at +all). + +If userspace actually *triggers* an IRQ with an invalid target, that +will fail cleanly, as kvm_xen_set_evtchn_fast() also does the same range +check. + +If KVM enforced that the IRQ target must be valid at the time it is +*configured*, that would force userspace to create all vCPUs and do +various other parts of setup (in this case, setting the Xen long_mode) +before restoring the IRQ table. + +Cc: stable@vger.kernel.org +Signed-off-by: David Woodhouse +Reviewed-by: Paul Durrant +Link: https://lore.kernel.org/r/e489252745ac4b53f1f7f50570b03fb416aa2065.camel@infradead.org +[sean: massage comment] +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/xen.c | 15 +++++++++++++-- + 1 file changed, 13 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/xen.c ++++ b/arch/x86/kvm/xen.c +@@ -1737,8 +1737,19 @@ int kvm_xen_setup_evtchn(struct kvm *kvm + { + struct kvm_vcpu *vcpu; + +- if (ue->u.xen_evtchn.port >= max_evtchn_port(kvm)) +- return -EINVAL; ++ /* ++ * Don't check for the port being within range of max_evtchn_port(). ++ * Userspace can configure what ever targets it likes; events just won't ++ * be delivered if/while the target is invalid, just like userspace can ++ * configure MSIs which target non-existent APICs. ++ * ++ * This allow on Live Migration and Live Update, the IRQ routing table ++ * can be restored *independently* of other things like creating vCPUs, ++ * without imposing an ordering dependency on userspace. In this ++ * particular case, the problematic ordering would be with setting the ++ * Xen 'long mode' flag, which changes max_evtchn_port() to allow 4096 ++ * instead of 1024 event channels. ++ */ + + /* We only support 2 level event channels for now */ + if (ue->u.xen_evtchn.priority != KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL) diff --git a/queue-6.6/md-md-bitmap-fix-gpf-in-bitmap_get_stats.patch b/queue-6.6/md-md-bitmap-fix-gpf-in-bitmap_get_stats.patch new file mode 100644 index 0000000000..179b734ebb --- /dev/null +++ b/queue-6.6/md-md-bitmap-fix-gpf-in-bitmap_get_stats.patch @@ -0,0 +1,62 @@ +From c17fb542dbd1db745c9feac15617056506dd7195 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?H=C3=A5kon=20Bugge?= +Date: Wed, 2 Jul 2025 11:10:34 +0200 +Subject: md/md-bitmap: fix GPF in bitmap_get_stats() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: HÃ¥kon Bugge + +commit c17fb542dbd1db745c9feac15617056506dd7195 upstream. + +The commit message of commit 6ec1f0239485 ("md/md-bitmap: fix stats +collection for external bitmaps") states: + + Remove the external bitmap check as the statistics should be + available regardless of bitmap storage location. + + Return -EINVAL only for invalid bitmap with no storage (neither in + superblock nor in external file). + +But, the code does not adhere to the above, as it does only check for +a valid super-block for "internal" bitmaps. Hence, we observe: + +Oops: GPF, probably for non-canonical address 0x1cd66f1f40000028 +RIP: 0010:bitmap_get_stats+0x45/0xd0 +Call Trace: + + seq_read_iter+0x2b9/0x46a + seq_read+0x12f/0x180 + proc_reg_read+0x57/0xb0 + vfs_read+0xf6/0x380 + ksys_read+0x6d/0xf0 + do_syscall_64+0x8c/0x1b0 + entry_SYSCALL_64_after_hwframe+0x76/0x7e + +We fix this by checking the existence of a super-block for both the +internal and external case. + +Fixes: 6ec1f0239485 ("md/md-bitmap: fix stats collection for external bitmaps") +Cc: stable@vger.kernel.org +Reported-by: Gerald Gibson +Signed-off-by: HÃ¥kon Bugge +Link: https://lore.kernel.org/linux-raid/20250702091035.2061312-1-haakon.bugge@oracle.com +Signed-off-by: Yu Kuai +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/md-bitmap.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/md/md-bitmap.c ++++ b/drivers/md/md-bitmap.c +@@ -2119,8 +2119,7 @@ int md_bitmap_get_stats(struct bitmap *b + + if (!bitmap) + return -ENOENT; +- if (!bitmap->mddev->bitmap_info.external && +- !bitmap->storage.sb_page) ++ if (!bitmap->storage.sb_page) + return -EINVAL; + sb = kmap_local_page(bitmap->storage.sb_page); + stats->sync_size = le64_to_cpu(sb->sync_size); diff --git a/queue-6.6/pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch b/queue-6.6/pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch new file mode 100644 index 0000000000..8eaa31c2bf --- /dev/null +++ b/queue-6.6/pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch @@ -0,0 +1,71 @@ +From 93712205ce2f1fb047739494c0399a26ea4f0890 Mon Sep 17 00:00:00 2001 +From: Bartosz Golaszewski +Date: Thu, 12 Jun 2025 11:14:48 +0200 +Subject: pinctrl: qcom: msm: mark certain pins as invalid for interrupts + +From: Bartosz Golaszewski + +commit 93712205ce2f1fb047739494c0399a26ea4f0890 upstream. + +On some platforms, the UFS-reset pin has no interrupt logic in TLMM but +is nevertheless registered as a GPIO in the kernel. This enables the +user-space to trigger a BUG() in the pinctrl-msm driver by running, for +example: `gpiomon -c 0 113` on RB2. + +The exact culprit is requesting pins whose intr_detection_width setting +is not 1 or 2 for interrupts. This hits a BUG() in +msm_gpio_irq_set_type(). Potentially crashing the kernel due to an +invalid request from user-space is not optimal, so let's go through the +pins and mark those that would fail the check as invalid for the irq chip +as we should not even register them as available irqs. + +This function can be extended if we determine that there are more +corner-cases like this. + +Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver") +Cc: stable@vger.kernel.org +Reviewed-by: Bjorn Andersson +Signed-off-by: Bartosz Golaszewski +Link: https://lore.kernel.org/20250612091448.41546-1-brgl@bgdev.pl +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pinctrl/qcom/pinctrl-msm.c | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +--- a/drivers/pinctrl/qcom/pinctrl-msm.c ++++ b/drivers/pinctrl/qcom/pinctrl-msm.c +@@ -1031,6 +1031,25 @@ static bool msm_gpio_needs_dual_edge_par + test_bit(d->hwirq, pctrl->skip_wake_irqs); + } + ++static void msm_gpio_irq_init_valid_mask(struct gpio_chip *gc, ++ unsigned long *valid_mask, ++ unsigned int ngpios) ++{ ++ struct msm_pinctrl *pctrl = gpiochip_get_data(gc); ++ const struct msm_pingroup *g; ++ int i; ++ ++ bitmap_fill(valid_mask, ngpios); ++ ++ for (i = 0; i < ngpios; i++) { ++ g = &pctrl->soc->groups[i]; ++ ++ if (g->intr_detection_width != 1 && ++ g->intr_detection_width != 2) ++ clear_bit(i, valid_mask); ++ } ++} ++ + static int msm_gpio_irq_set_type(struct irq_data *d, unsigned int type) + { + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); +@@ -1392,6 +1411,7 @@ static int msm_gpio_init(struct msm_pinc + girq->default_type = IRQ_TYPE_NONE; + girq->handler = handle_bad_irq; + girq->parents[0] = pctrl->irq; ++ girq->init_valid_mask = msm_gpio_irq_init_valid_mask; + + ret = gpiochip_add_data(&pctrl->chip, pctrl); + if (ret) { diff --git a/queue-6.6/series b/queue-6.6/series index 7ed3cb787a..656564474b 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -31,3 +31,13 @@ perf-build-setup-pkg_config_libdir-for-cross-compilation.patch bluetooth-hci-set-extended-advertising-data-synchronously.patch rxrpc-fix-oops-due-to-non-existence-of-prealloc-backlog-struct.patch ipmi-msghandler-fix-potential-memory-corruption-in-ipmi_create_user.patch +x86-mce-amd-add-default-names-for-mca-banks-and-blocks.patch +x86-mce-amd-fix-threshold-limit-reset.patch +x86-mce-don-t-remove-sysfs-if-thresholding-sysfs-init-fails.patch +x86-mce-make-sure-cmci-banks-are-cleared-during-shutdown-on-intel.patch +kvm-x86-xen-allow-out-of-range-event-channel-ports-in-irq-routing-table.patch +kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch +gre-fix-ipv6-multicast-route-creation.patch +md-md-bitmap-fix-gpf-in-bitmap_get_stats.patch +pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch +wifi-prevent-a-msdu-attacks-in-mesh-networks.patch diff --git a/queue-6.6/wifi-prevent-a-msdu-attacks-in-mesh-networks.patch b/queue-6.6/wifi-prevent-a-msdu-attacks-in-mesh-networks.patch new file mode 100644 index 0000000000..2cedacf1ea --- /dev/null +++ b/queue-6.6/wifi-prevent-a-msdu-attacks-in-mesh-networks.patch @@ -0,0 +1,114 @@ +From 737bb912ebbe4571195c56eba557c4d7315b26fb Mon Sep 17 00:00:00 2001 +From: Mathy Vanhoef +Date: Mon, 16 Jun 2025 02:46:35 +0200 +Subject: wifi: prevent A-MSDU attacks in mesh networks + +From: Mathy Vanhoef + +commit 737bb912ebbe4571195c56eba557c4d7315b26fb upstream. + +This patch is a mitigation to prevent the A-MSDU spoofing vulnerability +for mesh networks. The initial update to the IEEE 802.11 standard, in +response to the FragAttacks, missed this case (CVE-2025-27558). It can +be considered a variant of CVE-2020-24588 but for mesh networks. + +This patch tries to detect if a standard MSDU was turned into an A-MSDU +by an adversary. This is done by parsing a received A-MSDU as a standard +MSDU, calculating the length of the Mesh Control header, and seeing if +the 6 bytes after this header equal the start of an rfc1042 header. If +equal, this is a strong indication of an ongoing attack attempt. + +This defense was tested with mac80211_hwsim against a mesh network that +uses an empty Mesh Address Extension field, i.e., when four addresses +are used, and when using a 12-byte Mesh Address Extension field, i.e., +when six addresses are used. Functionality of normal MSDUs and A-MSDUs +was also tested, and confirmed working, when using both an empty and +12-byte Mesh Address Extension field. + +It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh +networks keep being detected and prevented. + +Note that the vulnerability being patched, and the defense being +implemented, was also discussed in the following paper and in the +following IEEE 802.11 presentation: + +https://papers.mathyvanhoef.com/wisec2025.pdf +https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx + +Cc: stable@vger.kernel.org +Signed-off-by: Mathy Vanhoef +Link: https://patch.msgid.link/20250616004635.224344-1-Mathy.Vanhoef@kuleuven.be +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + net/wireless/util.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++-- + 1 file changed, 50 insertions(+), 2 deletions(-) + +--- a/net/wireless/util.c ++++ b/net/wireless/util.c +@@ -826,6 +826,52 @@ bool ieee80211_is_valid_amsdu(struct sk_ + } + EXPORT_SYMBOL(ieee80211_is_valid_amsdu); + ++ ++/* ++ * Detects if an MSDU frame was maliciously converted into an A-MSDU ++ * frame by an adversary. This is done by parsing the received frame ++ * as if it were a regular MSDU, even though the A-MSDU flag is set. ++ * ++ * For non-mesh interfaces, detection involves checking whether the ++ * payload, when interpreted as an MSDU, begins with a valid RFC1042 ++ * header. This is done by comparing the A-MSDU subheader's destination ++ * address to the start of the RFC1042 header. ++ * ++ * For mesh interfaces, the MSDU includes a 6-byte Mesh Control field ++ * and an optional variable-length Mesh Address Extension field before ++ * the RFC1042 header. The position of the RFC1042 header must therefore ++ * be calculated based on the mesh header length. ++ * ++ * Since this function intentionally parses an A-MSDU frame as an MSDU, ++ * it only assumes that the A-MSDU subframe header is present, and ++ * beyond this it performs its own bounds checks under the assumption ++ * that the frame is instead parsed as a non-aggregated MSDU. ++ */ ++static bool ++is_amsdu_aggregation_attack(struct ethhdr *eth, struct sk_buff *skb, ++ enum nl80211_iftype iftype) ++{ ++ int offset; ++ ++ /* Non-mesh case can be directly compared */ ++ if (iftype != NL80211_IFTYPE_MESH_POINT) ++ return ether_addr_equal(eth->h_dest, rfc1042_header); ++ ++ offset = __ieee80211_get_mesh_hdrlen(eth->h_dest[0]); ++ if (offset == 6) { ++ /* Mesh case with empty address extension field */ ++ return ether_addr_equal(eth->h_source, rfc1042_header); ++ } else if (offset + ETH_ALEN <= skb->len) { ++ /* Mesh case with non-empty address extension field */ ++ u8 temp[ETH_ALEN]; ++ ++ skb_copy_bits(skb, offset, temp, ETH_ALEN); ++ return ether_addr_equal(temp, rfc1042_header); ++ } ++ ++ return false; ++} ++ + void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list, + const u8 *addr, enum nl80211_iftype iftype, + const unsigned int extra_headroom, +@@ -867,8 +913,10 @@ void ieee80211_amsdu_to_8023s(struct sk_ + /* the last MSDU has no padding */ + if (subframe_len > remaining) + goto purge; +- /* mitigate A-MSDU aggregation injection attacks */ +- if (ether_addr_equal(hdr.eth.h_dest, rfc1042_header)) ++ /* mitigate A-MSDU aggregation injection attacks, to be ++ * checked when processing first subframe (offset == 0). ++ */ ++ if (offset == 0 && is_amsdu_aggregation_attack(&hdr.eth, skb, iftype)) + goto purge; + + offset += sizeof(struct ethhdr); diff --git a/queue-6.6/x86-mce-amd-add-default-names-for-mca-banks-and-blocks.patch b/queue-6.6/x86-mce-amd-add-default-names-for-mca-banks-and-blocks.patch new file mode 100644 index 0000000000..e83d0e2149 --- /dev/null +++ b/queue-6.6/x86-mce-amd-add-default-names-for-mca-banks-and-blocks.patch @@ -0,0 +1,58 @@ +From d66e1e90b16055d2f0ee76e5384e3f119c3c2773 Mon Sep 17 00:00:00 2001 +From: Yazen Ghannam +Date: Tue, 24 Jun 2025 14:15:58 +0000 +Subject: x86/mce/amd: Add default names for MCA banks and blocks + +From: Yazen Ghannam + +commit d66e1e90b16055d2f0ee76e5384e3f119c3c2773 upstream. + +Ensure that sysfs init doesn't fail for new/unrecognized bank types or if +a bank has additional blocks available. + +Most MCA banks have a single thresholding block, so the block takes the same +name as the bank. + +Unified Memory Controllers (UMCs) are a special case where there are two +blocks and each has a unique name. + +However, the microarchitecture allows for five blocks. Any new MCA bank types +with more than one block will be missing names for the extra blocks. The MCE +sysfs will fail to initialize in this case. + +Fixes: 87a6d4091bd7 ("x86/mce/AMD: Update sysfs bank names for SMCA systems") +Signed-off-by: Yazen Ghannam +Signed-off-by: Borislav Petkov (AMD) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-3-236dd74f645f@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/mce/amd.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/arch/x86/kernel/cpu/mce/amd.c ++++ b/arch/x86/kernel/cpu/mce/amd.c +@@ -1049,13 +1049,20 @@ static const char *get_name(unsigned int + } + + bank_type = smca_get_bank_type(cpu, bank); +- if (bank_type >= N_SMCA_BANK_TYPES) +- return NULL; + + if (b && (bank_type == SMCA_UMC || bank_type == SMCA_UMC_V2)) { + if (b->block < ARRAY_SIZE(smca_umc_block_names)) + return smca_umc_block_names[b->block]; +- return NULL; ++ } ++ ++ if (b && b->block) { ++ snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_block_%u", b->block); ++ return buf_mcatype; ++ } ++ ++ if (bank_type >= N_SMCA_BANK_TYPES) { ++ snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_bank_%u", bank); ++ return buf_mcatype; + } + + if (per_cpu(smca_bank_counts, cpu)[bank_type] == 1) diff --git a/queue-6.6/x86-mce-amd-fix-threshold-limit-reset.patch b/queue-6.6/x86-mce-amd-fix-threshold-limit-reset.patch new file mode 100644 index 0000000000..9816dc5fc2 --- /dev/null +++ b/queue-6.6/x86-mce-amd-fix-threshold-limit-reset.patch @@ -0,0 +1,59 @@ +From 5f6e3b720694ad771911f637a51930f511427ce1 Mon Sep 17 00:00:00 2001 +From: Yazen Ghannam +Date: Tue, 24 Jun 2025 14:15:59 +0000 +Subject: x86/mce/amd: Fix threshold limit reset + +From: Yazen Ghannam + +commit 5f6e3b720694ad771911f637a51930f511427ce1 upstream. + +The MCA threshold limit must be reset after servicing the interrupt. + +Currently, the restart function doesn't have an explicit check for this. It +makes some assumptions based on the current limit and what's in the registers. +These assumptions don't always hold, so the limit won't be reset in some +cases. + +Make the reset condition explicit. Either an interrupt/overflow has occurred +or the bank is being initialized. + +Signed-off-by: Yazen Ghannam +Signed-off-by: Borislav Petkov (AMD) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-4-236dd74f645f@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/mce/amd.c | 15 +++++++-------- + 1 file changed, 7 insertions(+), 8 deletions(-) + +--- a/arch/x86/kernel/cpu/mce/amd.c ++++ b/arch/x86/kernel/cpu/mce/amd.c +@@ -335,7 +335,6 @@ static void smca_configure(unsigned int + + struct thresh_restart { + struct threshold_block *b; +- int reset; + int set_lvt_off; + int lvt_off; + u16 old_limit; +@@ -430,13 +429,13 @@ static void threshold_restart_bank(void + + rdmsr(tr->b->address, lo, hi); + +- if (tr->b->threshold_limit < (hi & THRESHOLD_MAX)) +- tr->reset = 1; /* limit cannot be lower than err count */ +- +- if (tr->reset) { /* reset err count and overflow bit */ +- hi = +- (hi & ~(MASK_ERR_COUNT_HI | MASK_OVERFLOW_HI)) | +- (THRESHOLD_MAX - tr->b->threshold_limit); ++ /* ++ * Reset error count and overflow bit. ++ * This is done during init or after handling an interrupt. ++ */ ++ if (hi & MASK_OVERFLOW_HI || tr->set_lvt_off) { ++ hi &= ~(MASK_ERR_COUNT_HI | MASK_OVERFLOW_HI); ++ hi |= THRESHOLD_MAX - tr->b->threshold_limit; + } else if (tr->old_limit) { /* change limit w/o reset */ + int new_count = (hi & THRESHOLD_MAX) + + (tr->old_limit - tr->b->threshold_limit); diff --git a/queue-6.6/x86-mce-don-t-remove-sysfs-if-thresholding-sysfs-init-fails.patch b/queue-6.6/x86-mce-don-t-remove-sysfs-if-thresholding-sysfs-init-fails.patch new file mode 100644 index 0000000000..541e6216d5 --- /dev/null +++ b/queue-6.6/x86-mce-don-t-remove-sysfs-if-thresholding-sysfs-init-fails.patch @@ -0,0 +1,52 @@ +From 4c113a5b28bfd589e2010b5fc8867578b0135ed7 Mon Sep 17 00:00:00 2001 +From: Yazen Ghannam +Date: Tue, 24 Jun 2025 14:15:56 +0000 +Subject: x86/mce: Don't remove sysfs if thresholding sysfs init fails + +From: Yazen Ghannam + +commit 4c113a5b28bfd589e2010b5fc8867578b0135ed7 upstream. + +Currently, the MCE subsystem sysfs interface will be removed if the +thresholding sysfs interface fails to be created. A common failure is due to +new MCA bank types that are not recognized and don't have a short name set. + +The MCA thresholding feature is optional and should not break the common MCE +sysfs interface. Also, new MCA bank types are occasionally introduced, and +updates will be needed to recognize them. But likewise, this should not break +the common sysfs interface. + +Keep the MCE sysfs interface regardless of the status of the thresholding +sysfs interface. + +Signed-off-by: Yazen Ghannam +Signed-off-by: Borislav Petkov (AMD) +Reviewed-by: Qiuxu Zhuo +Reviewed-by: Tony Luck +Tested-by: Tony Luck +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-1-236dd74f645f@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/mce/core.c | 8 +------- + 1 file changed, 1 insertion(+), 7 deletions(-) + +--- a/arch/x86/kernel/cpu/mce/core.c ++++ b/arch/x86/kernel/cpu/mce/core.c +@@ -2704,15 +2704,9 @@ static int mce_cpu_dead(unsigned int cpu + static int mce_cpu_online(unsigned int cpu) + { + struct timer_list *t = this_cpu_ptr(&mce_timer); +- int ret; + + mce_device_create(cpu); +- +- ret = mce_threshold_create_device(cpu); +- if (ret) { +- mce_device_remove(cpu); +- return ret; +- } ++ mce_threshold_create_device(cpu); + mce_reenable_cpu(); + mce_start_timer(t); + return 0; diff --git a/queue-6.6/x86-mce-make-sure-cmci-banks-are-cleared-during-shutdown-on-intel.patch b/queue-6.6/x86-mce-make-sure-cmci-banks-are-cleared-during-shutdown-on-intel.patch new file mode 100644 index 0000000000..c8207cf520 --- /dev/null +++ b/queue-6.6/x86-mce-make-sure-cmci-banks-are-cleared-during-shutdown-on-intel.patch @@ -0,0 +1,40 @@ +From 30ad231a5029bfa16e46ce868497b1a5cdd3c24d Mon Sep 17 00:00:00 2001 +From: JP Kobryn +Date: Fri, 27 Jun 2025 10:49:35 -0700 +Subject: x86/mce: Make sure CMCI banks are cleared during shutdown on Intel + +From: JP Kobryn + +commit 30ad231a5029bfa16e46ce868497b1a5cdd3c24d upstream. + +CMCI banks are not cleared during shutdown on Intel CPUs. As a side effect, +when a kexec is performed, CPUs coming back online are unable to +rediscover/claim these occupied banks which breaks MCE reporting. + +Clear the CPU ownership during shutdown via cmci_clear() so the banks can +be reclaimed and MCE reporting will become functional once more. + + [ bp: Massage commit message. ] + +Reported-by: Aijay Adams +Signed-off-by: JP Kobryn +Signed-off-by: Borislav Petkov (AMD) +Reviewed-by: Tony Luck +Reviewed-by: Qiuxu Zhuo +Cc: +Link: https://lore.kernel.org/20250627174935.95194-1-inwardvessel@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/mce/intel.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/kernel/cpu/mce/intel.c ++++ b/arch/x86/kernel/cpu/mce/intel.c +@@ -517,6 +517,7 @@ void mce_intel_feature_init(struct cpuin + void mce_intel_feature_clear(struct cpuinfo_x86 *c) + { + intel_clear_lmce(); ++ cmci_clear(); + } + + bool intel_filter_mce(struct mce *m)