From: Greg Kroah-Hartman Date: Sat, 12 Jul 2025 14:24:23 +0000 (+0200) Subject: 6.15-stable patches X-Git-Tag: v5.15.188~60 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=90443bda31e14db2fa66adb766274b6677f395ed;p=thirdparty%2Fkernel%2Fstable-queue.git 6.15-stable patches added patches: alsa-ad1816a-fix-potential-null-pointer-deref-in-snd_card_ad1816a_pnp.patch alsa-hda-realtek-add-mute-led-support-for-hp-victus-15-fb2xxx.patch arm64-filter-out-sme-hwcaps-when-feat_sme-isn-t-implemented.patch asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch drm-amdgpu-include-sdma_4_4_4.bin.patch drm-amdkfd-add-hqd_sdma_get_doorbell-callbacks-for-gfx7-8.patch drm-amdkfd-don-t-call-mmput-from-mmu-notifier-callback.patch drm-imagination-fix-kernel-crash-when-hard-resetting-the-gpu.patch gpiolib-fix-performance-regression-when-using-gpio_chip_get_multiple.patch gre-fix-ipv6-multicast-route-creation.patch io_uring-msg_ring-ensure-io_kiocb-freeing-is-deferred-for-rcu.patch kvm-allow-cpu-to-reschedule-while-setting-per-page-memory-attributes.patch kvm-svm-add-missing-member-in-snp_launch_start-command-structure.patch kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch kvm-x86-hyper-v-skip-non-canonical-addresses-during-pv-tlb-flush.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 net-ethernet-rtsn-fix-a-null-pointer-dereference-in-rtsn_probe.patch pinctrl-nuvoton-fix-boot-on-ma35dx-platforms.patch pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch pwm-fix-invalid-state-detection.patch pwm-mediatek-ensure-to-disable-clocks-in-error-path.patch sched-fix-preemption-string-of-preempt_dynamic_none.patch wifi-mt76-mt7921-prevent-decap-offload-config-before-sta-initialization.patch wifi-mt76-mt7925-fix-invalid-array-index-in-ssid-assignment-during-hw-scan.patch wifi-mt76-mt7925-fix-the-wrong-config-for-tx-interrupt.patch wifi-mt76-mt7925-prevent-null-pointer-dereference-in-mt7925_sta_set_decap_offload.patch wifi-mwifiex-discard-erroneous-disassoc-frames-on-sta-interface.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-ensure-user-polling-settings-are-honored-when-restarting-timer.patch x86-mce-make-sure-cmci-banks-are-cleared-during-shutdown-on-intel.patch --- diff --git a/queue-6.15/alsa-ad1816a-fix-potential-null-pointer-deref-in-snd_card_ad1816a_pnp.patch b/queue-6.15/alsa-ad1816a-fix-potential-null-pointer-deref-in-snd_card_ad1816a_pnp.patch new file mode 100644 index 0000000000..3ee2d2b757 --- /dev/null +++ b/queue-6.15/alsa-ad1816a-fix-potential-null-pointer-deref-in-snd_card_ad1816a_pnp.patch @@ -0,0 +1,33 @@ +From 043faef334a1f3d96ae88e1b7618bfa2b4946388 Mon Sep 17 00:00:00 2001 +From: Thorsten Blum +Date: Thu, 3 Jul 2025 22:06:13 +0200 +Subject: ALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp() + +From: Thorsten Blum + +commit 043faef334a1f3d96ae88e1b7618bfa2b4946388 upstream. + +Use pr_warn() instead of dev_warn() when 'pdev' is NULL to avoid a +potential NULL pointer dereference. + +Cc: stable@vger.kernel.org +Fixes: 20869176d7a7 ("ALSA: ad1816a: Use standard print API") +Signed-off-by: Thorsten Blum +Link: https://patch.msgid.link/20250703200616.304309-2-thorsten.blum@linux.dev +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/isa/ad1816a/ad1816a.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/isa/ad1816a/ad1816a.c ++++ b/sound/isa/ad1816a/ad1816a.c +@@ -98,7 +98,7 @@ static int snd_card_ad1816a_pnp(int dev, + pdev = pnp_request_card_device(card, id->devs[1].id, NULL); + if (pdev == NULL) { + mpu_port[dev] = -1; +- dev_warn(&pdev->dev, "MPU401 device busy, skipping.\n"); ++ pr_warn("MPU401 device busy, skipping.\n"); + return 0; + } + diff --git a/queue-6.15/alsa-hda-realtek-add-mute-led-support-for-hp-victus-15-fb2xxx.patch b/queue-6.15/alsa-hda-realtek-add-mute-led-support-for-hp-victus-15-fb2xxx.patch new file mode 100644 index 0000000000..8efc895253 --- /dev/null +++ b/queue-6.15/alsa-hda-realtek-add-mute-led-support-for-hp-victus-15-fb2xxx.patch @@ -0,0 +1,34 @@ +From ce174b48aebb3fa18fe48c59a3d10a89c414fdf2 Mon Sep 17 00:00:00 2001 +From: Edip Hazuri +Date: Fri, 27 Jun 2025 23:34:16 +0300 +Subject: ALSA: hda/realtek - Add mute LED support for HP Victus 15-fb2xxx + +From: Edip Hazuri + +commit ce174b48aebb3fa18fe48c59a3d10a89c414fdf2 upstream. + +The mute led on this laptop is using ALC245 but requires a quirk to work +This patch enables the existing quirk for the device. + +Tested on my friend's Victus 15-fb2xxx Laptop. The LED behaviour works +as intended. + +Cc: +Signed-off-by: Edip Hazuri +Link: https://patch.msgid.link/20250627203415.56785-2-edip@medip.dev +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -10855,6 +10855,7 @@ static const struct hda_quirk alc269_fix + SND_PCI_QUIRK(0x103c, 0x8ce0, "HP SnowWhite", ALC287_FIXUP_CS35L41_I2C_2_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x8cf5, "HP ZBook Studio 16", ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x8d01, "HP ZBook Power 14 G12", ALC285_FIXUP_HP_GPIO_LED), ++ SND_PCI_QUIRK(0x103c, 0x8d07, "HP Victus 15-fb2xxx (MB 8D07)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), + SND_PCI_QUIRK(0x103c, 0x8d18, "HP EliteStudio 8 AIO", ALC274_FIXUP_HP_AIO_BIND_DACS), + SND_PCI_QUIRK(0x103c, 0x8d84, "HP EliteBook X G1i", ALC285_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x8d85, "HP EliteBook 14 G12", ALC285_FIXUP_HP_GPIO_LED), diff --git a/queue-6.15/arm64-filter-out-sme-hwcaps-when-feat_sme-isn-t-implemented.patch b/queue-6.15/arm64-filter-out-sme-hwcaps-when-feat_sme-isn-t-implemented.patch new file mode 100644 index 0000000000..8df091ae1b --- /dev/null +++ b/queue-6.15/arm64-filter-out-sme-hwcaps-when-feat_sme-isn-t-implemented.patch @@ -0,0 +1,106 @@ +From a75ad2fc76a2ab70817c7eed3163b66ea84ca6ac Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Fri, 20 Jun 2025 12:28:48 +0100 +Subject: arm64: Filter out SME hwcaps when FEAT_SME isn't implemented + +From: Mark Brown + +commit a75ad2fc76a2ab70817c7eed3163b66ea84ca6ac upstream. + +We have a number of hwcaps for various SME subfeatures enumerated via +ID_AA64SMFR0_EL1. Currently we advertise these without cross checking +against the main SME feature, advertised in ID_AA64PFR1_EL1.SME which +means that if the two are out of sync userspace can see a confusing +situation where SME subfeatures are advertised without the base SME +hwcap. This can be readily triggered by using the arm64.nosme override +which only masks out ID_AA64PFR1_EL1.SME, and there have also been +reports of VMMs which do the same thing. + +Fix this as we did previously for SVE in 064737920bdb ("arm64: Filter +out SVE hwcaps when FEAT_SVE isn't implemented") by filtering out the +SME subfeature hwcaps when FEAT_SME is not present. + +Fixes: 5e64b862c482 ("arm64/sme: Basic enumeration support") +Reported-by: Yury Khrustalev +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250620-arm64-sme-filter-hwcaps-v1-1-02b9d3c2d8ef@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/cpufeature.c | 57 +++++++++++++++++++++++------------------ + 1 file changed, 32 insertions(+), 25 deletions(-) + +--- a/arch/arm64/kernel/cpufeature.c ++++ b/arch/arm64/kernel/cpufeature.c +@@ -3122,6 +3122,13 @@ static bool has_sve_feature(const struct + } + #endif + ++#ifdef CONFIG_ARM64_SME ++static bool has_sme_feature(const struct arm64_cpu_capabilities *cap, int scope) ++{ ++ return system_supports_sme() && has_user_cpuid_feature(cap, scope); ++} ++#endif ++ + static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = { + HWCAP_CAP(ID_AA64ISAR0_EL1, AES, PMULL, CAP_HWCAP, KERNEL_HWCAP_PMULL), + HWCAP_CAP(ID_AA64ISAR0_EL1, AES, AES, CAP_HWCAP, KERNEL_HWCAP_AES), +@@ -3210,31 +3217,31 @@ static const struct arm64_cpu_capabiliti + HWCAP_CAP(ID_AA64ISAR2_EL1, BC, IMP, CAP_HWCAP, KERNEL_HWCAP_HBC), + #ifdef CONFIG_ARM64_SME + HWCAP_CAP(ID_AA64PFR1_EL1, SME, IMP, CAP_HWCAP, KERNEL_HWCAP_SME), +- HWCAP_CAP(ID_AA64SMFR0_EL1, FA64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_FA64), +- HWCAP_CAP(ID_AA64SMFR0_EL1, LUTv2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_LUTV2), +- HWCAP_CAP(ID_AA64SMFR0_EL1, SMEver, SME2p2, CAP_HWCAP, KERNEL_HWCAP_SME2P2), +- HWCAP_CAP(ID_AA64SMFR0_EL1, SMEver, SME2p1, CAP_HWCAP, KERNEL_HWCAP_SME2P1), +- HWCAP_CAP(ID_AA64SMFR0_EL1, SMEver, SME2, CAP_HWCAP, KERNEL_HWCAP_SME2), +- HWCAP_CAP(ID_AA64SMFR0_EL1, I16I64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I64), +- HWCAP_CAP(ID_AA64SMFR0_EL1, F64F64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F64F64), +- HWCAP_CAP(ID_AA64SMFR0_EL1, I16I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I32), +- HWCAP_CAP(ID_AA64SMFR0_EL1, B16B16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16B16), +- HWCAP_CAP(ID_AA64SMFR0_EL1, F16F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F16), +- HWCAP_CAP(ID_AA64SMFR0_EL1, F8F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F16), +- HWCAP_CAP(ID_AA64SMFR0_EL1, F8F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F32), +- HWCAP_CAP(ID_AA64SMFR0_EL1, I8I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I8I32), +- HWCAP_CAP(ID_AA64SMFR0_EL1, F16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F32), +- HWCAP_CAP(ID_AA64SMFR0_EL1, B16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16F32), +- HWCAP_CAP(ID_AA64SMFR0_EL1, BI32I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_BI32I32), +- HWCAP_CAP(ID_AA64SMFR0_EL1, F32F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F32F32), +- HWCAP_CAP(ID_AA64SMFR0_EL1, SF8FMA, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8FMA), +- HWCAP_CAP(ID_AA64SMFR0_EL1, SF8DP4, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP4), +- HWCAP_CAP(ID_AA64SMFR0_EL1, SF8DP2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP2), +- HWCAP_CAP(ID_AA64SMFR0_EL1, SBitPerm, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SBITPERM), +- HWCAP_CAP(ID_AA64SMFR0_EL1, AES, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_AES), +- HWCAP_CAP(ID_AA64SMFR0_EL1, SFEXPA, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SFEXPA), +- HWCAP_CAP(ID_AA64SMFR0_EL1, STMOP, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_STMOP), +- HWCAP_CAP(ID_AA64SMFR0_EL1, SMOP4, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SMOP4), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, FA64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_FA64), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, LUTv2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_LUTV2), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2p2, CAP_HWCAP, KERNEL_HWCAP_SME2P2), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2p1, CAP_HWCAP, KERNEL_HWCAP_SME2P1), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2, CAP_HWCAP, KERNEL_HWCAP_SME2), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, I16I64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I64), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F64F64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F64F64), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, I16I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I32), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, B16B16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16B16), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F16F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F16), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F8F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F16), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F8F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F32), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, I8I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I8I32), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F32), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, B16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16F32), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, BI32I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_BI32I32), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F32F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F32F32), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SF8FMA, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8FMA), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SF8DP4, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP4), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SF8DP2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP2), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SBitPerm, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SBITPERM), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, AES, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_AES), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SFEXPA, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SFEXPA), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, STMOP, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_STMOP), ++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMOP4, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SMOP4), + #endif /* CONFIG_ARM64_SME */ + HWCAP_CAP(ID_AA64FPFR0_EL1, F8CVT, IMP, CAP_HWCAP, KERNEL_HWCAP_F8CVT), + HWCAP_CAP(ID_AA64FPFR0_EL1, F8FMA, IMP, CAP_HWCAP, KERNEL_HWCAP_F8FMA), diff --git a/queue-6.15/asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch b/queue-6.15/asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch new file mode 100644 index 0000000000..b5ba251dd2 --- /dev/null +++ b/queue-6.15/asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch @@ -0,0 +1,59 @@ +From dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 Mon Sep 17 00:00:00 2001 +From: Arun Raghavan +Date: Thu, 26 Jun 2025 09:08:25 -0400 +Subject: ASoC: fsl_sai: Force a software reset when starting in consumer mode + +From: Arun Raghavan + +commit dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 upstream. + +On an imx8mm platform with an external clock provider, when running the +receiver (arecord) and triggering an xrun with xrun_injection, we see a +channel swap/offset. This happens sometimes when running only the +receiver, but occurs reliably if a transmitter (aplay) is also +concurrently running. + +It seems that the SAI loses track of frame sync during the trigger stop +-> trigger start cycle that occurs during an xrun. Doing just a FIFO +reset in this case does not suffice, and only a software reset seems to +get it back on track. + +This looks like the same h/w bug that is already handled for the +producer case, so we now do the reset unconditionally on config disable. + +Signed-off-by: Arun Raghavan +Reported-by: Pieterjan Camerlynck +Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode") +Cc: stable@vger.kernel.org +Reviewed-by: Fabio Estevam +Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/fsl/fsl_sai.c | 14 ++++++++------ + 1 file changed, 8 insertions(+), 6 deletions(-) + +--- a/sound/soc/fsl/fsl_sai.c ++++ b/sound/soc/fsl/fsl_sai.c +@@ -771,13 +771,15 @@ static void fsl_sai_config_disable(struc + * anymore. Add software reset to fix this issue. + * This is a hardware bug, and will be fix in the + * next sai version. ++ * ++ * In consumer mode, this can happen even after a ++ * single open/close, especially if both tx and rx ++ * are running concurrently. + */ +- if (!sai->is_consumer_mode[tx]) { +- /* Software Reset */ +- regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); +- /* Clear SR bit to finish the reset */ +- regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); +- } ++ /* Software Reset */ ++ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR); ++ /* Clear SR bit to finish the reset */ ++ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0); + } + + static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd, diff --git a/queue-6.15/drm-amdgpu-include-sdma_4_4_4.bin.patch b/queue-6.15/drm-amdgpu-include-sdma_4_4_4.bin.patch new file mode 100644 index 0000000000..36aa42f119 --- /dev/null +++ b/queue-6.15/drm-amdgpu-include-sdma_4_4_4.bin.patch @@ -0,0 +1,37 @@ +From e54c5de901ea56fc68f8d56b3cce9940169346f4 Mon Sep 17 00:00:00 2001 +From: Kent Russell +Date: Tue, 24 Jun 2025 11:42:06 -0400 +Subject: drm/amdgpu: Include sdma_4_4_4.bin + +From: Kent Russell + +commit e54c5de901ea56fc68f8d56b3cce9940169346f4 upstream. + +This got missed during SDMA 4.4.4 support. + +Fixes: 968e3811c3e8 ("drm/amdgpu: add initial support for sdma444") +Signed-off-by: Kent Russell +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +(cherry picked from commit 51526efe02714339ed6139f7bc348377d363200a) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c b/drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c +index cef68df4c663..bb82c652e4c0 100644 +--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c ++++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c +@@ -45,6 +45,7 @@ + #include "amdgpu_ras.h" + + MODULE_FIRMWARE("amdgpu/sdma_4_4_2.bin"); ++MODULE_FIRMWARE("amdgpu/sdma_4_4_4.bin"); + MODULE_FIRMWARE("amdgpu/sdma_4_4_5.bin"); + + static const struct amdgpu_hwip_reg_entry sdma_reg_list_4_4_2[] = { +-- +2.50.1 + diff --git a/queue-6.15/drm-amdkfd-add-hqd_sdma_get_doorbell-callbacks-for-gfx7-8.patch b/queue-6.15/drm-amdkfd-add-hqd_sdma_get_doorbell-callbacks-for-gfx7-8.patch new file mode 100644 index 0000000000..20c21742c5 --- /dev/null +++ b/queue-6.15/drm-amdkfd-add-hqd_sdma_get_doorbell-callbacks-for-gfx7-8.patch @@ -0,0 +1,72 @@ +From 34659c1a1f4fd4c148ab13e13b11fd64df01ffcd Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 25 Jun 2025 18:15:37 -0400 +Subject: drm/amdkfd: add hqd_sdma_get_doorbell callbacks for gfx7/8 + +From: Alex Deucher + +commit 34659c1a1f4fd4c148ab13e13b11fd64df01ffcd upstream. + +These were missed when support was added for other generations. +The callbacks are called unconditionally so we need to make +sure all generations have them. + +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4304 +Link: https://github.com/ROCm/ROCm/issues/4965 +Fixes: bac38ca8c475 ("drm/amdkfd: implement per queue sdma reset for gfx 9.4+") +Cc: Jonathan Kim +Reported-by: Johl Brown +Reviewed-by: Jonathan Kim +Signed-off-by: Alex Deucher +(cherry picked from commit 1e9d17a5dcf1242e9518e461d8e63ad35240e49e) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 8 ++++++++ + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 8 ++++++++ + 2 files changed, 16 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c +@@ -561,6 +561,13 @@ static uint32_t read_vmid_from_vmfault_r + return REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS, VMID); + } + ++static uint32_t kgd_hqd_sdma_get_doorbell(struct amdgpu_device *adev, ++ int engine, int queue) ++ ++{ ++ return 0; ++} ++ + const struct kfd2kgd_calls gfx_v7_kfd2kgd = { + .program_sh_mem_settings = kgd_program_sh_mem_settings, + .set_pasid_vmid_mapping = kgd_set_pasid_vmid_mapping, +@@ -578,4 +585,5 @@ const struct kfd2kgd_calls gfx_v7_kfd2kg + .set_scratch_backing_va = set_scratch_backing_va, + .set_vm_context_page_table_base = set_vm_context_page_table_base, + .read_vmid_from_vmfault_reg = read_vmid_from_vmfault_reg, ++ .hqd_sdma_get_doorbell = kgd_hqd_sdma_get_doorbell, + }; +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c +@@ -582,6 +582,13 @@ static void set_vm_context_page_table_ba + lower_32_bits(page_table_base)); + } + ++static uint32_t kgd_hqd_sdma_get_doorbell(struct amdgpu_device *adev, ++ int engine, int queue) ++ ++{ ++ return 0; ++} ++ + const struct kfd2kgd_calls gfx_v8_kfd2kgd = { + .program_sh_mem_settings = kgd_program_sh_mem_settings, + .set_pasid_vmid_mapping = kgd_set_pasid_vmid_mapping, +@@ -599,4 +606,5 @@ const struct kfd2kgd_calls gfx_v8_kfd2kg + get_atc_vmid_pasid_mapping_info, + .set_scratch_backing_va = set_scratch_backing_va, + .set_vm_context_page_table_base = set_vm_context_page_table_base, ++ .hqd_sdma_get_doorbell = kgd_hqd_sdma_get_doorbell, + }; diff --git a/queue-6.15/drm-amdkfd-don-t-call-mmput-from-mmu-notifier-callback.patch b/queue-6.15/drm-amdkfd-don-t-call-mmput-from-mmu-notifier-callback.patch new file mode 100644 index 0000000000..41a110f887 --- /dev/null +++ b/queue-6.15/drm-amdkfd-don-t-call-mmput-from-mmu-notifier-callback.patch @@ -0,0 +1,185 @@ +From cf234231fcbc7d391e2135b9518613218cc5347f Mon Sep 17 00:00:00 2001 +From: Philip Yang +Date: Fri, 20 Jun 2025 18:32:32 -0400 +Subject: drm/amdkfd: Don't call mmput from MMU notifier callback + +From: Philip Yang + +commit cf234231fcbc7d391e2135b9518613218cc5347f upstream. + +If the process is exiting, the mmput inside mmu notifier callback from +compactd or fork or numa balancing could release the last reference +of mm struct to call exit_mmap and free_pgtable, this triggers deadlock +with below backtrace. + +The deadlock will leak kfd process as mmu notifier release is not called +and cause VRAM leaking. + +The fix is to take mm reference mmget_non_zero when adding prange to the +deferred list to pair with mmput in deferred list work. + +If prange split and add into pchild list, the pchild work_item.mm is not +used, so remove the mm parameter from svm_range_unmap_split and +svm_range_add_child. + +The backtrace of hung task: + + INFO: task python:348105 blocked for more than 64512 seconds. + Call Trace: + __schedule+0x1c3/0x550 + schedule+0x46/0xb0 + rwsem_down_write_slowpath+0x24b/0x4c0 + unlink_anon_vmas+0xb1/0x1c0 + free_pgtables+0xa9/0x130 + exit_mmap+0xbc/0x1a0 + mmput+0x5a/0x140 + svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] + mn_itree_invalidate+0x72/0xc0 + __mmu_notifier_invalidate_range_start+0x48/0x60 + try_to_unmap_one+0x10fa/0x1400 + rmap_walk_anon+0x196/0x460 + try_to_unmap+0xbb/0x210 + migrate_page_unmap+0x54d/0x7e0 + migrate_pages_batch+0x1c3/0xae0 + migrate_pages_sync+0x98/0x240 + migrate_pages+0x25c/0x520 + compact_zone+0x29d/0x590 + compact_zone_order+0xb6/0xf0 + try_to_compact_pages+0xbe/0x220 + __alloc_pages_direct_compact+0x96/0x1a0 + __alloc_pages_slowpath+0x410/0x930 + __alloc_pages_nodemask+0x3a9/0x3e0 + do_huge_pmd_anonymous_page+0xd7/0x3e0 + __handle_mm_fault+0x5e3/0x5f0 + handle_mm_fault+0xf7/0x2e0 + hmm_vma_fault.isra.0+0x4d/0xa0 + walk_pmd_range.isra.0+0xa8/0x310 + walk_pud_range+0x167/0x240 + walk_pgd_range+0x55/0x100 + __walk_page_range+0x87/0x90 + walk_page_range+0xf6/0x160 + hmm_range_fault+0x4f/0x90 + amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] + amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] + init_user_pages+0xb1/0x2a0 [amdgpu] + amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] + kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] + kfd_ioctl+0x29d/0x500 [amdgpu] + +Fixes: fa582c6f3684 ("drm/amdkfd: Use mmget_not_zero in MMU notifier") +Signed-off-by: Philip Yang +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 43 ++++++++++++++++------------------- + 1 file changed, 20 insertions(+), 23 deletions(-) + +--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c +@@ -1171,13 +1171,12 @@ svm_range_split_head(struct svm_range *p + } + + static void +-svm_range_add_child(struct svm_range *prange, struct mm_struct *mm, +- struct svm_range *pchild, enum svm_work_list_ops op) ++svm_range_add_child(struct svm_range *prange, struct svm_range *pchild, enum svm_work_list_ops op) + { + pr_debug("add child 0x%p [0x%lx 0x%lx] to prange 0x%p child list %d\n", + pchild, pchild->start, pchild->last, prange, op); + +- pchild->work_item.mm = mm; ++ pchild->work_item.mm = NULL; + pchild->work_item.op = op; + list_add_tail(&pchild->child_list, &prange->child_list); + } +@@ -2394,15 +2393,17 @@ svm_range_add_list_work(struct svm_range + prange->work_item.op != SVM_OP_UNMAP_RANGE) + prange->work_item.op = op; + } else { +- prange->work_item.op = op; +- +- /* Pairs with mmput in deferred_list_work */ +- mmget(mm); +- prange->work_item.mm = mm; +- list_add_tail(&prange->deferred_list, +- &prange->svms->deferred_range_list); +- pr_debug("add prange 0x%p [0x%lx 0x%lx] to work list op %d\n", +- prange, prange->start, prange->last, op); ++ /* Pairs with mmput in deferred_list_work. ++ * If process is exiting and mm is gone, don't update mmu notifier. ++ */ ++ if (mmget_not_zero(mm)) { ++ prange->work_item.mm = mm; ++ prange->work_item.op = op; ++ list_add_tail(&prange->deferred_list, ++ &prange->svms->deferred_range_list); ++ pr_debug("add prange 0x%p [0x%lx 0x%lx] to work list op %d\n", ++ prange, prange->start, prange->last, op); ++ } + } + spin_unlock(&svms->deferred_list_lock); + } +@@ -2416,8 +2417,7 @@ void schedule_deferred_list_work(struct + } + + static void +-svm_range_unmap_split(struct mm_struct *mm, struct svm_range *parent, +- struct svm_range *prange, unsigned long start, ++svm_range_unmap_split(struct svm_range *parent, struct svm_range *prange, unsigned long start, + unsigned long last) + { + struct svm_range *head; +@@ -2438,12 +2438,12 @@ svm_range_unmap_split(struct mm_struct * + svm_range_split(tail, last + 1, tail->last, &head); + + if (head != prange && tail != prange) { +- svm_range_add_child(parent, mm, head, SVM_OP_UNMAP_RANGE); +- svm_range_add_child(parent, mm, tail, SVM_OP_ADD_RANGE); ++ svm_range_add_child(parent, head, SVM_OP_UNMAP_RANGE); ++ svm_range_add_child(parent, tail, SVM_OP_ADD_RANGE); + } else if (tail != prange) { +- svm_range_add_child(parent, mm, tail, SVM_OP_UNMAP_RANGE); ++ svm_range_add_child(parent, tail, SVM_OP_UNMAP_RANGE); + } else if (head != prange) { +- svm_range_add_child(parent, mm, head, SVM_OP_UNMAP_RANGE); ++ svm_range_add_child(parent, head, SVM_OP_UNMAP_RANGE); + } else if (parent != prange) { + prange->work_item.op = SVM_OP_UNMAP_RANGE; + } +@@ -2520,14 +2520,14 @@ svm_range_unmap_from_cpu(struct mm_struc + l = min(last, pchild->last); + if (l >= s) + svm_range_unmap_from_gpus(pchild, s, l, trigger); +- svm_range_unmap_split(mm, prange, pchild, start, last); ++ svm_range_unmap_split(prange, pchild, start, last); + mutex_unlock(&pchild->lock); + } + s = max(start, prange->start); + l = min(last, prange->last); + if (l >= s) + svm_range_unmap_from_gpus(prange, s, l, trigger); +- svm_range_unmap_split(mm, prange, prange, start, last); ++ svm_range_unmap_split(prange, prange, start, last); + + if (unmap_parent) + svm_range_add_list_work(svms, prange, mm, SVM_OP_UNMAP_RANGE); +@@ -2570,8 +2570,6 @@ svm_range_cpu_invalidate_pagetables(stru + + if (range->event == MMU_NOTIFY_RELEASE) + return true; +- if (!mmget_not_zero(mni->mm)) +- return true; + + start = mni->interval_tree.start; + last = mni->interval_tree.last; +@@ -2598,7 +2596,6 @@ svm_range_cpu_invalidate_pagetables(stru + } + + svm_range_unlock(prange); +- mmput(mni->mm); + + return true; + } diff --git a/queue-6.15/drm-imagination-fix-kernel-crash-when-hard-resetting-the-gpu.patch b/queue-6.15/drm-imagination-fix-kernel-crash-when-hard-resetting-the-gpu.patch new file mode 100644 index 0000000000..2b403eeefd --- /dev/null +++ b/queue-6.15/drm-imagination-fix-kernel-crash-when-hard-resetting-the-gpu.patch @@ -0,0 +1,55 @@ +From d38376b3ee48d073c64e75e150510d7e6b4b04f7 Mon Sep 17 00:00:00 2001 +From: Alessio Belle +Date: Tue, 24 Jun 2025 15:22:08 +0100 +Subject: drm/imagination: Fix kernel crash when hard resetting the GPU + +From: Alessio Belle + +commit d38376b3ee48d073c64e75e150510d7e6b4b04f7 upstream. + +The GPU hard reset sequence calls pm_runtime_force_suspend() and +pm_runtime_force_resume(), which according to their documentation should +only be used during system-wide PM transitions to sleep states. + +The main issue though is that depending on some internal runtime PM +state as seen by pm_runtime_force_suspend() (whether the usage count is +<= 1), pm_runtime_force_resume() might not resume the device unless +needed. If that happens, the runtime PM resume callback +pvr_power_device_resume() is not called, the GPU clocks are not +re-enabled, and the kernel crashes on the next attempt to access GPU +registers as part of the power-on sequence. + +Replace calls to pm_runtime_force_suspend() and +pm_runtime_force_resume() with direct calls to the driver's runtime PM +callbacks, pvr_power_device_suspend() and pvr_power_device_resume(), +to ensure clocks are re-enabled and avoid the kernel crash. + +Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") +Signed-off-by: Alessio Belle +Reviewed-by: Matt Coster +Link: https://lore.kernel.org/r/20250624-fix-kernel-crash-gpu-hard-reset-v1-1-6d24810d72a6@imgtec.com +Cc: stable@vger.kernel.org +Signed-off-by: Matt Coster +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/imagination/pvr_power.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/imagination/pvr_power.c ++++ b/drivers/gpu/drm/imagination/pvr_power.c +@@ -363,13 +363,13 @@ pvr_power_reset(struct pvr_device *pvr_d + if (!err) { + if (hard_reset) { + pvr_dev->fw_dev.booted = false; +- WARN_ON(pm_runtime_force_suspend(from_pvr_device(pvr_dev)->dev)); ++ WARN_ON(pvr_power_device_suspend(from_pvr_device(pvr_dev)->dev)); + + err = pvr_fw_hard_reset(pvr_dev); + if (err) + goto err_device_lost; + +- err = pm_runtime_force_resume(from_pvr_device(pvr_dev)->dev); ++ err = pvr_power_device_resume(from_pvr_device(pvr_dev)->dev); + pvr_dev->fw_dev.booted = true; + if (err) + goto err_device_lost; diff --git a/queue-6.15/gpiolib-fix-performance-regression-when-using-gpio_chip_get_multiple.patch b/queue-6.15/gpiolib-fix-performance-regression-when-using-gpio_chip_get_multiple.patch new file mode 100644 index 0000000000..2126d62bc5 --- /dev/null +++ b/queue-6.15/gpiolib-fix-performance-regression-when-using-gpio_chip_get_multiple.patch @@ -0,0 +1,54 @@ +From 30e0fd3c0273dc106320081793793a424f1f1950 Mon Sep 17 00:00:00 2001 +From: Hugo Villeneuve +Date: Thu, 3 Jul 2025 15:18:29 -0400 +Subject: gpiolib: fix performance regression when using gpio_chip_get_multiple() + +From: Hugo Villeneuve + +commit 30e0fd3c0273dc106320081793793a424f1f1950 upstream. + +commit 74abd086d2ee ("gpiolib: sanitize the return value of +gpio_chip::get_multiple()") altered the value returned by +gc->get_multiple() in case it is positive (> 0), but failed to return +for other cases (<= 0). + +This may result in the "if (gc->get)" block being executed and thus +negates the performance gain that is normally obtained by using +gc->get_multiple(). + +Fix by returning the result of gc->get_multiple() if it is <= 0. + +Also move the "ret" variable to the scope where it is used, which as an +added bonus fixes an indentation error introduced by the aforementioned +commit. + +Fixes: 74abd086d2ee ("gpiolib: sanitize the return value of gpio_chip::get_multiple()") +Cc: stable@vger.kernel.org +Signed-off-by: Hugo Villeneuve +Link: https://lore.kernel.org/r/20250703191829.2952986-1-hugo@hugovil.com +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpiolib.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -3277,14 +3277,15 @@ static int gpiod_get_raw_value_commit(co + static int gpio_chip_get_multiple(struct gpio_chip *gc, + unsigned long *mask, unsigned long *bits) + { +- int ret; +- + lockdep_assert_held(&gc->gpiodev->srcu); + + if (gc->get_multiple) { ++ int ret; ++ + ret = gc->get_multiple(gc, mask, bits); + if (ret > 0) + return -EBADE; ++ return ret; + } + + if (gc->get) { diff --git a/queue-6.15/gre-fix-ipv6-multicast-route-creation.patch b/queue-6.15/gre-fix-ipv6-multicast-route-creation.patch new file mode 100644 index 0000000000..9f01814ee9 --- /dev/null +++ b/queue-6.15/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 +@@ -3525,11 +3525,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 +@@ -3543,9 +3541,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.15/io_uring-msg_ring-ensure-io_kiocb-freeing-is-deferred-for-rcu.patch b/queue-6.15/io_uring-msg_ring-ensure-io_kiocb-freeing-is-deferred-for-rcu.patch new file mode 100644 index 0000000000..6b196fc333 --- /dev/null +++ b/queue-6.15/io_uring-msg_ring-ensure-io_kiocb-freeing-is-deferred-for-rcu.patch @@ -0,0 +1,90 @@ +From fc582cd26e888b0652bc1494f252329453fd3b23 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Tue, 8 Jul 2025 11:00:32 -0600 +Subject: io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU + +From: Jens Axboe + +commit fc582cd26e888b0652bc1494f252329453fd3b23 upstream. + +syzbot reports that defer/local task_work adding via msg_ring can hit +a request that has been freed: + +CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full) +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 +Call Trace: + + dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 + print_address_description mm/kasan/report.c:408 [inline] + print_report+0xd2/0x2b0 mm/kasan/report.c:521 + kasan_report+0x118/0x150 mm/kasan/report.c:634 + io_req_local_work_add io_uring/io_uring.c:1184 [inline] + __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252 + io_msg_remote_post io_uring/msg_ring.c:103 [inline] + io_msg_data_remote io_uring/msg_ring.c:133 [inline] + __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151 + io_msg_ring_data io_uring/msg_ring.c:173 [inline] + io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314 + __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739 + io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762 + io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874 + io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642 + io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696 + ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 + ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 + + +which is supposed to be safe with how requests are allocated. But msg +ring requests alloc and free on their own, and hence must defer freeing +to a sane time. + +Add an rcu_head and use kfree_rcu() in both spots where requests are +freed. Only the one in io_msg_tw_complete() is strictly required as it +has been visible on the other ring, but use it consistently in the other +spot as well. + +This should not cause any other issues outside of KASAN rightfully +complaining about it. + +Link: https://lore.kernel.org/io-uring/686cd2ea.a00a0220.338033.0007.GAE@google.com/ +Reported-by: syzbot+54cbbfb4db9145d26fc2@syzkaller.appspotmail.com +Cc: stable@vger.kernel.org +Fixes: 0617bb500bfa ("io_uring/msg_ring: improve handling of target CQE posting") +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/io_uring_types.h | 2 ++ + io_uring/msg_ring.c | 4 ++-- + 2 files changed, 4 insertions(+), 2 deletions(-) + +--- a/include/linux/io_uring_types.h ++++ b/include/linux/io_uring_types.h +@@ -701,6 +701,8 @@ struct io_kiocb { + struct hlist_node hash_node; + /* For IOPOLL setup queues, with hybrid polling */ + u64 iopoll_start; ++ /* for private io_kiocb freeing */ ++ struct rcu_head rcu_head; + }; + /* internal polling, see IORING_FEAT_FAST_POLL */ + struct async_poll *apoll; +--- a/io_uring/msg_ring.c ++++ b/io_uring/msg_ring.c +@@ -82,7 +82,7 @@ static void io_msg_tw_complete(struct io + spin_unlock(&ctx->msg_lock); + } + if (req) +- kmem_cache_free(req_cachep, req); ++ kfree_rcu(req, rcu_head); + percpu_ref_put(&ctx->refs); + } + +@@ -90,7 +90,7 @@ static int io_msg_remote_post(struct io_ + int res, u32 cflags, u64 user_data) + { + if (!READ_ONCE(ctx->submitter_task)) { +- kmem_cache_free(req_cachep, req); ++ kfree_rcu(req, rcu_head); + return -EOWNERDEAD; + } + req->opcode = IORING_OP_NOP; diff --git a/queue-6.15/kvm-allow-cpu-to-reschedule-while-setting-per-page-memory-attributes.patch b/queue-6.15/kvm-allow-cpu-to-reschedule-while-setting-per-page-memory-attributes.patch new file mode 100644 index 0000000000..2098109f5a --- /dev/null +++ b/queue-6.15/kvm-allow-cpu-to-reschedule-while-setting-per-page-memory-attributes.patch @@ -0,0 +1,84 @@ +From 47bb584237cc285e3a860b70c01f7bda9dcfb05b Mon Sep 17 00:00:00 2001 +From: Liam Merwick +Date: Mon, 9 Jun 2025 09:11:19 +0000 +Subject: KVM: Allow CPU to reschedule while setting per-page memory attributes + +From: Liam Merwick + +commit 47bb584237cc285e3a860b70c01f7bda9dcfb05b upstream. + +When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+), +the host can experience CPU soft lockups when running an operation in +kvm_vm_set_mem_attributes() to set memory attributes on the whole +range of guest memory. + +watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372] +CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary) +Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024 +RIP: 0010:xas_create+0x78/0x1f0 +Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87 +RSP: 0018:ffffad890a34b940 EFLAGS: 00000286 +RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000 +RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000 +RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868 +R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868 +FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0 +PKRU: 55555554 +Call Trace: + + xas_store+0x58/0x630 + __xa_store+0xa5/0x130 + xa_store+0x2c/0x50 + kvm_vm_set_mem_attributes+0x343/0x710 [kvm] + kvm_vm_ioctl+0x796/0xab0 [kvm] + __x64_sys_ioctl+0xa3/0xd0 + do_syscall_64+0x8c/0x7a0 + entry_SYSCALL_64_after_hwframe+0x76/0x7e +RIP: 0033:0x7f5578d031bb +Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48 +RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 +RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb +RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b +RBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000 +R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120 +R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0 + +While looping through the range of memory setting the attributes, +call cond_resched() to give the scheduler a chance to run a higher +priority task on the runqueue if necessary and avoid staying in +kernel mode long enough to trigger the lockup. + +Fixes: 5a475554db1e ("KVM: Introduce per-page memory attributes") +Cc: stable@vger.kernel.org # 6.12.x +Suggested-by: Sean Christopherson +Signed-off-by: Liam Merwick +Reviewed-by: Pankaj Gupta +Link: https://lore.kernel.org/r/20250609091121.2497429-2-liam.merwick@oracle.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + virt/kvm/kvm_main.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -2515,6 +2515,8 @@ static int kvm_vm_set_mem_attributes(str + r = xa_reserve(&kvm->mem_attr_array, i, GFP_KERNEL_ACCOUNT); + if (r) + goto out_unlock; ++ ++ cond_resched(); + } + + kvm_handle_gfn_range(kvm, &pre_set_range); +@@ -2523,6 +2525,7 @@ static int kvm_vm_set_mem_attributes(str + r = xa_err(xa_store(&kvm->mem_attr_array, i, entry, + GFP_KERNEL_ACCOUNT)); + KVM_BUG_ON(r, kvm); ++ cond_resched(); + } + + kvm_handle_gfn_range(kvm, &post_set_range); diff --git a/queue-6.15/kvm-svm-add-missing-member-in-snp_launch_start-command-structure.patch b/queue-6.15/kvm-svm-add-missing-member-in-snp_launch_start-command-structure.patch new file mode 100644 index 0000000000..e70f5f5b81 --- /dev/null +++ b/queue-6.15/kvm-svm-add-missing-member-in-snp_launch_start-command-structure.patch @@ -0,0 +1,46 @@ +From 51a4273dcab39dd1e850870945ccec664352d383 Mon Sep 17 00:00:00 2001 +From: Nikunj A Dadhania +Date: Tue, 8 Apr 2025 15:02:11 +0530 +Subject: KVM: SVM: Add missing member in SNP_LAUNCH_START command structure + +From: Nikunj A Dadhania + +commit 51a4273dcab39dd1e850870945ccec664352d383 upstream. + +The sev_data_snp_launch_start structure should include a 4-byte +desired_tsc_khz field before the gosvw field, which was missed in the +initial implementation. As a result, the structure is 4 bytes shorter than +expected by the firmware, causing the gosvw field to start 4 bytes early. +Fix this by adding the missing 4-byte member for the desired TSC frequency. + +Fixes: 3a45dc2b419e ("crypto: ccp: Define the SEV-SNP commands") +Cc: stable@vger.kernel.org +Suggested-by: Tom Lendacky +Reviewed-by: Tom Lendacky +Tested-by: Vaishali Thakkar +Signed-off-by: Nikunj A Dadhania +Link: https://lore.kernel.org/r/20250408093213.57962-3-nikunj@amd.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/psp-sev.h | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/include/linux/psp-sev.h ++++ b/include/linux/psp-sev.h +@@ -594,6 +594,7 @@ struct sev_data_snp_addr { + * @imi_en: launch flow is launching an IMI (Incoming Migration Image) for the + * purpose of guest-assisted migration. + * @rsvd: reserved ++ * @desired_tsc_khz: hypervisor desired mean TSC freq in kHz of the guest + * @gosvw: guest OS-visible workarounds, as defined by hypervisor + */ + struct sev_data_snp_launch_start { +@@ -603,6 +604,7 @@ struct sev_data_snp_launch_start { + u32 ma_en:1; /* In */ + u32 imi_en:1; /* In */ + u32 rsvd:30; ++ u32 desired_tsc_khz; /* In */ + u8 gosvw[16]; /* In */ + } __packed; + diff --git a/queue-6.15/kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch b/queue-6.15/kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch new file mode 100644 index 0000000000..c0bab5de68 --- /dev/null +++ b/queue-6.15/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 +@@ -2032,6 +2032,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.15/kvm-x86-hyper-v-skip-non-canonical-addresses-during-pv-tlb-flush.patch b/queue-6.15/kvm-x86-hyper-v-skip-non-canonical-addresses-during-pv-tlb-flush.patch new file mode 100644 index 0000000000..4fc149d58f --- /dev/null +++ b/queue-6.15/kvm-x86-hyper-v-skip-non-canonical-addresses-during-pv-tlb-flush.patch @@ -0,0 +1,68 @@ +From fa787ac07b3ceb56dd88a62d1866038498e96230 Mon Sep 17 00:00:00 2001 +From: Manuel Andreas +Date: Wed, 25 Jun 2025 15:53:19 +0200 +Subject: KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush + +From: Manuel Andreas + +commit fa787ac07b3ceb56dd88a62d1866038498e96230 upstream. + +In KVM guests with Hyper-V hypercalls enabled, the hypercalls +HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX +allow a guest to request invalidation of portions of a virtual TLB. +For this, the hypercall parameter includes a list of GVAs that are supposed +to be invalidated. + +However, when non-canonical GVAs are passed, there is currently no +filtering in place and they are eventually passed to checked invocations of +INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores +non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly +signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error(): + + invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 + WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 + invvpid_error+0x91/0xa0 [kvm_intel] + Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse + CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) + RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] + Call Trace: + vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] + kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] + kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm] + +Hyper-V documents that invalid GVAs (those that are beyond a partition's +GVA space) are to be ignored. While not completely clear whether this +ruling also applies to non-canonical GVAs, it is likely fine to make that +assumption, and manual testing on Azure confirms "real" Hyper-V interprets +the specification in the same way. + +Skip non-canonical GVAs when processing the list of address to avoid +tripping the INVVPID failure. Alternatively, KVM could filter out "bad" +GVAs before inserting into the FIFO, but practically speaking the only +downside of pushing validation to the final processing is that doing so +is suboptimal for the guest, and no well-behaved guest will request TLB +flushes for non-canonical addresses. + +Fixes: 260970862c88 ("KVM: x86: hyper-v: Handle HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} calls gently") +Cc: stable@vger.kernel.org +Signed-off-by: Manuel Andreas +Suggested-by: Vitaly Kuznetsov +Link: https://lore.kernel.org/r/c090efb3-ef82-499f-a5e0-360fc8420fb7@tum.de +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/hyperv.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/kvm/hyperv.c ++++ b/arch/x86/kvm/hyperv.c +@@ -1979,6 +1979,9 @@ int kvm_hv_vcpu_flush_tlb(struct kvm_vcp + if (entries[i] == KVM_HV_TLB_FLUSHALL_ENTRY) + goto out_flush_all; + ++ if (is_noncanonical_invlpg_address(entries[i], vcpu)) ++ continue; ++ + /* + * Lower 12 bits of 'address' encode the number of additional + * pages to flush. diff --git a/queue-6.15/kvm-x86-xen-allow-out-of-range-event-channel-ports-in-irq-routing-table.patch b/queue-6.15/kvm-x86-xen-allow-out-of-range-event-channel-ports-in-irq-routing-table.patch new file mode 100644 index 0000000000..826e40d7ac --- /dev/null +++ b/queue-6.15/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 +@@ -1970,8 +1970,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.15/md-md-bitmap-fix-gpf-in-bitmap_get_stats.patch b/queue-6.15/md-md-bitmap-fix-gpf-in-bitmap_get_stats.patch new file mode 100644 index 0000000000..d1677da7c0 --- /dev/null +++ b/queue-6.15/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 +@@ -2357,8 +2357,7 @@ static int bitmap_get_stats(void *data, + + 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.15/net-ethernet-rtsn-fix-a-null-pointer-dereference-in-rtsn_probe.patch b/queue-6.15/net-ethernet-rtsn-fix-a-null-pointer-dereference-in-rtsn_probe.patch new file mode 100644 index 0000000000..7c7ae30624 --- /dev/null +++ b/queue-6.15/net-ethernet-rtsn-fix-a-null-pointer-dereference-in-rtsn_probe.patch @@ -0,0 +1,41 @@ +From 95a234f6affbf51f06338383537ab80d637bb785 Mon Sep 17 00:00:00 2001 +From: Haoxiang Li +Date: Thu, 3 Jul 2025 18:01:09 +0800 +Subject: net: ethernet: rtsn: Fix a null pointer dereference in rtsn_probe() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Haoxiang Li + +commit 95a234f6affbf51f06338383537ab80d637bb785 upstream. + +Add check for the return value of rcar_gen4_ptp_alloc() +to prevent potential null pointer dereference. + +Fixes: b0d3969d2b4d ("net: ethernet: rtsn: Add support for Renesas Ethernet-TSN") +Cc: stable@vger.kernel.org +Signed-off-by: Haoxiang Li +Reviewed-by: Niklas Söderlund +Link: https://patch.msgid.link/20250703100109.2541018-1-haoxiang_li2024@163.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/renesas/rtsn.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/net/ethernet/renesas/rtsn.c ++++ b/drivers/net/ethernet/renesas/rtsn.c +@@ -1259,7 +1259,12 @@ static int rtsn_probe(struct platform_de + priv = netdev_priv(ndev); + priv->pdev = pdev; + priv->ndev = ndev; ++ + priv->ptp_priv = rcar_gen4_ptp_alloc(pdev); ++ if (!priv->ptp_priv) { ++ ret = -ENOMEM; ++ goto error_free; ++ } + + spin_lock_init(&priv->lock); + platform_set_drvdata(pdev, priv); diff --git a/queue-6.15/pinctrl-nuvoton-fix-boot-on-ma35dx-platforms.patch b/queue-6.15/pinctrl-nuvoton-fix-boot-on-ma35dx-platforms.patch new file mode 100644 index 0000000000..800aab6d0e --- /dev/null +++ b/queue-6.15/pinctrl-nuvoton-fix-boot-on-ma35dx-platforms.patch @@ -0,0 +1,78 @@ +From 46147490b4098e200b7d7d3ac4637a3e4f7b806a Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +Date: Fri, 13 Jun 2025 20:13:12 +0200 +Subject: pinctrl: nuvoton: Fix boot on ma35dx platforms + +From: Miquel Raynal + +commit 46147490b4098e200b7d7d3ac4637a3e4f7b806a upstream. + +As part of a wider cleanup trying to get rid of OF specific APIs, an +incorrect (and partially unrelated) cleanup was introduced. + +The goal was to replace a device_for_each_chil_node() loop including an +additional condition inside by a macro doing both the loop and the +check on a single line. + +The snippet: + + device_for_each_child_node(dev, child) + if (fwnode_property_present(child, "gpio-controller")) + continue; + +was replaced by: + + for_each_gpiochip_node(dev, child) + +which expands into: + + device_for_each_child_node(dev, child) + for_each_if(fwnode_property_present(child, "gpio-controller")) + +This change is actually doing the opposite of what was initially +expected, breaking the probe of this driver, breaking at the same time +the whole boot of Nuvoton platforms (no more console, the kernel WARN()). + +Revert these two changes to roll back to the correct behavior. + +Fixes: 693c9ecd8326 ("pinctrl: nuvoton: Reduce use of OF-specific APIs") +Cc: stable@vger.kernel.org +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/20250613181312.1269794-1-miquel.raynal@bootlin.com +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pinctrl/nuvoton/pinctrl-ma35.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +diff --git a/drivers/pinctrl/nuvoton/pinctrl-ma35.c b/drivers/pinctrl/nuvoton/pinctrl-ma35.c +index 06ae1fe8b8c5..b51704bafd81 100644 +--- a/drivers/pinctrl/nuvoton/pinctrl-ma35.c ++++ b/drivers/pinctrl/nuvoton/pinctrl-ma35.c +@@ -1074,7 +1074,10 @@ static int ma35_pinctrl_probe_dt(struct platform_device *pdev, struct ma35_pinct + u32 idx = 0; + int ret; + +- for_each_gpiochip_node(dev, child) { ++ device_for_each_child_node(dev, child) { ++ if (fwnode_property_present(child, "gpio-controller")) ++ continue; ++ + npctl->nfunctions++; + npctl->ngroups += of_get_child_count(to_of_node(child)); + } +@@ -1092,7 +1095,10 @@ static int ma35_pinctrl_probe_dt(struct platform_device *pdev, struct ma35_pinct + if (!npctl->groups) + return -ENOMEM; + +- for_each_gpiochip_node(dev, child) { ++ device_for_each_child_node(dev, child) { ++ if (fwnode_property_present(child, "gpio-controller")) ++ continue; ++ + ret = ma35_pinctrl_parse_functions(child, npctl, idx++); + if (ret) { + fwnode_handle_put(child); +-- +2.50.1 + diff --git a/queue-6.15/pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch b/queue-6.15/pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch new file mode 100644 index 0000000000..c23e987d07 --- /dev/null +++ b/queue-6.15/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 +@@ -1036,6 +1036,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); +@@ -1439,6 +1458,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.15/pwm-fix-invalid-state-detection.patch b/queue-6.15/pwm-fix-invalid-state-detection.patch new file mode 100644 index 0000000000..59b2c397fe --- /dev/null +++ b/queue-6.15/pwm-fix-invalid-state-detection.patch @@ -0,0 +1,43 @@ +From 9ee124caae1b0defd0e02c65686f539845a3ac9b Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= +Date: Fri, 4 Jul 2025 19:24:17 +0200 +Subject: pwm: Fix invalid state detection +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Uwe Kleine-König + +commit 9ee124caae1b0defd0e02c65686f539845a3ac9b upstream. + +Commit 9dd42d019e63 ("pwm: Allow pwm state transitions from an invalid +state") intended to allow some state transitions that were not allowed +before. The idea is sane and back then I also got the code comment +right, but the check for enabled is bogus. This resulted in state +transitions for enabled states to be allowed to have invalid duty/period +settings and thus it can happen that low-level drivers get requests for +invalid states🙄. + +Invert the check to allow state transitions for disabled states only. + +Fixes: 9dd42d019e63 ("pwm: Allow pwm state transitions from an invalid state") +Signed-off-by: Uwe Kleine-König +Link: https://lore.kernel.org/r/20250704172416.626433-2-u.kleine-koenig@baylibre.com +Cc: stable@vger.kernel.org +Signed-off-by: Uwe Kleine-König +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pwm/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/pwm/core.c ++++ b/drivers/pwm/core.c +@@ -549,7 +549,7 @@ static bool pwm_state_valid(const struct + * and supposed to be ignored. So also ignore any strange values and + * consider the state ok. + */ +- if (state->enabled) ++ if (!state->enabled) + return true; + + if (!state->period) diff --git a/queue-6.15/pwm-mediatek-ensure-to-disable-clocks-in-error-path.patch b/queue-6.15/pwm-mediatek-ensure-to-disable-clocks-in-error-path.patch new file mode 100644 index 0000000000..dfdaa7077a --- /dev/null +++ b/queue-6.15/pwm-mediatek-ensure-to-disable-clocks-in-error-path.patch @@ -0,0 +1,65 @@ +From 505b730ede7f5c4083ff212aa955155b5b92e574 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= +Date: Fri, 4 Jul 2025 19:27:27 +0200 +Subject: pwm: mediatek: Ensure to disable clocks in error path +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Uwe Kleine-König + +commit 505b730ede7f5c4083ff212aa955155b5b92e574 upstream. + +After enabling the clocks each error path must disable the clocks again. +One of them failed to do so. Unify the error paths to use goto to make it +harder for future changes to add a similar bug. + +Fixes: 7ca59947b5fc ("pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()") +Signed-off-by: Uwe Kleine-König +Link: https://lore.kernel.org/r/20250704172728.626815-2-u.kleine-koenig@baylibre.com +Cc: stable@vger.kernel.org +Signed-off-by: Uwe Kleine-König +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pwm/pwm-mediatek.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +--- a/drivers/pwm/pwm-mediatek.c ++++ b/drivers/pwm/pwm-mediatek.c +@@ -130,8 +130,10 @@ static int pwm_mediatek_config(struct pw + return ret; + + clk_rate = clk_get_rate(pc->clk_pwms[pwm->hwpwm]); +- if (!clk_rate) +- return -EINVAL; ++ if (!clk_rate) { ++ ret = -EINVAL; ++ goto out; ++ } + + /* Make sure we use the bus clock and not the 26MHz clock */ + if (pc->soc->has_ck_26m_sel) +@@ -150,9 +152,9 @@ static int pwm_mediatek_config(struct pw + } + + if (clkdiv > PWM_CLK_DIV_MAX) { +- pwm_mediatek_clk_disable(chip, pwm); + dev_err(pwmchip_parent(chip), "period of %d ns not supported\n", period_ns); +- return -EINVAL; ++ ret = -EINVAL; ++ goto out; + } + + if (pc->soc->pwm45_fixup && pwm->hwpwm > 2) { +@@ -169,9 +171,10 @@ static int pwm_mediatek_config(struct pw + pwm_mediatek_writel(pc, pwm->hwpwm, reg_width, cnt_period); + pwm_mediatek_writel(pc, pwm->hwpwm, reg_thres, cnt_duty); + ++out: + pwm_mediatek_clk_disable(chip, pwm); + +- return 0; ++ return ret; + } + + static int pwm_mediatek_enable(struct pwm_chip *chip, struct pwm_device *pwm) diff --git a/queue-6.15/sched-fix-preemption-string-of-preempt_dynamic_none.patch b/queue-6.15/sched-fix-preemption-string-of-preempt_dynamic_none.patch new file mode 100644 index 0000000000..3fa9efdba3 --- /dev/null +++ b/queue-6.15/sched-fix-preemption-string-of-preempt_dynamic_none.patch @@ -0,0 +1,41 @@ +From 3ebb1b6522392f64902b4e96954e35927354aa27 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= +Date: Thu, 26 Jun 2025 11:23:44 +0200 +Subject: sched: Fix preemption string of preempt_dynamic_none +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Weißschuh + +commit 3ebb1b6522392f64902b4e96954e35927354aa27 upstream. + +Zero is a valid value for "preempt_dynamic_mode", namely +"preempt_dynamic_none". + +Fix the off-by-one in preempt_model_str(), so that "preempty_dynamic_none" +is correctly formatted as PREEMPT(none) instead of PREEMPT(undef). + +Fixes: 8bdc5daaa01e ("sched: Add a generic function to return the preemption string") +Signed-off-by: Thomas Weißschuh +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Sebastian Andrzej Siewior +Tested-by: Shrikanth Hegde +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20250626-preempt-str-none-v2-1-526213b70a89@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + kernel/sched/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/sched/core.c ++++ b/kernel/sched/core.c +@@ -7695,7 +7695,7 @@ const char *preempt_model_str(void) + + if (IS_ENABLED(CONFIG_PREEMPT_DYNAMIC)) { + seq_buf_printf(&s, "(%s)%s", +- preempt_dynamic_mode > 0 ? ++ preempt_dynamic_mode >= 0 ? + preempt_modes[preempt_dynamic_mode] : "undef", + brace ? "}" : ""); + return seq_buf_str(&s); diff --git a/queue-6.15/series b/queue-6.15/series index 10bc769459..121c537cc6 100644 --- a/queue-6.15/series +++ b/queue-6.15/series @@ -48,3 +48,37 @@ rxrpc-fix-bug-due-to-prealloc-collision.patch crypto-s390-sha-fix-uninitialized-variable-in-sha-1-and-sha-2.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-ensure-user-polling-settings-are-honored-when-restarting-timer.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-x86-hyper-v-skip-non-canonical-addresses-during-pv-tlb-flush.patch +kvm-svm-add-missing-member-in-snp_launch_start-command-structure.patch +kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch +kvm-allow-cpu-to-reschedule-while-setting-per-page-memory-attributes.patch +sched-fix-preemption-string-of-preempt_dynamic_none.patch +alsa-ad1816a-fix-potential-null-pointer-deref-in-snd_card_ad1816a_pnp.patch +alsa-hda-realtek-add-mute-led-support-for-hp-victus-15-fb2xxx.patch +arm64-filter-out-sme-hwcaps-when-feat_sme-isn-t-implemented.patch +asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch +io_uring-msg_ring-ensure-io_kiocb-freeing-is-deferred-for-rcu.patch +gre-fix-ipv6-multicast-route-creation.patch +net-ethernet-rtsn-fix-a-null-pointer-dereference-in-rtsn_probe.patch +gpiolib-fix-performance-regression-when-using-gpio_chip_get_multiple.patch +md-md-bitmap-fix-gpf-in-bitmap_get_stats.patch +pinctrl-nuvoton-fix-boot-on-ma35dx-platforms.patch +pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch +pwm-fix-invalid-state-detection.patch +pwm-mediatek-ensure-to-disable-clocks-in-error-path.patch +wifi-prevent-a-msdu-attacks-in-mesh-networks.patch +wifi-mwifiex-discard-erroneous-disassoc-frames-on-sta-interface.patch +wifi-mt76-mt7921-prevent-decap-offload-config-before-sta-initialization.patch +wifi-mt76-mt7925-prevent-null-pointer-dereference-in-mt7925_sta_set_decap_offload.patch +wifi-mt76-mt7925-fix-the-wrong-config-for-tx-interrupt.patch +wifi-mt76-mt7925-fix-invalid-array-index-in-ssid-assignment-during-hw-scan.patch +drm-imagination-fix-kernel-crash-when-hard-resetting-the-gpu.patch +drm-amdkfd-don-t-call-mmput-from-mmu-notifier-callback.patch +drm-amdgpu-include-sdma_4_4_4.bin.patch +drm-amdkfd-add-hqd_sdma_get_doorbell-callbacks-for-gfx7-8.patch diff --git a/queue-6.15/wifi-mt76-mt7921-prevent-decap-offload-config-before-sta-initialization.patch b/queue-6.15/wifi-mt76-mt7921-prevent-decap-offload-config-before-sta-initialization.patch new file mode 100644 index 0000000000..7aed6b68cb --- /dev/null +++ b/queue-6.15/wifi-mt76-mt7921-prevent-decap-offload-config-before-sta-initialization.patch @@ -0,0 +1,39 @@ +From 7035a082348acf1d43ffb9ff735899f8e3863f8f Mon Sep 17 00:00:00 2001 +From: Deren Wu +Date: Sun, 25 May 2025 14:11:22 +0800 +Subject: wifi: mt76: mt7921: prevent decap offload config before STA initialization + +From: Deren Wu + +commit 7035a082348acf1d43ffb9ff735899f8e3863f8f upstream. + +The decap offload configuration should only be applied after the STA has +been successfully initialized. Attempting to configure it earlier can lead +to corruption of the MAC configuration in the chip's hardware state. + +Add an early check for `msta->deflink.wcid.sta` to ensure the station peer +is properly initialized before proceeding with decapsulation offload +configuration. + +Cc: stable@vger.kernel.org +Fixes: 24299fc869f7 ("mt76: mt7921: enable rx header traslation offload") +Signed-off-by: Deren Wu +Link: https://patch.msgid.link/f23a72ba7a3c1ad38ba9e13bb54ef21d6ef44ffb.1748149855.git.deren.wu@mediatek.com +Signed-off-by: Felix Fietkau +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/mediatek/mt76/mt7921/main.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/net/wireless/mediatek/mt76/mt7921/main.c ++++ b/drivers/net/wireless/mediatek/mt76/mt7921/main.c +@@ -1180,6 +1180,9 @@ static void mt7921_sta_set_decap_offload + struct mt792x_sta *msta = (struct mt792x_sta *)sta->drv_priv; + struct mt792x_dev *dev = mt792x_hw_dev(hw); + ++ if (!msta->deflink.wcid.sta) ++ return; ++ + mt792x_mutex_acquire(dev); + + if (enabled) diff --git a/queue-6.15/wifi-mt76-mt7925-fix-invalid-array-index-in-ssid-assignment-during-hw-scan.patch b/queue-6.15/wifi-mt76-mt7925-fix-invalid-array-index-in-ssid-assignment-during-hw-scan.patch new file mode 100644 index 0000000000..aea743f455 --- /dev/null +++ b/queue-6.15/wifi-mt76-mt7925-fix-invalid-array-index-in-ssid-assignment-during-hw-scan.patch @@ -0,0 +1,52 @@ +From c701574c54121af2720648572efbfe77564652d1 Mon Sep 17 00:00:00 2001 +From: Michael Lo +Date: Thu, 12 Jun 2025 14:20:46 +0800 +Subject: wifi: mt76: mt7925: fix invalid array index in ssid assignment during hw scan + +From: Michael Lo + +commit c701574c54121af2720648572efbfe77564652d1 upstream. + +Update the destination index to use 'n_ssids', which is incremented only +when a valid SSID is present. Previously, both mt76_connac_mcu_hw_scan() +and mt7925_mcu_hw_scan() used the loop index 'i' for the destination +array, potentially leaving gaps if any source SSIDs had zero length. + +Cc: stable@vger.kernel.org +Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") +Signed-off-by: Michael Lo +Signed-off-by: Ming Yen Hsieh +Link: https://patch.msgid.link/20250612062046.160598-1-mingyen.hsieh@mediatek.com +Signed-off-by: Felix Fietkau +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 4 ++-- + drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 4 ++-- + 2 files changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c ++++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c +@@ -1703,8 +1703,8 @@ int mt76_connac_mcu_hw_scan(struct mt76_ + if (!sreq->ssids[i].ssid_len) + continue; + +- req->ssids[i].ssid_len = cpu_to_le32(sreq->ssids[i].ssid_len); +- memcpy(req->ssids[i].ssid, sreq->ssids[i].ssid, ++ req->ssids[n_ssids].ssid_len = cpu_to_le32(sreq->ssids[i].ssid_len); ++ memcpy(req->ssids[n_ssids].ssid, sreq->ssids[i].ssid, + sreq->ssids[i].ssid_len); + n_ssids++; + } +--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c ++++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +@@ -2834,8 +2834,8 @@ int mt7925_mcu_hw_scan(struct mt76_phy * + if (!sreq->ssids[i].ssid_len) + continue; + +- ssid->ssids[i].ssid_len = cpu_to_le32(sreq->ssids[i].ssid_len); +- memcpy(ssid->ssids[i].ssid, sreq->ssids[i].ssid, ++ ssid->ssids[n_ssids].ssid_len = cpu_to_le32(sreq->ssids[i].ssid_len); ++ memcpy(ssid->ssids[n_ssids].ssid, sreq->ssids[i].ssid, + sreq->ssids[i].ssid_len); + n_ssids++; + } diff --git a/queue-6.15/wifi-mt76-mt7925-fix-the-wrong-config-for-tx-interrupt.patch b/queue-6.15/wifi-mt76-mt7925-fix-the-wrong-config-for-tx-interrupt.patch new file mode 100644 index 0000000000..f7baecfd95 --- /dev/null +++ b/queue-6.15/wifi-mt76-mt7925-fix-the-wrong-config-for-tx-interrupt.patch @@ -0,0 +1,35 @@ +From d20de55332e92f9e614c34783c00bb6ce2fec067 Mon Sep 17 00:00:00 2001 +From: Ming Yen Hsieh +Date: Thu, 12 Jun 2025 14:09:31 +0800 +Subject: wifi: mt76: mt7925: fix the wrong config for tx interrupt + +From: Ming Yen Hsieh + +commit d20de55332e92f9e614c34783c00bb6ce2fec067 upstream. + +MT_INT_TX_DONE_MCU_WM may cause tx interrupt to be mishandled +during a reset failure, leading to the reset process failing. +By using MT_INT_TX_DONE_MCU instead of MT_INT_TX_DONE_MCU_WM, +the handling of tx interrupt is improved. + +Cc: stable@vger.kernel.org +Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") +Signed-off-by: Ming Yen Hsieh +Link: https://patch.msgid.link/20250612060931.135635-1-mingyen.hsieh@mediatek.com +Signed-off-by: Felix Fietkau +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/mediatek/mt76/mt7925/regs.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/mediatek/mt76/mt7925/regs.h ++++ b/drivers/net/wireless/mediatek/mt76/mt7925/regs.h +@@ -58,7 +58,7 @@ + + #define MT_INT_TX_DONE_MCU (MT_INT_TX_DONE_MCU_WM | \ + MT_INT_TX_DONE_FWDL) +-#define MT_INT_TX_DONE_ALL (MT_INT_TX_DONE_MCU_WM | \ ++#define MT_INT_TX_DONE_ALL (MT_INT_TX_DONE_MCU | \ + MT_INT_TX_DONE_BAND0 | \ + GENMASK(18, 4)) + diff --git a/queue-6.15/wifi-mt76-mt7925-prevent-null-pointer-dereference-in-mt7925_sta_set_decap_offload.patch b/queue-6.15/wifi-mt76-mt7925-prevent-null-pointer-dereference-in-mt7925_sta_set_decap_offload.patch new file mode 100644 index 0000000000..2745e9a21d --- /dev/null +++ b/queue-6.15/wifi-mt76-mt7925-prevent-null-pointer-dereference-in-mt7925_sta_set_decap_offload.patch @@ -0,0 +1,92 @@ +From 35ad47c0b3da04b00b19a8b9ed5632e2f2520472 Mon Sep 17 00:00:00 2001 +From: Deren Wu +Date: Sun, 25 May 2025 14:11:21 +0800 +Subject: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload() + +From: Deren Wu + +commit 35ad47c0b3da04b00b19a8b9ed5632e2f2520472 upstream. + +Add a NULL check for msta->vif before accessing its members to prevent +a kernel panic in AP mode deployment. This also fix the issue reported +in [1]. + +The crash occurs when this function is triggered before the station is +fully initialized. The call trace shows a page fault at +mt7925_sta_set_decap_offload() due to accessing resources when msta->vif +is NULL. + +Fix this by adding an early return if msta->vif is NULL and also check +wcid.sta is ready. This ensures we only proceed with decap offload +configuration when the station's state is properly initialized. + +[14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0 +[14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G +[14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE +[14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) +[14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) +[14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] +[14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common] +[14739.851985] sp : ffffffc085efb500 +[14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158 +[14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001 +[14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88 +[14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000 +[14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080 +[14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000 +[14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0 +[14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100 +[14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000 +[14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8 +[14739.926686] Call trace: +[14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] +[14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211] +[14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211] +[14739.946860] sta_info_move_state+0x1c/0x30 [mac80211] +[14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211] +[14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211] +[14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211] +[14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211] +[14739.975516] genl_family_rcv_msg_doit+0xdc/0x150 +[14739.980158] genl_rcv_msg+0x218/0x298 +[14739.983830] netlink_rcv_skb+0x64/0x138 +[14739.987670] genl_rcv+0x40/0x60 +[14739.990816] netlink_unicast+0x314/0x380 +[14739.994742] netlink_sendmsg+0x198/0x3f0 +[14739.998664] __sock_sendmsg+0x64/0xc0 +[14740.002324] ____sys_sendmsg+0x260/0x298 +[14740.006242] ___sys_sendmsg+0xb4/0x110 + +Cc: stable@vger.kernel.org +Link: https://github.com/morrownr/USB-WiFi/issues/603 [1] +Fixes: b859ad65309a ("wifi: mt76: mt7925: add link handling in mt7925_sta_set_decap_offload") +Signed-off-by: Deren Wu +Link: https://patch.msgid.link/35aedbffa050e98939264300407a52ba4e236d52.1748149855.git.deren.wu@mediatek.com +Signed-off-by: Felix Fietkau +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/mediatek/mt76/mt7925/main.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c ++++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c +@@ -1600,6 +1600,9 @@ static void mt7925_sta_set_decap_offload + unsigned long valid = mvif->valid_links; + u8 i; + ++ if (!msta->vif) ++ return; ++ + mt792x_mutex_acquire(dev); + + valid = ieee80211_vif_is_mld(vif) ? mvif->valid_links : BIT(0); +@@ -1614,6 +1617,9 @@ static void mt7925_sta_set_decap_offload + else + clear_bit(MT_WCID_FLAG_HDR_TRANS, &mlink->wcid.flags); + ++ if (!mlink->wcid.sta) ++ continue; ++ + mt7925_mcu_wtbl_update_hdr_trans(dev, vif, sta, i); + } + diff --git a/queue-6.15/wifi-mwifiex-discard-erroneous-disassoc-frames-on-sta-interface.patch b/queue-6.15/wifi-mwifiex-discard-erroneous-disassoc-frames-on-sta-interface.patch new file mode 100644 index 0000000000..990ed2b7f2 --- /dev/null +++ b/queue-6.15/wifi-mwifiex-discard-erroneous-disassoc-frames-on-sta-interface.patch @@ -0,0 +1,85 @@ +From 3b602ddc0df723992721b0d286c90c9bdd755b34 Mon Sep 17 00:00:00 2001 +From: Vitor Soares +Date: Tue, 1 Jul 2025 15:26:43 +0100 +Subject: wifi: mwifiex: discard erroneous disassoc frames on STA interface + +From: Vitor Soares + +commit 3b602ddc0df723992721b0d286c90c9bdd755b34 upstream. + +When operating in concurrent STA/AP mode with host MLME enabled, +the firmware incorrectly sends disassociation frames to the STA +interface when clients disconnect from the AP interface. +This causes kernel warnings as the STA interface processes +disconnect events that don't apply to it: + +[ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211] +[ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us +[ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT +[ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT) +[ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] +[ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) +[ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211] +[ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211] +[ 1303.370221] sp : ffff800083053be0 +[ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000 +[ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae +[ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008 +[ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006 +[ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048 +[ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000 +[ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300 +[ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002 +[ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186 +[ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de +[ 1303.446221] Call trace: +[ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P) +[ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211] +[ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex] +[ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex] +[ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex] +[ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex] +[ 1303.483734] process_one_work+0x14c/0x28c +[ 1303.487845] worker_thread+0x2cc/0x3d4 +[ 1303.491680] kthread+0x12c/0x208 +[ 1303.495014] ret_from_fork+0x10/0x20 + +Add validation in the STA receive path to verify that disassoc/deauth +frames originate from the connected AP. Frames that fail this check +are discarded early, preventing them from reaching the MLME layer and +triggering WARN_ON(). + +This filtering logic is similar with that used in the +ieee80211_rx_mgmt_disassoc() function in mac80211, which drops +disassoc frames that don't match the current BSSID +(!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), ensuring +only relevant frames are processed. + +Tested on: +- 8997 with FW 16.68.1.p197 + +Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode") +Cc: stable@vger.kernel.org +Signed-off-by: Vitor Soares +Reviewed-by: Jeff Chen +Reviewed-by: Francesco Dolcini +Link: https://patch.msgid.link/20250701142643.658990-1-ivitro@gmail.com +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/marvell/mwifiex/util.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/net/wireless/marvell/mwifiex/util.c ++++ b/drivers/net/wireless/marvell/mwifiex/util.c +@@ -477,7 +477,9 @@ mwifiex_process_mgmt_packet(struct mwifi + "auth: receive authentication from %pM\n", + ieee_hdr->addr3); + } else { +- if (!priv->wdev.connected) ++ if (!priv->wdev.connected || ++ !ether_addr_equal(ieee_hdr->addr3, ++ priv->curr_bss_params.bss_descriptor.mac_address)) + return 0; + + if (ieee80211_is_deauth(ieee_hdr->frame_control)) { diff --git a/queue-6.15/wifi-prevent-a-msdu-attacks-in-mesh-networks.patch b/queue-6.15/wifi-prevent-a-msdu-attacks-in-mesh-networks.patch new file mode 100644 index 0000000000..c76c4503b3 --- /dev/null +++ b/queue-6.15/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 +@@ -820,6 +820,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, +@@ -861,8 +907,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.15/x86-mce-amd-add-default-names-for-mca-banks-and-blocks.patch b/queue-6.15/x86-mce-amd-add-default-names-for-mca-banks-and-blocks.patch new file mode 100644 index 0000000000..ec76b9bc8c --- /dev/null +++ b/queue-6.15/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 +@@ -1113,13 +1113,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.15/x86-mce-amd-fix-threshold-limit-reset.patch b/queue-6.15/x86-mce-amd-fix-threshold-limit-reset.patch new file mode 100644 index 0000000000..576db6d080 --- /dev/null +++ b/queue-6.15/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 +@@ -350,7 +350,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; +@@ -432,13 +431,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.15/x86-mce-don-t-remove-sysfs-if-thresholding-sysfs-init-fails.patch b/queue-6.15/x86-mce-don-t-remove-sysfs-if-thresholding-sysfs-init-fails.patch new file mode 100644 index 0000000000..5d9240ccad --- /dev/null +++ b/queue-6.15/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 +@@ -2801,15 +2801,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.15/x86-mce-ensure-user-polling-settings-are-honored-when-restarting-timer.patch b/queue-6.15/x86-mce-ensure-user-polling-settings-are-honored-when-restarting-timer.patch new file mode 100644 index 0000000000..6af18b530e --- /dev/null +++ b/queue-6.15/x86-mce-ensure-user-polling-settings-are-honored-when-restarting-timer.patch @@ -0,0 +1,75 @@ +From 00c092de6f28ebd32208aef83b02d61af2229b60 Mon Sep 17 00:00:00 2001 +From: Yazen Ghannam +Date: Tue, 24 Jun 2025 14:15:57 +0000 +Subject: x86/mce: Ensure user polling settings are honored when restarting timer + +From: Yazen Ghannam + +commit 00c092de6f28ebd32208aef83b02d61af2229b60 upstream. + +Users can disable MCA polling by setting the "ignore_ce" parameter or by +setting "check_interval=0". This tells the kernel to *not* start the MCE +timer on a CPU. + +If the user did not disable CMCI, then storms can occur. When these +happen, the MCE timer will be started with a fixed interval. After the +storm subsides, the timer's next interval is set to check_interval. + +This disregards the user's input through "ignore_ce" and +"check_interval". Furthermore, if "check_interval=0", then the new timer +will run faster than expected. + +Create a new helper to check these conditions and use it when a CMCI +storm ends. + + [ bp: Massage. ] + +Fixes: 7eae17c4add5 ("x86/mce: Add per-bank CMCI storm mitigation") +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-2-236dd74f645f@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/mce/core.c | 16 ++++++++++------ + 1 file changed, 10 insertions(+), 6 deletions(-) + +--- a/arch/x86/kernel/cpu/mce/core.c ++++ b/arch/x86/kernel/cpu/mce/core.c +@@ -1740,6 +1740,11 @@ static void mc_poll_banks_default(void) + + void (*mc_poll_banks)(void) = mc_poll_banks_default; + ++static bool should_enable_timer(unsigned long iv) ++{ ++ return !mca_cfg.ignore_ce && iv; ++} ++ + static void mce_timer_fn(struct timer_list *t) + { + struct timer_list *cpu_t = this_cpu_ptr(&mce_timer); +@@ -1763,7 +1768,7 @@ static void mce_timer_fn(struct timer_li + + if (mce_get_storm_mode()) { + __start_timer(t, HZ); +- } else { ++ } else if (should_enable_timer(iv)) { + __this_cpu_write(mce_next_interval, iv); + __start_timer(t, iv); + } +@@ -2156,11 +2161,10 @@ static void mce_start_timer(struct timer + { + unsigned long iv = check_interval * HZ; + +- if (mca_cfg.ignore_ce || !iv) +- return; +- +- this_cpu_write(mce_next_interval, iv); +- __start_timer(t, iv); ++ if (should_enable_timer(iv)) { ++ this_cpu_write(mce_next_interval, iv); ++ __start_timer(t, iv); ++ } + } + + static void __mcheck_cpu_setup_timer(void) diff --git a/queue-6.15/x86-mce-make-sure-cmci-banks-are-cleared-during-shutdown-on-intel.patch b/queue-6.15/x86-mce-make-sure-cmci-banks-are-cleared-during-shutdown-on-intel.patch new file mode 100644 index 0000000000..324a47fdfe --- /dev/null +++ b/queue-6.15/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 +@@ -478,6 +478,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)