From: Greg Kroah-Hartman Date: Mon, 29 Dec 2025 14:35:56 +0000 (+0100) Subject: 6.18-stable patches X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b2fdc73119bb9fc39c28345771a6504c2c09fc82;p=thirdparty%2Fkernel%2Fstable-queue.git 6.18-stable patches added patches: alsa-hda-realtek-add-asus-quirk-for-tas-amplifiers.patch arm64-gcs-flush-the-gcs-locking-state-on-exec.patch asoc-sof-ipc4-topology-convert-float-to-s32-during-blob-selection.patch asoc-sof-ipc4-topology-prefer-32-bit-dmic-blobs-for-8-bit-formats-as-well.patch btrfs-don-t-log-conflicting-inode-if-it-s-a-dir-moved-in-the-current-transaction.patch cgroup-rstat-use-lock-cmpxchg-in-css_rstat_updated.patch dm-pcache-advance-slot-index-before-writing-slot.patch fsnotify-do-not-generate-access-modify-events-on-child-for-special-files.patch gpio-loongson-switch-2k2000-3000-gpio-to-byte_ctrl_mode.patch gpio-regmap-fix-memleak-in-error-path-in-gpio_regmap_register.patch gpiolib-acpi-add-quirk-for-dell-precision-7780.patch kvm-disallow-toggling-kvm_mem_guest_memfd-on-an-existing-memslot.patch kvm-fix-last_boosted_vcpu-index-assignment-bug.patch kvm-nsvm-avoid-incorrect-injection-of-svm_exit_cr0_sel_write.patch kvm-nsvm-clear-exit_code_hi-in-vmcb-when-synthesizing-nested-vm-exits.patch kvm-nsvm-propagate-svm_exit_cr0_sel_write-correctly-for-lmsw-emulation.patch kvm-nsvm-set-exit_code_hi-to-1-when-synthesizing-svm_exit_err-failed-vmrun.patch kvm-nvmx-immediately-refresh-apicv-controls-as-needed-on-nested-vm-exit.patch kvm-selftests-add-missing-break-in-rseq_test-s-param-parsing.patch kvm-selftests-forcefully-override-arch-from-x86_64-to-x86.patch kvm-svm-mark-vmcb_npt-as-dirty-on-nested-vmrun.patch kvm-svm-mark-vmcb_perm_map-as-dirty-on-nested-vmrun.patch kvm-tdx-explicitly-set-user-return-msrs-that-may-be-clobbered-by-the-tdx-module.patch kvm-x86-apply-runtime-updates-to-current-cpuid-during-kvm_set_cpuid-2.patch kvm-x86-don-t-clear-async-pf-queue-when-cr0.pg-is-disabled-e.g.-on-smi.patch kvm-x86-explicitly-set-new-periodic-hrtimer-expiration-in-apic_timer_fn.patch kvm-x86-fix-vm-hard-lockup-after-prolonged-inactivity-with-periodic-hv-timer.patch kvm-x86-warn-if-hrtimer-callback-for-periodic-apic-timer-fires-with-period-0.patch lib-crypto-riscv-add-poly1305-core.s-to-.gitignore.patch lib-crypto-riscv-chacha-avoid-s0-fp-register.patch libceph-make-decode_pool-more-resilient-against-corrupted-osdmaps.patch media-iris-add-sanity-check-for-stop-streaming.patch media-vidtv-initialize-local-pointers-upon-transfer-of-memory-ownership.patch mm-slub-reset-kasan-tag-in-defer_free-before-accessing-freed-memory.patch net-handshake-restore-destructor-on-submit-failure.patch net-phy-marvell-88q2xxx-fix-clamped-value-in-mv88q2xxx_hwmon_write.patch nfsd-clear-seclabel-in-the-suppattr_exclcreat-bitmap.patch nfsd-clear-time_deleg-in-the-suppattr_exclcreat-bitmap.patch nfsd-mark-variable-__maybe_unused-to-avoid-w-1-build-break.patch nfsd-nfsv4-file-creation-neglects-setting-acl.patch ocfs2-fix-kernel-bug-in-ocfs2_find_victim_chain.patch parisc-do-not-reprogram-affinitiy-on-asp-chip.patch pinctrl-renesas-rzg2l-fix-isel-restore-on-resume.patch platform-chrome-cros_ec_ishtp-fix-uaf-after-unbinding-driver.patch pm-runtime-do-not-clear-needs_force_resume-with-enabled-runtime-pm.patch powerpc-add-reloc_offset-to-font-bitmap-pointer-used-for-bootx_printf.patch powerpc-kexec-enable-smt-before-waking-offline-cpus.patch r8169-fix-rtl8117-wake-on-lan-in-dash-mode.patch s390-ipl-clear-sbp-flag-when-bootprog-is-set.patch scs-fix-a-wrong-parameter-in-__scs_magic.patch sunrpc-svcauth_gss-avoid-null-deref-on-zero-length-gss_token-in-gss_read_proxy_verf.patch svcrdma-bound-check-rq_pages-index-in-inline-path.patch svcrdma-return-0-on-success-from-svc_rdma_copy_inline_range.patch svcrdma-use-rc_pageoff-for-memcpy-byte-offset.patch tools-testing-nvdimm-use-per-dimm-device-handle.patch tracing-do-not-register-unsupported-perf-events.patch xfs-fix-a-memory-leak-in-xfs_buf_item_init.patch xfs-fix-a-uaf-problem-in-xattr-repair.patch xfs-fix-stupid-compiler-warning.patch xfs-fix-the-zoned-rt-growfs-check-for-zone-alignment.patch xfs-validate-that-zoned-rt-devices-are-zone-aligned.patch --- diff --git a/queue-6.18/alsa-hda-realtek-add-asus-quirk-for-tas-amplifiers.patch b/queue-6.18/alsa-hda-realtek-add-asus-quirk-for-tas-amplifiers.patch new file mode 100644 index 0000000000..ba8361a90a --- /dev/null +++ b/queue-6.18/alsa-hda-realtek-add-asus-quirk-for-tas-amplifiers.patch @@ -0,0 +1,58 @@ +From f7cede182c963720edd1e5fb50ea4f1c7eafa30e Mon Sep 17 00:00:00 2001 +From: Antheas Kapenekakis +Date: Tue, 16 Dec 2025 22:17:14 +0100 +Subject: ALSA: hda/realtek: Add Asus quirk for TAS amplifiers + +From: Antheas Kapenekakis + +commit f7cede182c963720edd1e5fb50ea4f1c7eafa30e upstream. + +By default, these devices use the quirk ALC294_FIXUP_ASUS_SPK. Not +using it causes the headphone jack to stop working. Therefore, +introduce a new quirk ALC287_FIXUP_TXNW2781_I2C_ASUS that binds +to the TAS amplifier while using that quirk. + +Cc: stable@kernel.org +Fixes: 18a4895370a7 ("ALSA: hda/realtek: Add match for ASUS Xbox Ally projects") +Signed-off-by: Antheas Kapenekakis +Link: https://patch.msgid.link/20251216211714.1116898-1-lkml@antheas.dev +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/hda/codecs/realtek/alc269.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/sound/hda/codecs/realtek/alc269.c ++++ b/sound/hda/codecs/realtek/alc269.c +@@ -3703,6 +3703,7 @@ enum { + ALC295_FIXUP_DELL_TAS2781_I2C, + ALC245_FIXUP_TAS2781_SPI_2, + ALC287_FIXUP_TXNW2781_I2C, ++ ALC287_FIXUP_TXNW2781_I2C_ASUS, + ALC287_FIXUP_YOGA7_14ARB7_I2C, + ALC245_FIXUP_HP_MUTE_LED_COEFBIT, + ALC245_FIXUP_HP_MUTE_LED_V1_COEFBIT, +@@ -5993,6 +5994,12 @@ static const struct hda_fixup alc269_fix + .chained = true, + .chain_id = ALC285_FIXUP_THINKPAD_HEADSET_JACK, + }, ++ [ALC287_FIXUP_TXNW2781_I2C_ASUS] = { ++ .type = HDA_FIXUP_FUNC, ++ .v.func = tas2781_fixup_txnw_i2c, ++ .chained = true, ++ .chain_id = ALC294_FIXUP_ASUS_SPK, ++ }, + [ALC287_FIXUP_YOGA7_14ARB7_I2C] = { + .type = HDA_FIXUP_FUNC, + .v.func = yoga7_14arb7_fixup_i2c, +@@ -6736,8 +6743,8 @@ static const struct hda_quirk alc269_fix + SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC), +- SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C), +- SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), ++ SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C_ASUS), ++ SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C_ASUS), + SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), + SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC), diff --git a/queue-6.18/arm64-gcs-flush-the-gcs-locking-state-on-exec.patch b/queue-6.18/arm64-gcs-flush-the-gcs-locking-state-on-exec.patch new file mode 100644 index 0000000000..ce5220629f --- /dev/null +++ b/queue-6.18/arm64-gcs-flush-the-gcs-locking-state-on-exec.patch @@ -0,0 +1,35 @@ +From 98a97bf41528ef738b06eb07ec2b2eb1cfde6ce6 Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Sat, 29 Nov 2025 00:48:45 +0000 +Subject: arm64/gcs: Flush the GCS locking state on exec + +From: Mark Brown + +commit 98a97bf41528ef738b06eb07ec2b2eb1cfde6ce6 upstream. + +When we exec a new task we forget to flush the set of locked GCS mode bits. +Since we do flush the rest of the state this means that if GCS is locked +the new task will be unable to enable GCS, it will be locked as being +disabled. Add the expected flush. + +Fixes: fc84bc5378a8 ("arm64/gcs: Context switch GCS state for EL0") +Cc: # 6.13.x +Reported-by: Yury Khrustalev +Signed-off-by: Mark Brown +Tested-by: Yury Khrustalev +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/process.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm64/kernel/process.c ++++ b/arch/arm64/kernel/process.c +@@ -292,6 +292,7 @@ static void flush_gcs(void) + current->thread.gcs_base = 0; + current->thread.gcs_size = 0; + current->thread.gcs_el0_mode = 0; ++ current->thread.gcs_el0_locked = 0; + write_sysreg_s(GCSCRE0_EL1_nTR, SYS_GCSCRE0_EL1); + write_sysreg_s(0, SYS_GCSPR_EL0); + } diff --git a/queue-6.18/asoc-sof-ipc4-topology-convert-float-to-s32-during-blob-selection.patch b/queue-6.18/asoc-sof-ipc4-topology-convert-float-to-s32-during-blob-selection.patch new file mode 100644 index 0000000000..774499bd7c --- /dev/null +++ b/queue-6.18/asoc-sof-ipc4-topology-convert-float-to-s32-during-blob-selection.patch @@ -0,0 +1,47 @@ +From 816f291fc23f325d31509d0e97873249ad75ae9a Mon Sep 17 00:00:00 2001 +From: Peter Ujfalusi +Date: Mon, 15 Dec 2025 14:06:48 +0200 +Subject: ASoC: SOF: ipc4-topology: Convert FLOAT to S32 during blob selection + +From: Peter Ujfalusi + +commit 816f291fc23f325d31509d0e97873249ad75ae9a upstream. + +SSP/DMIC blobs have no support for FLOAT type, they are using S32 on data +bus. + +Convert the format from FLOAT_LE to S32_LE to make sure that the correct +format is used within the path. + +FLOAT conversion will be done on the host side (or within the path). + +Fixes: f7c41911ad74 ("ASoC: SOF: ipc4-topology: Add support for float sample type") +Cc: stable@vger.kernel.org +Signed-off-by: Peter Ujfalusi +Reviewed-by: Bard Liao +Reviewed-by: Seppo Ingalsuo +Reviewed-by: Kai Vehmanen +Reviewed-by: Ranjani Sridharan +Link: https://patch.msgid.link/20251215120648.4827-3-peter.ujfalusi@linux.intel.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/sof/ipc4-topology.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c +index 47959f182f4b..32b628e2fe29 100644 +--- a/sound/soc/sof/ipc4-topology.c ++++ b/sound/soc/sof/ipc4-topology.c +@@ -1843,7 +1843,7 @@ snd_sof_get_nhlt_endpoint_data(struct snd_sof_dev *sdev, struct snd_sof_dai *dai + *len = cfg->size >> 2; + *dst = (u32 *)cfg->caps; + +- if (format_change) { ++ if (format_change || params_format(params) == SNDRV_PCM_FORMAT_FLOAT_LE) { + /* + * Update the params to reflect that different blob was loaded + * instead of the requested bit depth (16 -> 32 or 32 -> 16). +-- +2.52.0 + diff --git a/queue-6.18/asoc-sof-ipc4-topology-prefer-32-bit-dmic-blobs-for-8-bit-formats-as-well.patch b/queue-6.18/asoc-sof-ipc4-topology-prefer-32-bit-dmic-blobs-for-8-bit-formats-as-well.patch new file mode 100644 index 0000000000..97ca52abe4 --- /dev/null +++ b/queue-6.18/asoc-sof-ipc4-topology-prefer-32-bit-dmic-blobs-for-8-bit-formats-as-well.patch @@ -0,0 +1,74 @@ +From 26e455064983e00013c0a63ffe0eed9e9ec2fa89 Mon Sep 17 00:00:00 2001 +From: Peter Ujfalusi +Date: Mon, 15 Dec 2025 14:06:47 +0200 +Subject: ASoC: SOF: ipc4-topology: Prefer 32-bit DMIC blobs for 8-bit formats as well + +From: Peter Ujfalusi + +commit 26e455064983e00013c0a63ffe0eed9e9ec2fa89 upstream. + +With the introduction of 8-bit formats the DMIC blob lookup also needs to +be modified to prefer the 32-bit blob when 8-bit format is used on FE. + +At the same time we also need to make sure that in case 8-bit format is +used, but only 16-bit blob is available for DMIC then we will not try to +look for 8-bit blob (which is invalid) as fallback, but for a 16-bit one. + +Fixes: c04c2e829649 ("ASoC: SOF: ipc4-topology: Add support for 8-bit formats") +Cc: stable@vger.kernel.org +Signed-off-by: Peter Ujfalusi +Reviewed-by: Bard Liao +Reviewed-by: Seppo Ingalsuo +Reviewed-by: Kai Vehmanen +Reviewed-by: Ranjani Sridharan +Link: https://patch.msgid.link/20251215120648.4827-2-peter.ujfalusi@linux.intel.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/sof/ipc4-topology.c | 22 ++++++++++++++-------- + 1 file changed, 14 insertions(+), 8 deletions(-) + +diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c +index 221e9d4052b8..47959f182f4b 100644 +--- a/sound/soc/sof/ipc4-topology.c ++++ b/sound/soc/sof/ipc4-topology.c +@@ -1752,11 +1752,9 @@ snd_sof_get_nhlt_endpoint_data(struct snd_sof_dev *sdev, struct snd_sof_dai *dai + channel_count = params_channels(params); + sample_rate = params_rate(params); + bit_depth = params_width(params); +- /* +- * Look for 32-bit blob first instead of 16-bit if copier +- * supports multiple formats +- */ +- if (bit_depth == 16 && !single_bitdepth) { ++ ++ /* Prefer 32-bit blob if copier supports multiple formats */ ++ if (bit_depth <= 16 && !single_bitdepth) { + dev_dbg(sdev->dev, "Looking for 32-bit blob first for DMIC\n"); + format_change = true; + bit_depth = 32; +@@ -1799,10 +1797,18 @@ snd_sof_get_nhlt_endpoint_data(struct snd_sof_dev *sdev, struct snd_sof_dai *dai + if (format_change) { + /* + * The 32-bit blob was not found in NHLT table, try to +- * look for one based on the params ++ * look for 16-bit for DMIC or based on the params for ++ * SSP + */ +- bit_depth = params_width(params); +- format_change = false; ++ if (linktype == SOF_DAI_INTEL_DMIC) { ++ bit_depth = 16; ++ if (params_width(params) == 16) ++ format_change = false; ++ } else { ++ bit_depth = params_width(params); ++ format_change = false; ++ } ++ + get_new_blob = true; + } else if (linktype == SOF_DAI_INTEL_DMIC && !single_bitdepth) { + /* +-- +2.52.0 + diff --git a/queue-6.18/btrfs-don-t-log-conflicting-inode-if-it-s-a-dir-moved-in-the-current-transaction.patch b/queue-6.18/btrfs-don-t-log-conflicting-inode-if-it-s-a-dir-moved-in-the-current-transaction.patch new file mode 100644 index 0000000000..0b604561bd --- /dev/null +++ b/queue-6.18/btrfs-don-t-log-conflicting-inode-if-it-s-a-dir-moved-in-the-current-transaction.patch @@ -0,0 +1,269 @@ +From 266273eaf4d99475f1ae57f687b3e42bc71ec6f0 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Thu, 27 Nov 2025 16:35:59 +0000 +Subject: btrfs: don't log conflicting inode if it's a dir moved in the current transaction + +From: Filipe Manana + +commit 266273eaf4d99475f1ae57f687b3e42bc71ec6f0 upstream. + +We can't log a conflicting inode if it's a directory and it was moved +from one parent directory to another parent directory in the current +transaction, as this can result an attempt to have a directory with +two hard links during log replay, one for the old parent directory and +another for the new parent directory. + +The following scenario triggers that issue: + +1) We have directories "dir1" and "dir2" created in a past transaction. + Directory "dir1" has inode A as its parent directory; + +2) We move "dir1" to some other directory; + +3) We create a file with the name "dir1" in directory inode A; + +4) We fsync the new file. This results in logging the inode of the new file + and the inode for the directory "dir1" that was previously moved in the + current transaction. So the log tree has the INODE_REF item for the + new location of "dir1"; + +5) We move the new file to some other directory. This results in updating + the log tree to included the new INODE_REF for the new location of the + file and removes the INODE_REF for the old location. This happens + during the rename when we call btrfs_log_new_name(); + +6) We fsync the file, and that persists the log tree changes done in the + previous step (btrfs_log_new_name() only updates the log tree in + memory); + +7) We have a power failure; + +8) Next time the fs is mounted, log replay happens and when processing + the inode for directory "dir1" we find a new INODE_REF and add that + link, but we don't remove the old link of the inode since we have + not logged the old parent directory of the directory inode "dir1". + +As a result after log replay finishes when we trigger writeback of the +subvolume tree's extent buffers, the tree check will detect that we have +a directory a hard link count of 2 and we get a mount failure. +The errors and stack traces reported in dmesg/syslog are like this: + + [ 3845.729764] BTRFS info (device dm-0): start tree-log replay + [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c + [ 3845.731236] memcg:ffff9264c02f4e00 + [ 3845.731751] aops:btree_aops [btrfs] ino:1 + [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) + [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 + [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 + [ 3845.735305] page dumped because: eb page dump + [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir + [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5 + [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701 + [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 + [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 + [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 + [ 3845.737797] rdev 0 sequence 2 flags 0x0 + [ 3845.737798] atime 1764259517.0 + [ 3845.737800] ctime 1764259517.572889464 + [ 3845.737801] mtime 1764259517.572889464 + [ 3845.737802] otime 1764259517.0 + [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 + [ 3845.737805] index 0 name_len 2 + [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 + [ 3845.737808] location key (257 1 0) type 2 + [ 3845.737810] transid 9 data_len 0 name_len 4 + [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 + [ 3845.737813] location key (258 1 0) type 2 + [ 3845.737814] transid 9 data_len 0 name_len 4 + [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 + [ 3845.737816] location key (257 1 0) type 2 + [ 3845.737818] transid 9 data_len 0 name_len 4 + [ 3845.737819] item 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 + [ 3845.737820] location key (258 1 0) type 2 + [ 3845.737821] transid 9 data_len 0 name_len 4 + [ 3845.737822] item 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 + [ 3845.737824] inode generation 9 transid 10 size 6 nbytes 0 + [ 3845.737825] block group 0 mode 40755 links 2 uid 0 gid 0 + [ 3845.737826] rdev 0 sequence 1 flags 0x0 + [ 3845.737827] atime 1764259517.572889464 + [ 3845.737828] ctime 1764259517.572889464 + [ 3845.737830] mtime 1764259517.572889464 + [ 3845.737831] otime 1764259517.572889464 + [ 3845.737832] item 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 + [ 3845.737833] index 2 name_len 4 + [ 3845.737834] item 8 key (257 INODE_REF 258) itemoff 15787 itemsize 14 + [ 3845.737836] index 2 name_len 4 + [ 3845.737837] item 9 key (257 DIR_ITEM 2507850652) itemoff 15754 itemsize 33 + [ 3845.737838] location key (259 1 0) type 1 + [ 3845.737839] transid 10 data_len 0 name_len 3 + [ 3845.737840] item 10 key (257 DIR_INDEX 2) itemoff 15721 itemsize 33 + [ 3845.737842] location key (259 1 0) type 1 + [ 3845.737843] transid 10 data_len 0 name_len 3 + [ 3845.737844] item 11 key (258 INODE_ITEM 0) itemoff 15561 itemsize 160 + [ 3845.737846] inode generation 9 transid 10 size 8 nbytes 0 + [ 3845.737847] block group 0 mode 40755 links 1 uid 0 gid 0 + [ 3845.737848] rdev 0 sequence 1 flags 0x0 + [ 3845.737849] atime 1764259517.572889464 + [ 3845.737850] ctime 1764259517.572889464 + [ 3845.737851] mtime 1764259517.572889464 + [ 3845.737852] otime 1764259517.572889464 + [ 3845.737853] item 12 key (258 INODE_REF 256) itemoff 15547 itemsize 14 + [ 3845.737855] index 3 name_len 4 + [ 3845.737856] item 13 key (258 DIR_ITEM 1843588421) itemoff 15513 itemsize 34 + [ 3845.737857] location key (257 1 0) type 2 + [ 3845.737858] transid 10 data_len 0 name_len 4 + [ 3845.737860] item 14 key (258 DIR_INDEX 2) itemoff 15479 itemsize 34 + [ 3845.737861] location key (257 1 0) type 2 + [ 3845.737862] transid 10 data_len 0 name_len 4 + [ 3845.737863] item 15 key (259 INODE_ITEM 0) itemoff 15319 itemsize 160 + [ 3845.737865] inode generation 10 transid 10 size 0 nbytes 0 + [ 3845.737866] block group 0 mode 100600 links 1 uid 0 gid 0 + [ 3845.737867] rdev 0 sequence 2 flags 0x0 + [ 3845.737868] atime 1764259517.580874966 + [ 3845.737869] ctime 1764259517.586121869 + [ 3845.737870] mtime 1764259517.580874966 + [ 3845.737872] otime 1764259517.580874966 + [ 3845.737873] item 16 key (259 INODE_REF 257) itemoff 15306 itemsize 13 + [ 3845.737874] index 2 name_len 3 + [ 3845.737875] BTRFS error (device dm-0): block=30408704 write time tree block corruption detected + [ 3845.739448] ------------[ cut here ]------------ + [ 3845.740092] WARNING: CPU: 5 PID: 30701 at fs/btrfs/disk-io.c:335 btree_csum_one_bio+0x25a/0x270 [btrfs] + [ 3845.741439] Modules linked in: btrfs dm_flakey crc32c_cryptoapi (...) + [ 3845.750626] CPU: 5 UID: 0 PID: 30701 Comm: mount Tainted: G W 6.18.0-rc6-btrfs-next-218+ #1 PREEMPT(full) + [ 3845.752414] Tainted: [W]=WARN + [ 3845.752828] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 + [ 3845.754499] RIP: 0010:btree_csum_one_bio+0x25a/0x270 [btrfs] + [ 3845.755460] Code: 31 f6 48 89 (...) + [ 3845.758685] RSP: 0018:ffffa8d9c5677678 EFLAGS: 00010246 + [ 3845.759450] RAX: 0000000000000000 RBX: ffff92650e6d4738 RCX: 0000000000000000 + [ 3845.760309] RDX: 0000000000000000 RSI: ffffffff9aab45b9 RDI: ffff9264c4748000 + [ 3845.761239] RBP: ffff9264d4324000 R08: 0000000000000000 R09: ffffa8d9c5677468 + [ 3845.762607] R10: ffff926bdc1fffa8 R11: 0000000000000003 R12: ffffa8d9c5677680 + [ 3845.764099] R13: 0000000000004000 R14: ffff9264dd624000 R15: ffff9264d978aba8 + [ 3845.765094] FS: 00007f751fa5a840(0000) GS:ffff926c42a82000(0000) knlGS:0000000000000000 + [ 3845.766226] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + [ 3845.766970] CR2: 0000558df1815380 CR3: 000000010ed88003 CR4: 0000000000370ef0 + [ 3845.768009] Call Trace: + [ 3845.768392] + [ 3845.768714] btrfs_submit_bbio+0x6ee/0x7f0 [btrfs] + [ 3845.769640] ? write_one_eb+0x28e/0x340 [btrfs] + [ 3845.770588] btree_write_cache_pages+0x2f0/0x550 [btrfs] + [ 3845.771286] ? alloc_extent_state+0x19/0x100 [btrfs] + [ 3845.771967] ? merge_next_state+0x1a/0x90 [btrfs] + [ 3845.772586] ? set_extent_bit+0x233/0x8b0 [btrfs] + [ 3845.773198] ? xas_load+0x9/0xc0 + [ 3845.773589] ? xas_find+0x14d/0x1a0 + [ 3845.773969] do_writepages+0xc6/0x160 + [ 3845.774367] filemap_fdatawrite_wbc+0x48/0x60 + [ 3845.775003] __filemap_fdatawrite_range+0x5b/0x80 + [ 3845.775902] btrfs_write_marked_extents+0x61/0x170 [btrfs] + [ 3845.776707] btrfs_write_and_wait_transaction+0x4e/0xc0 [btrfs] + [ 3845.777379] ? _raw_spin_unlock_irqrestore+0x23/0x40 + [ 3845.777923] btrfs_commit_transaction+0x5ea/0xd20 [btrfs] + [ 3845.778551] ? _raw_spin_unlock+0x15/0x30 + [ 3845.778986] ? release_extent_buffer+0x34/0x160 [btrfs] + [ 3845.779659] btrfs_recover_log_trees+0x7a3/0x7c0 [btrfs] + [ 3845.780416] ? __pfx_replay_one_buffer+0x10/0x10 [btrfs] + [ 3845.781499] open_ctree+0x10bb/0x15f0 [btrfs] + [ 3845.782194] btrfs_get_tree.cold+0xb/0x16c [btrfs] + [ 3845.782764] ? fscontext_read+0x15c/0x180 + [ 3845.783202] ? rw_verify_area+0x50/0x180 + [ 3845.783667] vfs_get_tree+0x25/0xd0 + [ 3845.784047] vfs_cmd_create+0x59/0xe0 + [ 3845.784458] __do_sys_fsconfig+0x4f6/0x6b0 + [ 3845.784914] do_syscall_64+0x50/0x1220 + [ 3845.785340] entry_SYSCALL_64_after_hwframe+0x76/0x7e + [ 3845.785980] RIP: 0033:0x7f751fc7f4aa + [ 3845.786759] Code: 73 01 c3 48 (...) + [ 3845.789951] RSP: 002b:00007ffcdba45dc8 EFLAGS: 00000246 ORIG_RAX: 00000000000001af + [ 3845.791402] RAX: ffffffffffffffda RBX: 000055ccc8291c20 RCX: 00007f751fc7f4aa + [ 3845.792688] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003 + [ 3845.794308] RBP: 000055ccc8292120 R08: 0000000000000000 R09: 0000000000000000 + [ 3845.795829] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 + [ 3845.797183] R13: 00007f751fe11580 R14: 00007f751fe1326c R15: 00007f751fdf8a23 + [ 3845.798633] + [ 3845.799067] ---[ end trace 0000000000000000 ]--- + [ 3845.800215] BTRFS: error (device dm-0) in btrfs_commit_transaction:2553: errno=-5 IO failure (Error while writing out transaction) + [ 3845.801860] BTRFS warning (device dm-0 state E): Skipping commit of aborted transaction. + [ 3845.802815] BTRFS error (device dm-0 state EA): Transaction aborted (error -5) + [ 3845.803728] BTRFS: error (device dm-0 state EA) in cleanup_transaction:2036: errno=-5 IO failure + [ 3845.805374] BTRFS: error (device dm-0 state EA) in btrfs_replay_log:2083: errno=-5 IO failure (Failed to recover log tree) + [ 3845.807919] BTRFS error (device dm-0 state EA): open_ctree failed: -5 + +Fix this by never logging a conflicting inode that is a directory and was +moved in the current transaction (its last_unlink_trans equals the current +transaction) and instead fallback to a transaction commit. + +A test case for fstests will follow soon. + +Reported-by: Vyacheslav Kovalevsky +Link: https://lore.kernel.org/linux-btrfs/7bbc9419-5c56-450a-b5a0-efeae7457113@gmail.com/ +CC: stable@vger.kernel.org # 6.1+ +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/tree-log.c | 38 ++++++++++++++++++++++++++++++++++++++ + 1 file changed, 38 insertions(+) + +--- a/fs/btrfs/tree-log.c ++++ b/fs/btrfs/tree-log.c +@@ -6050,6 +6050,33 @@ static int conflicting_inode_is_dir(stru + return ret; + } + ++static bool can_log_conflicting_inode(const struct btrfs_trans_handle *trans, ++ const struct btrfs_inode *inode) ++{ ++ if (!S_ISDIR(inode->vfs_inode.i_mode)) ++ return true; ++ ++ if (inode->last_unlink_trans < trans->transid) ++ return true; ++ ++ /* ++ * If this is a directory and its unlink_trans is not from a past ++ * transaction then we must fallback to a transaction commit in order ++ * to avoid getting a directory with 2 hard links after log replay. ++ * ++ * This happens if a directory A is renamed, moved from one parent ++ * directory to another one, a new file is created in the old parent ++ * directory with the old name of our directory A, the new file is ++ * fsynced, then we moved the new file to some other parent directory ++ * and fsync again the new file. This results in a log tree where we ++ * logged that directory A existed, with the INODE_REF item for the ++ * new location but without having logged its old parent inode, so ++ * that on log replay we add a new link for the new location but the ++ * old link remains, resulting in a link count of 2. ++ */ ++ return false; ++} ++ + static int add_conflicting_inode(struct btrfs_trans_handle *trans, + struct btrfs_root *root, + struct btrfs_path *path, +@@ -6153,6 +6180,11 @@ static int add_conflicting_inode(struct + return 0; + } + ++ if (!can_log_conflicting_inode(trans, inode)) { ++ btrfs_add_delayed_iput(inode); ++ return BTRFS_LOG_FORCE_COMMIT; ++ } ++ + btrfs_add_delayed_iput(inode); + + ino_elem = kmalloc(sizeof(*ino_elem), GFP_NOFS); +@@ -6217,6 +6249,12 @@ static int log_conflicting_inodes(struct + break; + } + ++ if (!can_log_conflicting_inode(trans, inode)) { ++ btrfs_add_delayed_iput(inode); ++ ret = BTRFS_LOG_FORCE_COMMIT; ++ break; ++ } ++ + /* + * Always log the directory, we cannot make this + * conditional on need_log_inode() because the directory diff --git a/queue-6.18/cgroup-rstat-use-lock-cmpxchg-in-css_rstat_updated.patch b/queue-6.18/cgroup-rstat-use-lock-cmpxchg-in-css_rstat_updated.patch new file mode 100644 index 0000000000..0c19f0a458 --- /dev/null +++ b/queue-6.18/cgroup-rstat-use-lock-cmpxchg-in-css_rstat_updated.patch @@ -0,0 +1,102 @@ +From 3309b63a2281efb72df7621d60cc1246b6286ad3 Mon Sep 17 00:00:00 2001 +From: Shakeel Butt +Date: Fri, 5 Dec 2025 12:01:06 -0800 +Subject: cgroup: rstat: use LOCK CMPXCHG in css_rstat_updated + +From: Shakeel Butt + +commit 3309b63a2281efb72df7621d60cc1246b6286ad3 upstream. + +On x86-64, this_cpu_cmpxchg() uses CMPXCHG without LOCK prefix which +means it is only safe for the local CPU and not for multiple CPUs. +Recently the commit 36df6e3dbd7e ("cgroup: make css_rstat_updated nmi +safe") make css_rstat_updated lockless and uses lockless list to allow +reentrancy. Since css_rstat_updated can invoked from process context, +IRQ and NMI, it uses this_cpu_cmpxchg() to select the winner which will +inset the lockless lnode into the global per-cpu lockless list. + +However the commit missed one case where lockless node of a cgroup can +be accessed and modified by another CPU doing the flushing. Basically +llist_del_first_init() in css_process_update_tree(). + +On a cursory look, it can be questioned how css_process_update_tree() +can see a lockless node in global lockless list where the updater is at +this_cpu_cmpxchg() and before llist_add() call in css_rstat_updated(). +This can indeed happen in the presence of IRQs/NMI. + +Consider this scenario: Updater for cgroup stat C on CPU A in process +context is after llist_on_list() check and before this_cpu_cmpxchg() in +css_rstat_updated() where it get interrupted by IRQ/NMI. In the IRQ/NMI +context, a new updater calls css_rstat_updated() for same cgroup C and +successfully inserts rstatc_pcpu->lnode. + +Now concurrently CPU B is running the flusher and it calls +llist_del_first_init() for CPU A and got rstatc_pcpu->lnode of cgroup C +which was added by the IRQ/NMI updater. + +Now imagine CPU B calling init_llist_node() on cgroup C's +rstatc_pcpu->lnode of CPU A and on CPU A, the process context updater +calling this_cpu_cmpxchg(rstatc_pcpu->lnode) concurrently. + +The CMPXCNG without LOCK on CPU A is not safe and thus we need LOCK +prefix. + +In Meta's fleet running the kernel with the commit 36df6e3dbd7e, we are +observing on some machines the memcg stats are getting skewed by more +than the actual memory on the system. On close inspection, we noticed +that lockless node for a workload for specific CPU was in the bad state +and thus all the updates on that CPU for that cgroup was being lost. + +To confirm if this skew was indeed due to this CMPXCHG without LOCK in +css_rstat_updated(), we created a repro (using AI) at [1] which shows +that CMPXCHG without LOCK creates almost the same lnode corruption as +seem in Meta's fleet and with LOCK CMPXCHG the issue does not +reproduces. + +Link: http://lore.kernel.org/efiagdwmzfwpdzps74fvcwq3n4cs36q33ij7eebcpssactv3zu@se4hqiwxcfxq [1] +Signed-off-by: Shakeel Butt +Cc: stable@vger.kernel.org # v6.17+ +Fixes: 36df6e3dbd7e ("cgroup: make css_rstat_updated nmi safe") +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman +--- + kernel/cgroup/rstat.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +--- a/kernel/cgroup/rstat.c ++++ b/kernel/cgroup/rstat.c +@@ -71,7 +71,6 @@ __bpf_kfunc void css_rstat_updated(struc + { + struct llist_head *lhead; + struct css_rstat_cpu *rstatc; +- struct css_rstat_cpu __percpu *rstatc_pcpu; + struct llist_node *self; + + /* +@@ -104,18 +103,22 @@ __bpf_kfunc void css_rstat_updated(struc + /* + * This function can be renentered by irqs and nmis for the same cgroup + * and may try to insert the same per-cpu lnode into the llist. Note +- * that llist_add() does not protect against such scenarios. ++ * that llist_add() does not protect against such scenarios. In addition ++ * this same per-cpu lnode can be modified through init_llist_node() ++ * from css_rstat_flush() running on a different CPU. + * + * To protect against such stacked contexts of irqs/nmis, we use the + * fact that lnode points to itself when not on a list and then use +- * this_cpu_cmpxchg() to atomically set to NULL to select the winner ++ * try_cmpxchg() to atomically set to NULL to select the winner + * which will call llist_add(). The losers can assume the insertion is + * successful and the winner will eventually add the per-cpu lnode to + * the llist. ++ * ++ * Please note that we can not use this_cpu_cmpxchg() here as on some ++ * archs it is not safe against modifications from multiple CPUs. + */ + self = &rstatc->lnode; +- rstatc_pcpu = css->rstat_cpu; +- if (this_cpu_cmpxchg(rstatc_pcpu->lnode.next, self, NULL) != self) ++ if (!try_cmpxchg(&rstatc->lnode.next, &self, NULL)) + return; + + lhead = ss_lhead_cpu(css->ss, cpu); diff --git a/queue-6.18/dm-pcache-advance-slot-index-before-writing-slot.patch b/queue-6.18/dm-pcache-advance-slot-index-before-writing-slot.patch new file mode 100644 index 0000000000..44f6419bae --- /dev/null +++ b/queue-6.18/dm-pcache-advance-slot-index-before-writing-slot.patch @@ -0,0 +1,91 @@ +From ebbb90344a7da2421e4b54668b94e81828b8b308 Mon Sep 17 00:00:00 2001 +From: Dongsheng Yang +Date: Fri, 5 Dec 2025 05:46:18 +0000 +Subject: dm-pcache: advance slot index before writing slot +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Dongsheng Yang + +commit ebbb90344a7da2421e4b54668b94e81828b8b308 upstream. + +In dm-pcache, in order to ensure crash-consistency, a dual-copy scheme +is used to alternately update metadata, and there is a slot index that +records the current slot. However, in the write path the current +implementation writes directly to the current slot indexed by slot +index, and then advances the slot — which ends up overwriting the +existing slot, violating the crash-consistency guarantee. + +This patch fixes that behavior, preventing metadata from being +overwritten incorrectly. + +In addition, this patch add a missing pmem_wmb() after memcpy_flushcache(). + +Signed-off-by: Dongsheng Yang +Signed-off-by: Mikulas Patocka +Reviewed-by: Zheng Gu +Cc: stable@vger.kernel.org # 6.18 +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-pcache/cache.c | 8 ++++---- + drivers/md/dm-pcache/cache_segment.c | 8 ++++---- + 2 files changed, 8 insertions(+), 8 deletions(-) + +--- a/drivers/md/dm-pcache/cache.c ++++ b/drivers/md/dm-pcache/cache.c +@@ -21,10 +21,10 @@ static void cache_info_write(struct pcac + cache_info->header.crc = pcache_meta_crc(&cache_info->header, + sizeof(struct pcache_cache_info)); + ++ cache->info_index = (cache->info_index + 1) % PCACHE_META_INDEX_MAX; + memcpy_flushcache(get_cache_info_addr(cache), cache_info, + sizeof(struct pcache_cache_info)); +- +- cache->info_index = (cache->info_index + 1) % PCACHE_META_INDEX_MAX; ++ pmem_wmb(); + } + + static void cache_info_init_default(struct pcache_cache *cache); +@@ -93,10 +93,10 @@ void cache_pos_encode(struct pcache_cach + pos_onmedia.header.seq = seq; + pos_onmedia.header.crc = cache_pos_onmedia_crc(&pos_onmedia); + ++ *index = (*index + 1) % PCACHE_META_INDEX_MAX; ++ + memcpy_flushcache(pos_onmedia_addr, &pos_onmedia, sizeof(struct pcache_cache_pos_onmedia)); + pmem_wmb(); +- +- *index = (*index + 1) % PCACHE_META_INDEX_MAX; + } + + int cache_pos_decode(struct pcache_cache *cache, +--- a/drivers/md/dm-pcache/cache_segment.c ++++ b/drivers/md/dm-pcache/cache_segment.c +@@ -26,11 +26,11 @@ static void cache_seg_info_write(struct + seg_info->header.seq++; + seg_info->header.crc = pcache_meta_crc(&seg_info->header, sizeof(struct pcache_segment_info)); + ++ cache_seg->info_index = (cache_seg->info_index + 1) % PCACHE_META_INDEX_MAX; ++ + seg_info_addr = get_seg_info_addr(cache_seg); + memcpy_flushcache(seg_info_addr, seg_info, sizeof(struct pcache_segment_info)); + pmem_wmb(); +- +- cache_seg->info_index = (cache_seg->info_index + 1) % PCACHE_META_INDEX_MAX; + mutex_unlock(&cache_seg->info_lock); + } + +@@ -129,10 +129,10 @@ static void cache_seg_ctrl_write(struct + cache_seg_gen.header.crc = pcache_meta_crc(&cache_seg_gen.header, + sizeof(struct pcache_cache_seg_gen)); + ++ cache_seg->gen_index = (cache_seg->gen_index + 1) % PCACHE_META_INDEX_MAX; ++ + memcpy_flushcache(get_cache_seg_gen_addr(cache_seg), &cache_seg_gen, sizeof(struct pcache_cache_seg_gen)); + pmem_wmb(); +- +- cache_seg->gen_index = (cache_seg->gen_index + 1) % PCACHE_META_INDEX_MAX; + } + + static void cache_seg_ctrl_init(struct pcache_cache_segment *cache_seg) diff --git a/queue-6.18/fsnotify-do-not-generate-access-modify-events-on-child-for-special-files.patch b/queue-6.18/fsnotify-do-not-generate-access-modify-events-on-child-for-special-files.patch new file mode 100644 index 0000000000..d231630df4 --- /dev/null +++ b/queue-6.18/fsnotify-do-not-generate-access-modify-events-on-child-for-special-files.patch @@ -0,0 +1,58 @@ +From 635bc4def026a24e071436f4f356ea08c0eed6ff Mon Sep 17 00:00:00 2001 +From: Amir Goldstein +Date: Sun, 7 Dec 2025 11:44:55 +0100 +Subject: fsnotify: do not generate ACCESS/MODIFY events on child for special files + +From: Amir Goldstein + +commit 635bc4def026a24e071436f4f356ea08c0eed6ff upstream. + +inotify/fanotify do not allow users with no read access to a file to +subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the +same user to subscribe for watching events on children when the user +has access to the parent directory (e.g. /dev). + +Users with no read access to a file but with read access to its parent +directory can still stat the file and see if it was accessed/modified +via atime/mtime change. + +The same is not true for special files (e.g. /dev/null). Users will not +generally observe atime/mtime changes when other users read/write to +special files, only when someone sets atime/mtime via utimensat(). + +Align fsnotify events with this stat behavior and do not generate +ACCESS/MODIFY events to parent watchers on read/write of special files. +The events are still generated to parent watchers on utimensat(). This +closes some side-channels that could be possibly used for information +exfiltration [1]. + +[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf + +Reported-by: Sudheendra Raghav Neela +CC: stable@vger.kernel.org +Signed-off-by: Amir Goldstein +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman +--- + fs/notify/fsnotify.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/fs/notify/fsnotify.c ++++ b/fs/notify/fsnotify.c +@@ -270,8 +270,15 @@ int __fsnotify_parent(struct dentry *den + /* + * Include parent/name in notification either if some notification + * groups require parent info or the parent is interested in this event. ++ * The parent interest in ACCESS/MODIFY events does not apply to special ++ * files, where read/write are not on the filesystem of the parent and ++ * events can provide an undesirable side-channel for information ++ * exfiltration. + */ +- parent_interested = mask & p_mask & ALL_FSNOTIFY_EVENTS; ++ parent_interested = mask & p_mask & ALL_FSNOTIFY_EVENTS && ++ !(data_type == FSNOTIFY_EVENT_PATH && ++ d_is_special(dentry) && ++ (mask & (FS_ACCESS | FS_MODIFY))); + if (parent_needed || parent_interested) { + /* When notifying parent, child should be passed as data */ + WARN_ON_ONCE(inode != fsnotify_data_inode(data, data_type)); diff --git a/queue-6.18/gpio-loongson-switch-2k2000-3000-gpio-to-byte_ctrl_mode.patch b/queue-6.18/gpio-loongson-switch-2k2000-3000-gpio-to-byte_ctrl_mode.patch new file mode 100644 index 0000000000..5007bb285d --- /dev/null +++ b/queue-6.18/gpio-loongson-switch-2k2000-3000-gpio-to-byte_ctrl_mode.patch @@ -0,0 +1,45 @@ +From dae9750105cf93ac1e156ef91f4beeb53bd64777 Mon Sep 17 00:00:00 2001 +From: Xi Ruoyao +Date: Fri, 28 Nov 2025 15:50:32 +0800 +Subject: gpio: loongson: Switch 2K2000/3000 GPIO to BYTE_CTRL_MODE + +From: Xi Ruoyao + +commit dae9750105cf93ac1e156ef91f4beeb53bd64777 upstream. + +The manuals of 2K2000 says both BIT_CTRL_MODE and BYTE_CTRL_MODE are +supported but the latter is recommended. Also on 2K3000, per the ACPI +DSDT the GPIO controller is compatible with 2K2000, but it fails to +operate GPIOs 62 and 63 (and maybe others) using BIT_CTRL_MODE. +Using BYTE_CTRL_MODE also makes those 2K3000 GPIOs work. + +Fixes: 3feb70a61740 ("gpio: loongson: add more gpio chip support") +Cc: stable@vger.kernel.org +Signed-off-by: Xi Ruoyao +Reviewed-by: Huacai Chen +Link: https://lore.kernel.org/r/20251128075033.255821-1-xry111@xry111.site +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpio-loongson-64bit.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/gpio/gpio-loongson-64bit.c ++++ b/drivers/gpio/gpio-loongson-64bit.c +@@ -407,11 +407,11 @@ static const struct loongson_gpio_chip_d + + static const struct loongson_gpio_chip_data loongson_gpio_ls2k2000_data1 = { + .label = "ls2k2000_gpio", +- .mode = BIT_CTRL_MODE, +- .conf_offset = 0x0, +- .in_offset = 0x20, +- .out_offset = 0x10, +- .inten_offset = 0x30, ++ .mode = BYTE_CTRL_MODE, ++ .conf_offset = 0x800, ++ .in_offset = 0xa00, ++ .out_offset = 0x900, ++ .inten_offset = 0xb00, + }; + + static const struct loongson_gpio_chip_data loongson_gpio_ls2k2000_data2 = { diff --git a/queue-6.18/gpio-regmap-fix-memleak-in-error-path-in-gpio_regmap_register.patch b/queue-6.18/gpio-regmap-fix-memleak-in-error-path-in-gpio_regmap_register.patch new file mode 100644 index 0000000000..237866a745 --- /dev/null +++ b/queue-6.18/gpio-regmap-fix-memleak-in-error-path-in-gpio_regmap_register.patch @@ -0,0 +1,38 @@ +From 52721cfc78c76b09c66e092b52617006390ae96a Mon Sep 17 00:00:00 2001 +From: Wentao Guan +Date: Thu, 4 Dec 2025 18:13:04 +0800 +Subject: gpio: regmap: Fix memleak in error path in gpio_regmap_register() + +From: Wentao Guan + +commit 52721cfc78c76b09c66e092b52617006390ae96a upstream. + +Call gpiochip_remove() to free the resources allocated by +gpiochip_add_data() in error path. + +Fixes: 553b75d4bfe9 ("gpio: regmap: Allow to allocate regmap-irq device") +Fixes: ae495810cffe ("gpio: regmap: add the .fixed_direction_output configuration parameter") +CC: stable@vger.kernel.org +Co-developed-by: WangYuli +Signed-off-by: WangYuli +Signed-off-by: Wentao Guan +Reviewed-by: Andy Shevchenko +Link: https://lore.kernel.org/r/20251204101303.30353-1-guanwentao@uniontech.com +[Bartosz: reworked the commit message] +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpio-regmap.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpio/gpio-regmap.c ++++ b/drivers/gpio/gpio-regmap.c +@@ -328,7 +328,7 @@ struct gpio_regmap *gpio_regmap_register + config->regmap_irq_line, config->regmap_irq_flags, + 0, config->regmap_irq_chip, &gpio->irq_chip_data); + if (ret) +- goto err_free_bitmap; ++ goto err_remove_gpiochip; + + irq_domain = regmap_irq_get_domain(gpio->irq_chip_data); + } else diff --git a/queue-6.18/gpiolib-acpi-add-quirk-for-dell-precision-7780.patch b/queue-6.18/gpiolib-acpi-add-quirk-for-dell-precision-7780.patch new file mode 100644 index 0000000000..fc04ed3f18 --- /dev/null +++ b/queue-6.18/gpiolib-acpi-add-quirk-for-dell-precision-7780.patch @@ -0,0 +1,56 @@ +From 2d967310c49ed93ac11cef408a55ddf15c3dd52e Mon Sep 17 00:00:00 2001 +From: Askar Safin +Date: Sat, 6 Dec 2025 18:04:13 +0000 +Subject: gpiolib: acpi: Add quirk for Dell Precision 7780 + +From: Askar Safin + +commit 2d967310c49ed93ac11cef408a55ddf15c3dd52e upstream. + +Dell Precision 7780 often wakes up on its own from suspend. Sometimes +wake up happens immediately (i. e. within 7 seconds), sometimes it happens +after, say, 30 minutes. + +Fixes: 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable") +Link: https://lore.kernel.org/linux-i2c/197ae95ffd8.dc819e60457077.7692120488609091556@zohomail.com/ +Cc: stable@vger.kernel.org +Reviewed-by: Andy Shevchenko +Signed-off-by: Askar Safin +Link: https://lore.kernel.org/r/20251206180414.3183334-2-safinaskar@gmail.com +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpiolib-acpi-quirks.c | 22 ++++++++++++++++++++++ + 1 file changed, 22 insertions(+) + +--- a/drivers/gpio/gpiolib-acpi-quirks.c ++++ b/drivers/gpio/gpiolib-acpi-quirks.c +@@ -370,6 +370,28 @@ static const struct dmi_system_id gpioli + .ignore_wake = "ASCP1A00:00@8", + }, + }, ++ { ++ /* ++ * Spurious wakeups, likely from touchpad controller ++ * Dell Precision 7780 ++ * Found in BIOS 1.24.1 ++ * ++ * Found in touchpad firmware, installed by Dell Touchpad Firmware Update Utility version 1160.4196.9, A01 ++ * ( Dell-Touchpad-Firmware-Update-Utility_VYGNN_WIN64_1160.4196.9_A00.EXE ), ++ * released on 11 Jul 2024 ++ * ++ * https://lore.kernel.org/linux-i2c/197ae95ffd8.dc819e60457077.7692120488609091556@zohomail.com/ ++ */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), ++ DMI_MATCH(DMI_PRODUCT_FAMILY, "Precision"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Precision 7780"), ++ DMI_MATCH(DMI_BOARD_NAME, "0C6JVW"), ++ }, ++ .driver_data = &(struct acpi_gpiolib_dmi_quirk) { ++ .ignore_wake = "VEN_0488:00@355", ++ }, ++ }, + {} /* Terminating entry */ + }; + diff --git a/queue-6.18/kvm-disallow-toggling-kvm_mem_guest_memfd-on-an-existing-memslot.patch b/queue-6.18/kvm-disallow-toggling-kvm_mem_guest_memfd-on-an-existing-memslot.patch new file mode 100644 index 0000000000..574c07f24a --- /dev/null +++ b/queue-6.18/kvm-disallow-toggling-kvm_mem_guest_memfd-on-an-existing-memslot.patch @@ -0,0 +1,87 @@ +From 9935df5333aa503a18de5071f53762b65c783c4c Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Mon, 1 Dec 2025 18:03:33 -0800 +Subject: KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslot + +From: Sean Christopherson + +commit 9935df5333aa503a18de5071f53762b65c783c4c upstream. + +Reject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that was +initially created with a guest_memfd binding, as KVM doesn't support +toggling KVM_MEM_GUEST_MEMFD on existing memslots. KVM prevents enabling +KVM_MEM_GUEST_MEMFD, but doesn't prevent clearing the flag. + +Failure to reject the new memslot results in a use-after-free due to KVM +not unbinding from the guest_memfd instance. Unbinding on a FLAGS_ONLY +change is easy enough, and can/will be done as a hardening measure (in +anticipation of KVM supporting dirty logging on guest_memfd at some point), +but fixing the use-after-free would only address the immediate symptom. + + ================================================================== + BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm] + Write of size 8 at addr ffff8881111ae908 by task repro/745 + + CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 + Call Trace: + + dump_stack_lvl+0x51/0x60 + print_report+0xcb/0x5c0 + kasan_report+0xb4/0xe0 + kvm_gmem_release+0x362/0x400 [kvm] + __fput+0x2fa/0x9d0 + task_work_run+0x12c/0x200 + do_exit+0x6ae/0x2100 + do_group_exit+0xa8/0x230 + __x64_sys_exit_group+0x3a/0x50 + x64_sys_call+0x737/0x740 + do_syscall_64+0x5b/0x900 + entry_SYSCALL_64_after_hwframe+0x4b/0x53 + RIP: 0033:0x7f581f2eac31 + + + Allocated by task 745 on cpu 6 at 9.746971s: + kasan_save_stack+0x20/0x40 + kasan_save_track+0x13/0x50 + __kasan_kmalloc+0x77/0x90 + kvm_set_memory_region.part.0+0x652/0x1110 [kvm] + kvm_vm_ioctl+0x14b0/0x3290 [kvm] + __x64_sys_ioctl+0x129/0x1a0 + do_syscall_64+0x5b/0x900 + entry_SYSCALL_64_after_hwframe+0x4b/0x53 + + Freed by task 745 on cpu 6 at 9.747467s: + kasan_save_stack+0x20/0x40 + kasan_save_track+0x13/0x50 + __kasan_save_free_info+0x37/0x50 + __kasan_slab_free+0x3b/0x60 + kfree+0xf5/0x440 + kvm_set_memslot+0x3c2/0x1160 [kvm] + kvm_set_memory_region.part.0+0x86a/0x1110 [kvm] + kvm_vm_ioctl+0x14b0/0x3290 [kvm] + __x64_sys_ioctl+0x129/0x1a0 + do_syscall_64+0x5b/0x900 + entry_SYSCALL_64_after_hwframe+0x4b/0x53 + +Reported-by: Alexander Potapenko +Fixes: a7800aa80ea4 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20251202020334.1171351-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + virt/kvm/kvm_main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -2085,7 +2085,7 @@ static int kvm_set_memory_region(struct + return -EINVAL; + if ((mem->userspace_addr != old->userspace_addr) || + (npages != old->npages) || +- ((mem->flags ^ old->flags) & KVM_MEM_READONLY)) ++ ((mem->flags ^ old->flags) & (KVM_MEM_READONLY | KVM_MEM_GUEST_MEMFD))) + return -EINVAL; + + if (base_gfn != old->base_gfn) diff --git a/queue-6.18/kvm-fix-last_boosted_vcpu-index-assignment-bug.patch b/queue-6.18/kvm-fix-last_boosted_vcpu-index-assignment-bug.patch new file mode 100644 index 0000000000..1a1beb6eec --- /dev/null +++ b/queue-6.18/kvm-fix-last_boosted_vcpu-index-assignment-bug.patch @@ -0,0 +1,38 @@ +From 32bd348be3fa07b26c5ea6b818a161c142dcc2f2 Mon Sep 17 00:00:00 2001 +From: Wanpeng Li +Date: Mon, 10 Nov 2025 11:32:27 +0800 +Subject: KVM: Fix last_boosted_vcpu index assignment bug + +From: Wanpeng Li + +commit 32bd348be3fa07b26c5ea6b818a161c142dcc2f2 upstream. + +In kvm_vcpu_on_spin(), the loop counter 'i' is incorrectly written to +last_boosted_vcpu instead of the actual vCPU index 'idx'. This causes +last_boosted_vcpu to store the loop iteration count rather than the +vCPU index, leading to incorrect round-robin behavior in subsequent +directed yield operations. + +Fix this by using 'idx' instead of 'i' in the assignment. + +Signed-off-by: Wanpeng Li +Reviewed-by: Sean Christopherson +Message-ID: <20251110033232.12538-7-kernellwp@gmail.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + virt/kvm/kvm_main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -4026,7 +4026,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *m + + yielded = kvm_vcpu_yield_to(vcpu); + if (yielded > 0) { +- WRITE_ONCE(kvm->last_boosted_vcpu, i); ++ WRITE_ONCE(kvm->last_boosted_vcpu, idx); + break; + } else if (yielded < 0 && !--try) { + break; diff --git a/queue-6.18/kvm-nsvm-avoid-incorrect-injection-of-svm_exit_cr0_sel_write.patch b/queue-6.18/kvm-nsvm-avoid-incorrect-injection-of-svm_exit_cr0_sel_write.patch new file mode 100644 index 0000000000..868a00dab8 --- /dev/null +++ b/queue-6.18/kvm-nsvm-avoid-incorrect-injection-of-svm_exit_cr0_sel_write.patch @@ -0,0 +1,79 @@ +From 3d80f4c93d3d26d0f9a0dd2844961a632eeea634 Mon Sep 17 00:00:00 2001 +From: Yosry Ahmed +Date: Fri, 24 Oct 2025 19:29:18 +0000 +Subject: KVM: nSVM: Avoid incorrect injection of SVM_EXIT_CR0_SEL_WRITE +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Yosry Ahmed + +commit 3d80f4c93d3d26d0f9a0dd2844961a632eeea634 upstream. + +When emulating L2 instructions, svm_check_intercept() checks whether a +write to CR0 should trigger a synthesized #VMEXIT with +SVM_EXIT_CR0_SEL_WRITE. However, it does not check whether L1 enabled +the intercept for SVM_EXIT_WRITE_CR0, which has higher priority +according to the APM (24593—Rev. 3.42—March 2024, Table 15-7): + + When both selective and non-selective CR0-write intercepts are active at + the same time, the non-selective intercept takes priority. With respect + to exceptions, the priority of this intercept is the same as the generic + CR0-write intercept. + +Make sure L1 does NOT intercept SVM_EXIT_WRITE_CR0 before checking if +SVM_EXIT_CR0_SEL_WRITE needs to be injected. + +Opportunistically tweak the "not CR0" logic to explicitly bail early so +that it's more obvious that only CR0 has a selective intercept, and that +modifying icpt_info.exit_code is functionally necessary so that the call +to nested_svm_exit_handled() checks the correct exit code. + +Fixes: cfec82cb7d31 ("KVM: SVM: Add intercept check for emulated cr accesses") +Cc: stable@vger.kernel.org +Signed-off-by: Yosry Ahmed +Link: https://patch.msgid.link/20251024192918.3191141-4-yosry.ahmed@linux.dev +[sean: isolate non-CR0 write logic, tweak comments accordingly] +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 24 +++++++++++++++++++----- + 1 file changed, 19 insertions(+), 5 deletions(-) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -4528,15 +4528,29 @@ static int svm_check_intercept(struct kv + case SVM_EXIT_WRITE_CR0: { + unsigned long cr0, val; + +- if (info->intercept == x86_intercept_cr_write) ++ /* ++ * Adjust the exit code accordingly if a CR other than CR0 is ++ * being written, and skip straight to the common handling as ++ * only CR0 has an additional selective intercept. ++ */ ++ if (info->intercept == x86_intercept_cr_write && info->modrm_reg) { + icpt_info.exit_code += info->modrm_reg; ++ break; ++ } + +- if (icpt_info.exit_code != SVM_EXIT_WRITE_CR0 || +- info->intercept == x86_intercept_clts) ++ /* ++ * Convert the exit_code to SVM_EXIT_CR0_SEL_WRITE if a ++ * selective CR0 intercept is triggered (the common logic will ++ * treat the selective intercept as being enabled). Note, the ++ * unconditional intercept has higher priority, i.e. this is ++ * only relevant if *only* the selective intercept is enabled. ++ */ ++ if (vmcb12_is_intercept(&svm->nested.ctl, INTERCEPT_CR0_WRITE) || ++ !(vmcb12_is_intercept(&svm->nested.ctl, INTERCEPT_SELECTIVE_CR0))) + break; + +- if (!(vmcb12_is_intercept(&svm->nested.ctl, +- INTERCEPT_SELECTIVE_CR0))) ++ /* CLTS never triggers INTERCEPT_SELECTIVE_CR0 */ ++ if (info->intercept == x86_intercept_clts) + break; + + cr0 = vcpu->arch.cr0 & ~SVM_CR0_SELECTIVE_MASK; diff --git a/queue-6.18/kvm-nsvm-clear-exit_code_hi-in-vmcb-when-synthesizing-nested-vm-exits.patch b/queue-6.18/kvm-nsvm-clear-exit_code_hi-in-vmcb-when-synthesizing-nested-vm-exits.patch new file mode 100644 index 0000000000..b34323c8fe --- /dev/null +++ b/queue-6.18/kvm-nsvm-clear-exit_code_hi-in-vmcb-when-synthesizing-nested-vm-exits.patch @@ -0,0 +1,59 @@ +From da01f64e7470988f8607776aa7afa924208863fb Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 13 Nov 2025 14:56:13 -0800 +Subject: KVM: nSVM: Clear exit_code_hi in VMCB when synthesizing nested VM-Exits + +From: Sean Christopherson + +commit da01f64e7470988f8607776aa7afa924208863fb upstream. + +Explicitly clear exit_code_hi in the VMCB when synthesizing "normal" +nested VM-Exits, as the full exit code is a 64-bit value (spoiler alert), +and all exit codes for non-failing VMRUN use only bits 31:0. + +Cc: Jim Mattson +Cc: Yosry Ahmed +Cc: stable@vger.kernel.org +Reviewed-by: Yosry Ahmed +Link: https://patch.msgid.link/20251113225621.1688428-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 2 ++ + arch/x86/kvm/svm/svm.h | 7 ++++--- + 2 files changed, 6 insertions(+), 3 deletions(-) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -2438,6 +2438,7 @@ static bool check_selective_cr0_intercep + + if (cr0 ^ val) { + svm->vmcb->control.exit_code = SVM_EXIT_CR0_SEL_WRITE; ++ svm->vmcb->control.exit_code_hi = 0; + ret = (nested_svm_exit_handled(svm) == NESTED_EXIT_DONE); + } + +@@ -4627,6 +4628,7 @@ static int svm_check_intercept(struct kv + if (static_cpu_has(X86_FEATURE_NRIPS)) + vmcb->control.next_rip = info->next_rip; + vmcb->control.exit_code = icpt_info.exit_code; ++ vmcb->control.exit_code_hi = 0; + vmexit = nested_svm_exit_handled(svm); + + ret = (vmexit == NESTED_EXIT_DONE) ? X86EMUL_INTERCEPTED +--- a/arch/x86/kvm/svm/svm.h ++++ b/arch/x86/kvm/svm/svm.h +@@ -764,9 +764,10 @@ int nested_svm_vmexit(struct vcpu_svm *s + + static inline int nested_svm_simple_vmexit(struct vcpu_svm *svm, u32 exit_code) + { +- svm->vmcb->control.exit_code = exit_code; +- svm->vmcb->control.exit_info_1 = 0; +- svm->vmcb->control.exit_info_2 = 0; ++ svm->vmcb->control.exit_code = exit_code; ++ svm->vmcb->control.exit_code_hi = 0; ++ svm->vmcb->control.exit_info_1 = 0; ++ svm->vmcb->control.exit_info_2 = 0; + return nested_svm_vmexit(svm); + } + diff --git a/queue-6.18/kvm-nsvm-propagate-svm_exit_cr0_sel_write-correctly-for-lmsw-emulation.patch b/queue-6.18/kvm-nsvm-propagate-svm_exit_cr0_sel_write-correctly-for-lmsw-emulation.patch new file mode 100644 index 0000000000..8b72c480b7 --- /dev/null +++ b/queue-6.18/kvm-nsvm-propagate-svm_exit_cr0_sel_write-correctly-for-lmsw-emulation.patch @@ -0,0 +1,68 @@ +From 5674a76db0213f9db1e4d08e847ff649b46889c0 Mon Sep 17 00:00:00 2001 +From: Yosry Ahmed +Date: Fri, 24 Oct 2025 19:29:17 +0000 +Subject: KVM: nSVM: Propagate SVM_EXIT_CR0_SEL_WRITE correctly for LMSW emulation +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Yosry Ahmed + +commit 5674a76db0213f9db1e4d08e847ff649b46889c0 upstream. + +When emulating L2 instructions, svm_check_intercept() checks whether a +write to CR0 should trigger a synthesized #VMEXIT with +SVM_EXIT_CR0_SEL_WRITE. For MOV-to-CR0, SVM_EXIT_CR0_SEL_WRITE is only +triggered if any bit other than CR0.MP and CR0.TS is updated. However, +according to the APM (24593—Rev. 3.42—March 2024, Table 15-7): + + The LMSW instruction treats the selective CR0-write + intercept as a non-selective intercept (i.e., it intercepts + regardless of the value being written). + +Skip checking the changed bits for x86_intercept_lmsw and always inject +SVM_EXIT_CR0_SEL_WRITE. + +Fixes: cfec82cb7d31 ("KVM: SVM: Add intercept check for emulated cr accesses") +Cc: stable@vger.kernel.org +Reported-by: Matteo Rizzo +Signed-off-by: Yosry Ahmed +Link: https://patch.msgid.link/20251024192918.3191141-3-yosry.ahmed@linux.dev +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 18 +++++++++--------- + 1 file changed, 9 insertions(+), 9 deletions(-) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -4553,20 +4553,20 @@ static int svm_check_intercept(struct kv + if (info->intercept == x86_intercept_clts) + break; + +- cr0 = vcpu->arch.cr0 & ~SVM_CR0_SELECTIVE_MASK; +- val = info->src_val & ~SVM_CR0_SELECTIVE_MASK; +- ++ /* LMSW always triggers INTERCEPT_SELECTIVE_CR0 */ + if (info->intercept == x86_intercept_lmsw) { +- cr0 &= 0xfUL; +- val &= 0xfUL; +- /* lmsw can't clear PE - catch this here */ +- if (cr0 & X86_CR0_PE) +- val |= X86_CR0_PE; ++ icpt_info.exit_code = SVM_EXIT_CR0_SEL_WRITE; ++ break; + } + ++ /* ++ * MOV-to-CR0 only triggers INTERCEPT_SELECTIVE_CR0 if any bit ++ * other than SVM_CR0_SELECTIVE_MASK is changed. ++ */ ++ cr0 = vcpu->arch.cr0 & ~SVM_CR0_SELECTIVE_MASK; ++ val = info->src_val & ~SVM_CR0_SELECTIVE_MASK; + if (cr0 ^ val) + icpt_info.exit_code = SVM_EXIT_CR0_SEL_WRITE; +- + break; + } + case SVM_EXIT_READ_DR0: diff --git a/queue-6.18/kvm-nsvm-set-exit_code_hi-to-1-when-synthesizing-svm_exit_err-failed-vmrun.patch b/queue-6.18/kvm-nsvm-set-exit_code_hi-to-1-when-synthesizing-svm_exit_err-failed-vmrun.patch new file mode 100644 index 0000000000..921f93c9c1 --- /dev/null +++ b/queue-6.18/kvm-nsvm-set-exit_code_hi-to-1-when-synthesizing-svm_exit_err-failed-vmrun.patch @@ -0,0 +1,65 @@ +From f402ecd7a8b6446547076f4bd24bd5d4dcc94481 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 13 Nov 2025 14:56:14 -0800 +Subject: KVM: nSVM: Set exit_code_hi to -1 when synthesizing SVM_EXIT_ERR (failed VMRUN) +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Sean Christopherson + +commit f402ecd7a8b6446547076f4bd24bd5d4dcc94481 upstream. + +Set exit_code_hi to -1u as a temporary band-aid to fix a long-standing +(effectively since KVM's inception) bug where KVM treats the exit code as +a 32-bit value, when in reality it's a 64-bit value. Per the APM, offset +0x70 is a single 64-bit value: + + 070h 63:0 EXITCODE + +And a sane reading of the error values defined in "Table C-1. SVM Intercept +Codes" is that negative values use the full 64 bits: + + –1 VMEXIT_INVALID Invalid guest state in VMCB. + –2 VMEXIT_BUSYBUSY bit was set in the VMSA + –3 VMEXIT_IDLE_REQUIREDThe sibling thread is not in an idle state + -4 VMEXIT_INVALID_PMC Invalid PMC state + +And that interpretation is confirmed by testing on Milan and Turin (by +setting bits in CR0[63:32] to generate VMEXIT_INVALID on VMRUN). + +Furthermore, Xen has treated exitcode as a 64-bit value since HVM support +was adding in 2006 (see Xen commit d1bd157fbc ("Big merge the HVM +full-virtualisation abstractions.")). + +Cc: Jim Mattson +Cc: Yosry Ahmed +Cc: stable@vger.kernel.org +Reviewed-by: Yosry Ahmed +Link: https://patch.msgid.link/20251113225621.1688428-3-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/nested.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/svm/nested.c ++++ b/arch/x86/kvm/svm/nested.c +@@ -985,7 +985,7 @@ int nested_svm_vmrun(struct kvm_vcpu *vc + if (!nested_vmcb_check_save(vcpu) || + !nested_vmcb_check_controls(vcpu)) { + vmcb12->control.exit_code = SVM_EXIT_ERR; +- vmcb12->control.exit_code_hi = 0; ++ vmcb12->control.exit_code_hi = -1u; + vmcb12->control.exit_info_1 = 0; + vmcb12->control.exit_info_2 = 0; + goto out; +@@ -1018,7 +1018,7 @@ out_exit_err: + svm->soft_int_injected = false; + + svm->vmcb->control.exit_code = SVM_EXIT_ERR; +- svm->vmcb->control.exit_code_hi = 0; ++ svm->vmcb->control.exit_code_hi = -1u; + svm->vmcb->control.exit_info_1 = 0; + svm->vmcb->control.exit_info_2 = 0; + diff --git a/queue-6.18/kvm-nvmx-immediately-refresh-apicv-controls-as-needed-on-nested-vm-exit.patch b/queue-6.18/kvm-nvmx-immediately-refresh-apicv-controls-as-needed-on-nested-vm-exit.patch new file mode 100644 index 0000000000..c63e4037c0 --- /dev/null +++ b/queue-6.18/kvm-nvmx-immediately-refresh-apicv-controls-as-needed-on-nested-vm-exit.patch @@ -0,0 +1,73 @@ +From 29763138830916f46daaa50e83e7f4f907a3236b Mon Sep 17 00:00:00 2001 +From: Dongli Zhang +Date: Fri, 5 Dec 2025 15:19:05 -0800 +Subject: KVM: nVMX: Immediately refresh APICv controls as needed on nested VM-Exit + +From: Dongli Zhang + +commit 29763138830916f46daaa50e83e7f4f907a3236b upstream. + +If an APICv status updated was pended while L2 was active, immediately +refresh vmcs01's controls instead of pending KVM_REQ_APICV_UPDATE as +kvm_vcpu_update_apicv() only calls into vendor code if a change is +necessary. + +E.g. if APICv is inhibited, and then activated while L2 is running: + + kvm_vcpu_update_apicv() + | + -> __kvm_vcpu_update_apicv() + | + -> apic->apicv_active = true + | + -> vmx_refresh_apicv_exec_ctrl() + | + -> vmx->nested.update_vmcs01_apicv_status = true + | + -> return + +Then L2 exits to L1: + + __nested_vmx_vmexit() + | + -> kvm_make_request(KVM_REQ_APICV_UPDATE) + + vcpu_enter_guest(): KVM_REQ_APICV_UPDATE + -> kvm_vcpu_update_apicv() + | + -> __kvm_vcpu_update_apicv() + | + -> return // because if (apic->apicv_active == activate) + +Reported-by: Chao Gao +Closes: https://lore.kernel.org/all/aQ2jmnN8wUYVEawF@intel.com +Fixes: 7c69661e225c ("KVM: nVMX: Defer APICv updates while L2 is active until L1 is active") +Cc: stable@vger.kernel.org +Signed-off-by: Dongli Zhang +[sean: write changelog] +Link: https://patch.msgid.link/20251205231913.441872-3-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/vmx/nested.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/vmx/nested.c ++++ b/arch/x86/kvm/vmx/nested.c +@@ -19,6 +19,7 @@ + #include "trace.h" + #include "vmx.h" + #include "smm.h" ++#include "x86_ops.h" + + static bool __read_mostly enable_shadow_vmcs = 1; + module_param_named(enable_shadow_vmcs, enable_shadow_vmcs, bool, S_IRUGO); +@@ -5216,7 +5217,7 @@ void __nested_vmx_vmexit(struct kvm_vcpu + + if (vmx->nested.update_vmcs01_apicv_status) { + vmx->nested.update_vmcs01_apicv_status = false; +- kvm_make_request(KVM_REQ_APICV_UPDATE, vcpu); ++ vmx_refresh_apicv_exec_ctrl(vcpu); + } + + if (vmx->nested.update_vmcs01_hwapic_isr) { diff --git a/queue-6.18/kvm-selftests-add-missing-break-in-rseq_test-s-param-parsing.patch b/queue-6.18/kvm-selftests-add-missing-break-in-rseq_test-s-param-parsing.patch new file mode 100644 index 0000000000..150cd6109f --- /dev/null +++ b/queue-6.18/kvm-selftests-add-missing-break-in-rseq_test-s-param-parsing.patch @@ -0,0 +1,43 @@ +From 1b9439c933b500cb24710bbd81fe56e9b0025b6f Mon Sep 17 00:00:00 2001 +From: Gavin Shan +Date: Mon, 24 Nov 2025 15:04:27 +1000 +Subject: KVM: selftests: Add missing "break" in rseq_test's param parsing + +From: Gavin Shan + +commit 1b9439c933b500cb24710bbd81fe56e9b0025b6f upstream. + +In commit 0297cdc12a87 ("KVM: selftests: Add option to rseq test to +override /dev/cpu_dma_latency"), a 'break' is missed before the option +'l' in the argument parsing loop, which leads to an unexpected core +dump in atoi_paranoid(). It tries to get the latency from non-existent +argument. + + host$ ./rseq_test -u + Random seed: 0x6b8b4567 + Segmentation fault (core dumped) + +Add a 'break' before the option 'l' in the argument parsing loop to avoid +the unexpected core dump. + +Fixes: 0297cdc12a87 ("KVM: selftests: Add option to rseq test to override /dev/cpu_dma_latency") +Cc: stable@vger.kernel.org # v6.15+ +Signed-off-by: Gavin Shan +Link: https://patch.msgid.link/20251124050427.1924591-1-gshan@redhat.com +[sean: describe code change in shortlog] +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/kvm/rseq_test.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/tools/testing/selftests/kvm/rseq_test.c ++++ b/tools/testing/selftests/kvm/rseq_test.c +@@ -215,6 +215,7 @@ int main(int argc, char *argv[]) + switch (opt) { + case 'u': + skip_sanity_check = true; ++ break; + case 'l': + latency = atoi_paranoid(optarg); + break; diff --git a/queue-6.18/kvm-selftests-forcefully-override-arch-from-x86_64-to-x86.patch b/queue-6.18/kvm-selftests-forcefully-override-arch-from-x86_64-to-x86.patch new file mode 100644 index 0000000000..d79d825e04 --- /dev/null +++ b/queue-6.18/kvm-selftests-forcefully-override-arch-from-x86_64-to-x86.patch @@ -0,0 +1,34 @@ +From 17e5a9b77716564540d81f0c1e6082d28cf305c9 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 7 Oct 2025 15:30:57 -0700 +Subject: KVM: selftests: Forcefully override ARCH from x86_64 to x86 + +From: Sean Christopherson + +commit 17e5a9b77716564540d81f0c1e6082d28cf305c9 upstream. + +Forcefully override ARCH from x86_64 to x86 to handle the scenario where +the user specifies ARCH=x86_64 on the command line. + +Fixes: 9af04539d474 ("KVM: selftests: Override ARCH for x86_64 instead of using ARCH_DIR") +Cc: stable@vger.kernel.org +Reported-by: David Matlack +Closes: https://lore.kernel.org/all/20250724213130.3374922-1-dmatlack@google.com +Link: https://lore.kernel.org/r/20251007223057.368082-1-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/kvm/Makefile | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/testing/selftests/kvm/Makefile ++++ b/tools/testing/selftests/kvm/Makefile +@@ -6,7 +6,7 @@ ARCH ?= $(SUBARCH) + ifeq ($(ARCH),$(filter $(ARCH),arm64 s390 riscv x86 x86_64 loongarch)) + # Top-level selftests allows ARCH=x86_64 :-( + ifeq ($(ARCH),x86_64) +- ARCH := x86 ++ override ARCH := x86 + endif + include Makefile.kvm + else diff --git a/queue-6.18/kvm-svm-mark-vmcb_npt-as-dirty-on-nested-vmrun.patch b/queue-6.18/kvm-svm-mark-vmcb_npt-as-dirty-on-nested-vmrun.patch new file mode 100644 index 0000000000..91dd8cc5fb --- /dev/null +++ b/queue-6.18/kvm-svm-mark-vmcb_npt-as-dirty-on-nested-vmrun.patch @@ -0,0 +1,36 @@ +From 7c8b465a1c91f674655ea9cec5083744ec5f796a Mon Sep 17 00:00:00 2001 +From: Jim Mattson +Date: Mon, 22 Sep 2025 09:29:23 -0700 +Subject: KVM: SVM: Mark VMCB_NPT as dirty on nested VMRUN + +From: Jim Mattson + +commit 7c8b465a1c91f674655ea9cec5083744ec5f796a upstream. + +Mark the VMCB_NPT bit as dirty in nested_vmcb02_prepare_save() +on every nested VMRUN. + +If L1 changes the PAT MSR between two VMRUN instructions on the same +L1 vCPU, the g_pat field in the associated vmcb02 will change, and the +VMCB_NPT clean bit should be cleared. + +Fixes: 4bb170a5430b ("KVM: nSVM: do not mark all VMCB02 fields dirty on nested vmexit") +Cc: stable@vger.kernel.org +Signed-off-by: Jim Mattson +Link: https://lore.kernel.org/r/20250922162935.621409-3-jmattson@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/nested.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/kvm/svm/nested.c ++++ b/arch/x86/kvm/svm/nested.c +@@ -613,6 +613,7 @@ static void nested_vmcb02_prepare_save(s + struct kvm_vcpu *vcpu = &svm->vcpu; + + nested_vmcb02_compute_g_pat(svm); ++ vmcb_mark_dirty(vmcb02, VMCB_NPT); + + /* Load the nested guest state */ + if (svm->nested.vmcb12_gpa != svm->nested.last_vmcb12_gpa) { diff --git a/queue-6.18/kvm-svm-mark-vmcb_perm_map-as-dirty-on-nested-vmrun.patch b/queue-6.18/kvm-svm-mark-vmcb_perm_map-as-dirty-on-nested-vmrun.patch new file mode 100644 index 0000000000..1de1afb72f --- /dev/null +++ b/queue-6.18/kvm-svm-mark-vmcb_perm_map-as-dirty-on-nested-vmrun.patch @@ -0,0 +1,37 @@ +From 93c9e107386dbe1243287a5b14ceca894de372b9 Mon Sep 17 00:00:00 2001 +From: Jim Mattson +Date: Mon, 22 Sep 2025 09:29:22 -0700 +Subject: KVM: SVM: Mark VMCB_PERM_MAP as dirty on nested VMRUN + +From: Jim Mattson + +commit 93c9e107386dbe1243287a5b14ceca894de372b9 upstream. + +Mark the VMCB_PERM_MAP bit as dirty in nested_vmcb02_prepare_control() +on every nested VMRUN. + +If L1 changes MSR interception (INTERCEPT_MSR_PROT) between two VMRUN +instructions on the same L1 vCPU, the msrpm_base_pa in the associated +vmcb02 will change, and the VMCB_PERM_MAP clean bit should be cleared. + +Fixes: 4bb170a5430b ("KVM: nSVM: do not mark all VMCB02 fields dirty on nested vmexit") +Reported-by: Matteo Rizzo +Cc: stable@vger.kernel.org +Signed-off-by: Jim Mattson +Link: https://lore.kernel.org/r/20250922162935.621409-2-jmattson@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/nested.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/kvm/svm/nested.c ++++ b/arch/x86/kvm/svm/nested.c +@@ -752,6 +752,7 @@ static void nested_vmcb02_prepare_contro + vmcb02->control.nested_ctl = vmcb01->control.nested_ctl; + vmcb02->control.iopm_base_pa = vmcb01->control.iopm_base_pa; + vmcb02->control.msrpm_base_pa = vmcb01->control.msrpm_base_pa; ++ vmcb_mark_dirty(vmcb02, VMCB_PERM_MAP); + + /* + * Stash vmcb02's counter if the guest hasn't moved past the guilty diff --git a/queue-6.18/kvm-tdx-explicitly-set-user-return-msrs-that-may-be-clobbered-by-the-tdx-module.patch b/queue-6.18/kvm-tdx-explicitly-set-user-return-msrs-that-may-be-clobbered-by-the-tdx-module.patch new file mode 100644 index 0000000000..1fc05b0881 --- /dev/null +++ b/queue-6.18/kvm-tdx-explicitly-set-user-return-msrs-that-may-be-clobbered-by-the-tdx-module.patch @@ -0,0 +1,189 @@ +From c0711f8c610e1634ed54fb04da1e82252730306a Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 30 Oct 2025 12:15:25 -0700 +Subject: KVM: TDX: Explicitly set user-return MSRs that *may* be clobbered by the TDX-Module + +From: Sean Christopherson + +commit c0711f8c610e1634ed54fb04da1e82252730306a upstream. + +Set all user-return MSRs to their post-TD-exit value when preparing to run +a TDX vCPU to ensure the value that KVM expects to be loaded after running +the vCPU is indeed the value that's loaded in hardware. If the TDX-Module +doesn't actually enter the guest, i.e. doesn't do VM-Enter, then it won't +"restore" VMM state, i.e. won't clobber user-return MSRs to their expected +post-run values, in which case simply updating KVM's "cached" value will +effectively corrupt the cache due to hardware still holding the original +value. + +In theory, KVM could conditionally update the current user-return value if +and only if tdh_vp_enter() succeeds, but in practice "success" doesn't +guarantee the TDX-Module actually entered the guest, e.g. if the TDX-Module +synthesizes an EPT Violation because it suspects a zero-step attack. + +Force-load the expected values instead of trying to decipher whether or +not the TDX-Module restored/clobbered MSRs, as the risk doesn't justify +the benefits. Effectively avoiding four WRMSRs once per run loop (even if +the vCPU is scheduled out, user-return MSRs only need to be reloaded if +the CPU exits to userspace or runs a non-TDX vCPU) is likely in the noise +when amortized over all entries, given the cost of running a TDX vCPU. +E.g. the cost of the WRMSRs is somewhere between ~300 and ~500 cycles, +whereas the cost of a _single_ roundtrip to/from a TDX guest is thousands +of cycles. + +Fixes: e0b4f31a3c65 ("KVM: TDX: restore user ret MSRs") +Cc: stable@vger.kernel.org +Cc: Yan Zhao +Cc: Xiaoyao Li +Cc: Rick Edgecombe +Reviewed-by: Xiaoyao Li +Link: https://patch.msgid.link/20251030191528.3380553-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/vmx/tdx.c | 56 ++++++++++++++++------------------------ + arch/x86/kvm/vmx/tdx.h | 1 + arch/x86/kvm/x86.c | 9 ------ + 4 files changed, 23 insertions(+), 44 deletions(-) + +--- a/arch/x86/include/asm/kvm_host.h ++++ b/arch/x86/include/asm/kvm_host.h +@@ -2387,7 +2387,6 @@ int kvm_pv_send_ipi(struct kvm *kvm, uns + int kvm_add_user_return_msr(u32 msr); + int kvm_find_user_return_msr(u32 msr); + int kvm_set_user_return_msr(unsigned index, u64 val, u64 mask); +-void kvm_user_return_msr_update_cache(unsigned int index, u64 val); + u64 kvm_get_user_return_msr(unsigned int slot); + + static inline bool kvm_is_supported_user_return_msr(u32 msr) +--- a/arch/x86/kvm/vmx/tdx.c ++++ b/arch/x86/kvm/vmx/tdx.c +@@ -763,25 +763,6 @@ static bool tdx_protected_apic_has_inter + return tdx_vcpu_state_details_intr_pending(vcpu_state_details); + } + +-/* +- * Compared to vmx_prepare_switch_to_guest(), there is not much to do +- * as SEAMCALL/SEAMRET calls take care of most of save and restore. +- */ +-void tdx_prepare_switch_to_guest(struct kvm_vcpu *vcpu) +-{ +- struct vcpu_vt *vt = to_vt(vcpu); +- +- if (vt->guest_state_loaded) +- return; +- +- if (likely(is_64bit_mm(current->mm))) +- vt->msr_host_kernel_gs_base = current->thread.gsbase; +- else +- vt->msr_host_kernel_gs_base = read_msr(MSR_KERNEL_GS_BASE); +- +- vt->guest_state_loaded = true; +-} +- + struct tdx_uret_msr { + u32 msr; + unsigned int slot; +@@ -795,19 +776,38 @@ static struct tdx_uret_msr tdx_uret_msrs + {.msr = MSR_TSC_AUX,}, + }; + +-static void tdx_user_return_msr_update_cache(void) ++void tdx_prepare_switch_to_guest(struct kvm_vcpu *vcpu) + { ++ struct vcpu_vt *vt = to_vt(vcpu); + int i; + ++ if (vt->guest_state_loaded) ++ return; ++ ++ if (likely(is_64bit_mm(current->mm))) ++ vt->msr_host_kernel_gs_base = current->thread.gsbase; ++ else ++ vt->msr_host_kernel_gs_base = read_msr(MSR_KERNEL_GS_BASE); ++ ++ vt->guest_state_loaded = true; ++ ++ /* ++ * Explicitly set user-return MSRs that are clobbered by the TDX-Module ++ * if VP.ENTER succeeds, i.e. on TD-Exit, with the values that would be ++ * written by the TDX-Module. Don't rely on the TDX-Module to actually ++ * clobber the MSRs, as the contract is poorly defined and not upheld. ++ * E.g. the TDX-Module will synthesize an EPT Violation without doing ++ * VM-Enter if it suspects a zero-step attack, and never "restore" VMM ++ * state. ++ */ + for (i = 0; i < ARRAY_SIZE(tdx_uret_msrs); i++) +- kvm_user_return_msr_update_cache(tdx_uret_msrs[i].slot, +- tdx_uret_msrs[i].defval); ++ kvm_set_user_return_msr(tdx_uret_msrs[i].slot, ++ tdx_uret_msrs[i].defval, -1ull); + } + + static void tdx_prepare_switch_to_host(struct kvm_vcpu *vcpu) + { + struct vcpu_vt *vt = to_vt(vcpu); +- struct vcpu_tdx *tdx = to_tdx(vcpu); + + if (!vt->guest_state_loaded) + return; +@@ -815,11 +815,6 @@ static void tdx_prepare_switch_to_host(s + ++vcpu->stat.host_state_reload; + wrmsrl(MSR_KERNEL_GS_BASE, vt->msr_host_kernel_gs_base); + +- if (tdx->guest_entered) { +- tdx_user_return_msr_update_cache(); +- tdx->guest_entered = false; +- } +- + vt->guest_state_loaded = false; + } + +@@ -1059,7 +1054,6 @@ fastpath_t tdx_vcpu_run(struct kvm_vcpu + update_debugctlmsr(vcpu->arch.host_debugctl); + + tdx_load_host_xsave_state(vcpu); +- tdx->guest_entered = true; + + vcpu->arch.regs_avail &= TDX_REGS_AVAIL_SET; + +@@ -3447,10 +3441,6 @@ static int __init __tdx_bringup(void) + /* + * Check if MSRs (tdx_uret_msrs) can be saved/restored + * before returning to user space. +- * +- * this_cpu_ptr(user_return_msrs)->registered isn't checked +- * because the registration is done at vcpu runtime by +- * tdx_user_return_msr_update_cache(). + */ + tdx_uret_msrs[i].slot = kvm_find_user_return_msr(tdx_uret_msrs[i].msr); + if (tdx_uret_msrs[i].slot == -1) { +--- a/arch/x86/kvm/vmx/tdx.h ++++ b/arch/x86/kvm/vmx/tdx.h +@@ -67,7 +67,6 @@ struct vcpu_tdx { + u64 vp_enter_ret; + + enum vcpu_tdx_state state; +- bool guest_entered; + + u64 map_gpa_next; + u64 map_gpa_end; +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -681,15 +681,6 @@ int kvm_set_user_return_msr(unsigned slo + } + EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_set_user_return_msr); + +-void kvm_user_return_msr_update_cache(unsigned int slot, u64 value) +-{ +- struct kvm_user_return_msrs *msrs = this_cpu_ptr(user_return_msrs); +- +- msrs->values[slot].curr = value; +- kvm_user_return_register_notifier(msrs); +-} +-EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_user_return_msr_update_cache); +- + u64 kvm_get_user_return_msr(unsigned int slot) + { + return this_cpu_ptr(user_return_msrs)->values[slot].curr; diff --git a/queue-6.18/kvm-x86-apply-runtime-updates-to-current-cpuid-during-kvm_set_cpuid-2.patch b/queue-6.18/kvm-x86-apply-runtime-updates-to-current-cpuid-during-kvm_set_cpuid-2.patch new file mode 100644 index 0000000000..17616f7b7a --- /dev/null +++ b/queue-6.18/kvm-x86-apply-runtime-updates-to-current-cpuid-during-kvm_set_cpuid-2.patch @@ -0,0 +1,53 @@ +From e2b43fb25243d502ad36b07bab9de09f4b76fff9 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Mon, 1 Dec 2025 17:50:48 -0800 +Subject: KVM: x86: Apply runtime updates to current CPUID during KVM_SET_CPUID{,2} + +From: Sean Christopherson + +commit e2b43fb25243d502ad36b07bab9de09f4b76fff9 upstream. + +When handling KVM_SET_CPUID{,2}, do runtime CPUID updates on the vCPU's +current CPUID (and caps) prior to swapping in the incoming CPUID state so +that KVM doesn't lose pending updates if the incoming CPUID is rejected, +and to prevent a false failure on the equality check. + +Note, runtime updates are unconditionally performed on the incoming/new +CPUID (and associated caps), i.e. clearing the dirty flag won't negatively +affect the new CPUID. + +Fixes: 93da6af3ae56 ("KVM: x86: Defer runtime updates of dynamic CPUID bits until CPUID emulation") +Reported-by: Igor Mammedov +Closes: https://lore.kernel.org/all/20251128123202.68424a95@imammedo +Cc: stable@vger.kernel.org +Acked-by: Igor Mammedov +Tested-by: Igor Mammedov +Link: https://patch.msgid.link/20251202015049.1167490-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/cpuid.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/cpuid.c ++++ b/arch/x86/kvm/cpuid.c +@@ -510,10 +510,17 @@ static int kvm_set_cpuid(struct kvm_vcpu + int r; + + /* ++ * Apply pending runtime CPUID updates to the current CPUID entries to ++ * avoid false positives due to mismatches on KVM-owned feature flags. ++ */ ++ if (vcpu->arch.cpuid_dynamic_bits_dirty) ++ kvm_update_cpuid_runtime(vcpu); ++ ++ /* + * Swap the existing (old) entries with the incoming (new) entries in + * order to massage the new entries, e.g. to account for dynamic bits +- * that KVM controls, without clobbering the current guest CPUID, which +- * KVM needs to preserve in order to unwind on failure. ++ * that KVM controls, without losing the current guest CPUID, which KVM ++ * needs to preserve in order to unwind on failure. + * + * Similarly, save the vCPU's current cpu_caps so that the capabilities + * can be updated alongside the CPUID entries when performing runtime diff --git a/queue-6.18/kvm-x86-don-t-clear-async-pf-queue-when-cr0.pg-is-disabled-e.g.-on-smi.patch b/queue-6.18/kvm-x86-don-t-clear-async-pf-queue-when-cr0.pg-is-disabled-e.g.-on-smi.patch new file mode 100644 index 0000000000..a415cb5f70 --- /dev/null +++ b/queue-6.18/kvm-x86-don-t-clear-async-pf-queue-when-cr0.pg-is-disabled-e.g.-on-smi.patch @@ -0,0 +1,105 @@ +From ab4e41eb9fabd4607304fa7cfe8ec9c0bd8e1552 Mon Sep 17 00:00:00 2001 +From: Maxim Levitsky +Date: Tue, 14 Oct 2025 23:32:58 -0400 +Subject: KVM: x86: Don't clear async #PF queue when CR0.PG is disabled (e.g. on #SMI) + +From: Maxim Levitsky + +commit ab4e41eb9fabd4607304fa7cfe8ec9c0bd8e1552 upstream. + +Fix an interaction between SMM and PV asynchronous #PFs where an #SMI can +cause KVM to drop an async #PF ready event, and thus result in guest tasks +becoming permanently stuck due to the task that encountered the #PF never +being resumed. Specifically, don't clear the completion queue when paging +is disabled, and re-check for completed async #PFs if/when paging is +enabled. + +Prior to commit 2635b5c4a0e4 ("KVM: x86: interrupt based APF 'page ready' +event delivery"), flushing the APF queue without notifying the guest of +completed APF requests when paging is disabled was "necessary", in that +delivering a #PF to the guest when paging is disabled would likely confuse +and/or crash the guest. And presumably the original async #PF development +assumed that a guest would only disable paging when there was no intent to +ever re-enable paging. + +That assumption fails in several scenarios, most visibly on an emulated +SMI, as entering SMM always disables CR0.PG (i.e. initially runs with +paging disabled). When the SMM handler eventually executes RSM, the +interrupted paging-enabled is restored, and the async #PF event is lost. + +Similarly, invoking firmware, e.g. via EFI runtime calls, might require a +transition through paging modes and thus also disable paging with valid +entries in the competion queue. + +To avoid dropping completion events, drop the "clear" entirely, and handle +paging-enable transitions in the same way KVM already handles APIC +enable/disable events: if a vCPU's APIC is disabled, APF completion events +are not kept pending and not injected while APIC is disabled. Once a +vCPU's APIC is re-enabled, KVM raises KVM_REQ_APF_READY so that the vCPU +recognizes any pending pending #APF ready events. + +Signed-off-by: Maxim Levitsky +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20251015033258.50974-4-mlevitsk@redhat.com +[sean: rework changelog to call out #PF injection, drop "real mode" + references, expand the code comment] +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/x86.c | 25 +++++++++++++++---------- + 1 file changed, 15 insertions(+), 10 deletions(-) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -1045,6 +1045,13 @@ bool kvm_require_dr(struct kvm_vcpu *vcp + } + EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_require_dr); + ++static bool kvm_pv_async_pf_enabled(struct kvm_vcpu *vcpu) ++{ ++ u64 mask = KVM_ASYNC_PF_ENABLED | KVM_ASYNC_PF_DELIVERY_AS_INT; ++ ++ return (vcpu->arch.apf.msr_en_val & mask) == mask; ++} ++ + static inline u64 pdptr_rsvd_bits(struct kvm_vcpu *vcpu) + { + return vcpu->arch.reserved_gpa_bits | rsvd_bits(5, 8) | rsvd_bits(1, 2); +@@ -1137,15 +1144,20 @@ void kvm_post_set_cr0(struct kvm_vcpu *v + } + + if ((cr0 ^ old_cr0) & X86_CR0_PG) { +- kvm_clear_async_pf_completion_queue(vcpu); +- kvm_async_pf_hash_reset(vcpu); +- + /* + * Clearing CR0.PG is defined to flush the TLB from the guest's + * perspective. + */ + if (!(cr0 & X86_CR0_PG)) + kvm_make_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu); ++ /* ++ * Check for async #PF completion events when enabling paging, ++ * as the vCPU may have previously encountered async #PFs (it's ++ * entirely legal for the guest to toggle paging on/off without ++ * waiting for the async #PF queue to drain). ++ */ ++ else if (kvm_pv_async_pf_enabled(vcpu)) ++ kvm_make_request(KVM_REQ_APF_READY, vcpu); + } + + if ((cr0 ^ old_cr0) & KVM_MMU_CR0_ROLE_BITS) +@@ -3650,13 +3662,6 @@ static int set_msr_mce(struct kvm_vcpu * + return 0; + } + +-static inline bool kvm_pv_async_pf_enabled(struct kvm_vcpu *vcpu) +-{ +- u64 mask = KVM_ASYNC_PF_ENABLED | KVM_ASYNC_PF_DELIVERY_AS_INT; +- +- return (vcpu->arch.apf.msr_en_val & mask) == mask; +-} +- + static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data) + { + gpa_t gpa = data & ~0x3f; diff --git a/queue-6.18/kvm-x86-explicitly-set-new-periodic-hrtimer-expiration-in-apic_timer_fn.patch b/queue-6.18/kvm-x86-explicitly-set-new-periodic-hrtimer-expiration-in-apic_timer_fn.patch new file mode 100644 index 0000000000..0e60e9df6a --- /dev/null +++ b/queue-6.18/kvm-x86-explicitly-set-new-periodic-hrtimer-expiration-in-apic_timer_fn.patch @@ -0,0 +1,38 @@ +From 9633f180ce994ab293ce4924a9b7aaf4673aa114 Mon Sep 17 00:00:00 2001 +From: fuqiang wang +Date: Thu, 13 Nov 2025 12:51:12 -0800 +Subject: KVM: x86: Explicitly set new periodic hrtimer expiration in apic_timer_fn() + +From: fuqiang wang + +commit 9633f180ce994ab293ce4924a9b7aaf4673aa114 upstream. + +When restarting an hrtimer to emulate a the guest's APIC timer in periodic +mode, explicitly set the expiration using the target expiration computed +by advance_periodic_target_expiration() instead of adding the period to +the existing timer. This will allow making adjustments to the expiration, +e.g. to deal with expirations far in the past, without having to implement +the same logic in both advance_periodic_target_expiration() and +apic_timer_fn(). + +Cc: stable@vger.kernel.org +Signed-off-by: fuqiang wang +[sean: split to separate patch, write changelog] +Link: https://patch.msgid.link/20251113205114.1647493-3-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/lapic.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -2972,7 +2972,7 @@ static enum hrtimer_restart apic_timer_f + + if (lapic_is_periodic(apic) && !WARN_ON_ONCE(!apic->lapic_timer.period)) { + advance_periodic_target_expiration(apic); +- hrtimer_add_expires_ns(&ktimer->timer, ktimer->period); ++ hrtimer_set_expires(&ktimer->timer, ktimer->target_expiration); + return HRTIMER_RESTART; + } else + return HRTIMER_NORESTART; diff --git a/queue-6.18/kvm-x86-fix-vm-hard-lockup-after-prolonged-inactivity-with-periodic-hv-timer.patch b/queue-6.18/kvm-x86-fix-vm-hard-lockup-after-prolonged-inactivity-with-periodic-hv-timer.patch new file mode 100644 index 0000000000..e18a15d735 --- /dev/null +++ b/queue-6.18/kvm-x86-fix-vm-hard-lockup-after-prolonged-inactivity-with-periodic-hv-timer.patch @@ -0,0 +1,134 @@ +From 18ab3fc8e880791aa9f7c000261320fc812b5465 Mon Sep 17 00:00:00 2001 +From: fuqiang wang +Date: Thu, 13 Nov 2025 12:51:13 -0800 +Subject: KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer + +From: fuqiang wang + +commit 18ab3fc8e880791aa9f7c000261320fc812b5465 upstream. + +When advancing the target expiration for the guest's APIC timer in periodic +mode, set the expiration to "now" if the target expiration is in the past +(similar to what is done in update_target_expiration()). Blindly adding +the period to the previous target expiration can result in KVM generating +a practically unbounded number of hrtimer IRQs due to programming an +expired timer over and over. In extreme scenarios, e.g. if userspace +pauses/suspends a VM for an extended duration, this can even cause hard +lockups in the host. + +Currently, the bug only affects Intel CPUs when using the hypervisor timer +(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, +a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the +HV timer only runs while the guest is active. As a result, if the vCPU +does not run for an extended duration, there will be a huge gap between +the target expiration and the current time the vCPU resumes running. +Because the target expiration is incremented by only one period on each +timer expiration, this leads to a series of timer expirations occurring +rapidly after the vCPU/VM resumes. + +More critically, when the vCPU first triggers a periodic HV timer +expiration after resuming, advancing the expiration by only one period +will result in a target expiration in the past. As a result, the delta +may be calculated as a negative value. When the delta is converted into +an absolute value (tscdeadline is an unsigned u64), the resulting value +can overflow what the HV timer is capable of programming. I.e. the large +value will exceed the VMX Preemption Timer's maximum bit width of +cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the +HV timer to the software timer (hrtimers). + +After switching to the software timer, periodic timer expiration callbacks +may be executed consecutively within a single clock interrupt handler, +because hrtimers honors KVM's request for an expiration in the past and +immediately re-invokes KVM's callback after reprogramming. And because +the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer +over and over until the target expiration is advanced to "now" can result +in a hard lockup. + +E.g. the following hard lockup was triggered in the host when running a +Windows VM (only relevant because it used the APIC timer in periodic mode) +after resuming the VM from a long suspend (in the host). + + NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 + ... + RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] + ... + RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 + RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc + RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 + RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 + R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 + R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 + FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 + PKRU: 55555554 + Call Trace: + + apic_timer_fn+0x31/0x50 [kvm] + __hrtimer_run_queues+0x100/0x280 + hrtimer_interrupt+0x100/0x210 + ? ttwu_do_wakeup+0x19/0x160 + smp_apic_timer_interrupt+0x6a/0x130 + apic_timer_interrupt+0xf/0x20 + + +Moreover, if the suspend duration of the virtual machine is not long enough +to trigger a hard lockup in this scenario, since commit 98c25ead5eda +("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM +will continue using the software timer until the guest reprograms the APIC +timer in some way. Since the periodic timer does not require frequent APIC +timer register programming, the guest may continue to use the software +timer in perpetuity. + +Fixes: d8f2f498d9ed ("x86/kvm: fix LAPIC timer drift when guest uses periodic mode") +Cc: stable@vger.kernel.org +Signed-off-by: fuqiang wang +[sean: massage comments and changelog] +Link: https://patch.msgid.link/20251113205114.1647493-4-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/lapic.c | 28 +++++++++++++++++++++++----- + 1 file changed, 23 insertions(+), 5 deletions(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -2131,15 +2131,33 @@ static void advance_periodic_target_expi + ktime_t delta; + + /* +- * Synchronize both deadlines to the same time source or +- * differences in the periods (caused by differences in the +- * underlying clocks or numerical approximation errors) will +- * cause the two to drift apart over time as the errors +- * accumulate. ++ * Use kernel time as the time source for both the hrtimer deadline and ++ * TSC-based deadline so that they stay synchronized. Computing each ++ * deadline independently will cause the two deadlines to drift apart ++ * over time as differences in the periods accumulate, e.g. due to ++ * differences in the underlying clocks or numerical approximation errors. + */ + apic->lapic_timer.target_expiration = + ktime_add_ns(apic->lapic_timer.target_expiration, + apic->lapic_timer.period); ++ ++ /* ++ * If the new expiration is in the past, e.g. because userspace stopped ++ * running the VM for an extended duration, then force the expiration ++ * to "now" and don't try to play catch-up with the missed events. KVM ++ * will only deliver a single interrupt regardless of how many events ++ * are pending, i.e. restarting the timer with an expiration in the ++ * past will do nothing more than waste host cycles, and can even lead ++ * to a hard lockup in extreme cases. ++ */ ++ if (ktime_before(apic->lapic_timer.target_expiration, now)) ++ apic->lapic_timer.target_expiration = now; ++ ++ /* ++ * Note, ensuring the expiration isn't in the past also prevents delta ++ * from going negative, which could cause the TSC deadline to become ++ * excessively large due to it an unsigned value. ++ */ + delta = ktime_sub(apic->lapic_timer.target_expiration, now); + apic->lapic_timer.tscdeadline = kvm_read_l1_tsc(apic->vcpu, tscl) + + nsec_to_cycles(apic->vcpu, delta); diff --git a/queue-6.18/kvm-x86-warn-if-hrtimer-callback-for-periodic-apic-timer-fires-with-period-0.patch b/queue-6.18/kvm-x86-warn-if-hrtimer-callback-for-periodic-apic-timer-fires-with-period-0.patch new file mode 100644 index 0000000000..2492e4d866 --- /dev/null +++ b/queue-6.18/kvm-x86-warn-if-hrtimer-callback-for-periodic-apic-timer-fires-with-period-0.patch @@ -0,0 +1,36 @@ +From 0ea9494be9c931ddbc084ad5e11fda91b554cf47 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 13 Nov 2025 12:51:11 -0800 +Subject: KVM: x86: WARN if hrtimer callback for periodic APIC timer fires with period=0 + +From: Sean Christopherson + +commit 0ea9494be9c931ddbc084ad5e11fda91b554cf47 upstream. + +WARN and don't restart the hrtimer if KVM's callback runs with the guest's +APIC timer in periodic mode but with a period of '0', as not advancing the +hrtimer's deadline would put the CPU into an infinite loop of hrtimer +events. Observing a period of '0' should be impossible, even when the +hrtimer is running on a different CPU than the vCPU, as KVM is supposed to +cancel the hrtimer before changing (or zeroing) the period, e.g. when +switching from periodic to one-shot. + +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20251113205114.1647493-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/lapic.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -2970,7 +2970,7 @@ static enum hrtimer_restart apic_timer_f + + apic_timer_expired(apic, true); + +- if (lapic_is_periodic(apic)) { ++ if (lapic_is_periodic(apic) && !WARN_ON_ONCE(!apic->lapic_timer.period)) { + advance_periodic_target_expiration(apic); + hrtimer_add_expires_ns(&ktimer->timer, ktimer->period); + return HRTIMER_RESTART; diff --git a/queue-6.18/lib-crypto-riscv-add-poly1305-core.s-to-.gitignore.patch b/queue-6.18/lib-crypto-riscv-add-poly1305-core.s-to-.gitignore.patch new file mode 100644 index 0000000000..544b068a5c --- /dev/null +++ b/queue-6.18/lib-crypto-riscv-add-poly1305-core.s-to-.gitignore.patch @@ -0,0 +1,33 @@ +From 5a0b1882506858b12cc77f0e2439a5f3c5052761 Mon Sep 17 00:00:00 2001 +From: Charles Mirabile +Date: Fri, 12 Dec 2025 13:47:17 -0500 +Subject: lib/crypto: riscv: Add poly1305-core.S to .gitignore + +From: Charles Mirabile + +commit 5a0b1882506858b12cc77f0e2439a5f3c5052761 upstream. + +poly1305-core.S is an auto-generated file, so it should be ignored. + +Fixes: bef9c7559869 ("lib/crypto: riscv/poly1305: Import OpenSSL/CRYPTOGAMS implementation") +Cc: stable@vger.kernel.org +Signed-off-by: Charles Mirabile +Link: https://lore.kernel.org/r/20251212184717.133701-1-cmirabil@redhat.com +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + lib/crypto/riscv/.gitignore | 2 ++ + 1 file changed, 2 insertions(+) + create mode 100644 lib/crypto/riscv/.gitignore + +diff --git a/lib/crypto/riscv/.gitignore b/lib/crypto/riscv/.gitignore +new file mode 100644 +index 000000000000..0d47d4f21c6d +--- /dev/null ++++ b/lib/crypto/riscv/.gitignore +@@ -0,0 +1,2 @@ ++# SPDX-License-Identifier: GPL-2.0-only ++poly1305-core.S +-- +2.52.0 + diff --git a/queue-6.18/lib-crypto-riscv-chacha-avoid-s0-fp-register.patch b/queue-6.18/lib-crypto-riscv-chacha-avoid-s0-fp-register.patch new file mode 100644 index 0000000000..0849020c28 --- /dev/null +++ b/queue-6.18/lib-crypto-riscv-chacha-avoid-s0-fp-register.patch @@ -0,0 +1,54 @@ +From 43169328c7b4623b54b7713ec68479cebda5465f Mon Sep 17 00:00:00 2001 +From: Vivian Wang +Date: Tue, 2 Dec 2025 13:25:07 +0800 +Subject: lib/crypto: riscv/chacha: Avoid s0/fp register + +From: Vivian Wang + +commit 43169328c7b4623b54b7713ec68479cebda5465f upstream. + +In chacha_zvkb, avoid using the s0 register, which is the frame pointer, +by reallocating KEY0 to t5. This makes stack traces available if e.g. a +crash happens in chacha_zvkb. + +No frame pointer maintenance is otherwise required since this is a leaf +function. + +Signed-off-by: Vivian Wang +Fixes: bb54668837a0 ("crypto: riscv - add vector crypto accelerated ChaCha20") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20251202-riscv-chacha_zvkb-fp-v2-1-7bd00098c9dc@iscas.ac.cn +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + lib/crypto/riscv/chacha-riscv64-zvkb.S | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/lib/crypto/riscv/chacha-riscv64-zvkb.S ++++ b/lib/crypto/riscv/chacha-riscv64-zvkb.S +@@ -60,7 +60,8 @@ + #define VL t2 + #define STRIDE t3 + #define ROUND_CTR t4 +-#define KEY0 s0 ++#define KEY0 t5 ++// Avoid s0/fp to allow for unwinding + #define KEY1 s1 + #define KEY2 s2 + #define KEY3 s3 +@@ -143,7 +144,6 @@ + // The updated 32-bit counter is written back to state->x[12] before returning. + SYM_FUNC_START(chacha_zvkb) + addi sp, sp, -96 +- sd s0, 0(sp) + sd s1, 8(sp) + sd s2, 16(sp) + sd s3, 24(sp) +@@ -280,7 +280,6 @@ SYM_FUNC_START(chacha_zvkb) + bnez NBLOCKS, .Lblock_loop + + sw COUNTER, 48(STATEP) +- ld s0, 0(sp) + ld s1, 8(sp) + ld s2, 16(sp) + ld s3, 24(sp) diff --git a/queue-6.18/libceph-make-decode_pool-more-resilient-against-corrupted-osdmaps.patch b/queue-6.18/libceph-make-decode_pool-more-resilient-against-corrupted-osdmaps.patch new file mode 100644 index 0000000000..6948c58083 --- /dev/null +++ b/queue-6.18/libceph-make-decode_pool-more-resilient-against-corrupted-osdmaps.patch @@ -0,0 +1,221 @@ +From 8c738512714e8c0aa18f8a10c072d5b01c83db39 Mon Sep 17 00:00:00 2001 +From: Ilya Dryomov +Date: Tue, 2 Dec 2025 10:32:31 +0100 +Subject: libceph: make decode_pool() more resilient against corrupted osdmaps + +From: Ilya Dryomov + +commit 8c738512714e8c0aa18f8a10c072d5b01c83db39 upstream. + +If the osdmap is (maliciously) corrupted such that the encoded length +of ceph_pg_pool envelope is less than what is expected for a particular +encoding version, out-of-bounds reads may ensue because the only bounds +check that is there is based on that length value. + +This patch adds explicit bounds checks for each field that is decoded +or skipped. + +Cc: stable@vger.kernel.org +Reported-by: ziming zhang +Signed-off-by: Ilya Dryomov +Reviewed-by: Xiubo Li +Tested-by: ziming zhang +Signed-off-by: Greg Kroah-Hartman +--- + net/ceph/osdmap.c | 118 ++++++++++++++++++++++++------------------------------ + 1 file changed, 53 insertions(+), 65 deletions(-) + +--- a/net/ceph/osdmap.c ++++ b/net/ceph/osdmap.c +@@ -806,51 +806,49 @@ static int decode_pool(void **p, void *e + ceph_decode_need(p, end, len, bad); + pool_end = *p + len; + ++ ceph_decode_need(p, end, 4 + 4 + 4, bad); + pi->type = ceph_decode_8(p); + pi->size = ceph_decode_8(p); + pi->crush_ruleset = ceph_decode_8(p); + pi->object_hash = ceph_decode_8(p); +- + pi->pg_num = ceph_decode_32(p); + pi->pgp_num = ceph_decode_32(p); + +- *p += 4 + 4; /* skip lpg* */ +- *p += 4; /* skip last_change */ +- *p += 8 + 4; /* skip snap_seq, snap_epoch */ ++ /* lpg*, last_change, snap_seq, snap_epoch */ ++ ceph_decode_skip_n(p, end, 8 + 4 + 8 + 4, bad); + + /* skip snaps */ +- num = ceph_decode_32(p); ++ ceph_decode_32_safe(p, end, num, bad); + while (num--) { +- *p += 8; /* snapid key */ +- *p += 1 + 1; /* versions */ +- len = ceph_decode_32(p); +- *p += len; ++ /* snapid key, pool snap (with versions) */ ++ ceph_decode_skip_n(p, end, 8 + 2, bad); ++ ceph_decode_skip_string(p, end, bad); + } + +- /* skip removed_snaps */ +- num = ceph_decode_32(p); +- *p += num * (8 + 8); ++ /* removed_snaps */ ++ ceph_decode_skip_map(p, end, 64, 64, bad); + ++ ceph_decode_need(p, end, 8 + 8 + 4, bad); + *p += 8; /* skip auid */ + pi->flags = ceph_decode_64(p); + *p += 4; /* skip crash_replay_interval */ + + if (ev >= 7) +- pi->min_size = ceph_decode_8(p); ++ ceph_decode_8_safe(p, end, pi->min_size, bad); + else + pi->min_size = pi->size - pi->size / 2; + + if (ev >= 8) +- *p += 8 + 8; /* skip quota_max_* */ ++ /* quota_max_* */ ++ ceph_decode_skip_n(p, end, 8 + 8, bad); + + if (ev >= 9) { +- /* skip tiers */ +- num = ceph_decode_32(p); +- *p += num * 8; ++ /* tiers */ ++ ceph_decode_skip_set(p, end, 64, bad); + ++ ceph_decode_need(p, end, 8 + 1 + 8 + 8, bad); + *p += 8; /* skip tier_of */ + *p += 1; /* skip cache_mode */ +- + pi->read_tier = ceph_decode_64(p); + pi->write_tier = ceph_decode_64(p); + } else { +@@ -858,86 +856,76 @@ static int decode_pool(void **p, void *e + pi->write_tier = -1; + } + +- if (ev >= 10) { +- /* skip properties */ +- num = ceph_decode_32(p); +- while (num--) { +- len = ceph_decode_32(p); +- *p += len; /* key */ +- len = ceph_decode_32(p); +- *p += len; /* val */ +- } +- } ++ if (ev >= 10) ++ /* properties */ ++ ceph_decode_skip_map(p, end, string, string, bad); + + if (ev >= 11) { +- /* skip hit_set_params */ +- *p += 1 + 1; /* versions */ +- len = ceph_decode_32(p); +- *p += len; ++ /* hit_set_params (with versions) */ ++ ceph_decode_skip_n(p, end, 2, bad); ++ ceph_decode_skip_string(p, end, bad); + +- *p += 4; /* skip hit_set_period */ +- *p += 4; /* skip hit_set_count */ ++ /* hit_set_period, hit_set_count */ ++ ceph_decode_skip_n(p, end, 4 + 4, bad); + } + + if (ev >= 12) +- *p += 4; /* skip stripe_width */ ++ /* stripe_width */ ++ ceph_decode_skip_32(p, end, bad); + +- if (ev >= 13) { +- *p += 8; /* skip target_max_bytes */ +- *p += 8; /* skip target_max_objects */ +- *p += 4; /* skip cache_target_dirty_ratio_micro */ +- *p += 4; /* skip cache_target_full_ratio_micro */ +- *p += 4; /* skip cache_min_flush_age */ +- *p += 4; /* skip cache_min_evict_age */ +- } +- +- if (ev >= 14) { +- /* skip erasure_code_profile */ +- len = ceph_decode_32(p); +- *p += len; +- } ++ if (ev >= 13) ++ /* target_max_*, cache_target_*, cache_min_* */ ++ ceph_decode_skip_n(p, end, 16 + 8 + 8, bad); ++ ++ if (ev >= 14) ++ /* erasure_code_profile */ ++ ceph_decode_skip_string(p, end, bad); + + /* + * last_force_op_resend_preluminous, will be overridden if the + * map was encoded with RESEND_ON_SPLIT + */ + if (ev >= 15) +- pi->last_force_request_resend = ceph_decode_32(p); ++ ceph_decode_32_safe(p, end, pi->last_force_request_resend, bad); + else + pi->last_force_request_resend = 0; + + if (ev >= 16) +- *p += 4; /* skip min_read_recency_for_promote */ ++ /* min_read_recency_for_promote */ ++ ceph_decode_skip_32(p, end, bad); + + if (ev >= 17) +- *p += 8; /* skip expected_num_objects */ ++ /* expected_num_objects */ ++ ceph_decode_skip_64(p, end, bad); + + if (ev >= 19) +- *p += 4; /* skip cache_target_dirty_high_ratio_micro */ ++ /* cache_target_dirty_high_ratio_micro */ ++ ceph_decode_skip_32(p, end, bad); + + if (ev >= 20) +- *p += 4; /* skip min_write_recency_for_promote */ ++ /* min_write_recency_for_promote */ ++ ceph_decode_skip_32(p, end, bad); + + if (ev >= 21) +- *p += 1; /* skip use_gmt_hitset */ ++ /* use_gmt_hitset */ ++ ceph_decode_skip_8(p, end, bad); + + if (ev >= 22) +- *p += 1; /* skip fast_read */ ++ /* fast_read */ ++ ceph_decode_skip_8(p, end, bad); + +- if (ev >= 23) { +- *p += 4; /* skip hit_set_grade_decay_rate */ +- *p += 4; /* skip hit_set_search_last_n */ +- } ++ if (ev >= 23) ++ /* hit_set_grade_decay_rate, hit_set_search_last_n */ ++ ceph_decode_skip_n(p, end, 4 + 4, bad); + + if (ev >= 24) { +- /* skip opts */ +- *p += 1 + 1; /* versions */ +- len = ceph_decode_32(p); +- *p += len; ++ /* opts (with versions) */ ++ ceph_decode_skip_n(p, end, 2, bad); ++ ceph_decode_skip_string(p, end, bad); + } + + if (ev >= 25) +- pi->last_force_request_resend = ceph_decode_32(p); ++ ceph_decode_32_safe(p, end, pi->last_force_request_resend, bad); + + /* ignore the rest */ + diff --git a/queue-6.18/media-iris-add-sanity-check-for-stop-streaming.patch b/queue-6.18/media-iris-add-sanity-check-for-stop-streaming.patch new file mode 100644 index 0000000000..0dde47db9b --- /dev/null +++ b/queue-6.18/media-iris-add-sanity-check-for-stop-streaming.patch @@ -0,0 +1,56 @@ +From ad699fa78b59241c9d71a8cafb51525f3dab04d4 Mon Sep 17 00:00:00 2001 +From: Wangao Wang +Date: Mon, 27 Oct 2025 17:35:59 +0800 +Subject: media: iris: Add sanity check for stop streaming + +From: Wangao Wang + +commit ad699fa78b59241c9d71a8cafb51525f3dab04d4 upstream. + +Add sanity check in iris_vb2_stop_streaming. If inst->state is +already IRIS_INST_ERROR, we should skip the stream_off operation +because it would still send packets to the firmware. + +In iris_kill_session, inst->state is set to IRIS_INST_ERROR and +session_close is executed, which will kfree(inst_hfi_gen2->packet). +If stop_streaming is called afterward, it will cause a crash. + +Fixes: 11712ce70f8e5 ("media: iris: implement vb2 streaming ops") +Cc: stable@vger.kernel.org +Reviewed-by: Bryan O'Donoghue +Reviewed-by: Dikshita Agarwal +Signed-off-by: Wangao Wang +Reviewed-by: Vikash Garodia +[bod: remove qcom from patch title] +Signed-off-by: Bryan O'Donoghue +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/qcom/iris/iris_vb2.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/drivers/media/platform/qcom/iris/iris_vb2.c ++++ b/drivers/media/platform/qcom/iris/iris_vb2.c +@@ -231,6 +231,8 @@ void iris_vb2_stop_streaming(struct vb2_ + return; + + mutex_lock(&inst->lock); ++ if (inst->state == IRIS_INST_ERROR) ++ goto exit; + + if (!V4L2_TYPE_IS_OUTPUT(q->type) && + !V4L2_TYPE_IS_CAPTURE(q->type)) +@@ -241,10 +243,10 @@ void iris_vb2_stop_streaming(struct vb2_ + goto exit; + + exit: +- iris_helper_buffers_done(inst, q->type, VB2_BUF_STATE_ERROR); +- if (ret) ++ if (ret) { ++ iris_helper_buffers_done(inst, q->type, VB2_BUF_STATE_ERROR); + iris_inst_change_state(inst, IRIS_INST_ERROR); +- ++ } + mutex_unlock(&inst->lock); + } + diff --git a/queue-6.18/media-vidtv-initialize-local-pointers-upon-transfer-of-memory-ownership.patch b/queue-6.18/media-vidtv-initialize-local-pointers-upon-transfer-of-memory-ownership.patch new file mode 100644 index 0000000000..ded6517515 --- /dev/null +++ b/queue-6.18/media-vidtv-initialize-local-pointers-upon-transfer-of-memory-ownership.patch @@ -0,0 +1,56 @@ +From 98aabfe2d79f74613abc2b0b1cef08f97eaf5322 Mon Sep 17 00:00:00 2001 +From: Jeongjun Park +Date: Fri, 5 Sep 2025 14:18:16 +0900 +Subject: media: vidtv: initialize local pointers upon transfer of memory ownership + +From: Jeongjun Park + +commit 98aabfe2d79f74613abc2b0b1cef08f97eaf5322 upstream. + +vidtv_channel_si_init() creates a temporary list (program, service, event) +and ownership of the memory itself is transferred to the PAT/SDT/EIT +tables through vidtv_psi_pat_program_assign(), +vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign(). + +The problem here is that the local pointer where the memory ownership +transfer was completed is not initialized to NULL. This causes the +vidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, and +in the flow that jumps to free_eit, the memory that was freed by +vidtv_psi_*_table_destroy() can be accessed again by +vidtv_psi_*_event_destroy() due to the uninitialized local pointer, so it +is freed once again. + +Therefore, to prevent use-after-free and double-free vulnerability, +local pointers must be initialized to NULL when transferring memory +ownership. + +Cc: +Reported-by: syzbot+1d9c0edea5907af239e0@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=1d9c0edea5907af239e0 +Fixes: 3be8037960bc ("media: vidtv: add error checks") +Signed-off-by: Jeongjun Park +Reviewed-by: Daniel Almeida +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/test-drivers/vidtv/vidtv_channel.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/media/test-drivers/vidtv/vidtv_channel.c ++++ b/drivers/media/test-drivers/vidtv/vidtv_channel.c +@@ -461,12 +461,15 @@ int vidtv_channel_si_init(struct vidtv_m + + /* assemble all programs and assign to PAT */ + vidtv_psi_pat_program_assign(m->si.pat, programs); ++ programs = NULL; + + /* assemble all services and assign to SDT */ + vidtv_psi_sdt_service_assign(m->si.sdt, services); ++ services = NULL; + + /* assemble all events and assign to EIT */ + vidtv_psi_eit_event_assign(m->si.eit, events); ++ events = NULL; + + m->si.pmt_secs = vidtv_psi_pmt_create_sec_for_each_pat_entry(m->si.pat, + m->pcr_pid); diff --git a/queue-6.18/mm-slub-reset-kasan-tag-in-defer_free-before-accessing-freed-memory.patch b/queue-6.18/mm-slub-reset-kasan-tag-in-defer_free-before-accessing-freed-memory.patch new file mode 100644 index 0000000000..7d82b33c64 --- /dev/null +++ b/queue-6.18/mm-slub-reset-kasan-tag-in-defer_free-before-accessing-freed-memory.patch @@ -0,0 +1,51 @@ +From 53ca00a19d345197a37a1bf552e8d1e7b091666c Mon Sep 17 00:00:00 2001 +From: Deepanshu Kartikey +Date: Wed, 10 Dec 2025 07:50:24 +0530 +Subject: mm/slub: reset KASAN tag in defer_free() before accessing freed memory + +From: Deepanshu Kartikey + +commit 53ca00a19d345197a37a1bf552e8d1e7b091666c upstream. + +When CONFIG_SLUB_TINY is enabled, kfree_nolock() calls kasan_slab_free() +before defer_free(). On ARM64 with MTE (Memory Tagging Extension), +kasan_slab_free() poisons the memory and changes the tag from the +original (e.g., 0xf3) to a poison tag (0xfe). + +When defer_free() then tries to write to the freed object to build the +deferred free list via llist_add(), the pointer still has the old tag, +causing a tag mismatch and triggering a KASAN use-after-free report: + + BUG: KASAN: slab-use-after-free in defer_free+0x3c/0xbc mm/slub.c:6537 + Write at addr f3f000000854f020 by task kworker/u8:6/983 + Pointer tag: [f3], memory tag: [fe] + +Fix this by calling kasan_reset_tag() before accessing the freed memory. +This is safe because defer_free() is part of the allocator itself and is +expected to manipulate freed memory for bookkeeping purposes. + +Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") +Cc: stable@vger.kernel.org +Reported-by: syzbot+7a25305a76d872abcfa1@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=7a25305a76d872abcfa1 +Tested-by: syzbot+7a25305a76d872abcfa1@syzkaller.appspotmail.com +Signed-off-by: Deepanshu Kartikey +Acked-by: Alexei Starovoitov +Link: https://patch.msgid.link/20251210022024.3255826-1-kartikey406@gmail.com +Signed-off-by: Vlastimil Babka +Signed-off-by: Greg Kroah-Hartman +--- + mm/slub.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -6509,6 +6509,8 @@ static void defer_free(struct kmem_cache + + guard(preempt)(); + ++ head = kasan_reset_tag(head); ++ + df = this_cpu_ptr(&defer_free_objects); + if (llist_add(head + s->offset, &df->objects)) + irq_work_queue(&df->work); diff --git a/queue-6.18/net-handshake-restore-destructor-on-submit-failure.patch b/queue-6.18/net-handshake-restore-destructor-on-submit-failure.patch new file mode 100644 index 0000000000..7db1eec32a --- /dev/null +++ b/queue-6.18/net-handshake-restore-destructor-on-submit-failure.patch @@ -0,0 +1,36 @@ +From 6af2a01d65f89e73c1cbb9267f8880d83a88cee4 Mon Sep 17 00:00:00 2001 +From: caoping +Date: Thu, 4 Dec 2025 01:10:58 -0800 +Subject: net/handshake: restore destructor on submit failure + +From: caoping + +commit 6af2a01d65f89e73c1cbb9267f8880d83a88cee4 upstream. + +handshake_req_submit() replaces sk->sk_destruct but never restores it when +submission fails before the request is hashed. handshake_sk_destruct() then +returns early and the original destructor never runs, leaking the socket. +Restore sk_destruct on the error path. + +Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests") +Reviewed-by: Chuck Lever +Cc: stable@vger.kernel.org +Signed-off-by: caoping +Link: https://patch.msgid.link/20251204091058.1545151-1-caoping@cmss.chinamobile.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/handshake/request.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/handshake/request.c ++++ b/net/handshake/request.c +@@ -276,6 +276,8 @@ int handshake_req_submit(struct socket * + out_unlock: + spin_unlock(&hn->hn_lock); + out_err: ++ /* Restore original destructor so socket teardown still runs on failure */ ++ req->hr_sk->sk_destruct = req->hr_odestruct; + trace_handshake_submit_err(net, req, req->hr_sk, ret); + handshake_req_destroy(req); + return ret; diff --git a/queue-6.18/net-phy-marvell-88q2xxx-fix-clamped-value-in-mv88q2xxx_hwmon_write.patch b/queue-6.18/net-phy-marvell-88q2xxx-fix-clamped-value-in-mv88q2xxx_hwmon_write.patch new file mode 100644 index 0000000000..6c99e05e7e --- /dev/null +++ b/queue-6.18/net-phy-marvell-88q2xxx-fix-clamped-value-in-mv88q2xxx_hwmon_write.patch @@ -0,0 +1,36 @@ +From c4cdf7376271bce5714c06d79ec67759b18910eb Mon Sep 17 00:00:00 2001 +From: Thorsten Blum +Date: Tue, 2 Dec 2025 18:27:44 +0100 +Subject: net: phy: marvell-88q2xxx: Fix clamped value in mv88q2xxx_hwmon_write + +From: Thorsten Blum + +commit c4cdf7376271bce5714c06d79ec67759b18910eb upstream. + +The local variable 'val' was never clamped to -75000 or 180000 because +the return value of clamp_val() was not used. Fix this by assigning the +clamped value back to 'val', and use clamp() instead of clamp_val(). + +Cc: stable@vger.kernel.org +Fixes: a557a92e6881 ("net: phy: marvell-88q2xxx: add support for temperature sensor") +Signed-off-by: Thorsten Blum +Reviewed-by: Dimitri Fedrau +Reviewed-by: Andrew Lunn +Link: https://patch.msgid.link/20251202172743.453055-3-thorsten.blum@linux.dev +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/phy/marvell-88q2xxx.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/phy/marvell-88q2xxx.c ++++ b/drivers/net/phy/marvell-88q2xxx.c +@@ -698,7 +698,7 @@ static int mv88q2xxx_hwmon_write(struct + + switch (attr) { + case hwmon_temp_max: +- clamp_val(val, -75000, 180000); ++ val = clamp(val, -75000, 180000); + val = (val / 1000) + 75; + val = FIELD_PREP(MDIO_MMD_PCS_MV_TEMP_SENSOR3_INT_THRESH_MASK, + val); diff --git a/queue-6.18/nfsd-clear-seclabel-in-the-suppattr_exclcreat-bitmap.patch b/queue-6.18/nfsd-clear-seclabel-in-the-suppattr_exclcreat-bitmap.patch new file mode 100644 index 0000000000..3b242c7fad --- /dev/null +++ b/queue-6.18/nfsd-clear-seclabel-in-the-suppattr_exclcreat-bitmap.patch @@ -0,0 +1,52 @@ +From 27d17641cacfedd816789b75d342430f6b912bd2 Mon Sep 17 00:00:00 2001 +From: Chuck Lever +Date: Mon, 17 Nov 2025 11:00:49 -0500 +Subject: NFSD: Clear SECLABEL in the suppattr_exclcreat bitmap + +From: Chuck Lever + +commit 27d17641cacfedd816789b75d342430f6b912bd2 upstream. + +>From RFC 8881: + +5.8.1.14. Attribute 75: suppattr_exclcreat + +> The bit vector that would set all REQUIRED and RECOMMENDED +> attributes that are supported by the EXCLUSIVE4_1 method of file +> creation via the OPEN operation. The scope of this attribute +> applies to all objects with a matching fsid. + +There's nothing in RFC 8881 that states that suppattr_exclcreat is +or is not allowed to contain bits for attributes that are clear in +the reported supported_attrs bitmask. But it doesn't make sense for +an NFS server to indicate that it /doesn't/ implement an attribute, +but then also indicate that clients /are/ allowed to set that +attribute using OPEN(create) with EXCLUSIVE4_1. + +Ensure that the SECURITY_LABEL and ACL bits are not set in the +suppattr_exclcreat bitmask when they are also not set in the +supported_attrs bitmask. + +Fixes: 8c18f2052e75 ("nfsd41: SUPPATTR_EXCLCREAT attribute") +Cc: stable@vger.kernel.org +Reviewed-by: Jeff Layton +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfsd/nfs4xdr.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/fs/nfsd/nfs4xdr.c ++++ b/fs/nfsd/nfs4xdr.c +@@ -3375,6 +3375,11 @@ static __be32 nfsd4_encode_fattr4_suppat + u32 supp[3]; + + memcpy(supp, nfsd_suppattrs[resp->cstate.minorversion], sizeof(supp)); ++ if (!IS_POSIXACL(d_inode(args->dentry))) ++ supp[0] &= ~FATTR4_WORD0_ACL; ++ if (!args->contextsupport) ++ supp[2] &= ~FATTR4_WORD2_SECURITY_LABEL; ++ + supp[0] &= NFSD_SUPPATTR_EXCLCREAT_WORD0; + supp[1] &= NFSD_SUPPATTR_EXCLCREAT_WORD1; + supp[2] &= NFSD_SUPPATTR_EXCLCREAT_WORD2; diff --git a/queue-6.18/nfsd-clear-time_deleg-in-the-suppattr_exclcreat-bitmap.patch b/queue-6.18/nfsd-clear-time_deleg-in-the-suppattr_exclcreat-bitmap.patch new file mode 100644 index 0000000000..b339231b91 --- /dev/null +++ b/queue-6.18/nfsd-clear-time_deleg-in-the-suppattr_exclcreat-bitmap.patch @@ -0,0 +1,56 @@ +From ad3cbbb0c1892c48919727fcb8dec5965da8bacb Mon Sep 17 00:00:00 2001 +From: Chuck Lever +Date: Mon, 17 Nov 2025 11:00:50 -0500 +Subject: NFSD: Clear TIME_DELEG in the suppattr_exclcreat bitmap + +From: Chuck Lever + +commit ad3cbbb0c1892c48919727fcb8dec5965da8bacb upstream. + +>From RFC 8881: + +5.8.1.14. Attribute 75: suppattr_exclcreat + +> The bit vector that would set all REQUIRED and RECOMMENDED +> attributes that are supported by the EXCLUSIVE4_1 method of file +> creation via the OPEN operation. The scope of this attribute +> applies to all objects with a matching fsid. + +There's nothing in RFC 8881 that states that suppattr_exclcreat is +or is not allowed to contain bits for attributes that are clear in +the reported supported_attrs bitmask. But it doesn't make sense for +an NFS server to indicate that it /doesn't/ implement an attribute, +but then also indicate that clients /are/ allowed to set that +attribute using OPEN(create) with EXCLUSIVE4_1. + +The FATTR4_WORD2_TIME_DELEG attributes are also not to be allowed +for OPEN(create) with EXCLUSIVE4_1. It doesn't make sense to set +a delegated timestamp on a new file. + +Fixes: 7e13f4f8d27d ("nfsd: handle delegated timestamps in SETATTR") +Cc: stable@vger.kernel.org +Reviewed-by: Jeff Layton +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfsd/nfsd.h | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/fs/nfsd/nfsd.h ++++ b/fs/nfsd/nfsd.h +@@ -547,8 +547,14 @@ static inline bool nfsd_attrs_supported( + #define NFSD_SUPPATTR_EXCLCREAT_WORD1 \ + (NFSD_WRITEABLE_ATTRS_WORD1 & \ + ~(FATTR4_WORD1_TIME_ACCESS_SET | FATTR4_WORD1_TIME_MODIFY_SET)) ++/* ++ * The FATTR4_WORD2_TIME_DELEG attributes are not to be allowed for ++ * OPEN(create) with EXCLUSIVE4_1. It doesn't make sense to set a ++ * delegated timestamp on a new file. ++ */ + #define NFSD_SUPPATTR_EXCLCREAT_WORD2 \ +- NFSD_WRITEABLE_ATTRS_WORD2 ++ (NFSD_WRITEABLE_ATTRS_WORD2 & \ ++ ~(FATTR4_WORD2_TIME_DELEG_ACCESS | FATTR4_WORD2_TIME_DELEG_MODIFY)) + + extern int nfsd4_is_junction(struct dentry *dentry); + extern int register_cld_notifier(void); diff --git a/queue-6.18/nfsd-mark-variable-__maybe_unused-to-avoid-w-1-build-break.patch b/queue-6.18/nfsd-mark-variable-__maybe_unused-to-avoid-w-1-build-break.patch new file mode 100644 index 0000000000..da48e5e0d2 --- /dev/null +++ b/queue-6.18/nfsd-mark-variable-__maybe_unused-to-avoid-w-1-build-break.patch @@ -0,0 +1,41 @@ +From ebae102897e760e9e6bc625f701dd666b2163bd1 Mon Sep 17 00:00:00 2001 +From: Andy Shevchenko +Date: Thu, 13 Nov 2025 09:31:31 +0100 +Subject: nfsd: Mark variable __maybe_unused to avoid W=1 build break + +From: Andy Shevchenko + +commit ebae102897e760e9e6bc625f701dd666b2163bd1 upstream. + +Clang is not happy about set but (in some cases) unused variable: + +fs/nfsd/export.c:1027:17: error: variable 'inode' set but not used [-Werror,-Wunused-but-set-variable] + +since it's used as a parameter to dprintk() which might be configured +a no-op. To avoid uglifying code with the specific ifdeffery just mark +the variable __maybe_unused. + +The commit [1], which introduced this behaviour, is quite old and hence +the Fixes tag points to the first of the Git era. + +Link: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=0431923fb7a1 [1] +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Cc: stable@vger.kernel.org +Signed-off-by: Andy Shevchenko +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfsd/export.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/nfsd/export.c ++++ b/fs/nfsd/export.c +@@ -1024,7 +1024,7 @@ exp_rootfh(struct net *net, struct auth_ + { + struct svc_export *exp; + struct path path; +- struct inode *inode; ++ struct inode *inode __maybe_unused; + struct svc_fh fh; + int err; + struct nfsd_net *nn = net_generic(net, nfsd_net_id); diff --git a/queue-6.18/nfsd-nfsv4-file-creation-neglects-setting-acl.patch b/queue-6.18/nfsd-nfsv4-file-creation-neglects-setting-acl.patch new file mode 100644 index 0000000000..f0eb9e4ab2 --- /dev/null +++ b/queue-6.18/nfsd-nfsv4-file-creation-neglects-setting-acl.patch @@ -0,0 +1,51 @@ +From 913f7cf77bf14c13cfea70e89bcb6d0b22239562 Mon Sep 17 00:00:00 2001 +From: Chuck Lever +Date: Tue, 18 Nov 2025 19:51:19 -0500 +Subject: NFSD: NFSv4 file creation neglects setting ACL +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Chuck Lever + +commit 913f7cf77bf14c13cfea70e89bcb6d0b22239562 upstream. + +An NFSv4 client that sets an ACL with a named principal during file +creation retrieves the ACL afterwards, and finds that it is only a +default ACL (based on the mode bits) and not the ACL that was +requested during file creation. This violates RFC 8881 section +6.4.1.3: "the ACL attribute is set as given". + +The issue occurs in nfsd_create_setattr(), which calls +nfsd_attrs_valid() to determine whether to call nfsd_setattr(). +However, nfsd_attrs_valid() checks only for iattr changes and +security labels, but not POSIX ACLs. When only an ACL is present, +the function returns false, nfsd_setattr() is skipped, and the +POSIX ACL is never applied to the inode. + +Subsequently, when the client retrieves the ACL, the server finds +no POSIX ACL on the inode and returns one generated from the file's +mode bits rather than returning the originally-specified ACL. + +Reported-by: Aurélien Couderc +Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs") +Cc: Roland Mainz +Cc: stable@vger.kernel.org +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfsd/vfs.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/fs/nfsd/vfs.h ++++ b/fs/nfsd/vfs.h +@@ -67,7 +67,8 @@ static inline bool nfsd_attrs_valid(stru + struct iattr *iap = attrs->na_iattr; + + return (iap->ia_valid || (attrs->na_seclabel && +- attrs->na_seclabel->len)); ++ attrs->na_seclabel->len) || ++ attrs->na_pacl || attrs->na_dpacl); + } + + __be32 nfserrno (int errno); diff --git a/queue-6.18/ocfs2-fix-kernel-bug-in-ocfs2_find_victim_chain.patch b/queue-6.18/ocfs2-fix-kernel-bug-in-ocfs2_find_victim_chain.patch new file mode 100644 index 0000000000..47482c0645 --- /dev/null +++ b/queue-6.18/ocfs2-fix-kernel-bug-in-ocfs2_find_victim_chain.patch @@ -0,0 +1,67 @@ +From 039bef30e320827bac8990c9f29d2a68cd8adb5f Mon Sep 17 00:00:00 2001 +From: Prithvi Tambewagh +Date: Mon, 1 Dec 2025 18:37:11 +0530 +Subject: ocfs2: fix kernel BUG in ocfs2_find_victim_chain + +From: Prithvi Tambewagh + +commit 039bef30e320827bac8990c9f29d2a68cd8adb5f upstream. + +syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the +`cl_next_free_rec` field of the allocation chain list (next free slot in +the chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec) +condition in ocfs2_find_victim_chain() and panicking the kernel. + +To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(), +just before calling ocfs2_find_victim_chain(), the code block in it being +executed when either of the following conditions is true: + +1. `cl_next_free_rec` is equal to 0, indicating that there are no free +chains in the allocation chain list +2. `cl_next_free_rec` is greater than `cl_count` (the total number of +chains in the allocation chain list) + +Either of them being true is indicative of the fact that there are no +chains left for usage. + +This is addressed using ocfs2_error(), which prints +the error log for debugging purposes, rather than panicking the kernel. + +Link: https://lkml.kernel.org/r/20251201130711.143900-1-activprithvi@gmail.com +Signed-off-by: Prithvi Tambewagh +Reported-by: syzbot+96d38c6e1655c1420a72@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72 +Tested-by: syzbot+96d38c6e1655c1420a72@syzkaller.appspotmail.com +Reviewed-by: Joseph Qi +Cc: Mark Fasheh +Cc: Joel Becker +Cc: Junxiao Bi +Cc: Changwei Ge +Cc: Jun Piao +Cc: Heming Zhao +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/ocfs2/suballoc.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/fs/ocfs2/suballoc.c ++++ b/fs/ocfs2/suballoc.c +@@ -1992,6 +1992,16 @@ static int ocfs2_claim_suballoc_bits(str + } + + cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; ++ if (!le16_to_cpu(cl->cl_next_free_rec) || ++ le16_to_cpu(cl->cl_next_free_rec) > le16_to_cpu(cl->cl_count)) { ++ status = ocfs2_error(ac->ac_inode->i_sb, ++ "Chain allocator dinode %llu has invalid next " ++ "free chain record %u, but only %u total\n", ++ (unsigned long long)le64_to_cpu(fe->i_blkno), ++ le16_to_cpu(cl->cl_next_free_rec), ++ le16_to_cpu(cl->cl_count)); ++ goto bail; ++ } + + victim = ocfs2_find_victim_chain(cl); + ac->ac_chain = victim; diff --git a/queue-6.18/parisc-do-not-reprogram-affinitiy-on-asp-chip.patch b/queue-6.18/parisc-do-not-reprogram-affinitiy-on-asp-chip.patch new file mode 100644 index 0000000000..ed8cb4d0cc --- /dev/null +++ b/queue-6.18/parisc-do-not-reprogram-affinitiy-on-asp-chip.patch @@ -0,0 +1,36 @@ +From dca7da244349eef4d78527cafc0bf80816b261f5 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Tue, 25 Nov 2025 15:23:02 +0100 +Subject: parisc: Do not reprogram affinitiy on ASP chip + +From: Helge Deller + +commit dca7da244349eef4d78527cafc0bf80816b261f5 upstream. + +The ASP chip is a very old variant of the GSP chip and is used e.g. in +HP 730 workstations. When trying to reprogram the affinity it will crash +with a HPMC as the relevant registers don't seem to be at the usual +location. Let's avoid the crash by checking the sversion. Also note, +that reprogramming isn't necessary either, as the HP730 is a just a +single-CPU machine. + +Signed-off-by: Helge Deller +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/parisc/gsc.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/parisc/gsc.c ++++ b/drivers/parisc/gsc.c +@@ -154,7 +154,9 @@ static int gsc_set_affinity_irq(struct i + gsc_dev->eim = ((u32) gsc_dev->gsc_irq.txn_addr) | gsc_dev->gsc_irq.txn_data; + + /* switch IRQ's for devices below LASI/WAX to other CPU */ +- gsc_writel(gsc_dev->eim, gsc_dev->hpa + OFFSET_IAR); ++ /* ASP chip (svers 0x70) does not support reprogramming */ ++ if (gsc_dev->gsc->id.sversion != 0x70) ++ gsc_writel(gsc_dev->eim, gsc_dev->hpa + OFFSET_IAR); + + irq_data_update_effective_affinity(d, &tmask); + diff --git a/queue-6.18/pinctrl-renesas-rzg2l-fix-isel-restore-on-resume.patch b/queue-6.18/pinctrl-renesas-rzg2l-fix-isel-restore-on-resume.patch new file mode 100644 index 0000000000..f1c792523c --- /dev/null +++ b/queue-6.18/pinctrl-renesas-rzg2l-fix-isel-restore-on-resume.patch @@ -0,0 +1,341 @@ +From 44bf66122c12ef6d3382a9b84b9be1802e5f0e95 Mon Sep 17 00:00:00 2001 +From: Claudiu Beznea +Date: Fri, 12 Sep 2025 12:53:08 +0300 +Subject: pinctrl: renesas: rzg2l: Fix ISEL restore on resume + +From: Claudiu Beznea + +commit 44bf66122c12ef6d3382a9b84b9be1802e5f0e95 upstream. + +Commit 1d2da79708cb ("pinctrl: renesas: rzg2l: Avoid configuring ISEL in +gpio_irq_{en,dis}able*()") dropped the configuration of ISEL from +struct irq_chip::{irq_enable, irq_disable} APIs and moved it to +struct gpio_chip::irq::{child_to_parent_hwirq, +child_irq_domain_ops::free} APIs to fix spurious IRQs. + +After commit 1d2da79708cb ("pinctrl: renesas: rzg2l: Avoid configuring ISEL +in gpio_irq_{en,dis}able*()"), ISEL was no longer configured properly on +resume. This is because the pinctrl resume code used +struct irq_chip::irq_enable (called from rzg2l_gpio_irq_restore()) to +reconfigure the wakeup interrupts. Some drivers (e.g. Ethernet) may also +reconfigure non-wakeup interrupts on resume through their own code, +eventually calling struct irq_chip::irq_enable. + +Fix this by adding ISEL configuration back into the +struct irq_chip::irq_enable API and on resume path for wakeup interrupts. + +As struct irq_chip::irq_enable needs now to lock to update the ISEL, +convert the struct rzg2l_pinctrl::lock to a raw spinlock and replace the +locking API calls with the raw variants. Otherwise the lockdep reports +invalid wait context when probing the adv7511 module on RZ/G2L: + + [ BUG: Invalid wait context ] + 6.17.0-rc5-next-20250911-00001-gfcfac22533c9 #18 Not tainted + ----------------------------- + (udev-worker)/165 is trying to lock: + ffff00000e3664a8 (&pctrl->lock){....}-{3:3}, at: rzg2l_gpio_irq_enable+0x38/0x78 + other info that might help us debug this: + context-{5:5} + 3 locks held by (udev-worker)/165: + #0: ffff00000e890108 (&dev->mutex){....}-{4:4}, at: __driver_attach+0x90/0x1ac + #1: ffff000011c07240 (request_class){+.+.}-{4:4}, at: __setup_irq+0xb4/0x6dc + #2: ffff000011c070c8 (lock_class){....}-{2:2}, at: __setup_irq+0xdc/0x6dc + stack backtrace: + CPU: 1 UID: 0 PID: 165 Comm: (udev-worker) Not tainted 6.17.0-rc5-next-20250911-00001-gfcfac22533c9 #18 PREEMPT + Hardware name: Renesas SMARC EVK based on r9a07g044l2 (DT) + Call trace: + show_stack+0x18/0x24 (C) + dump_stack_lvl+0x90/0xd0 + dump_stack+0x18/0x24 + __lock_acquire+0xa14/0x20b4 + lock_acquire+0x1c8/0x354 + _raw_spin_lock_irqsave+0x60/0x88 + rzg2l_gpio_irq_enable+0x38/0x78 + irq_enable+0x40/0x8c + __irq_startup+0x78/0xa4 + irq_startup+0x108/0x16c + __setup_irq+0x3c0/0x6dc + request_threaded_irq+0xec/0x1ac + devm_request_threaded_irq+0x80/0x134 + adv7511_probe+0x928/0x9a4 [adv7511] + i2c_device_probe+0x22c/0x3dc + really_probe+0xbc/0x2a0 + __driver_probe_device+0x78/0x12c + driver_probe_device+0x40/0x164 + __driver_attach+0x9c/0x1ac + bus_for_each_dev+0x74/0xd0 + driver_attach+0x24/0x30 + bus_add_driver+0xe4/0x208 + driver_register+0x60/0x128 + i2c_register_driver+0x48/0xd0 + adv7511_init+0x5c/0x1000 [adv7511] + do_one_initcall+0x64/0x30c + do_init_module+0x58/0x23c + load_module+0x1bcc/0x1d40 + init_module_from_file+0x88/0xc4 + idempotent_init_module+0x188/0x27c + __arm64_sys_finit_module+0x68/0xac + invoke_syscall+0x48/0x110 + el0_svc_common.constprop.0+0xc0/0xe0 + do_el0_svc+0x1c/0x28 + el0_svc+0x4c/0x160 + el0t_64_sync_handler+0xa0/0xe4 + el0t_64_sync+0x198/0x19c + +Having ISEL configuration back into the struct irq_chip::irq_enable API +should be safe with respect to spurious IRQs, as in the probe case IRQs +are enabled anyway in struct gpio_chip::irq::child_to_parent_hwirq. No +spurious IRQs were detected on suspend/resume, boot, ethernet link +insert/remove tests (executed on RZ/G3S). Boot, ethernet link +insert/remove tests were also executed successfully on RZ/G2L. + +Fixes: 1d2da79708cb ("pinctrl: renesas: rzg2l: Avoid configuring ISEL in gpio_irq_{en,dis}able*(") +Cc: stable@vger.kernel.org +Signed-off-by: Claudiu Beznea +Reviewed-by: Geert Uytterhoeven +Link: https://patch.msgid.link/20250912095308.3603704-1-claudiu.beznea.uj@bp.renesas.com +Signed-off-by: Geert Uytterhoeven +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pinctrl/renesas/pinctrl-rzg2l.c | 71 +++++++++++++++++++------------- + 1 file changed, 44 insertions(+), 27 deletions(-) + +--- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c ++++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c +@@ -359,7 +359,7 @@ struct rzg2l_pinctrl { + spinlock_t bitmap_lock; /* protect tint_slot bitmap */ + unsigned int hwirq[RZG2L_TINT_MAX_INTERRUPT]; + +- spinlock_t lock; /* lock read/write registers */ ++ raw_spinlock_t lock; /* lock read/write registers */ + struct mutex mutex; /* serialize adding groups and functions */ + + struct rzg2l_pinctrl_pin_settings *settings; +@@ -543,7 +543,7 @@ static void rzg2l_pinctrl_set_pfc_mode(s + unsigned long flags; + u32 reg; + +- spin_lock_irqsave(&pctrl->lock, flags); ++ raw_spin_lock_irqsave(&pctrl->lock, flags); + + /* Set pin to 'Non-use (Hi-Z input protection)' */ + reg = readw(pctrl->base + PM(off)); +@@ -567,7 +567,7 @@ static void rzg2l_pinctrl_set_pfc_mode(s + + pctrl->data->pwpr_pfc_lock_unlock(pctrl, true); + +- spin_unlock_irqrestore(&pctrl->lock, flags); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + }; + + static int rzg2l_pinctrl_set_mux(struct pinctrl_dev *pctldev, +@@ -882,10 +882,10 @@ static void rzg2l_rmw_pin_config(struct + addr += 4; + } + +- spin_lock_irqsave(&pctrl->lock, flags); ++ raw_spin_lock_irqsave(&pctrl->lock, flags); + reg = readl(addr) & ~(mask << (bit * 8)); + writel(reg | (val << (bit * 8)), addr); +- spin_unlock_irqrestore(&pctrl->lock, flags); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + } + + static int rzg2l_caps_to_pwr_reg(const struct rzg2l_register_offsets *regs, u32 caps) +@@ -1121,7 +1121,7 @@ static int rzg2l_write_oen(struct rzg2l_ + if (bit < 0) + return -EINVAL; + +- spin_lock_irqsave(&pctrl->lock, flags); ++ raw_spin_lock_irqsave(&pctrl->lock, flags); + val = readb(pctrl->base + oen_offset); + if (oen) + val &= ~BIT(bit); +@@ -1134,7 +1134,7 @@ static int rzg2l_write_oen(struct rzg2l_ + writeb(val, pctrl->base + oen_offset); + if (pctrl->data->hwcfg->oen_pwpr_lock) + writeb(pwpr & ~PWPR_REGWE_B, pctrl->base + regs->pwpr); +- spin_unlock_irqrestore(&pctrl->lock, flags); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + + return 0; + } +@@ -1687,14 +1687,14 @@ static int rzg2l_gpio_request(struct gpi + if (ret) + return ret; + +- spin_lock_irqsave(&pctrl->lock, flags); ++ raw_spin_lock_irqsave(&pctrl->lock, flags); + + /* Select GPIO mode in PMC Register */ + reg8 = readb(pctrl->base + PMC(off)); + reg8 &= ~BIT(bit); + pctrl->data->pmc_writeb(pctrl, reg8, PMC(off)); + +- spin_unlock_irqrestore(&pctrl->lock, flags); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + + return 0; + } +@@ -1709,7 +1709,7 @@ static void rzg2l_gpio_set_direction(str + unsigned long flags; + u16 reg16; + +- spin_lock_irqsave(&pctrl->lock, flags); ++ raw_spin_lock_irqsave(&pctrl->lock, flags); + + reg16 = readw(pctrl->base + PM(off)); + reg16 &= ~(PM_MASK << (bit * 2)); +@@ -1717,7 +1717,7 @@ static void rzg2l_gpio_set_direction(str + reg16 |= (output ? PM_OUTPUT : PM_INPUT) << (bit * 2); + writew(reg16, pctrl->base + PM(off)); + +- spin_unlock_irqrestore(&pctrl->lock, flags); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + } + + static int rzg2l_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) +@@ -1761,7 +1761,7 @@ static int rzg2l_gpio_set(struct gpio_ch + unsigned long flags; + u8 reg8; + +- spin_lock_irqsave(&pctrl->lock, flags); ++ raw_spin_lock_irqsave(&pctrl->lock, flags); + + reg8 = readb(pctrl->base + P(off)); + +@@ -1770,7 +1770,7 @@ static int rzg2l_gpio_set(struct gpio_ch + else + writeb(reg8 & ~BIT(bit), pctrl->base + P(off)); + +- spin_unlock_irqrestore(&pctrl->lock, flags); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + + return 0; + } +@@ -2429,14 +2429,13 @@ static int rzg2l_gpio_get_gpioint(unsign + return gpioint; + } + +-static void rzg2l_gpio_irq_endisable(struct rzg2l_pinctrl *pctrl, +- unsigned int hwirq, bool enable) ++static void __rzg2l_gpio_irq_endisable(struct rzg2l_pinctrl *pctrl, ++ unsigned int hwirq, bool enable) + { + const struct pinctrl_pin_desc *pin_desc = &pctrl->desc.pins[hwirq]; + u64 *pin_data = pin_desc->drv_data; + u32 off = RZG2L_PIN_CFG_TO_PORT_OFFSET(*pin_data); + u8 bit = RZG2L_PIN_ID_TO_PIN(hwirq); +- unsigned long flags; + void __iomem *addr; + + addr = pctrl->base + ISEL(off); +@@ -2445,12 +2444,20 @@ static void rzg2l_gpio_irq_endisable(str + addr += 4; + } + +- spin_lock_irqsave(&pctrl->lock, flags); + if (enable) + writel(readl(addr) | BIT(bit * 8), addr); + else + writel(readl(addr) & ~BIT(bit * 8), addr); +- spin_unlock_irqrestore(&pctrl->lock, flags); ++} ++ ++static void rzg2l_gpio_irq_endisable(struct rzg2l_pinctrl *pctrl, ++ unsigned int hwirq, bool enable) ++{ ++ unsigned long flags; ++ ++ raw_spin_lock_irqsave(&pctrl->lock, flags); ++ __rzg2l_gpio_irq_endisable(pctrl, hwirq, enable); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + } + + static void rzg2l_gpio_irq_disable(struct irq_data *d) +@@ -2462,15 +2469,25 @@ static void rzg2l_gpio_irq_disable(struc + gpiochip_disable_irq(gc, hwirq); + } + +-static void rzg2l_gpio_irq_enable(struct irq_data *d) ++static void __rzg2l_gpio_irq_enable(struct irq_data *d, bool lock) + { + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); ++ struct rzg2l_pinctrl *pctrl = container_of(gc, struct rzg2l_pinctrl, gpio_chip); + unsigned int hwirq = irqd_to_hwirq(d); + + gpiochip_enable_irq(gc, hwirq); ++ if (lock) ++ rzg2l_gpio_irq_endisable(pctrl, hwirq, true); ++ else ++ __rzg2l_gpio_irq_endisable(pctrl, hwirq, true); + irq_chip_enable_parent(d); + } + ++static void rzg2l_gpio_irq_enable(struct irq_data *d) ++{ ++ __rzg2l_gpio_irq_enable(d, true); ++} ++ + static int rzg2l_gpio_irq_set_type(struct irq_data *d, unsigned int type) + { + return irq_chip_set_type_parent(d, type); +@@ -2616,11 +2633,11 @@ static void rzg2l_gpio_irq_restore(struc + * This has to be atomically executed to protect against a concurrent + * interrupt. + */ +- spin_lock_irqsave(&pctrl->lock, flags); ++ raw_spin_lock_irqsave(&pctrl->lock, flags); + ret = rzg2l_gpio_irq_set_type(data, irqd_get_trigger_type(data)); + if (!ret && !irqd_irq_disabled(data)) +- rzg2l_gpio_irq_enable(data); +- spin_unlock_irqrestore(&pctrl->lock, flags); ++ __rzg2l_gpio_irq_enable(data, false); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + + if (ret) + dev_crit(pctrl->dev, "Failed to set IRQ type for virq=%u\n", virq); +@@ -2950,7 +2967,7 @@ static int rzg2l_pinctrl_probe(struct pl + "failed to enable GPIO clk\n"); + } + +- spin_lock_init(&pctrl->lock); ++ raw_spin_lock_init(&pctrl->lock); + spin_lock_init(&pctrl->bitmap_lock); + mutex_init(&pctrl->mutex); + atomic_set(&pctrl->wakeup_path, 0); +@@ -3097,7 +3114,7 @@ static void rzg2l_pinctrl_pm_setup_pfc(s + u32 nports = pctrl->data->n_port_pins / RZG2L_PINS_PER_PORT; + unsigned long flags; + +- spin_lock_irqsave(&pctrl->lock, flags); ++ raw_spin_lock_irqsave(&pctrl->lock, flags); + pctrl->data->pwpr_pfc_lock_unlock(pctrl, false); + + /* Restore port registers. */ +@@ -3142,7 +3159,7 @@ static void rzg2l_pinctrl_pm_setup_pfc(s + } + + pctrl->data->pwpr_pfc_lock_unlock(pctrl, true); +- spin_unlock_irqrestore(&pctrl->lock, flags); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + } + + static int rzg2l_pinctrl_suspend_noirq(struct device *dev) +@@ -3191,14 +3208,14 @@ static int rzg2l_pinctrl_resume_noirq(st + + writeb(cache->qspi, pctrl->base + QSPI); + if (pctrl->data->hwcfg->oen_pwpr_lock) { +- spin_lock_irqsave(&pctrl->lock, flags); ++ raw_spin_lock_irqsave(&pctrl->lock, flags); + pwpr = readb(pctrl->base + regs->pwpr); + writeb(pwpr | PWPR_REGWE_B, pctrl->base + regs->pwpr); + } + writeb(cache->oen, pctrl->base + pctrl->data->hwcfg->regs.oen); + if (pctrl->data->hwcfg->oen_pwpr_lock) { + writeb(pwpr & ~PWPR_REGWE_B, pctrl->base + regs->pwpr); +- spin_unlock_irqrestore(&pctrl->lock, flags); ++ raw_spin_unlock_irqrestore(&pctrl->lock, flags); + } + for (u8 i = 0; i < 2; i++) { + if (regs->sd_ch) diff --git a/queue-6.18/platform-chrome-cros_ec_ishtp-fix-uaf-after-unbinding-driver.patch b/queue-6.18/platform-chrome-cros_ec_ishtp-fix-uaf-after-unbinding-driver.patch new file mode 100644 index 0000000000..2ecc5517d0 --- /dev/null +++ b/queue-6.18/platform-chrome-cros_ec_ishtp-fix-uaf-after-unbinding-driver.patch @@ -0,0 +1,34 @@ +From 944edca81e7aea15f83cf9a13a6ab67f711e8abd Mon Sep 17 00:00:00 2001 +From: Tzung-Bi Shih +Date: Fri, 31 Oct 2025 03:39:00 +0000 +Subject: platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driver + +From: Tzung-Bi Shih + +commit 944edca81e7aea15f83cf9a13a6ab67f711e8abd upstream. + +After unbinding the driver, another kthread `cros_ec_console_log_work` +is still accessing the device, resulting an UAF and crash. + +The driver doesn't unregister the EC device in .remove() which should +shutdown sub-devices synchronously. Fix it. + +Fixes: 26a14267aff2 ("platform/chrome: Add ChromeOS EC ISHTP driver") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20251031033900.3577394-1-tzungbi@kernel.org +Signed-off-by: Tzung-Bi Shih +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/chrome/cros_ec_ishtp.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/platform/chrome/cros_ec_ishtp.c ++++ b/drivers/platform/chrome/cros_ec_ishtp.c +@@ -667,6 +667,7 @@ static void cros_ec_ishtp_remove(struct + + cancel_work_sync(&client_data->work_ishtp_reset); + cancel_work_sync(&client_data->work_ec_evt); ++ cros_ec_unregister(client_data->ec_dev); + cros_ish_deinit(cros_ish_cl); + ishtp_put_device(cl_device); + } diff --git a/queue-6.18/pm-runtime-do-not-clear-needs_force_resume-with-enabled-runtime-pm.patch b/queue-6.18/pm-runtime-do-not-clear-needs_force_resume-with-enabled-runtime-pm.patch new file mode 100644 index 0000000000..d9498466b4 --- /dev/null +++ b/queue-6.18/pm-runtime-do-not-clear-needs_force_resume-with-enabled-runtime-pm.patch @@ -0,0 +1,63 @@ +From 359afc8eb02a518fbdd0cbd462c8c2827c6cbec2 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Mon, 15 Dec 2025 15:21:34 +0100 +Subject: PM: runtime: Do not clear needs_force_resume with enabled runtime PM + +From: Rafael J. Wysocki + +commit 359afc8eb02a518fbdd0cbd462c8c2827c6cbec2 upstream. + +Commit 89d9cec3b1e9 ("PM: runtime: Clear power.needs_force_resume in +pm_runtime_reinit()") added provisional clearing of power.needs_force_resume +to pm_runtime_reinit(), but it is done unconditionally which is a +mistake because pm_runtime_reinit() may race with driver probing +and removal [1]. + +To address this, notice that power.needs_force_resume should never +be set when runtime PM is enabled and so it only needs to be cleared +when runtime PM is disabled, and update pm_runtime_init() to only +clear that flag when runtime PM is disabled. + +Fixes: 89d9cec3b1e9 ("PM: runtime: Clear power.needs_force_resume in pm_runtime_reinit()") +Reported-by: Ed Tsai +Closes: https://lore.kernel.org/linux-pm/20251215122154.3180001-1-ed.tsai@mediatek.com/ [1] +Signed-off-by: Rafael J. Wysocki +Cc: 6.17+ # 6.17+ +Reviewed-by: Ulf Hansson +Link: https://patch.msgid.link/12807571.O9o76ZdvQC@rafael.j.wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/power/runtime.c | 22 ++++++++++++---------- + 1 file changed, 12 insertions(+), 10 deletions(-) + +--- a/drivers/base/power/runtime.c ++++ b/drivers/base/power/runtime.c +@@ -1869,16 +1869,18 @@ void pm_runtime_init(struct device *dev) + */ + void pm_runtime_reinit(struct device *dev) + { +- if (!pm_runtime_enabled(dev)) { +- if (dev->power.runtime_status == RPM_ACTIVE) +- pm_runtime_set_suspended(dev); +- if (dev->power.irq_safe) { +- spin_lock_irq(&dev->power.lock); +- dev->power.irq_safe = 0; +- spin_unlock_irq(&dev->power.lock); +- if (dev->parent) +- pm_runtime_put(dev->parent); +- } ++ if (pm_runtime_enabled(dev)) ++ return; ++ ++ if (dev->power.runtime_status == RPM_ACTIVE) ++ pm_runtime_set_suspended(dev); ++ ++ if (dev->power.irq_safe) { ++ spin_lock_irq(&dev->power.lock); ++ dev->power.irq_safe = 0; ++ spin_unlock_irq(&dev->power.lock); ++ if (dev->parent) ++ pm_runtime_put(dev->parent); + } + /* + * Clear power.needs_force_resume in case it has been set by diff --git a/queue-6.18/powerpc-add-reloc_offset-to-font-bitmap-pointer-used-for-bootx_printf.patch b/queue-6.18/powerpc-add-reloc_offset-to-font-bitmap-pointer-used-for-bootx_printf.patch new file mode 100644 index 0000000000..33d132f735 --- /dev/null +++ b/queue-6.18/powerpc-add-reloc_offset-to-font-bitmap-pointer-used-for-bootx_printf.patch @@ -0,0 +1,64 @@ +From b94b73567561642323617155bf4ee24ef0d258fe Mon Sep 17 00:00:00 2001 +From: Finn Thain +Date: Mon, 10 Nov 2025 10:30:22 +1100 +Subject: powerpc: Add reloc_offset() to font bitmap pointer used for bootx_printf() + +From: Finn Thain + +commit b94b73567561642323617155bf4ee24ef0d258fe upstream. + +Since Linux v6.7, booting using BootX on an Old World PowerMac produces +an early crash. Stan Johnson writes, "the symptoms are that the screen +goes blank and the backlight stays on, and the system freezes (Linux +doesn't boot)." + +Further testing revealed that the failure can be avoided by disabling +CONFIG_BOOTX_TEXT. Bisection revealed that the regression was caused by +a change to the font bitmap pointer that's used when btext_init() begins +painting characters on the display, early in the boot process. + +Christophe Leroy explains, "before kernel text is relocated to its final +location ... data is addressed with an offset which is added to the +Global Offset Table (GOT) entries at the start of bootx_init() +by function reloc_got2(). But the pointers that are located inside a +structure are not referenced in the GOT and are therefore not updated by +reloc_got2(). It is therefore needed to apply the offset manually by using +PTRRELOC() macro." + +Cc: stable@vger.kernel.org +Link: https://lists.debian.org/debian-powerpc/2025/10/msg00111.html +Link: https://lore.kernel.org/linuxppc-dev/d81ddca8-c5ee-d583-d579-02b19ed95301@yahoo.com/ +Reported-by: Cedar Maxwell +Closes: https://lists.debian.org/debian-powerpc/2025/09/msg00031.html +Bisected-by: Stan Johnson +Tested-by: Stan Johnson +Fixes: 0ebc7feae79a ("powerpc: Use shared font data") +Suggested-by: Christophe Leroy +Signed-off-by: Finn Thain +Reviewed-by: Christophe Leroy +Signed-off-by: Madhavan Srinivasan +Link: https://patch.msgid.link/22b3b247425a052b079ab84da926706b3702c2c7.1762731022.git.fthain@linux-m68k.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kernel/btext.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/kernel/btext.c ++++ b/arch/powerpc/kernel/btext.c +@@ -20,6 +20,7 @@ + #include + #include + #include ++#include + + #define NO_SCROLL + +@@ -463,7 +464,7 @@ static noinline void draw_byte(unsigned + { + unsigned char *base = calc_base(locX << 3, locY << 4); + unsigned int font_index = c * 16; +- const unsigned char *font = font_sun_8x16.data + font_index; ++ const unsigned char *font = PTRRELOC(font_sun_8x16.data) + font_index; + int rb = dispDeviceRowBytes; + + rmci_maybe_on(); diff --git a/queue-6.18/powerpc-kexec-enable-smt-before-waking-offline-cpus.patch b/queue-6.18/powerpc-kexec-enable-smt-before-waking-offline-cpus.patch new file mode 100644 index 0000000000..18fa4fb6b6 --- /dev/null +++ b/queue-6.18/powerpc-kexec-enable-smt-before-waking-offline-cpus.patch @@ -0,0 +1,83 @@ +From c2296a1e42418556efbeb5636c4fa6aa6106713a Mon Sep 17 00:00:00 2001 +From: "Nysal Jan K.A." +Date: Tue, 28 Oct 2025 16:25:12 +0530 +Subject: powerpc/kexec: Enable SMT before waking offline CPUs + +From: Nysal Jan K.A. + +commit c2296a1e42418556efbeb5636c4fa6aa6106713a upstream. + +If SMT is disabled or a partial SMT state is enabled, when a new kernel +image is loaded for kexec, on reboot the following warning is observed: + +kexec: Waking offline cpu 228. +WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc +[snip] + NIP kexec_prepare_cpus+0x1b0/0x1bc + LR kexec_prepare_cpus+0x1a0/0x1bc + Call Trace: + kexec_prepare_cpus+0x1a0/0x1bc (unreliable) + default_machine_kexec+0x160/0x19c + machine_kexec+0x80/0x88 + kernel_kexec+0xd0/0x118 + __do_sys_reboot+0x210/0x2c4 + system_call_exception+0x124/0x320 + system_call_vectored_common+0x15c/0x2ec + +This occurs as add_cpu() fails due to cpu_bootable() returning false for +CPUs that fail the cpu_smt_thread_allowed() check or non primary +threads if SMT is disabled. + +Fix the issue by enabling SMT and resetting the number of SMT threads to +the number of threads per core, before attempting to wake up all present +CPUs. + +Fixes: 38253464bc82 ("cpu/SMT: Create topology_smt_thread_allowed()") +Reported-by: Sachin P Bappalige +Cc: stable@vger.kernel.org # v6.6+ +Reviewed-by: Srikar Dronamraju +Signed-off-by: Nysal Jan K.A. +Tested-by: Samir M +Reviewed-by: Sourabh Jain +Signed-off-by: Madhavan Srinivasan +Link: https://patch.msgid.link/20251028105516.26258-1-nysal@linux.ibm.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kexec/core_64.c | 19 +++++++++++++++++++ + 1 file changed, 19 insertions(+) + +--- a/arch/powerpc/kexec/core_64.c ++++ b/arch/powerpc/kexec/core_64.c +@@ -202,6 +202,23 @@ static void kexec_prepare_cpus_wait(int + mb(); + } + ++ ++/* ++ * The add_cpu() call in wake_offline_cpus() can fail as cpu_bootable() ++ * returns false for CPUs that fail the cpu_smt_thread_allowed() check ++ * or non primary threads if SMT is disabled. Re-enable SMT and set the ++ * number of SMT threads to threads per core. ++ */ ++static void kexec_smt_reenable(void) ++{ ++#if defined(CONFIG_SMP) && defined(CONFIG_HOTPLUG_SMT) ++ lock_device_hotplug(); ++ cpu_smt_num_threads = threads_per_core; ++ cpu_smt_control = CPU_SMT_ENABLED; ++ unlock_device_hotplug(); ++#endif ++} ++ + /* + * We need to make sure each present CPU is online. The next kernel will scan + * the device tree and assume primary threads are online and query secondary +@@ -216,6 +233,8 @@ static void wake_offline_cpus(void) + { + int cpu = 0; + ++ kexec_smt_reenable(); ++ + for_each_present_cpu(cpu) { + if (!cpu_online(cpu)) { + printk(KERN_INFO "kexec: Waking offline cpu %d.\n", diff --git a/queue-6.18/r8169-fix-rtl8117-wake-on-lan-in-dash-mode.patch b/queue-6.18/r8169-fix-rtl8117-wake-on-lan-in-dash-mode.patch new file mode 100644 index 0000000000..c72bb9bc08 --- /dev/null +++ b/queue-6.18/r8169-fix-rtl8117-wake-on-lan-in-dash-mode.patch @@ -0,0 +1,51 @@ +From dd75c723ef566f7f009c047f47e0eee95fe348ab Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ren=C3=A9=20Rebe?= +Date: Tue, 2 Dec 2025 19:41:37 +0100 +Subject: r8169: fix RTL8117 Wake-on-Lan in DASH mode +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: René Rebe + +commit dd75c723ef566f7f009c047f47e0eee95fe348ab upstream. + +Wake-on-Lan does currently not work for r8169 in DASH mode, e.g. the +ASUS Pro WS X570-ACE with RTL8168fp/RTL8117. + +Fix by not returning early in rtl_prepare_power_down when dash_enabled. +While this fixes WoL, it still kills the OOB RTL8117 remote management +BMC connection. Fix by not calling rtl8168_driver_stop if WoL is enabled. + +Fixes: 065c27c184d6 ("r8169: phy power ops") +Signed-off-by: René Rebe +Cc: stable@vger.kernel.org +Reviewed-by: Heiner Kallweit +Link: https://patch.msgid.link/20251202.194137.1647877804487085954.rene@exactco.de +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/realtek/r8169_main.c | 5 +---- + 1 file changed, 1 insertion(+), 4 deletions(-) + +--- a/drivers/net/ethernet/realtek/r8169_main.c ++++ b/drivers/net/ethernet/realtek/r8169_main.c +@@ -2669,9 +2669,6 @@ static void rtl_wol_enable_rx(struct rtl + + static void rtl_prepare_power_down(struct rtl8169_private *tp) + { +- if (tp->dash_enabled) +- return; +- + if (tp->mac_version == RTL_GIGA_MAC_VER_32 || + tp->mac_version == RTL_GIGA_MAC_VER_33) + rtl_ephy_write(tp, 0x19, 0xff64); +@@ -4807,7 +4804,7 @@ static void rtl8169_down(struct rtl8169_ + rtl_disable_exit_l1(tp); + rtl_prepare_power_down(tp); + +- if (tp->dash_type != RTL_DASH_NONE) ++ if (tp->dash_type != RTL_DASH_NONE && !tp->saved_wolopts) + rtl8168_driver_stop(tp); + } + diff --git a/queue-6.18/s390-ipl-clear-sbp-flag-when-bootprog-is-set.patch b/queue-6.18/s390-ipl-clear-sbp-flag-when-bootprog-is-set.patch new file mode 100644 index 0000000000..862925f78f --- /dev/null +++ b/queue-6.18/s390-ipl-clear-sbp-flag-when-bootprog-is-set.patch @@ -0,0 +1,153 @@ +From b1aa01d31249bd116b18c7f512d3e46b4b4ad83b Mon Sep 17 00:00:00 2001 +From: Sven Schnelle +Date: Fri, 5 Dec 2025 10:58:57 +0100 +Subject: s390/ipl: Clear SBP flag when bootprog is set + +From: Sven Schnelle + +commit b1aa01d31249bd116b18c7f512d3e46b4b4ad83b upstream. + +With z16 a new flag 'search boot program' was introduced for +list-directed IPL (SCSI, NVMe, ECKD DASD). If this flag is set, +e.g. via selecting the "Automatic" value for the "Boot program +selector" control on an HMC load panel, it is copied to the reipl +structure from the initial ipl structure. When a user now sets a +boot prog via sysfs, the flag is not cleared and the bootloader +will again automatically select the boot program, ignoring user +configuration. + +To avoid that, clear the SBP flag when a bootprog sysfs file is +written. + +Cc: stable@vger.kernel.org +Reviewed-by: Peter Oberparleiter +Reviewed-by: Heiko Carstens +Signed-off-by: Sven Schnelle +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/include/uapi/asm/ipl.h | 1 + arch/s390/kernel/ipl.c | 48 +++++++++++++++++++++++++++++---------- + 2 files changed, 37 insertions(+), 12 deletions(-) + +--- a/arch/s390/include/uapi/asm/ipl.h ++++ b/arch/s390/include/uapi/asm/ipl.h +@@ -15,6 +15,7 @@ struct ipl_pl_hdr { + #define IPL_PL_FLAG_IPLPS 0x80 + #define IPL_PL_FLAG_SIPL 0x40 + #define IPL_PL_FLAG_IPLSR 0x20 ++#define IPL_PL_FLAG_SBP 0x10 + + /* IPL Parameter Block header */ + struct ipl_pb_hdr { +--- a/arch/s390/kernel/ipl.c ++++ b/arch/s390/kernel/ipl.c +@@ -262,6 +262,24 @@ static struct kobj_attribute sys_##_pref + sys_##_prefix##_##_name##_show, \ + sys_##_prefix##_##_name##_store) + ++#define DEFINE_IPL_ATTR_BOOTPROG_RW(_prefix, _name, _fmt_out, _fmt_in, _hdr, _value) \ ++ IPL_ATTR_SHOW_FN(_prefix, _name, _fmt_out, (unsigned long long) _value) \ ++static ssize_t sys_##_prefix##_##_name##_store(struct kobject *kobj, \ ++ struct kobj_attribute *attr, \ ++ const char *buf, size_t len) \ ++{ \ ++ unsigned long long value; \ ++ if (sscanf(buf, _fmt_in, &value) != 1) \ ++ return -EINVAL; \ ++ (_value) = value; \ ++ (_hdr).flags &= ~IPL_PL_FLAG_SBP; \ ++ return len; \ ++} \ ++static struct kobj_attribute sys_##_prefix##_##_name##_attr = \ ++ __ATTR(_name, 0644, \ ++ sys_##_prefix##_##_name##_show, \ ++ sys_##_prefix##_##_name##_store) ++ + #define DEFINE_IPL_ATTR_STR_RW(_prefix, _name, _fmt_out, _fmt_in, _value)\ + IPL_ATTR_SHOW_FN(_prefix, _name, _fmt_out, _value) \ + static ssize_t sys_##_prefix##_##_name##_store(struct kobject *kobj, \ +@@ -818,12 +836,13 @@ DEFINE_IPL_ATTR_RW(reipl_fcp, wwpn, "0x% + reipl_block_fcp->fcp.wwpn); + DEFINE_IPL_ATTR_RW(reipl_fcp, lun, "0x%016llx\n", "%llx\n", + reipl_block_fcp->fcp.lun); +-DEFINE_IPL_ATTR_RW(reipl_fcp, bootprog, "%lld\n", "%lld\n", +- reipl_block_fcp->fcp.bootprog); + DEFINE_IPL_ATTR_RW(reipl_fcp, br_lba, "%lld\n", "%lld\n", + reipl_block_fcp->fcp.br_lba); + DEFINE_IPL_ATTR_RW(reipl_fcp, device, "0.0.%04llx\n", "0.0.%llx\n", + reipl_block_fcp->fcp.devno); ++DEFINE_IPL_ATTR_BOOTPROG_RW(reipl_fcp, bootprog, "%lld\n", "%lld\n", ++ reipl_block_fcp->hdr, ++ reipl_block_fcp->fcp.bootprog); + + static void reipl_get_ascii_loadparm(char *loadparm, + struct ipl_parameter_block *ibp) +@@ -942,10 +961,11 @@ DEFINE_IPL_ATTR_RW(reipl_nvme, fid, "0x% + reipl_block_nvme->nvme.fid); + DEFINE_IPL_ATTR_RW(reipl_nvme, nsid, "0x%08llx\n", "%llx\n", + reipl_block_nvme->nvme.nsid); +-DEFINE_IPL_ATTR_RW(reipl_nvme, bootprog, "%lld\n", "%lld\n", +- reipl_block_nvme->nvme.bootprog); + DEFINE_IPL_ATTR_RW(reipl_nvme, br_lba, "%lld\n", "%lld\n", + reipl_block_nvme->nvme.br_lba); ++DEFINE_IPL_ATTR_BOOTPROG_RW(reipl_nvme, bootprog, "%lld\n", "%lld\n", ++ reipl_block_nvme->hdr, ++ reipl_block_nvme->nvme.bootprog); + + static struct attribute *reipl_nvme_attrs[] = { + &sys_reipl_nvme_fid_attr.attr, +@@ -1038,8 +1058,9 @@ static const struct bin_attribute *const + }; + + DEFINE_IPL_CCW_ATTR_RW(reipl_eckd, device, reipl_block_eckd->eckd); +-DEFINE_IPL_ATTR_RW(reipl_eckd, bootprog, "%lld\n", "%lld\n", +- reipl_block_eckd->eckd.bootprog); ++DEFINE_IPL_ATTR_BOOTPROG_RW(reipl_eckd, bootprog, "%lld\n", "%lld\n", ++ reipl_block_eckd->hdr, ++ reipl_block_eckd->eckd.bootprog); + + static struct attribute *reipl_eckd_attrs[] = { + &sys_reipl_eckd_device_attr.attr, +@@ -1567,12 +1588,13 @@ DEFINE_IPL_ATTR_RW(dump_fcp, wwpn, "0x%0 + dump_block_fcp->fcp.wwpn); + DEFINE_IPL_ATTR_RW(dump_fcp, lun, "0x%016llx\n", "%llx\n", + dump_block_fcp->fcp.lun); +-DEFINE_IPL_ATTR_RW(dump_fcp, bootprog, "%lld\n", "%lld\n", +- dump_block_fcp->fcp.bootprog); + DEFINE_IPL_ATTR_RW(dump_fcp, br_lba, "%lld\n", "%lld\n", + dump_block_fcp->fcp.br_lba); + DEFINE_IPL_ATTR_RW(dump_fcp, device, "0.0.%04llx\n", "0.0.%llx\n", + dump_block_fcp->fcp.devno); ++DEFINE_IPL_ATTR_BOOTPROG_RW(dump_fcp, bootprog, "%lld\n", "%lld\n", ++ dump_block_fcp->hdr, ++ dump_block_fcp->fcp.bootprog); + + DEFINE_IPL_ATTR_SCP_DATA_RW(dump_fcp, dump_block_fcp->hdr, + dump_block_fcp->fcp, +@@ -1604,10 +1626,11 @@ DEFINE_IPL_ATTR_RW(dump_nvme, fid, "0x%0 + dump_block_nvme->nvme.fid); + DEFINE_IPL_ATTR_RW(dump_nvme, nsid, "0x%08llx\n", "%llx\n", + dump_block_nvme->nvme.nsid); +-DEFINE_IPL_ATTR_RW(dump_nvme, bootprog, "%lld\n", "%llx\n", +- dump_block_nvme->nvme.bootprog); + DEFINE_IPL_ATTR_RW(dump_nvme, br_lba, "%lld\n", "%llx\n", + dump_block_nvme->nvme.br_lba); ++DEFINE_IPL_ATTR_BOOTPROG_RW(dump_nvme, bootprog, "%lld\n", "%llx\n", ++ dump_block_nvme->hdr, ++ dump_block_nvme->nvme.bootprog); + + DEFINE_IPL_ATTR_SCP_DATA_RW(dump_nvme, dump_block_nvme->hdr, + dump_block_nvme->nvme, +@@ -1635,8 +1658,9 @@ static const struct attribute_group dump + + /* ECKD dump device attributes */ + DEFINE_IPL_CCW_ATTR_RW(dump_eckd, device, dump_block_eckd->eckd); +-DEFINE_IPL_ATTR_RW(dump_eckd, bootprog, "%lld\n", "%llx\n", +- dump_block_eckd->eckd.bootprog); ++DEFINE_IPL_ATTR_BOOTPROG_RW(dump_eckd, bootprog, "%lld\n", "%llx\n", ++ dump_block_eckd->hdr, ++ dump_block_eckd->eckd.bootprog); + + IPL_ATTR_BR_CHR_SHOW_FN(dump, dump_block_eckd->eckd); + IPL_ATTR_BR_CHR_STORE_FN(dump, dump_block_eckd->eckd); diff --git a/queue-6.18/scs-fix-a-wrong-parameter-in-__scs_magic.patch b/queue-6.18/scs-fix-a-wrong-parameter-in-__scs_magic.patch new file mode 100644 index 0000000000..be4dddd40d --- /dev/null +++ b/queue-6.18/scs-fix-a-wrong-parameter-in-__scs_magic.patch @@ -0,0 +1,65 @@ +From 08bd4c46d5e63b78e77f2605283874bbe868ab19 Mon Sep 17 00:00:00 2001 +From: Zhichi Lin +Date: Sat, 11 Oct 2025 16:22:22 +0800 +Subject: scs: fix a wrong parameter in __scs_magic + +From: Zhichi Lin + +commit 08bd4c46d5e63b78e77f2605283874bbe868ab19 upstream. + +__scs_magic() needs a 'void *' variable, but a 'struct task_struct *' is +given. 'task_scs(tsk)' is the starting address of the task's shadow call +stack, and '__scs_magic(task_scs(tsk))' is the end address of the task's +shadow call stack. Here should be '__scs_magic(task_scs(tsk))'. + +The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE +is enabled, the shadow call stack usage checking function +(scs_check_usage) would scan an incorrect memory range. This could lead +to: + +1. **Inaccurate stack usage reporting**: The function would calculate + wrong usage statistics for the shadow call stack, potentially showing + incorrect value in kmsg. + +2. **Potential kernel crash**: If the value of __scs_magic(tsk)is + greater than that of __scs_magic(task_scs(tsk)), the for loop may + access unmapped memory, potentially causing a kernel panic. However, + this scenario is unlikely because task_struct is allocated via the slab + allocator (which typically returns lower addresses), while the shadow + call stack returned by task_scs(tsk) is allocated via vmalloc(which + typically returns higher addresses). + +However, since this is purely a debugging feature +(CONFIG_DEBUG_STACK_USAGE), normal production systems should be not +unaffected. The bug only impacts developers and testers who are actively +debugging stack usage with this configuration enabled. + +Link: https://lkml.kernel.org/r/20251011082222.12965-1-zhichi.lin@vivo.com +Fixes: 5bbaf9d1fcb9 ("scs: Add support for stack usage debugging") +Signed-off-by: Jiyuan Xie +Signed-off-by: Zhichi Lin +Reviewed-by: Sami Tolvanen +Acked-by: Will Deacon +Cc: Andrey Konovalov +Cc: Kees Cook +Cc: Marco Elver +Cc: Will Deacon +Cc: Yee Lee +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + kernel/scs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/scs.c ++++ b/kernel/scs.c +@@ -135,7 +135,7 @@ static void scs_check_usage(struct task_ + if (!IS_ENABLED(CONFIG_DEBUG_STACK_USAGE)) + return; + +- for (p = task_scs(tsk); p < __scs_magic(tsk); ++p) { ++ for (p = task_scs(tsk); p < __scs_magic(task_scs(tsk)); ++p) { + if (!READ_ONCE_NOCHECK(*p)) + break; + used += sizeof(*p); diff --git a/queue-6.18/series b/queue-6.18/series index e2f0ea6f6c..260254fe25 100644 --- a/queue-6.18/series +++ b/queue-6.18/series @@ -321,3 +321,64 @@ f2fs-fix-uninitialized-one_time_gc-in-victim_sel_policy.patch f2fs-fix-to-detect-recoverable-inode-during-dryrun-of-find_fsync_dnodes.patch f2fs-fix-to-not-account-invalid-blocks-in-get_left_section_blocks.patch f2fs-fix-return-value-of-f2fs_recover_fsync_data.patch +tools-testing-nvdimm-use-per-dimm-device-handle.patch +pinctrl-renesas-rzg2l-fix-isel-restore-on-resume.patch +kvm-disallow-toggling-kvm_mem_guest_memfd-on-an-existing-memslot.patch +mm-slub-reset-kasan-tag-in-defer_free-before-accessing-freed-memory.patch +media-vidtv-initialize-local-pointers-upon-transfer-of-memory-ownership.patch +ocfs2-fix-kernel-bug-in-ocfs2_find_victim_chain.patch +kvm-x86-don-t-clear-async-pf-queue-when-cr0.pg-is-disabled-e.g.-on-smi.patch +platform-chrome-cros_ec_ishtp-fix-uaf-after-unbinding-driver.patch +media-iris-add-sanity-check-for-stop-streaming.patch +scs-fix-a-wrong-parameter-in-__scs_magic.patch +parisc-do-not-reprogram-affinitiy-on-asp-chip.patch +dm-pcache-advance-slot-index-before-writing-slot.patch +lib-crypto-riscv-chacha-avoid-s0-fp-register.patch +libceph-make-decode_pool-more-resilient-against-corrupted-osdmaps.patch +powerpc-add-reloc_offset-to-font-bitmap-pointer-used-for-bootx_printf.patch +kvm-x86-warn-if-hrtimer-callback-for-periodic-apic-timer-fires-with-period-0.patch +kvm-x86-explicitly-set-new-periodic-hrtimer-expiration-in-apic_timer_fn.patch +kvm-x86-fix-vm-hard-lockup-after-prolonged-inactivity-with-periodic-hv-timer.patch +kvm-nsvm-avoid-incorrect-injection-of-svm_exit_cr0_sel_write.patch +kvm-svm-mark-vmcb_npt-as-dirty-on-nested-vmrun.patch +kvm-selftests-forcefully-override-arch-from-x86_64-to-x86.patch +kvm-nsvm-propagate-svm_exit_cr0_sel_write-correctly-for-lmsw-emulation.patch +kvm-fix-last_boosted_vcpu-index-assignment-bug.patch +kvm-svm-mark-vmcb_perm_map-as-dirty-on-nested-vmrun.patch +kvm-tdx-explicitly-set-user-return-msrs-that-may-be-clobbered-by-the-tdx-module.patch +kvm-nvmx-immediately-refresh-apicv-controls-as-needed-on-nested-vm-exit.patch +kvm-nsvm-set-exit_code_hi-to-1-when-synthesizing-svm_exit_err-failed-vmrun.patch +kvm-nsvm-clear-exit_code_hi-in-vmcb-when-synthesizing-nested-vm-exits.patch +kvm-x86-apply-runtime-updates-to-current-cpuid-during-kvm_set_cpuid-2.patch +kvm-selftests-add-missing-break-in-rseq_test-s-param-parsing.patch +xfs-fix-a-memory-leak-in-xfs_buf_item_init.patch +xfs-fix-stupid-compiler-warning.patch +xfs-fix-the-zoned-rt-growfs-check-for-zone-alignment.patch +xfs-fix-a-uaf-problem-in-xattr-repair.patch +xfs-validate-that-zoned-rt-devices-are-zone-aligned.patch +tracing-do-not-register-unsupported-perf-events.patch +pm-runtime-do-not-clear-needs_force_resume-with-enabled-runtime-pm.patch +arm64-gcs-flush-the-gcs-locking-state-on-exec.patch +lib-crypto-riscv-add-poly1305-core.s-to-.gitignore.patch +r8169-fix-rtl8117-wake-on-lan-in-dash-mode.patch +net-phy-marvell-88q2xxx-fix-clamped-value-in-mv88q2xxx_hwmon_write.patch +fsnotify-do-not-generate-access-modify-events-on-child-for-special-files.patch +net-handshake-restore-destructor-on-submit-failure.patch +nfsd-clear-seclabel-in-the-suppattr_exclcreat-bitmap.patch +nfsd-nfsv4-file-creation-neglects-setting-acl.patch +asoc-sof-ipc4-topology-prefer-32-bit-dmic-blobs-for-8-bit-formats-as-well.patch +alsa-hda-realtek-add-asus-quirk-for-tas-amplifiers.patch +nfsd-clear-time_deleg-in-the-suppattr_exclcreat-bitmap.patch +asoc-sof-ipc4-topology-convert-float-to-s32-during-blob-selection.patch +svcrdma-bound-check-rq_pages-index-in-inline-path.patch +nfsd-mark-variable-__maybe_unused-to-avoid-w-1-build-break.patch +svcrdma-return-0-on-success-from-svc_rdma_copy_inline_range.patch +svcrdma-use-rc_pageoff-for-memcpy-byte-offset.patch +sunrpc-svcauth_gss-avoid-null-deref-on-zero-length-gss_token-in-gss_read_proxy_verf.patch +powerpc-kexec-enable-smt-before-waking-offline-cpus.patch +btrfs-don-t-log-conflicting-inode-if-it-s-a-dir-moved-in-the-current-transaction.patch +cgroup-rstat-use-lock-cmpxchg-in-css_rstat_updated.patch +s390-ipl-clear-sbp-flag-when-bootprog-is-set.patch +gpio-regmap-fix-memleak-in-error-path-in-gpio_regmap_register.patch +gpiolib-acpi-add-quirk-for-dell-precision-7780.patch +gpio-loongson-switch-2k2000-3000-gpio-to-byte_ctrl_mode.patch diff --git a/queue-6.18/sunrpc-svcauth_gss-avoid-null-deref-on-zero-length-gss_token-in-gss_read_proxy_verf.patch b/queue-6.18/sunrpc-svcauth_gss-avoid-null-deref-on-zero-length-gss_token-in-gss_read_proxy_verf.patch new file mode 100644 index 0000000000..ef1ab578f1 --- /dev/null +++ b/queue-6.18/sunrpc-svcauth_gss-avoid-null-deref-on-zero-length-gss_token-in-gss_read_proxy_verf.patch @@ -0,0 +1,36 @@ +From d4b69a6186b215d2dc1ebcab965ed88e8d41768d Mon Sep 17 00:00:00 2001 +From: Joshua Rogers +Date: Fri, 7 Nov 2025 10:05:33 -0500 +Subject: SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf + +From: Joshua Rogers + +commit d4b69a6186b215d2dc1ebcab965ed88e8d41768d upstream. + +A zero length gss_token results in pages == 0 and in_token->pages[0] +is NULL. The code unconditionally evaluates +page_address(in_token->pages[0]) for the initial memcpy, which can +dereference NULL even when the copy length is 0. Guard the first +memcpy so it only runs when length > 0. + +Fixes: 5866efa8cbfb ("SUNRPC: Fix svcauth_gss_proxy_init()") +Cc: stable@vger.kernel.org +Signed-off-by: Joshua Rogers +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + net/sunrpc/auth_gss/svcauth_gss.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/sunrpc/auth_gss/svcauth_gss.c ++++ b/net/sunrpc/auth_gss/svcauth_gss.c +@@ -1083,7 +1083,8 @@ static int gss_read_proxy_verf(struct sv + } + + length = min_t(unsigned int, inlen, (char *)xdr->end - (char *)xdr->p); +- memcpy(page_address(in_token->pages[0]), xdr->p, length); ++ if (length) ++ memcpy(page_address(in_token->pages[0]), xdr->p, length); + inlen -= length; + + to_offs = length; diff --git a/queue-6.18/svcrdma-bound-check-rq_pages-index-in-inline-path.patch b/queue-6.18/svcrdma-bound-check-rq_pages-index-in-inline-path.patch new file mode 100644 index 0000000000..a7b27c895f --- /dev/null +++ b/queue-6.18/svcrdma-bound-check-rq_pages-index-in-inline-path.patch @@ -0,0 +1,34 @@ +From d1bea0ce35b6095544ee82bb54156fc62c067e58 Mon Sep 17 00:00:00 2001 +From: Joshua Rogers +Date: Fri, 7 Nov 2025 10:09:49 -0500 +Subject: svcrdma: bound check rq_pages index in inline path + +From: Joshua Rogers + +commit d1bea0ce35b6095544ee82bb54156fc62c067e58 upstream. + +svc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] without +verifying rc_curpage stays within the allocated page array. Add guards +before the first use and after advancing to a new page. + +Fixes: d7cc73972661 ("svcrdma: support multiple Read chunks per RPC") +Cc: stable@vger.kernel.org +Signed-off-by: Joshua Rogers +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + net/sunrpc/xprtrdma/svc_rdma_rw.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/net/sunrpc/xprtrdma/svc_rdma_rw.c ++++ b/net/sunrpc/xprtrdma/svc_rdma_rw.c +@@ -841,6 +841,9 @@ static int svc_rdma_copy_inline_range(st + for (page_no = 0; page_no < numpages; page_no++) { + unsigned int page_len; + ++ if (head->rc_curpage >= rqstp->rq_maxpages) ++ return -EINVAL; ++ + page_len = min_t(unsigned int, remaining, + PAGE_SIZE - head->rc_pageoff); + diff --git a/queue-6.18/svcrdma-return-0-on-success-from-svc_rdma_copy_inline_range.patch b/queue-6.18/svcrdma-return-0-on-success-from-svc_rdma_copy_inline_range.patch new file mode 100644 index 0000000000..8f3ed6b9b2 --- /dev/null +++ b/queue-6.18/svcrdma-return-0-on-success-from-svc_rdma_copy_inline_range.patch @@ -0,0 +1,32 @@ +From 94972027ab55b200e031059fd6c7a649f8248020 Mon Sep 17 00:00:00 2001 +From: Joshua Rogers +Date: Fri, 7 Nov 2025 10:09:48 -0500 +Subject: svcrdma: return 0 on success from svc_rdma_copy_inline_range + +From: Joshua Rogers + +commit 94972027ab55b200e031059fd6c7a649f8248020 upstream. + +The function comment specifies 0 on success and -EINVAL on invalid +parameters. Make the tail return 0 after a successful copy loop. + +Fixes: d7cc73972661 ("svcrdma: support multiple Read chunks per RPC") +Cc: stable@vger.kernel.org +Signed-off-by: Joshua Rogers +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + net/sunrpc/xprtrdma/svc_rdma_rw.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/sunrpc/xprtrdma/svc_rdma_rw.c ++++ b/net/sunrpc/xprtrdma/svc_rdma_rw.c +@@ -863,7 +863,7 @@ static int svc_rdma_copy_inline_range(st + offset += page_len; + } + +- return -EINVAL; ++ return 0; + } + + /** diff --git a/queue-6.18/svcrdma-use-rc_pageoff-for-memcpy-byte-offset.patch b/queue-6.18/svcrdma-use-rc_pageoff-for-memcpy-byte-offset.patch new file mode 100644 index 0000000000..3074435fce --- /dev/null +++ b/queue-6.18/svcrdma-use-rc_pageoff-for-memcpy-byte-offset.patch @@ -0,0 +1,35 @@ +From a8ee9099f30654917aa68f55d707b5627e1dbf77 Mon Sep 17 00:00:00 2001 +From: Joshua Rogers +Date: Fri, 7 Nov 2025 10:09:47 -0500 +Subject: svcrdma: use rc_pageoff for memcpy byte offset + +From: Joshua Rogers + +commit a8ee9099f30654917aa68f55d707b5627e1dbf77 upstream. + +svc_rdma_copy_inline_range added rc_curpage (page index) to the page +base instead of the byte offset rc_pageoff. Use rc_pageoff so copies +land within the current page. + +Found by ZeroPath (https://zeropath.com) + +Fixes: 8e122582680c ("svcrdma: Move svc_rdma_read_info::ri_pageno to struct svc_rdma_recv_ctxt") +Cc: stable@vger.kernel.org +Signed-off-by: Joshua Rogers +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + net/sunrpc/xprtrdma/svc_rdma_rw.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/sunrpc/xprtrdma/svc_rdma_rw.c ++++ b/net/sunrpc/xprtrdma/svc_rdma_rw.c +@@ -851,7 +851,7 @@ static int svc_rdma_copy_inline_range(st + head->rc_page_count++; + + dst = page_address(rqstp->rq_pages[head->rc_curpage]); +- memcpy(dst + head->rc_curpage, src + offset, page_len); ++ memcpy((unsigned char *)dst + head->rc_pageoff, src + offset, page_len); + + head->rc_readbytes += page_len; + head->rc_pageoff += page_len; diff --git a/queue-6.18/tools-testing-nvdimm-use-per-dimm-device-handle.patch b/queue-6.18/tools-testing-nvdimm-use-per-dimm-device-handle.patch new file mode 100644 index 0000000000..1f1a453134 --- /dev/null +++ b/queue-6.18/tools-testing-nvdimm-use-per-dimm-device-handle.patch @@ -0,0 +1,61 @@ +From f59b701b4674f7955170b54c4167c5590f4714eb Mon Sep 17 00:00:00 2001 +From: Alison Schofield +Date: Fri, 31 Oct 2025 16:42:20 -0700 +Subject: tools/testing/nvdimm: Use per-DIMM device handle + +From: Alison Schofield + +commit f59b701b4674f7955170b54c4167c5590f4714eb upstream. + +KASAN reports a global-out-of-bounds access when running these nfit +tests: clear.sh, pmem-errors.sh, pfn-meta-errors.sh, btt-errors.sh, +daxdev-errors.sh, and inject-error.sh. + +[] BUG: KASAN: global-out-of-bounds in nfit_test_ctl+0x769f/0x7840 [nfit_test] +[] Read of size 4 at addr ffffffffc03ea01c by task ndctl/1215 +[] The buggy address belongs to the variable: +[] handle+0x1c/0x1df4 [nfit_test] + +nfit_test_search_spa() uses handle[nvdimm->id] to retrieve a device +handle and triggers a KASAN error when it reads past the end of the +handle array. It should not be indexing the handle array at all. + +The correct device handle is stored in per-DIMM test data. Each DIMM +has a struct nfit_mem that embeds a struct acpi_nfit_memdev that +describes the NFIT device handle. Use that device handle here. + +Fixes: 10246dc84dfc ("acpi nfit: nfit_test supports translate SPA") +Cc: stable@vger.kernel.org +Signed-off-by: Alison Schofield +Reviewed-by: Dave Jiang > --- +Link: https://patch.msgid.link/20251031234227.1303113-1-alison.schofield@intel.com +Signed-off-by: Ira Weiny +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/nvdimm/test/nfit.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/tools/testing/nvdimm/test/nfit.c ++++ b/tools/testing/nvdimm/test/nfit.c +@@ -670,6 +670,7 @@ static int nfit_test_search_spa(struct n + .addr = spa->spa, + .region = NULL, + }; ++ struct nfit_mem *nfit_mem; + u64 dpa; + + ret = device_for_each_child(&bus->dev, &ctx, +@@ -687,8 +688,12 @@ static int nfit_test_search_spa(struct n + */ + nd_mapping = &nd_region->mapping[nd_region->ndr_mappings - 1]; + nvdimm = nd_mapping->nvdimm; ++ nfit_mem = nvdimm_provider_data(nvdimm); ++ if (!nfit_mem) ++ return -EINVAL; + +- spa->devices[0].nfit_device_handle = handle[nvdimm->id]; ++ spa->devices[0].nfit_device_handle = ++ __to_nfit_memdev(nfit_mem)->device_handle; + spa->num_nvdimms = 1; + spa->devices[0].dpa = dpa; + diff --git a/queue-6.18/tracing-do-not-register-unsupported-perf-events.patch b/queue-6.18/tracing-do-not-register-unsupported-perf-events.patch new file mode 100644 index 0000000000..6de2cd0550 --- /dev/null +++ b/queue-6.18/tracing-do-not-register-unsupported-perf-events.patch @@ -0,0 +1,82 @@ +From ef7f38df890f5dcd2ae62f8dbde191d72f3bebae Mon Sep 17 00:00:00 2001 +From: Steven Rostedt +Date: Tue, 16 Dec 2025 18:24:40 -0500 +Subject: tracing: Do not register unsupported perf events + +From: Steven Rostedt + +commit ef7f38df890f5dcd2ae62f8dbde191d72f3bebae upstream. + +Synthetic events currently do not have a function to register perf events. +This leads to calling the tracepoint register functions with a NULL +function pointer which triggers: + + ------------[ cut here ]------------ + WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 + Modules linked in: kvm_intel kvm irqbypass + CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 + RIP: 0010:tracepoint_add_func+0x357/0x370 + Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f + RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 + RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 + RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 + RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 + R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a + R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 + FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 + Call Trace: + + tracepoint_probe_register+0x5d/0x90 + synth_event_reg+0x3c/0x60 + perf_trace_event_init+0x204/0x340 + perf_trace_init+0x85/0xd0 + perf_tp_event_init+0x2e/0x50 + perf_try_init_event+0x6f/0x230 + ? perf_event_alloc+0x4bb/0xdc0 + perf_event_alloc+0x65a/0xdc0 + __se_sys_perf_event_open+0x290/0x9f0 + do_syscall_64+0x93/0x7b0 + ? entry_SYSCALL_64_after_hwframe+0x76/0x7e + ? trace_hardirqs_off+0x53/0xc0 + entry_SYSCALL_64_after_hwframe+0x76/0x7e + +Instead, have the code return -ENODEV, which doesn't warn and has perf +error out with: + + # perf record -e synthetic:futex_wait +Error: +The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait). +"dmesg | grep -i perf" may provide additional information. + +Ideally perf should support synthetic events, but for now just fix the +warning. The support can come later. + +Cc: stable@vger.kernel.org +Cc: Masami Hiramatsu +Cc: Mathieu Desnoyers +Cc: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: Namhyung Kim +Link: https://patch.msgid.link/20251216182440.147e4453@gandalf.local.home +Fixes: 4b147936fa509 ("tracing: Add support for 'synthetic' events") +Reported-by: Ian Rogers +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace_events.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/kernel/trace/trace_events.c ++++ b/kernel/trace/trace_events.c +@@ -700,6 +700,8 @@ int trace_event_reg(struct trace_event_c + + #ifdef CONFIG_PERF_EVENTS + case TRACE_REG_PERF_REGISTER: ++ if (!call->class->perf_probe) ++ return -ENODEV; + return tracepoint_probe_register(call->tp, + call->class->perf_probe, + call); diff --git a/queue-6.18/xfs-fix-a-memory-leak-in-xfs_buf_item_init.patch b/queue-6.18/xfs-fix-a-memory-leak-in-xfs_buf_item_init.patch new file mode 100644 index 0000000000..1edde9ebbb --- /dev/null +++ b/queue-6.18/xfs-fix-a-memory-leak-in-xfs_buf_item_init.patch @@ -0,0 +1,33 @@ +From fc40459de82543b565ebc839dca8f7987f16f62e Mon Sep 17 00:00:00 2001 +From: Haoxiang Li +Date: Wed, 10 Dec 2025 17:06:01 +0800 +Subject: xfs: fix a memory leak in xfs_buf_item_init() + +From: Haoxiang Li + +commit fc40459de82543b565ebc839dca8f7987f16f62e upstream. + +xfs_buf_item_get_format() may allocate memory for bip->bli_formats, +free the memory in the error path. + +Fixes: c3d5f0c2fb85 ("xfs: complain if anyone tries to create a too-large buffer log item") +Cc: stable@vger.kernel.org +Signed-off-by: Haoxiang Li +Reviewed-by: Christoph Hellwig +Reviewed-by: Carlos Maiolino +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_buf_item.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/xfs/xfs_buf_item.c ++++ b/fs/xfs/xfs_buf_item.c +@@ -896,6 +896,7 @@ xfs_buf_item_init( + map_size = DIV_ROUND_UP(chunks, NBWORD); + + if (map_size > XFS_BLF_DATAMAP_SIZE) { ++ xfs_buf_item_free_format(bip); + kmem_cache_free(xfs_buf_item_cache, bip); + xfs_err(mp, + "buffer item dirty bitmap (%u uints) too small to reflect %u bytes!", diff --git a/queue-6.18/xfs-fix-a-uaf-problem-in-xattr-repair.patch b/queue-6.18/xfs-fix-a-uaf-problem-in-xattr-repair.patch new file mode 100644 index 0000000000..b8c200f126 --- /dev/null +++ b/queue-6.18/xfs-fix-a-uaf-problem-in-xattr-repair.patch @@ -0,0 +1,42 @@ +From 5990fd756943836978ad184aac980e2b36ab7e01 Mon Sep 17 00:00:00 2001 +From: "Darrick J. Wong" +Date: Thu, 4 Dec 2025 13:43:50 -0800 +Subject: xfs: fix a UAF problem in xattr repair + +From: Darrick J. Wong + +commit 5990fd756943836978ad184aac980e2b36ab7e01 upstream. + +The xchk_setup_xattr_buf function can allocate a new value buffer, which +means that any reference to ab->value before the call could become a +dangling pointer. Fix this by moving an assignment to after the buffer +setup. + +Cc: stable@vger.kernel.org # v6.10 +Fixes: e47dcf113ae348 ("xfs: repair extended attributes") +Signed-off-by: Darrick J. Wong +Reviewed-by: Christoph Hellwig +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/scrub/attr_repair.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/xfs/scrub/attr_repair.c ++++ b/fs/xfs/scrub/attr_repair.c +@@ -333,7 +333,6 @@ xrep_xattr_salvage_remote_attr( + .attr_filter = ent->flags & XFS_ATTR_NSP_ONDISK_MASK, + .namelen = rentry->namelen, + .name = rentry->name, +- .value = ab->value, + .valuelen = be32_to_cpu(rentry->valuelen), + }; + unsigned int namesize; +@@ -363,6 +362,7 @@ xrep_xattr_salvage_remote_attr( + error = -EDEADLOCK; + if (error) + return error; ++ args.value = ab->value; + + /* Look up the remote value and stash it for reconstruction. */ + error = xfs_attr3_leaf_getvalue(leaf_bp, &args); diff --git a/queue-6.18/xfs-fix-stupid-compiler-warning.patch b/queue-6.18/xfs-fix-stupid-compiler-warning.patch new file mode 100644 index 0000000000..eaeaa60eeb --- /dev/null +++ b/queue-6.18/xfs-fix-stupid-compiler-warning.patch @@ -0,0 +1,49 @@ +From f06725052098d7b1133ac3846d693c383dc427a2 Mon Sep 17 00:00:00 2001 +From: "Darrick J. Wong" +Date: Thu, 4 Dec 2025 13:44:15 -0800 +Subject: xfs: fix stupid compiler warning +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Darrick J. Wong + +commit f06725052098d7b1133ac3846d693c383dc427a2 upstream. + +gcc 14.2 warns about: + +xfs_attr_item.c: In function ‘xfs_attr_recover_work’: +xfs_attr_item.c:785:9: warning: ‘ip’ may be used uninitialized [-Wmaybe-uninitialized] + 785 | xfs_trans_ijoin(tp, ip, 0); + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +xfs_attr_item.c:740:42: note: ‘ip’ was declared here + 740 | struct xfs_inode *ip; + | ^~ + +I think this is bogus since xfs_attri_recover_work either returns a real +pointer having initialized ip or an ERR_PTR having not touched it, but +the tools are smarter than me so let's just null-init the variable +anyway. + +Cc: stable@vger.kernel.org # v6.8 +Fixes: e70fb328d52772 ("xfs: recreate work items when recovering intent items") +Signed-off-by: Darrick J. Wong +Reviewed-by: Carlos Maiolino +Reviewed-by: Christoph Hellwig +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_attr_item.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/xfs/xfs_attr_item.c ++++ b/fs/xfs/xfs_attr_item.c +@@ -737,7 +737,7 @@ xfs_attr_recover_work( + struct xfs_attri_log_item *attrip = ATTRI_ITEM(lip); + struct xfs_attr_intent *attr; + struct xfs_mount *mp = lip->li_log->l_mp; +- struct xfs_inode *ip; ++ struct xfs_inode *ip = NULL; + struct xfs_da_args *args; + struct xfs_trans *tp; + struct xfs_trans_res resv; diff --git a/queue-6.18/xfs-fix-the-zoned-rt-growfs-check-for-zone-alignment.patch b/queue-6.18/xfs-fix-the-zoned-rt-growfs-check-for-zone-alignment.patch new file mode 100644 index 0000000000..b23afe28ad --- /dev/null +++ b/queue-6.18/xfs-fix-the-zoned-rt-growfs-check-for-zone-alignment.patch @@ -0,0 +1,68 @@ +From dc68c0f601691010dd5ae53442f8523f41a53131 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Tue, 16 Dec 2025 18:30:09 +0100 +Subject: xfs: fix the zoned RT growfs check for zone alignment + +From: Christoph Hellwig + +commit dc68c0f601691010dd5ae53442f8523f41a53131 upstream. + +The grofs code for zoned RT subvolums already tries to check for zone +alignment, but gets it wrong by using the old instead of the new mount +structure. + +Fixes: 01b71e64bb87 ("xfs: support growfs on zoned file systems") +Signed-off-by: Christoph Hellwig +Reviewed-by: Darrick J. Wong +Cc: stable@vger.kernel.org # v6.15 +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_rtalloc.c | 14 ++++++++------ + 1 file changed, 8 insertions(+), 6 deletions(-) + +diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c +index 6907e871fa15..e063f4f2f2e6 100644 +--- a/fs/xfs/xfs_rtalloc.c ++++ b/fs/xfs/xfs_rtalloc.c +@@ -1255,12 +1255,10 @@ xfs_growfs_check_rtgeom( + min_logfsbs = min_t(xfs_extlen_t, xfs_log_calc_minimum_size(nmp), + nmp->m_rsumblocks * 2); + +- kfree(nmp); +- + trace_xfs_growfs_check_rtgeom(mp, min_logfsbs); + + if (min_logfsbs > mp->m_sb.sb_logblocks) +- return -EINVAL; ++ goto out_inval; + + if (xfs_has_zoned(mp)) { + uint32_t gblocks = mp->m_groups[XG_TYPE_RTG].blocks; +@@ -1268,16 +1266,20 @@ xfs_growfs_check_rtgeom( + + if (rextsize != 1) + return -EINVAL; +- div_u64_rem(mp->m_sb.sb_rblocks, gblocks, &rem); ++ div_u64_rem(nmp->m_sb.sb_rblocks, gblocks, &rem); + if (rem) { + xfs_warn(mp, + "new RT volume size (%lld) not aligned to RT group size (%d)", +- mp->m_sb.sb_rblocks, gblocks); +- return -EINVAL; ++ nmp->m_sb.sb_rblocks, gblocks); ++ goto out_inval; + } + } + ++ kfree(nmp); + return 0; ++out_inval: ++ kfree(nmp); ++ return -EINVAL; + } + + /* +-- +2.52.0 + diff --git a/queue-6.18/xfs-validate-that-zoned-rt-devices-are-zone-aligned.patch b/queue-6.18/xfs-validate-that-zoned-rt-devices-are-zone-aligned.patch new file mode 100644 index 0000000000..9eeb610f1d --- /dev/null +++ b/queue-6.18/xfs-validate-that-zoned-rt-devices-are-zone-aligned.patch @@ -0,0 +1,52 @@ +From 982d2616a2906113e433fdc0cfcc122f8d1bb60a Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Tue, 16 Dec 2025 18:30:08 +0100 +Subject: xfs: validate that zoned RT devices are zone aligned + +From: Christoph Hellwig + +commit 982d2616a2906113e433fdc0cfcc122f8d1bb60a upstream. + +Garbage collection assumes all zones contain the full amount of blocks. +Mkfs already ensures this happens, but make the kernel check it as well +to avoid getting into trouble due to fuzzers or mkfs bugs. + +Fixes: 2167eaabe2fa ("xfs: define the zoned on-disk format") +Signed-off-by: Christoph Hellwig +Reviewed-by: Darrick J. Wong +Cc: stable@vger.kernel.org # v6.15 +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/libxfs/xfs_sb.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c +index cdd16dd805d7..94c272a2ae26 100644 +--- a/fs/xfs/libxfs/xfs_sb.c ++++ b/fs/xfs/libxfs/xfs_sb.c +@@ -301,6 +301,21 @@ xfs_validate_rt_geometry( + sbp->sb_rbmblocks != xfs_expected_rbmblocks(sbp)) + return false; + ++ if (xfs_sb_is_v5(sbp) && ++ (sbp->sb_features_incompat & XFS_SB_FEAT_INCOMPAT_ZONED)) { ++ uint32_t mod; ++ ++ /* ++ * Zoned RT devices must be aligned to the RT group size, ++ * because garbage collection assumes that all zones have the ++ * same size to avoid insane complexity if that weren't the ++ * case. ++ */ ++ div_u64_rem(sbp->sb_rextents, sbp->sb_rgextents, &mod); ++ if (mod) ++ return false; ++ } ++ + return true; + } + +-- +2.52.0 +