--- /dev/null
+From 4e914ef063de40397e25a025c70d9737a9e45a8c Mon Sep 17 00:00:00 2001
+From: Guillaume Nault <gnault@redhat.com>
+Date: Wed, 9 Jul 2025 16:30:10 +0200
+Subject: gre: Fix IPv6 multicast route creation.
+
+From: Guillaume Nault <gnault@redhat.com>
+
+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 <ling@moedove.com>
+Closes: https://lore.kernel.org/netdev/CANR=AhRM7YHHXVxJ4DmrTNMeuEOY87K2mLmo9KMed1JMr20p6g@mail.gmail.com/
+Reviewed-by: Gary Guo <gary@garyguo.net>
+Tested-by: Gary Guo <gary@garyguo.net>
+Signed-off-by: Guillaume Nault <gnault@redhat.com>
+Reviewed-by: Ido Schimmel <idosch@nvidia.com>
+Link: https://patch.msgid.link/027a923dcb550ad115e6d93ee8bb7d310378bd01.1752070620.git.gnault@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From ecf371f8b02d5e31b9aa1da7f159f1b2107bdb01 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+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 <seanjc@google.com>
+
+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:
+ <TASK>
+ 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
+ </TASK>
+ 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 <glider@google.com>
+Tested-by: Alexander Potapenko <glider@google.com>
+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 <jthoughton@google.com>
+Cc: Peter Gonda <pgonda@google.com>
+Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
+Tested-by: Liam Merwick <liam.merwick@oracle.com>
+Reviewed-by: James Houghton <jthoughton@google.com>
+Link: https://lore.kernel.org/r/20250602224459.41505-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From a7f4dff21fd744d08fa956c243d2b1795f23cbf7 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+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 <dwmw@amazon.co.uk>
+
+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 <dwmw@amazon.co.uk>
+Reviewed-by: Paul Durrant <paul@xen.org>
+Link: https://lore.kernel.org/r/e489252745ac4b53f1f7f50570b03fb416aa2065.camel@infradead.org
+[sean: massage comment]
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From c17fb542dbd1db745c9feac15617056506dd7195 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?H=C3=A5kon=20Bugge?= <haakon.bugge@oracle.com>
+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 <haakon.bugge@oracle.com>
+
+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 <gerald.gibson@oracle.com>
+Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
+Link: https://lore.kernel.org/linux-raid/20250702091035.2061312-1-haakon.bugge@oracle.com
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 93712205ce2f1fb047739494c0399a26ea4f0890 Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Date: Thu, 12 Jun 2025 11:14:48 +0200
+Subject: pinctrl: qcom: msm: mark certain pins as invalid for interrupts
+
+From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+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 <andersson@kernel.org>
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Link: https://lore.kernel.org/20250612091448.41546-1-brgl@bgdev.pl
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
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
--- /dev/null
+From 737bb912ebbe4571195c56eba557c4d7315b26fb Mon Sep 17 00:00:00 2001
+From: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
+Date: Mon, 16 Jun 2025 02:46:35 +0200
+Subject: wifi: prevent A-MSDU attacks in mesh networks
+
+From: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
+
+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 <Mathy.Vanhoef@kuleuven.be>
+Link: https://patch.msgid.link/20250616004635.224344-1-Mathy.Vanhoef@kuleuven.be
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From d66e1e90b16055d2f0ee76e5384e3f119c3c2773 Mon Sep 17 00:00:00 2001
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+Date: Tue, 24 Jun 2025 14:15:58 +0000
+Subject: x86/mce/amd: Add default names for MCA banks and blocks
+
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+
+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 <yazen.ghannam@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+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 <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From 5f6e3b720694ad771911f637a51930f511427ce1 Mon Sep 17 00:00:00 2001
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+Date: Tue, 24 Jun 2025 14:15:59 +0000
+Subject: x86/mce/amd: Fix threshold limit reset
+
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+
+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 <yazen.ghannam@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+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 <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 4c113a5b28bfd589e2010b5fc8867578b0135ed7 Mon Sep 17 00:00:00 2001
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+Date: Tue, 24 Jun 2025 14:15:56 +0000
+Subject: x86/mce: Don't remove sysfs if thresholding sysfs init fails
+
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+
+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 <yazen.ghannam@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
+Reviewed-by: Tony Luck <tony.luck@intel.com>
+Tested-by: Tony Luck <tony.luck@intel.com>
+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 <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 30ad231a5029bfa16e46ce868497b1a5cdd3c24d Mon Sep 17 00:00:00 2001
+From: JP Kobryn <inwardvessel@gmail.com>
+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 <inwardvessel@gmail.com>
+
+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 <aijay@meta.com>
+Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Tony Luck <tony.luck@intel.com>
+Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/20250627174935.95194-1-inwardvessel@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
projects / thirdparty / kernel / stable-queue.git / commitdiff
