From: Greg Kroah-Hartman Date: Mon, 20 Oct 2025 08:18:40 +0000 (+0200) Subject: 6.17-stable patches X-Git-Tag: v6.6.114~39 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5e7b82310046037792a9926862619d5bbbfd2582;p=thirdparty%2Fkernel%2Fstable-queue.git 6.17-stable patches added patches: alsa-hda-cs35l41-fix-null-pointer-dereference-in-cs35l41_get_acpi_mute_state.patch alsa-hda-fix-missing-pointer-check-in-hda_component_manager_init-function.patch alsa-hda-intel-add-msi-x870e-tomahawk-to-denylist.patch alsa-hda-realtek-add-quirk-entry-for-hp-zbook-17-g6.patch arm64-sysreg-fix-gic-cdeoi-instruction-encoding.patch ata-libata-core-relax-checks-in-ata_read_log_directory.patch btrfs-do-not-assert-we-found-block-group-item-when-creating-free-space-tree.patch btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch btrfs-fix-incorrect-readahead-expansion-length.patch btrfs-fix-memory-leak-on-duplicated-memory-in-the-qgroup-assign-ioctl.patch btrfs-fix-memory-leaks-when-rejecting-a-non-single-data-profile-without-an-rst.patch btrfs-only-set-the-device-specific-options-after-devices-are-opened.patch can-gs_usb-gs_make_candev-populate-net_device-dev_port.patch can-gs_usb-increase-max-interface-to-u8_max.patch cifs-parse_dfs_referrals-prevent-oob-on-malformed-input.patch cxl-acpi-fix-setup-of-memory-resource-in-cxl_acpi_set_cache_size.patch docs-kdoc-handle-the-obsolescensce-of-docutils.errorstring.patch drm-amdgpu-fix-gfx12-mes-packet-status-return-check.patch drm-amdgpu-use-atomic-functions-with-memory-barriers-for-vm-fault-info.patch drm-ast-blank-with-vgacr17-sync-enable-always-clear-vgacrb6-sync-off.patch drm-sched-fix-potential-double-free-in-drm_sched_job_add_resv_dependencies.patch drm-xe-guc-check-guc-running-state-before-deregistering-exec-queue.patch drm-xe-increase-global-invalidation-timeout-to-1000us.patch ext4-detect-invalid-inline_data-extents-flag-combination.patch ext4-wait-for-ongoing-i-o-to-complete-before-freeing-blocks.patch f2fs-fix-wrong-block-mapping-for-multi-devices.patch gve-check-valid-ts-bit-on-rx-descriptor-before-hw-timestamping.patch io_uring-protect-mem-region-deregistration.patch ixgbevf-fix-getting-link-speed-data-for-e610-devices.patch ixgbevf-fix-mailbox-api-compatibility-by-negotiating-supported-features.patch jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch kvm-arm64-prevent-access-to-vcpu-events-before-init.patch net-usb-lan78xx-fix-lost-eeprom-write-timeout-error-etimedout-in-lan78xx_write_raw_eeprom.patch pci-vmd-override-irq_startup-irq_shutdown-in-vmd_init_dev_msi_info.patch perf-core-fix-address-filter-match-with-backing-files.patch perf-core-fix-mmap-event-path-names-with-backing-files.patch perf-core-fix-mmap2-event-device-with-backing-files.patch r8152-add-error-handling-in-rtl8152_driver_init.patch revert-drm-amd-display-only-restore-backlight-after-amdgpu_dm_init-or-dm_resume.patch revert-fs-make-vfs_fileattr_-return-eopnotsupp.patch revert-io_uring-rw-drop-eopnotsupp-check-in-__io_complete_rw_common.patch rust-cfi-only-64-bit-arm-and-x86-support-cfi_clang.patch series slab-reset-slab-obj_ext-when-freeing-and-it-is-objexts_alloc_fail.patch smb-client-fix-refcount-leak-for-cifs_sb_tlink.patch vfs-don-t-leak-disconnected-dentries-on-umount.patch x86-cpu-amd-prevent-reset-reasons-from-being-retained-across-reboot.patch --- diff --git a/queue-6.17/alsa-hda-cs35l41-fix-null-pointer-dereference-in-cs35l41_get_acpi_mute_state.patch b/queue-6.17/alsa-hda-cs35l41-fix-null-pointer-dereference-in-cs35l41_get_acpi_mute_state.patch new file mode 100644 index 0000000000..f1baaa68ef --- /dev/null +++ b/queue-6.17/alsa-hda-cs35l41-fix-null-pointer-dereference-in-cs35l41_get_acpi_mute_state.patch @@ -0,0 +1,37 @@ +From 8527bbb33936340525a3504a00932b2f8fd75754 Mon Sep 17 00:00:00 2001 +From: Denis Arefev +Date: Tue, 7 Oct 2025 10:38:31 +0300 +Subject: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() + +From: Denis Arefev + +commit 8527bbb33936340525a3504a00932b2f8fd75754 upstream. + +Return value of a function acpi_evaluate_dsm() is dereferenced without +checking for NULL, but it is usually checked for this function. + +acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns +acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. + +Found by Linux Verification Center (linuxtesting.org) with SVACE. + +Fixes: 447106e92a0c ("ALSA: hda: cs35l41: Support mute notifications for CS35L41 HDA") +Cc: stable@vger.kernel.org +Signed-off-by: Denis Arefev +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/hda/codecs/side-codecs/cs35l41_hda.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/hda/codecs/side-codecs/cs35l41_hda.c ++++ b/sound/hda/codecs/side-codecs/cs35l41_hda.c +@@ -1426,6 +1426,8 @@ static int cs35l41_get_acpi_mute_state(s + + if (cs35l41_dsm_supported(handle, CS35L41_DSM_GET_MUTE)) { + ret = acpi_evaluate_dsm(handle, &guid, 0, CS35L41_DSM_GET_MUTE, NULL); ++ if (!ret) ++ return -EINVAL; + mute = *ret->buffer.pointer; + dev_dbg(cs35l41->dev, "CS35L41_DSM_GET_MUTE: %d\n", mute); + } diff --git a/queue-6.17/alsa-hda-fix-missing-pointer-check-in-hda_component_manager_init-function.patch b/queue-6.17/alsa-hda-fix-missing-pointer-check-in-hda_component_manager_init-function.patch new file mode 100644 index 0000000000..db6045659b --- /dev/null +++ b/queue-6.17/alsa-hda-fix-missing-pointer-check-in-hda_component_manager_init-function.patch @@ -0,0 +1,48 @@ +From 1cf11d80db5df805b538c942269e05a65bcaf5bc Mon Sep 17 00:00:00 2001 +From: Denis Arefev +Date: Thu, 9 Oct 2025 13:50:47 +0300 +Subject: ALSA: hda: Fix missing pointer check in hda_component_manager_init function + +From: Denis Arefev + +commit 1cf11d80db5df805b538c942269e05a65bcaf5bc upstream. + +The __component_match_add function may assign the 'matchptr' pointer +the value ERR_PTR(-ENOMEM), which will subsequently be dereferenced. + +The call stack leading to the error looks like this: + +hda_component_manager_init +|-> component_match_add + |-> component_match_add_release + |-> __component_match_add ( ... ,**matchptr, ... ) + |-> *matchptr = ERR_PTR(-ENOMEM); // assign +|-> component_master_add_with_match( ... match) + |-> component_match_realloc(match, match->num); // dereference + +Add IS_ERR() check to prevent the crash. + +Found by Linux Verification Center (linuxtesting.org) with SVACE. + +Fixes: ae7abe36e352 ("ALSA: hda/realtek: Add CS35L41 support for Thinkpad laptops") +Cc: stable@vger.kernel.org +Signed-off-by: Denis Arefev +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/hda/codecs/side-codecs/hda_component.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/sound/hda/codecs/side-codecs/hda_component.c ++++ b/sound/hda/codecs/side-codecs/hda_component.c +@@ -181,6 +181,10 @@ int hda_component_manager_init(struct hd + sm->match_str = match_str; + sm->index = i; + component_match_add(dev, &match, hda_comp_match_dev_name, sm); ++ if (IS_ERR(match)) { ++ codec_err(cdc, "Fail to add component %ld\n", PTR_ERR(match)); ++ return PTR_ERR(match); ++ } + } + + ret = component_master_add_with_match(dev, ops, match); diff --git a/queue-6.17/alsa-hda-intel-add-msi-x870e-tomahawk-to-denylist.patch b/queue-6.17/alsa-hda-intel-add-msi-x870e-tomahawk-to-denylist.patch new file mode 100644 index 0000000000..3b7025f3f4 --- /dev/null +++ b/queue-6.17/alsa-hda-intel-add-msi-x870e-tomahawk-to-denylist.patch @@ -0,0 +1,31 @@ +From 30b3211aa24161856134b2c2ea2ab1c6eb534b36 Mon Sep 17 00:00:00 2001 +From: Stuart Hayhurst +Date: Sat, 11 Oct 2025 00:28:29 +0100 +Subject: ALSA: hda/intel: Add MSI X870E Tomahawk to denylist + +From: Stuart Hayhurst + +commit 30b3211aa24161856134b2c2ea2ab1c6eb534b36 upstream. + +This motherboard uses USB audio instead, causing this driver to complain +about "no codecs found!". +Add it to the denylist to silence the warning. + +Signed-off-by: Stuart Hayhurst +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/hda/controllers/intel.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/hda/controllers/intel.c ++++ b/sound/hda/controllers/intel.c +@@ -2077,6 +2077,7 @@ static const struct pci_device_id driver + { PCI_DEVICE_SUB(0x1022, 0x1487, 0x1043, 0x874f) }, /* ASUS ROG Zenith II / Strix */ + { PCI_DEVICE_SUB(0x1022, 0x1487, 0x1462, 0xcb59) }, /* MSI TRX40 Creator */ + { PCI_DEVICE_SUB(0x1022, 0x1487, 0x1462, 0xcb60) }, /* MSI TRX40 */ ++ { PCI_DEVICE_SUB(0x1022, 0x15e3, 0x1462, 0xee59) }, /* MSI X870E Tomahawk WiFi */ + {} + }; + diff --git a/queue-6.17/alsa-hda-realtek-add-quirk-entry-for-hp-zbook-17-g6.patch b/queue-6.17/alsa-hda-realtek-add-quirk-entry-for-hp-zbook-17-g6.patch new file mode 100644 index 0000000000..9dec01b146 --- /dev/null +++ b/queue-6.17/alsa-hda-realtek-add-quirk-entry-for-hp-zbook-17-g6.patch @@ -0,0 +1,31 @@ +From 5ec6f9434225e18496a393f920b03eb46d67d71d Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 13 Oct 2025 09:26:49 +0200 +Subject: ALSA: hda/realtek: Add quirk entry for HP ZBook 17 G6 + +From: Takashi Iwai + +commit 5ec6f9434225e18496a393f920b03eb46d67d71d upstream. + +HP ZBook 17 G6 with SSID 103c:860c requires a similar workaround as +its 15-inch model in order to make the speaker and mute LED working. +Add the corresponding quirk entry to address it. + +Link: https://bugzilla.kernel.org/show_bug.cgi?id=220372 +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/hda/codecs/realtek/alc269.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/hda/codecs/realtek/alc269.c ++++ b/sound/hda/codecs/realtek/alc269.c +@@ -6390,6 +6390,7 @@ static const struct hda_quirk alc269_fix + SND_PCI_QUIRK(0x103c, 0x854a, "HP EliteBook 830 G6", ALC285_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x85c6, "HP Pavilion x360 Convertible 14-dy1xxx", ALC295_FIXUP_HP_MUTE_LED_COEFBIT11), + SND_PCI_QUIRK(0x103c, 0x85de, "HP Envy x360 13-ar0xxx", ALC285_FIXUP_HP_ENVY_X360), ++ SND_PCI_QUIRK(0x103c, 0x860c, "HP ZBook 17 G6", ALC285_FIXUP_HP_GPIO_AMP_INIT), + SND_PCI_QUIRK(0x103c, 0x860f, "HP ZBook 15 G6", ALC285_FIXUP_HP_GPIO_AMP_INIT), + SND_PCI_QUIRK(0x103c, 0x861f, "HP Elite Dragonfly G1", ALC285_FIXUP_HP_GPIO_AMP_INIT), + SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED), diff --git a/queue-6.17/arm64-sysreg-fix-gic-cdeoi-instruction-encoding.patch b/queue-6.17/arm64-sysreg-fix-gic-cdeoi-instruction-encoding.patch new file mode 100644 index 0000000000..e307199905 --- /dev/null +++ b/queue-6.17/arm64-sysreg-fix-gic-cdeoi-instruction-encoding.patch @@ -0,0 +1,75 @@ +From e9ad390a4812fd60c1da46823f7a6f84f2411f0c Mon Sep 17 00:00:00 2001 +From: Lorenzo Pieralisi +Date: Tue, 7 Oct 2025 12:26:00 +0200 +Subject: arm64/sysreg: Fix GIC CDEOI instruction encoding + +From: Lorenzo Pieralisi + +commit e9ad390a4812fd60c1da46823f7a6f84f2411f0c upstream. + +The GIC CDEOI system instruction requires the Rt field to be set to 0b11111 +otherwise the instruction behaviour becomes CONSTRAINED UNPREDICTABLE. + +Currenly, its usage is encoded as a system register write, with a constant +0 value: + +write_sysreg_s(0, GICV5_OP_GIC_CDEOI) + +While compiling with GCC, the 0 constant value, through these asm +constraints and modifiers ('x' modifier and 'Z' constraint combo): + +asm volatile(__msr_s(r, "%x0") : : "rZ" (__val)); + +forces the compiler to issue the XZR register for the MSR operation (ie +that corresponds to Rt == 0b11111) issuing the right instruction encoding. + +Unfortunately LLVM does not yet understand that modifier/constraint +combo so it ends up issuing a different register from XZR for the MSR +source, which in turns means that it encodes the GIC CDEOI instruction +wrongly and the instruction behaviour becomes CONSTRAINED UNPREDICTABLE +that we must prevent. + +Add a conditional to write_sysreg_s() macro that detects whether it +is passed a constant 0 value and issues an MSR write with XZR as source +register - explicitly doing what the asm modifier/constraint is meant to +achieve through constraints/modifiers, fixing the LLVM compilation issue. + +Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") +Suggested-by: Catalin Marinas +Signed-off-by: Lorenzo Pieralisi +Acked-by: Marc Zyngier +Cc: stable@vger.kernel.org +Cc: Sascha Bischoff +Cc: Will Deacon +Cc: Mark Rutland +Cc: Marc Zyngier +Reviewed-by: Catalin Marinas +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/sysreg.h | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/arch/arm64/include/asm/sysreg.h ++++ b/arch/arm64/include/asm/sysreg.h +@@ -1231,10 +1231,19 @@ + __val; \ + }) + ++/* ++ * The "Z" constraint combined with the "%x0" template should be enough ++ * to force XZR generation if (v) is a constant 0 value but LLVM does not ++ * yet understand that modifier/constraint combo so a conditional is required ++ * to nudge the compiler into using XZR as a source for a 0 constant value. ++ */ + #define write_sysreg_s(v, r) do { \ + u64 __val = (u64)(v); \ + u32 __maybe_unused __check_r = (u32)(r); \ +- asm volatile(__msr_s(r, "%x0") : : "rZ" (__val)); \ ++ if (__builtin_constant_p(__val) && __val == 0) \ ++ asm volatile(__msr_s(r, "xzr")); \ ++ else \ ++ asm volatile(__msr_s(r, "%x0") : : "r" (__val)); \ + } while (0) + + /* diff --git a/queue-6.17/ata-libata-core-relax-checks-in-ata_read_log_directory.patch b/queue-6.17/ata-libata-core-relax-checks-in-ata_read_log_directory.patch new file mode 100644 index 0000000000..c1636aea8f --- /dev/null +++ b/queue-6.17/ata-libata-core-relax-checks-in-ata_read_log_directory.patch @@ -0,0 +1,82 @@ +From 12d724f2852d094d68dccaf5101e0ef89a971cde Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Thu, 9 Oct 2025 19:46:00 +0900 +Subject: ata: libata-core: relax checks in ata_read_log_directory() + +From: Damien Le Moal + +commit 12d724f2852d094d68dccaf5101e0ef89a971cde upstream. + +Commit 6d4405b16d37 ("ata: libata-core: Cache the general purpose log +directory") introduced caching of a device general purpose log directory +to avoid repeated access to this log page during device scan. This +change also added a check on this log page to verify that the log page +version is 0x0001 as mandated by the ACS specifications. + +And it turns out that some devices do not bother reporting this version, +instead reporting a version 0, resulting in error messages such as: + +ata6.00: Invalid log directory version 0x0000 + +and to the device being marked as not supporting the general purpose log +directory log page. + +Since before commit 6d4405b16d37 the log page version check did not +exist and things were still working correctly for these devices, relax +ata_read_log_directory() version check and only warn about the invalid +log page version number without disabling access to the log directory +page. + +Fixes: 6d4405b16d37 ("ata: libata-core: Cache the general purpose log directory") +Cc: stable@vger.kernel.org +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220635 +Signed-off-by: Damien Le Moal +Signed-off-by: Niklas Cassel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/libata-core.c | 11 ++++------- + include/linux/libata.h | 6 ++++++ + 2 files changed, 10 insertions(+), 7 deletions(-) + +diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c +index ff53f5f029b4..2a210719c4ce 100644 +--- a/drivers/ata/libata-core.c ++++ b/drivers/ata/libata-core.c +@@ -2174,13 +2174,10 @@ static int ata_read_log_directory(struct ata_device *dev) + } + + version = get_unaligned_le16(&dev->gp_log_dir[0]); +- if (version != 0x0001) { +- ata_dev_err(dev, "Invalid log directory version 0x%04x\n", +- version); +- ata_clear_log_directory(dev); +- dev->quirks |= ATA_QUIRK_NO_LOG_DIR; +- return -EINVAL; +- } ++ if (version != 0x0001) ++ ata_dev_warn_once(dev, ++ "Invalid log directory version 0x%04x\n", ++ version); + + return 0; + } +diff --git a/include/linux/libata.h b/include/linux/libata.h +index 21de0935775d..7a98de1cc995 100644 +--- a/include/linux/libata.h ++++ b/include/linux/libata.h +@@ -1594,6 +1594,12 @@ do { \ + #define ata_dev_dbg(dev, fmt, ...) \ + ata_dev_printk(debug, dev, fmt, ##__VA_ARGS__) + ++#define ata_dev_warn_once(dev, fmt, ...) \ ++ pr_warn_once("ata%u.%02u: " fmt, \ ++ (dev)->link->ap->print_id, \ ++ (dev)->link->pmp + (dev)->devno, \ ++ ##__VA_ARGS__) ++ + static inline void ata_print_version_once(const struct device *dev, + const char *version) + { +-- +2.51.1.dirty + diff --git a/queue-6.17/btrfs-do-not-assert-we-found-block-group-item-when-creating-free-space-tree.patch b/queue-6.17/btrfs-do-not-assert-we-found-block-group-item-when-creating-free-space-tree.patch new file mode 100644 index 0000000000..ce84c3d722 --- /dev/null +++ b/queue-6.17/btrfs-do-not-assert-we-found-block-group-item-when-creating-free-space-tree.patch @@ -0,0 +1,115 @@ +From a5a51bf4e9b7354ce7cd697e610d72c1b33fd949 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Wed, 1 Oct 2025 11:08:13 +0100 +Subject: btrfs: do not assert we found block group item when creating free space tree + +From: Filipe Manana + +commit a5a51bf4e9b7354ce7cd697e610d72c1b33fd949 upstream. + +Currently, when building a free space tree at populate_free_space_tree(), +if we are not using the block group tree feature, we always expect to find +block group items (either extent items or a block group item with key type +BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with +btrfs_search_slot_for_read(), so we assert that we found an item. However +this expectation is wrong since we can have a new block group created in +the current transaction which is still empty and for which we still have +not added the block group's item to the extent tree, in which case we do +not have any items in the extent tree associated to the block group. + +The insertion of a new block group's block group item in the extent tree +happens at btrfs_create_pending_block_groups() when it calls the helper +insert_block_group_item(). This typically is done when a transaction +handle is released, committed or when running delayed refs (either as +part of a transaction commit or when serving tickets for space reservation +if we are low on free space). + +So remove the assertion at populate_free_space_tree() even when the block +group tree feature is not enabled and update the comment to mention this +case. + +Syzbot reported this with the following stack trace: + + BTRFS info (device loop3 state M): rebuilding free space tree + assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 + ------------[ cut here ]------------ + kernel BUG at fs/btrfs/free-space-tree.c:1115! + Oops: invalid opcode: 0000 [#1] SMP KASAN PTI + CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) + Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 + RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 + Code: ff ff e8 d3 (...) + RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 + RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 + RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 + RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 + R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 + R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 + FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 + Call Trace: + + btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 + btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 + btrfs_remount_rw fs/btrfs/super.c:1334 [inline] + btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 + reconfigure_super+0x227/0x890 fs/super.c:1076 + do_remount fs/namespace.c:3279 [inline] + path_mount+0xd1a/0xfe0 fs/namespace.c:4027 + do_mount fs/namespace.c:4048 [inline] + __do_sys_mount fs/namespace.c:4236 [inline] + __se_sys_mount+0x313/0x410 fs/namespace.c:4213 + do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] + do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + RIP: 0033:0x7f424e39066a + Code: d8 64 89 02 (...) + RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 + RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a + RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 + RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 + R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 + R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 + + Modules linked in: + ---[ end trace 0000000000000000 ]--- + +Reported-by: syzbot+884dc4621377ba579a6f@syzkaller.appspotmail.com +Link: https://lore.kernel.org/linux-btrfs/68dc3dab.a00a0220.102ee.004e.GAE@google.com/ +Fixes: a5ed91828518 ("Btrfs: implement the free space B-tree") +CC: # 6.1.x: 1961d20f6fa8: btrfs: fix assertion when building free space tree +CC: # 6.1.x +Reviewed-by: Qu Wenruo +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/free-space-tree.c | 15 ++++++++------- + 1 file changed, 8 insertions(+), 7 deletions(-) + +--- a/fs/btrfs/free-space-tree.c ++++ b/fs/btrfs/free-space-tree.c +@@ -1106,14 +1106,15 @@ static int populate_free_space_tree(stru + * If ret is 1 (no key found), it means this is an empty block group, + * without any extents allocated from it and there's no block group + * item (key BTRFS_BLOCK_GROUP_ITEM_KEY) located in the extent tree +- * because we are using the block group tree feature, so block group +- * items are stored in the block group tree. It also means there are no +- * extents allocated for block groups with a start offset beyond this +- * block group's end offset (this is the last, highest, block group). ++ * because we are using the block group tree feature (so block group ++ * items are stored in the block group tree) or this is a new block ++ * group created in the current transaction and its block group item ++ * was not yet inserted in the extent tree (that happens in ++ * btrfs_create_pending_block_groups() -> insert_block_group_item()). ++ * It also means there are no extents allocated for block groups with a ++ * start offset beyond this block group's end offset (this is the last, ++ * highest, block group). + */ +- if (!btrfs_fs_compat_ro(trans->fs_info, BLOCK_GROUP_TREE)) +- ASSERT(ret == 0); +- + start = block_group->start; + end = block_group->start + block_group->length; + while (ret == 0) { diff --git a/queue-6.17/btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch b/queue-6.17/btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch new file mode 100644 index 0000000000..16e01282b0 --- /dev/null +++ b/queue-6.17/btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch @@ -0,0 +1,93 @@ +From 7e5a5983edda664e8e4bb20af17b80f5135c655c Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Wed, 24 Sep 2025 16:10:38 +0100 +Subject: btrfs: fix clearing of BTRFS_FS_RELOC_RUNNING if relocation already running + +From: Filipe Manana + +commit 7e5a5983edda664e8e4bb20af17b80f5135c655c upstream. + +When starting relocation, at reloc_chunk_start(), if we happen to find +the flag BTRFS_FS_RELOC_RUNNING is already set we return an error +(-EINPROGRESS) to the callers, however the callers call reloc_chunk_end() +which will clear the flag BTRFS_FS_RELOC_RUNNING, which is wrong since +relocation was started by another task and still running. + +Finding the BTRFS_FS_RELOC_RUNNING flag already set is an unexpected +scenario, but still our current behaviour is not correct. + +Fix this by never calling reloc_chunk_end() if reloc_chunk_start() has +returned an error, which is what logically makes sense, since the general +widespread pattern is to have end functions called only if the counterpart +start functions succeeded. This requires changing reloc_chunk_start() to +clear BTRFS_FS_RELOC_RUNNING if there's a pending cancel request. + +Fixes: 907d2710d727 ("btrfs: add cancellable chunk relocation support") +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Boris Burkov +Reviewed-by: Johannes Thumshirn +Reviewed-by: Qu Wenruo +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/relocation.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +--- a/fs/btrfs/relocation.c ++++ b/fs/btrfs/relocation.c +@@ -3795,6 +3795,7 @@ out: + /* + * Mark start of chunk relocation that is cancellable. Check if the cancellation + * has been requested meanwhile and don't start in that case. ++ * NOTE: if this returns an error, reloc_chunk_end() must not be called. + * + * Return: + * 0 success +@@ -3811,10 +3812,8 @@ static int reloc_chunk_start(struct btrf + + if (atomic_read(&fs_info->reloc_cancel_req) > 0) { + btrfs_info(fs_info, "chunk relocation canceled on start"); +- /* +- * On cancel, clear all requests but let the caller mark +- * the end after cleanup operations. +- */ ++ /* On cancel, clear all requests. */ ++ clear_and_wake_up_bit(BTRFS_FS_RELOC_RUNNING, &fs_info->flags); + atomic_set(&fs_info->reloc_cancel_req, 0); + return -ECANCELED; + } +@@ -3823,9 +3822,11 @@ static int reloc_chunk_start(struct btrf + + /* + * Mark end of chunk relocation that is cancellable and wake any waiters. ++ * NOTE: call only if a previous call to reloc_chunk_start() succeeded. + */ + static void reloc_chunk_end(struct btrfs_fs_info *fs_info) + { ++ ASSERT(test_bit(BTRFS_FS_RELOC_RUNNING, &fs_info->flags)); + /* Requested after start, clear bit first so any waiters can continue */ + if (atomic_read(&fs_info->reloc_cancel_req) > 0) + btrfs_info(fs_info, "chunk relocation canceled during operation"); +@@ -4038,9 +4039,9 @@ out: + if (err && rw) + btrfs_dec_block_group_ro(rc->block_group); + iput(rc->data_inode); ++ reloc_chunk_end(fs_info); + out_put_bg: + btrfs_put_block_group(bg); +- reloc_chunk_end(fs_info); + free_reloc_control(rc); + return err; + } +@@ -4223,8 +4224,8 @@ out_clean: + ret = ret2; + out_unset: + unset_reloc_control(rc); +-out_end: + reloc_chunk_end(fs_info); ++out_end: + free_reloc_control(rc); + out: + free_reloc_roots(&reloc_roots); diff --git a/queue-6.17/btrfs-fix-incorrect-readahead-expansion-length.patch b/queue-6.17/btrfs-fix-incorrect-readahead-expansion-length.patch new file mode 100644 index 0000000000..2369dcf4ad --- /dev/null +++ b/queue-6.17/btrfs-fix-incorrect-readahead-expansion-length.patch @@ -0,0 +1,60 @@ +From 8ab2fa69691b2913a67f3c54fbb991247b3755be Mon Sep 17 00:00:00 2001 +From: Boris Burkov +Date: Tue, 30 Sep 2025 21:05:17 -0700 +Subject: btrfs: fix incorrect readahead expansion length + +From: Boris Burkov + +commit 8ab2fa69691b2913a67f3c54fbb991247b3755be upstream. + +The intent of btrfs_readahead_expand() was to expand to the length of +the current compressed extent being read. However, "ram_bytes" is *not* +that, in the case where a single physical compressed extent is used for +multiple file extents. + +Consider this case with a large compressed extent C and then later two +non-compressed extents N1 and N2 written over C, leaving C1 and C2 +pointing to offset/len pairs of C: + +[ C ] +[ N1 ][ C1 ][ N2 ][ C2 ] + +In such a case, ram_bytes for both C1 and C2 is the full uncompressed +length of C. So starting readahead in C1 will expand the readahead past +the end of C1, past N2, and into C2. This will then expand readahead +again, to C2_start + ram_bytes, way past EOF. First of all, this is +totally undesirable, we don't want to read the whole file in arbitrary +chunks of the large underlying extent if it happens to exist. Secondly, +it results in zeroing the range past the end of C2 up to ram_bytes. This +is particularly unpleasant with fs-verity as it can zero and set +uptodate pages in the verity virtual space past EOF. This incorrect +readahead behavior can lead to verity verification errors, if we iterate +in a way that happens to do the wrong readahead. + +Fix this by using em->len for readahead expansion, not em->ram_bytes, +resulting in the expected behavior of stopping readahead at the extent +boundary. + +Reported-by: Max Chernoff +Link: https://bugzilla.redhat.com/show_bug.cgi?id=2399898 +Fixes: 9e9ff875e417 ("btrfs: use readahead_expand() on compressed extents") +CC: stable@vger.kernel.org # 6.17 +Reviewed-by: Filipe Manana +Signed-off-by: Boris Burkov +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/extent_io.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/extent_io.c ++++ b/fs/btrfs/extent_io.c +@@ -914,7 +914,7 @@ static void btrfs_readahead_expand(struc + { + const u64 ra_pos = readahead_pos(ractl); + const u64 ra_end = ra_pos + readahead_length(ractl); +- const u64 em_end = em->start + em->ram_bytes; ++ const u64 em_end = em->start + em->len; + + /* No expansion for holes and inline extents. */ + if (em->disk_bytenr > EXTENT_MAP_LAST_BYTE) diff --git a/queue-6.17/btrfs-fix-memory-leak-on-duplicated-memory-in-the-qgroup-assign-ioctl.patch b/queue-6.17/btrfs-fix-memory-leak-on-duplicated-memory-in-the-qgroup-assign-ioctl.patch new file mode 100644 index 0000000000..b1e0639557 --- /dev/null +++ b/queue-6.17/btrfs-fix-memory-leak-on-duplicated-memory-in-the-qgroup-assign-ioctl.patch @@ -0,0 +1,43 @@ +From 53a4acbfc1de85fa637521ffab4f4e2ee03cbeeb Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Miquel=20Sabat=C3=A9=20Sol=C3=A0?= +Date: Thu, 25 Sep 2025 20:41:39 +0200 +Subject: btrfs: fix memory leak on duplicated memory in the qgroup assign ioctl +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Miquel Sabaté Solà + +commit 53a4acbfc1de85fa637521ffab4f4e2ee03cbeeb upstream. + +On 'btrfs_ioctl_qgroup_assign' we first duplicate the argument as +provided by the user, which is kfree'd in the end. But this was not the +case when allocating memory for 'prealloc'. In this case, if it somehow +failed, then the previous code would go directly into calling +'mnt_drop_write_file', without freeing the string duplicated from the +user space. + +Fixes: 4addc1ffd67a ("btrfs: qgroup: preallocate memory before adding a relation") +CC: stable@vger.kernel.org # 6.12+ +Reviewed-by: Boris Burkov +Reviewed-by: Filipe Manana +Signed-off-by: Miquel Sabaté Solà +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/ioctl.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/ioctl.c ++++ b/fs/btrfs/ioctl.c +@@ -3740,7 +3740,7 @@ static long btrfs_ioctl_qgroup_assign(st + prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL); + if (!prealloc) { + ret = -ENOMEM; +- goto drop_write; ++ goto out; + } + } + diff --git a/queue-6.17/btrfs-fix-memory-leaks-when-rejecting-a-non-single-data-profile-without-an-rst.patch b/queue-6.17/btrfs-fix-memory-leaks-when-rejecting-a-non-single-data-profile-without-an-rst.patch new file mode 100644 index 0000000000..ce50825088 --- /dev/null +++ b/queue-6.17/btrfs-fix-memory-leaks-when-rejecting-a-non-single-data-profile-without-an-rst.patch @@ -0,0 +1,42 @@ +From fec9b9d3ced39f16be8d7afdf81f4dd2653da319 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Miquel=20Sabat=C3=A9=20Sol=C3=A0?= +Date: Wed, 8 Oct 2025 14:18:59 +0200 +Subject: btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Miquel Sabaté Solà + +commit fec9b9d3ced39f16be8d7afdf81f4dd2653da319 upstream. + +At the end of btrfs_load_block_group_zone_info() the first thing we do +is to ensure that if the mapping type is not a SINGLE one and there is +no RAID stripe tree, then we return early with an error. + +Doing that, though, prevents the code from running the last calls from +this function which are about freeing memory allocated during its +run. Hence, in this case, instead of returning early, we set the ret +value and fall through the rest of the cleanup code. + +Fixes: 5906333cc4af ("btrfs: zoned: don't skip block group profile checks on conventional zones") +CC: stable@vger.kernel.org # 6.8+ +Reviewed-by: Johannes Thumshirn +Signed-off-by: Miquel Sabaté Solà +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/zoned.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/zoned.c ++++ b/fs/btrfs/zoned.c +@@ -1753,7 +1753,7 @@ out: + !fs_info->stripe_root) { + btrfs_err(fs_info, "zoned: data %s needs raid-stripe-tree", + btrfs_bg_type_to_raid_name(map->type)); +- return -EINVAL; ++ ret = -EINVAL; + } + + if (cache->alloc_offset > cache->zone_capacity) { diff --git a/queue-6.17/btrfs-only-set-the-device-specific-options-after-devices-are-opened.patch b/queue-6.17/btrfs-only-set-the-device-specific-options-after-devices-are-opened.patch new file mode 100644 index 0000000000..a4e6894e3e --- /dev/null +++ b/queue-6.17/btrfs-only-set-the-device-specific-options-after-devices-are-opened.patch @@ -0,0 +1,75 @@ +From b7fdfd29a136a17c5c8ad9e9bbf89c48919c3d19 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Fri, 26 Sep 2025 14:20:11 +0930 +Subject: btrfs: only set the device specific options after devices are opened + +From: Qu Wenruo + +commit b7fdfd29a136a17c5c8ad9e9bbf89c48919c3d19 upstream. + +[BUG] +With v6.17-rc kernels, btrfs will always set 'ssd' mount option even if +the block device is not a rotating one: + + # cat /sys/block/sdd/queue/rotational + 1 + # cat /etc/fstab: + LABEL=DATA2 /data2 btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/,nofail,nosuid,nodev 0 0 + + # mount + [...] + /dev/sdd on /data2 type btrfs (rw,nosuid,nodev,relatime,ssd,space_cache=v2,subvolid=5,subvol=/) + +[CAUSE] +The 'ssd' mount option is set by set_device_specific_options(), and it +expects that if there is any rotating device in the btrfs, it will set +fs_devices::rotating. + +However after commit bddf57a70781 ("btrfs: delay btrfs_open_devices() +until super block is created"), the device opening is delayed until the +super block is created. + +But the timing of set_device_specific_options() is still left as is, +this makes the function be called without any device opened. + +Since no device is opened, thus fs_devices::rotating will never be set, +making btrfs incorrectly set 'ssd' mount option. + +[FIX] +Only call set_device_specific_options() after btrfs_open_devices(). + +Also only call set_device_specific_options() after a new mount, if we're +mounting a mounted btrfs, there is no need to set the device specific +mount options again. + +Reported-by: HAN Yuwei +Link: https://lore.kernel.org/linux-btrfs/C8FF75669DFFC3C5+5f93bf8a-80a0-48a6-81bf-4ec890abc99a@bupt.moe/ +Fixes: bddf57a70781 ("btrfs: delay btrfs_open_devices() until super block is created") +CC: stable@vger.kernel.org # 6.17 +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/super.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/fs/btrfs/super.c ++++ b/fs/btrfs/super.c +@@ -1902,8 +1902,6 @@ static int btrfs_get_tree_super(struct f + return PTR_ERR(sb); + } + +- set_device_specific_options(fs_info); +- + if (sb->s_root) { + /* + * Not the first mount of the fs thus got an existing super block. +@@ -1948,6 +1946,7 @@ static int btrfs_get_tree_super(struct f + deactivate_locked_super(sb); + return -EACCES; + } ++ set_device_specific_options(fs_info); + bdev = fs_devices->latest_dev->bdev; + snprintf(sb->s_id, sizeof(sb->s_id), "%pg", bdev); + shrinker_debugfs_rename(sb->s_shrink, "sb-btrfs:%s", sb->s_id); diff --git a/queue-6.17/can-gs_usb-gs_make_candev-populate-net_device-dev_port.patch b/queue-6.17/can-gs_usb-gs_make_candev-populate-net_device-dev_port.patch new file mode 100644 index 0000000000..007ff8a84d --- /dev/null +++ b/queue-6.17/can-gs_usb-gs_make_candev-populate-net_device-dev_port.patch @@ -0,0 +1,37 @@ +From a12f0bc764da3781da2019c60826f47a6d7ed64f Mon Sep 17 00:00:00 2001 +From: Celeste Liu +Date: Tue, 30 Sep 2025 14:53:39 +0800 +Subject: can: gs_usb: gs_make_candev(): populate net_device->dev_port + +From: Celeste Liu + +commit a12f0bc764da3781da2019c60826f47a6d7ed64f upstream. + +The gs_usb driver supports USB devices with more than 1 CAN channel. +In old kernel before 3.15, it uses net_device->dev_id to distinguish +different channel in userspace, which was done in commit +acff76fa45b4 ("can: gs_usb: gs_make_candev(): set netdev->dev_id"). +But since 3.15, the correct way is populating net_device->dev_port. +And according to documentation, if network device support multiple +interface, lack of net_device->dev_port SHALL be treated as a bug. + +Fixes: acff76fa45b4 ("can: gs_usb: gs_make_candev(): set netdev->dev_id") +Cc: stable@vger.kernel.org +Signed-off-by: Celeste Liu +Link: https://patch.msgid.link/20250930-gs-usb-populate-net_device-dev_port-v1-1-68a065de6937@coelacanthus.name +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/usb/gs_usb.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/can/usb/gs_usb.c ++++ b/drivers/net/can/usb/gs_usb.c +@@ -1249,6 +1249,7 @@ static struct gs_can *gs_make_candev(uns + + netdev->flags |= IFF_ECHO; /* we support full roundtrip echo */ + netdev->dev_id = channel; ++ netdev->dev_port = channel; + + /* dev setup */ + strcpy(dev->bt_const.name, KBUILD_MODNAME); diff --git a/queue-6.17/can-gs_usb-increase-max-interface-to-u8_max.patch b/queue-6.17/can-gs_usb-increase-max-interface-to-u8_max.patch new file mode 100644 index 0000000000..ab34245f81 --- /dev/null +++ b/queue-6.17/can-gs_usb-increase-max-interface-to-u8_max.patch @@ -0,0 +1,118 @@ +From 2a27f6a8fb5722223d526843040f747e9b0e8060 Mon Sep 17 00:00:00 2001 +From: Celeste Liu +Date: Tue, 30 Sep 2025 19:34:28 +0800 +Subject: can: gs_usb: increase max interface to U8_MAX + +From: Celeste Liu + +commit 2a27f6a8fb5722223d526843040f747e9b0e8060 upstream. + +This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD +converter[1]. The original developers may have only 3 interfaces +device to test so they write 3 here and wait for future change. + +During the HSCanT development, we actually used 4 interfaces, so the +limitation of 3 is not enough now. But just increase one is not +future-proofed. Since the channel index type in gs_host_frame is u8, +just make canch[] become a flexible array with a u8 index, so it +naturally constraint by U8_MAX and avoid statically allocate 256 +pointer for every gs_usb device. + +[1]: https://github.com/cherry-embedded/HSCanT-hardware + +Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") +Reported-by: Runcheng Lu +Cc: stable@vger.kernel.org +Reviewed-by: Vincent Mailhol +Signed-off-by: Celeste Liu +Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacanthus.name +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/usb/gs_usb.c | 22 ++++++++++------------ + 1 file changed, 10 insertions(+), 12 deletions(-) + +--- a/drivers/net/can/usb/gs_usb.c ++++ b/drivers/net/can/usb/gs_usb.c +@@ -289,11 +289,6 @@ struct gs_host_frame { + #define GS_MAX_RX_URBS 30 + #define GS_NAPI_WEIGHT 32 + +-/* Maximum number of interfaces the driver supports per device. +- * Current hardware only supports 3 interfaces. The future may vary. +- */ +-#define GS_MAX_INTF 3 +- + struct gs_tx_context { + struct gs_can *dev; + unsigned int echo_id; +@@ -324,7 +319,6 @@ struct gs_can { + + /* usb interface struct */ + struct gs_usb { +- struct gs_can *canch[GS_MAX_INTF]; + struct usb_anchor rx_submitted; + struct usb_device *udev; + +@@ -336,9 +330,11 @@ struct gs_usb { + + unsigned int hf_size_rx; + u8 active_channels; ++ u8 channel_cnt; + + unsigned int pipe_in; + unsigned int pipe_out; ++ struct gs_can *canch[] __counted_by(channel_cnt); + }; + + /* 'allocate' a tx context. +@@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback + } + + /* device reports out of range channel id */ +- if (hf->channel >= GS_MAX_INTF) ++ if (hf->channel >= parent->channel_cnt) + goto device_detach; + + dev = parent->canch[hf->channel]; +@@ -699,7 +695,7 @@ resubmit_urb: + /* USB failure take down all interfaces */ + if (rc == -ENODEV) { + device_detach: +- for (rc = 0; rc < GS_MAX_INTF; rc++) { ++ for (rc = 0; rc < parent->channel_cnt; rc++) { + if (parent->canch[rc]) + netif_device_detach(parent->canch[rc]->netdev); + } +@@ -1461,17 +1457,19 @@ static int gs_usb_probe(struct usb_inter + icount = dconf.icount + 1; + dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); + +- if (icount > GS_MAX_INTF) { ++ if (icount > type_max(parent->channel_cnt)) { + dev_err(&intf->dev, + "Driver cannot handle more that %u CAN interfaces\n", +- GS_MAX_INTF); ++ type_max(parent->channel_cnt)); + return -EINVAL; + } + +- parent = kzalloc(sizeof(*parent), GFP_KERNEL); ++ parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); + if (!parent) + return -ENOMEM; + ++ parent->channel_cnt = icount; ++ + init_usb_anchor(&parent->rx_submitted); + + usb_set_intfdata(intf, parent); +@@ -1532,7 +1530,7 @@ static void gs_usb_disconnect(struct usb + return; + } + +- for (i = 0; i < GS_MAX_INTF; i++) ++ for (i = 0; i < parent->channel_cnt; i++) + if (parent->canch[i]) + gs_destroy_candev(parent->canch[i]); + diff --git a/queue-6.17/cifs-parse_dfs_referrals-prevent-oob-on-malformed-input.patch b/queue-6.17/cifs-parse_dfs_referrals-prevent-oob-on-malformed-input.patch new file mode 100644 index 0000000000..70b3c40c93 --- /dev/null +++ b/queue-6.17/cifs-parse_dfs_referrals-prevent-oob-on-malformed-input.patch @@ -0,0 +1,62 @@ +From 6447b0e355562a1ff748c4a2ffb89aae7e84d2c9 Mon Sep 17 00:00:00 2001 +From: Eugene Korenevsky +Date: Mon, 13 Oct 2025 21:39:30 +0300 +Subject: cifs: parse_dfs_referrals: prevent oob on malformed input + +From: Eugene Korenevsky + +commit 6447b0e355562a1ff748c4a2ffb89aae7e84d2c9 upstream. + +Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS + +- reply smaller than sizeof(struct get_dfs_referral_rsp) +- reply with number of referrals smaller than NumberOfReferrals in the +header + +Processing of such replies will cause oob. + +Return -EINVAL error on such replies to prevent oob-s. + +Signed-off-by: Eugene Korenevsky +Cc: stable@vger.kernel.org +Suggested-by: Nathan Chancellor +Acked-by: Paulo Alcantara (Red Hat) +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/misc.c | 17 +++++++++++++++++ + 1 file changed, 17 insertions(+) + +--- a/fs/smb/client/misc.c ++++ b/fs/smb/client/misc.c +@@ -916,6 +916,14 @@ parse_dfs_referrals(struct get_dfs_refer + char *data_end; + struct dfs_referral_level_3 *ref; + ++ if (rsp_size < sizeof(*rsp)) { ++ cifs_dbg(VFS | ONCE, ++ "%s: header is malformed (size is %u, must be %zu)\n", ++ __func__, rsp_size, sizeof(*rsp)); ++ rc = -EINVAL; ++ goto parse_DFS_referrals_exit; ++ } ++ + *num_of_nodes = le16_to_cpu(rsp->NumberOfReferrals); + + if (*num_of_nodes < 1) { +@@ -925,6 +933,15 @@ parse_dfs_referrals(struct get_dfs_refer + goto parse_DFS_referrals_exit; + } + ++ if (sizeof(*rsp) + *num_of_nodes * sizeof(REFERRAL3) > rsp_size) { ++ cifs_dbg(VFS | ONCE, ++ "%s: malformed buffer (size is %u, must be at least %zu)\n", ++ __func__, rsp_size, ++ sizeof(*rsp) + *num_of_nodes * sizeof(REFERRAL3)); ++ rc = -EINVAL; ++ goto parse_DFS_referrals_exit; ++ } ++ + ref = (struct dfs_referral_level_3 *) &(rsp->referrals); + if (ref->VersionNumber != cpu_to_le16(3)) { + cifs_dbg(VFS, "Referrals of V%d version are not supported, should be V3\n", diff --git a/queue-6.17/cxl-acpi-fix-setup-of-memory-resource-in-cxl_acpi_set_cache_size.patch b/queue-6.17/cxl-acpi-fix-setup-of-memory-resource-in-cxl_acpi_set_cache_size.patch new file mode 100644 index 0000000000..756db3a6fc --- /dev/null +++ b/queue-6.17/cxl-acpi-fix-setup-of-memory-resource-in-cxl_acpi_set_cache_size.patch @@ -0,0 +1,46 @@ +From 2e41e5a91a37202ff6743c3ae5329e106aeb1c6c Mon Sep 17 00:00:00 2001 +From: Dave Jiang +Date: Fri, 10 Oct 2025 13:57:53 -0700 +Subject: cxl/acpi: Fix setup of memory resource in cxl_acpi_set_cache_size() + +From: Dave Jiang + +commit 2e41e5a91a37202ff6743c3ae5329e106aeb1c6c upstream. + +In order to compare the resource against the HMAT memory target, +the resource needs to be memory type. Change the DEFINE_RES() +macro to DEFINE_RES_MEM() in order to set the correct resource type. +hmat_get_extended_linear_cache_size() uses resource_contains() +internally. This causes a regression for platforms with the +extended linear cache enabled as the comparison always fails and the +cache size is not set. User visible impact is that when 'cxl list' is +issued, a CXL region with extended linear cache support will only +report half the size of the actual size. And this also breaks MCE +reporting of the memory region due to incorrect offset calculation +for the memory. + +[dj: Fixup commit log suggested by djbw] +[dj: Fixup stable address for cc] + +Fixes: 12b3d697c812 ("cxl: Remove core/acpi.c and cxl core dependency on ACPI") +Cc: stable@vger.kernel.org +Reviewed-by: Gregory Price +Reviewed-by: Alison Schofield +Reviewed-by: Dan Williams +Signed-off-by: Dave Jiang +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cxl/acpi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/cxl/acpi.c ++++ b/drivers/cxl/acpi.c +@@ -345,7 +345,7 @@ static int cxl_acpi_set_cache_size(struc + struct resource res; + int nid, rc; + +- res = DEFINE_RES(start, size, 0); ++ res = DEFINE_RES_MEM(start, size); + nid = phys_to_target_node(start); + + rc = hmat_get_extended_linear_cache_size(&res, nid, &cache_size); diff --git a/queue-6.17/docs-kdoc-handle-the-obsolescensce-of-docutils.errorstring.patch b/queue-6.17/docs-kdoc-handle-the-obsolescensce-of-docutils.errorstring.patch new file mode 100644 index 0000000000..f032134cf4 --- /dev/null +++ b/queue-6.17/docs-kdoc-handle-the-obsolescensce-of-docutils.errorstring.patch @@ -0,0 +1,91 @@ +From c2ce9e6de0a3dfea99de08af7b5eef5c983e76c8 Mon Sep 17 00:00:00 2001 +From: Jonathan Corbet +Date: Tue, 9 Sep 2025 13:35:37 -0600 +Subject: docs: kdoc: handle the obsolescensce of docutils.ErrorString() + +From: Jonathan Corbet + +commit 00d95fcc4dee66dfb6980de6f2973b32f973a1eb upstream. + +The ErrorString() and SafeString() docutils functions were helpers meant to +ease the handling of encodings during the Python 3 transition. There is no +real need for them after Python 3.6, and docutils 0.22 removes them, +breaking the docs build + +Handle this by just injecting our own one-liner version of ErrorString(), +and removing the sole SafeString() call entirely. + +Reported-by: Zhixu Liu +Signed-off-by: Jonathan Corbet +Message-ID: <87ldmnv2pi.fsf@trenco.lwn.net> +[ Salvatore Bonaccorso: Backport to v6.17.y for context changes in + Documentation/sphinx/kernel_include.py with major refactorings for the v6.18 + development cycle ] +Signed-off-by: Salvatore Bonaccorso +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/sphinx/kernel_feat.py | 4 +++- + Documentation/sphinx/kernel_include.py | 6 ++++-- + Documentation/sphinx/maintainers_include.py | 4 +++- + 3 files changed, 10 insertions(+), 4 deletions(-) + +--- a/Documentation/sphinx/kernel_feat.py ++++ b/Documentation/sphinx/kernel_feat.py +@@ -40,9 +40,11 @@ import sys + from docutils import nodes, statemachine + from docutils.statemachine import ViewList + from docutils.parsers.rst import directives, Directive +-from docutils.utils.error_reporting import ErrorString + from sphinx.util.docutils import switch_source_input + ++def ErrorString(exc): # Shamelessly stolen from docutils ++ return f'{exc.__class__.__name}: {exc}' ++ + __version__ = '1.0' + + def setup(app): +--- a/Documentation/sphinx/kernel_include.py ++++ b/Documentation/sphinx/kernel_include.py +@@ -35,13 +35,15 @@ + import os.path + + from docutils import io, nodes, statemachine +-from docutils.utils.error_reporting import SafeString, ErrorString + from docutils.parsers.rst import directives + from docutils.parsers.rst.directives.body import CodeBlock, NumberLines + from docutils.parsers.rst.directives.misc import Include + + __version__ = '1.0' + ++def ErrorString(exc): # Shamelessly stolen from docutils ++ return f'{exc.__class__.__name}: {exc}' ++ + # ============================================================================== + def setup(app): + # ============================================================================== +@@ -112,7 +114,7 @@ class KernelInclude(Include): + raise self.severe('Problems with "%s" directive path:\n' + 'Cannot encode input file path "%s" ' + '(wrong locale?).' % +- (self.name, SafeString(path))) ++ (self.name, path)) + except IOError as error: + raise self.severe('Problems with "%s" directive path:\n%s.' % + (self.name, ErrorString(error))) +--- a/Documentation/sphinx/maintainers_include.py ++++ b/Documentation/sphinx/maintainers_include.py +@@ -22,10 +22,12 @@ import re + import os.path + + from docutils import statemachine +-from docutils.utils.error_reporting import ErrorString + from docutils.parsers.rst import Directive + from docutils.parsers.rst.directives.misc import Include + ++def ErrorString(exc): # Shamelessly stolen from docutils ++ return f'{exc.__class__.__name}: {exc}' ++ + __version__ = '1.0' + + def setup(app): diff --git a/queue-6.17/drm-amdgpu-fix-gfx12-mes-packet-status-return-check.patch b/queue-6.17/drm-amdgpu-fix-gfx12-mes-packet-status-return-check.patch new file mode 100644 index 0000000000..e935ffec95 --- /dev/null +++ b/queue-6.17/drm-amdgpu-fix-gfx12-mes-packet-status-return-check.patch @@ -0,0 +1,40 @@ +From d0de79f66a80eeb849033fae34bd07a69ce72235 Mon Sep 17 00:00:00 2001 +From: Jonathan Kim +Date: Thu, 9 Oct 2025 10:45:42 -0400 +Subject: drm/amdgpu: fix gfx12 mes packet status return check + +From: Jonathan Kim + +commit d0de79f66a80eeb849033fae34bd07a69ce72235 upstream. + +GFX12 MES uses low 32 bits of status return for success (1 or 0) +and high bits for debug information if low bits are 0. + +GFX11 MES doesn't do this so checking full 64-bit status return +for 1 or 0 is still valid. + +Signed-off-by: Jonathan Kim +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/mes_v12_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/mes_v12_0.c +@@ -225,7 +225,12 @@ static int mes_v12_0_submit_pkt_and_poll + pipe, x_pkt->header.opcode); + + r = amdgpu_fence_wait_polling(ring, seq, timeout); +- if (r < 1 || !*status_ptr) { ++ ++ /* ++ * status_ptr[31:0] == 0 (fail) or status_ptr[63:0] == 1 (success). ++ * If status_ptr[31:0] == 0 then status_ptr[63:32] will have debug error information. ++ */ ++ if (r < 1 || !(lower_32_bits(*status_ptr))) { + + if (misc_op_str) + dev_err(adev->dev, "MES(%d) failed to respond to msg=%s (%s)\n", diff --git a/queue-6.17/drm-amdgpu-use-atomic-functions-with-memory-barriers-for-vm-fault-info.patch b/queue-6.17/drm-amdgpu-use-atomic-functions-with-memory-barriers-for-vm-fault-info.patch new file mode 100644 index 0000000000..3e4d0a2d2f --- /dev/null +++ b/queue-6.17/drm-amdgpu-use-atomic-functions-with-memory-barriers-for-vm-fault-info.patch @@ -0,0 +1,119 @@ +From 6df8e84aa6b5b1812cc2cacd6b3f5ccbb18cda2b Mon Sep 17 00:00:00 2001 +From: Gui-Dong Han +Date: Wed, 8 Oct 2025 03:43:27 +0000 +Subject: drm/amdgpu: use atomic functions with memory barriers for vm fault info + +From: Gui-Dong Han + +commit 6df8e84aa6b5b1812cc2cacd6b3f5ccbb18cda2b upstream. + +The atomic variable vm_fault_info_updated is used to synchronize access to +adev->gmc.vm_fault_info between the interrupt handler and +get_vm_fault_info(). + +The default atomic functions like atomic_set() and atomic_read() do not +provide memory barriers. This allows for CPU instruction reordering, +meaning the memory accesses to vm_fault_info and the vm_fault_info_updated +flag are not guaranteed to occur in the intended order. This creates a +race condition that can lead to inconsistent or stale data being used. + +The previous implementation, which used an explicit mb(), was incomplete +and inefficient. It failed to account for all potential CPU reorderings, +such as the access of vm_fault_info being reordered before the atomic_read +of the flag. This approach is also more verbose and less performant than +using the proper atomic functions with acquire/release semantics. + +Fix this by switching to atomic_set_release() and atomic_read_acquire(). +These functions provide the necessary acquire and release semantics, +which act as memory barriers to ensure the correct order of operations. +It is also more efficient and idiomatic than using explicit full memory +barriers. + +Fixes: b97dfa27ef3a ("drm/amdgpu: save vm fault information for amdkfd") +Cc: stable@vger.kernel.org +Signed-off-by: Gui-Dong Han +Signed-off-by: Felix Kuehling +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 ++--- + drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 7 +++---- + drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 7 +++---- + 3 files changed, 8 insertions(+), 11 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +@@ -2325,10 +2325,9 @@ void amdgpu_amdkfd_gpuvm_unmap_gtt_bo_fr + int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct amdgpu_device *adev, + struct kfd_vm_fault_info *mem) + { +- if (atomic_read(&adev->gmc.vm_fault_info_updated) == 1) { ++ if (atomic_read_acquire(&adev->gmc.vm_fault_info_updated) == 1) { + *mem = *adev->gmc.vm_fault_info; +- mb(); /* make sure read happened */ +- atomic_set(&adev->gmc.vm_fault_info_updated, 0); ++ atomic_set_release(&adev->gmc.vm_fault_info_updated, 0); + } + return 0; + } +--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c +@@ -1066,7 +1066,7 @@ static int gmc_v7_0_sw_init(struct amdgp + GFP_KERNEL); + if (!adev->gmc.vm_fault_info) + return -ENOMEM; +- atomic_set(&adev->gmc.vm_fault_info_updated, 0); ++ atomic_set_release(&adev->gmc.vm_fault_info_updated, 0); + + return 0; + } +@@ -1288,7 +1288,7 @@ static int gmc_v7_0_process_interrupt(st + vmid = REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS, + VMID); + if (amdgpu_amdkfd_is_kfd_vmid(adev, vmid) +- && !atomic_read(&adev->gmc.vm_fault_info_updated)) { ++ && !atomic_read_acquire(&adev->gmc.vm_fault_info_updated)) { + struct kfd_vm_fault_info *info = adev->gmc.vm_fault_info; + u32 protections = REG_GET_FIELD(status, + VM_CONTEXT1_PROTECTION_FAULT_STATUS, +@@ -1304,8 +1304,7 @@ static int gmc_v7_0_process_interrupt(st + info->prot_read = protections & 0x8 ? true : false; + info->prot_write = protections & 0x10 ? true : false; + info->prot_exec = protections & 0x20 ? true : false; +- mb(); +- atomic_set(&adev->gmc.vm_fault_info_updated, 1); ++ atomic_set_release(&adev->gmc.vm_fault_info_updated, 1); + } + + return 0; +--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c +@@ -1179,7 +1179,7 @@ static int gmc_v8_0_sw_init(struct amdgp + GFP_KERNEL); + if (!adev->gmc.vm_fault_info) + return -ENOMEM; +- atomic_set(&adev->gmc.vm_fault_info_updated, 0); ++ atomic_set_release(&adev->gmc.vm_fault_info_updated, 0); + + return 0; + } +@@ -1474,7 +1474,7 @@ static int gmc_v8_0_process_interrupt(st + vmid = REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS, + VMID); + if (amdgpu_amdkfd_is_kfd_vmid(adev, vmid) +- && !atomic_read(&adev->gmc.vm_fault_info_updated)) { ++ && !atomic_read_acquire(&adev->gmc.vm_fault_info_updated)) { + struct kfd_vm_fault_info *info = adev->gmc.vm_fault_info; + u32 protections = REG_GET_FIELD(status, + VM_CONTEXT1_PROTECTION_FAULT_STATUS, +@@ -1490,8 +1490,7 @@ static int gmc_v8_0_process_interrupt(st + info->prot_read = protections & 0x8 ? true : false; + info->prot_write = protections & 0x10 ? true : false; + info->prot_exec = protections & 0x20 ? true : false; +- mb(); +- atomic_set(&adev->gmc.vm_fault_info_updated, 1); ++ atomic_set_release(&adev->gmc.vm_fault_info_updated, 1); + } + + return 0; diff --git a/queue-6.17/drm-ast-blank-with-vgacr17-sync-enable-always-clear-vgacrb6-sync-off.patch b/queue-6.17/drm-ast-blank-with-vgacr17-sync-enable-always-clear-vgacrb6-sync-off.patch new file mode 100644 index 0000000000..60f4f3b43e --- /dev/null +++ b/queue-6.17/drm-ast-blank-with-vgacr17-sync-enable-always-clear-vgacrb6-sync-off.patch @@ -0,0 +1,90 @@ +From 6f719373b943a955fee6fc2012aed207b65e2854 Mon Sep 17 00:00:00 2001 +From: Thomas Zimmermann +Date: Tue, 14 Oct 2025 10:46:34 +0200 +Subject: drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off + +From: Thomas Zimmermann + +commit 6f719373b943a955fee6fc2012aed207b65e2854 upstream. + +Blank the display by disabling sync pulses with VGACR17<7>. Unblank +by reenabling them. This VGA setting should be supported by all Aspeed +hardware. + +Ast currently blanks via sync-off bits in VGACRB6. Not all BMCs handle +VGACRB6 correctly. After disabling sync during a reboot, some BMCs do +not reenable it after the soft reset. The display output remains dark. +When the display is off during boot, some BMCs set the sync-off bits in +VGACRB6, so the display remains dark. Observed with Blackbird AST2500 +BMCs. Clearing the sync-off bits unconditionally fixes these issues. + +Also do not modify VGASR1's SD bit for blanking, as it only disables GPU +access to video memory. + +v2: +- init vgacrb6 correctly (Jocelyn) + +Signed-off-by: Thomas Zimmermann +Fixes: ce3d99c83495 ("drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers") +Tested-by: Nick Bowler +Reported-by: Nick Bowler +Closes: https://lore.kernel.org/dri-devel/wpwd7rit6t4mnu6kdqbtsnk5bhftgslio6e2jgkz6kgw6cuvvr@xbfswsczfqsi/ +Cc: Douglas Anderson +Cc: Dave Airlie +Cc: Thomas Zimmermann +Cc: Jocelyn Falempe +Cc: dri-devel@lists.freedesktop.org +Cc: # v6.7+ +Reviewed-by: Jocelyn Falempe +Link: https://lore.kernel.org/r/20251014084743.18242-1-tzimmermann@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/ast/ast_mode.c | 18 ++++++++++-------- + drivers/gpu/drm/ast/ast_reg.h | 1 + + 2 files changed, 11 insertions(+), 8 deletions(-) + +--- a/drivers/gpu/drm/ast/ast_mode.c ++++ b/drivers/gpu/drm/ast/ast_mode.c +@@ -836,22 +836,24 @@ ast_crtc_helper_atomic_flush(struct drm_ + static void ast_crtc_helper_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state) + { + struct ast_device *ast = to_ast_device(crtc->dev); ++ u8 vgacr17 = 0x00; ++ u8 vgacrb6 = 0xff; + +- ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, 0x00); +- ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, 0x00); ++ vgacr17 |= AST_IO_VGACR17_SYNC_ENABLE; ++ vgacrb6 &= ~(AST_IO_VGACRB6_VSYNC_OFF | AST_IO_VGACRB6_HSYNC_OFF); ++ ++ ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17); ++ ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6); + } + + static void ast_crtc_helper_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state *state) + { + struct drm_crtc_state *old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc); + struct ast_device *ast = to_ast_device(crtc->dev); +- u8 vgacrb6; ++ u8 vgacr17 = 0xff; + +- ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, AST_IO_VGASR1_SD); +- +- vgacrb6 = AST_IO_VGACRB6_VSYNC_OFF | +- AST_IO_VGACRB6_HSYNC_OFF; +- ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6); ++ vgacr17 &= ~AST_IO_VGACR17_SYNC_ENABLE; ++ ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17); + + /* + * HW cursors require the underlying primary plane and CRTC to +--- a/drivers/gpu/drm/ast/ast_reg.h ++++ b/drivers/gpu/drm/ast/ast_reg.h +@@ -29,6 +29,7 @@ + #define AST_IO_VGAGRI (0x4E) + + #define AST_IO_VGACRI (0x54) ++#define AST_IO_VGACR17_SYNC_ENABLE BIT(7) /* called "Hardware reset" in docs */ + #define AST_IO_VGACR80_PASSWORD (0xa8) + #define AST_IO_VGACR99_VGAMEM_RSRV_MASK GENMASK(1, 0) + #define AST_IO_VGACRA1_VGAIO_DISABLED BIT(1) diff --git a/queue-6.17/drm-sched-fix-potential-double-free-in-drm_sched_job_add_resv_dependencies.patch b/queue-6.17/drm-sched-fix-potential-double-free-in-drm_sched_job_add_resv_dependencies.patch new file mode 100644 index 0000000000..893c057a6f --- /dev/null +++ b/queue-6.17/drm-sched-fix-potential-double-free-in-drm_sched_job_add_resv_dependencies.patch @@ -0,0 +1,99 @@ +From 5801e65206b065b0b2af032f7f1eef222aa2fd83 Mon Sep 17 00:00:00 2001 +From: Tvrtko Ursulin +Date: Wed, 15 Oct 2025 09:40:15 +0100 +Subject: drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Tvrtko Ursulin + +commit 5801e65206b065b0b2af032f7f1eef222aa2fd83 upstream. + +When adding dependencies with drm_sched_job_add_dependency(), that +function consumes the fence reference both on success and failure, so in +the latter case the dma_fence_put() on the error path (xarray failed to +expand) is a double free. + +Interestingly this bug appears to have been present ever since +commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code +back then looked like this: + +drm_sched_job_add_implicit_dependencies(): +... + for (i = 0; i < fence_count; i++) { + ret = drm_sched_job_add_dependency(job, fences[i]); + if (ret) + break; + } + + for (; i < fence_count; i++) + dma_fence_put(fences[i]); + +Which means for the failing 'i' the dma_fence_put was already a double +free. Possibly there were no users at that time, or the test cases were +insufficient to hit it. + +The bug was then only noticed and fixed after +commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") +landed, with its fixup of +commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies"). + +At that point it was a slightly different flavour of a double free, which +commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") +noticed and attempted to fix. + +But it only moved the double free from happening inside the +drm_sched_job_add_dependency(), when releasing the reference not yet +obtained, to the caller, when releasing the reference already released by +the former in the failure case. + +As such it is not easy to identify the right target for the fixes tag so +lets keep it simple and just continue the chain. + +While fixing we also improve the comment and explain the reason for taking +the reference and not dropping it. + +Signed-off-by: Tvrtko Ursulin +Fixes: 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") +Reported-by: Dan Carpenter +Closes: https://lore.kernel.org/dri-devel/aNFbXq8OeYl3QSdm@stanley.mountain/ +Cc: Christian König +Cc: Rob Clark +Cc: Daniel Vetter +Cc: Matthew Brost +Cc: Danilo Krummrich +Cc: Philipp Stanner +Cc: Christian König +Cc: dri-devel@lists.freedesktop.org +Cc: stable@vger.kernel.org # v5.16+ +Signed-off-by: Philipp Stanner +Link: https://lore.kernel.org/r/20251015084015.6273-1-tvrtko.ursulin@igalia.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/scheduler/sched_main.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/scheduler/sched_main.c ++++ b/drivers/gpu/drm/scheduler/sched_main.c +@@ -986,13 +986,14 @@ int drm_sched_job_add_resv_dependencies( + dma_resv_assert_held(resv); + + dma_resv_for_each_fence(&cursor, resv, usage, fence) { +- /* Make sure to grab an additional ref on the added fence */ +- dma_fence_get(fence); +- ret = drm_sched_job_add_dependency(job, fence); +- if (ret) { +- dma_fence_put(fence); ++ /* ++ * As drm_sched_job_add_dependency always consumes the fence ++ * reference (even when it fails), and dma_resv_for_each_fence ++ * is not obtaining one, we need to grab one before calling. ++ */ ++ ret = drm_sched_job_add_dependency(job, dma_fence_get(fence)); ++ if (ret) + return ret; +- } + } + return 0; + } diff --git a/queue-6.17/drm-xe-guc-check-guc-running-state-before-deregistering-exec-queue.patch b/queue-6.17/drm-xe-guc-check-guc-running-state-before-deregistering-exec-queue.patch new file mode 100644 index 0000000000..39e9a92dba --- /dev/null +++ b/queue-6.17/drm-xe-guc-check-guc-running-state-before-deregistering-exec-queue.patch @@ -0,0 +1,76 @@ +From 9f64b3cd051b825de0a2a9f145c8e003200cedd5 Mon Sep 17 00:00:00 2001 +From: Shuicheng Lin +Date: Fri, 10 Oct 2025 17:25:29 +0000 +Subject: drm/xe/guc: Check GuC running state before deregistering exec queue + +From: Shuicheng Lin + +commit 9f64b3cd051b825de0a2a9f145c8e003200cedd5 upstream. + +In normal operation, a registered exec queue is disabled and +deregistered through the GuC, and freed only after the GuC confirms +completion. However, if the driver is forced to unbind while the exec +queue is still running, the user may call exec_destroy() after the GuC +has already been stopped and CT communication disabled. + +In this case, the driver cannot receive a response from the GuC, +preventing proper cleanup of exec queue resources. Fix this by directly +releasing the resources when GuC is not running. + +Here is the failure dmesg log: +" +[ 468.089581] ---[ end trace 0000000000000000 ]--- +[ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535) +[ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535 +[ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1 +[ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1) +[ 468.092716] ------------[ cut here ]------------ +[ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe] +" + +v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled(). + As CT may go down and come back during VF migration. + +Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") +Cc: stable@vger.kernel.org +Cc: Matthew Brost +Signed-off-by: Shuicheng Lin +Reviewed-by: Matthew Brost +Signed-off-by: Matthew Brost +Link: https://lore.kernel.org/r/20251010172529.2967639-2-shuicheng.lin@intel.com +(cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea) +Signed-off-by: Lucas De Marchi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/xe/xe_guc_submit.c | 13 ++++++++++++- + 1 file changed, 12 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/xe/xe_guc_submit.c ++++ b/drivers/gpu/drm/xe/xe_guc_submit.c +@@ -44,6 +44,7 @@ + #include "xe_ring_ops_types.h" + #include "xe_sched_job.h" + #include "xe_trace.h" ++#include "xe_uc_fw.h" + #include "xe_vm.h" + + static struct xe_guc * +@@ -1413,7 +1414,17 @@ static void __guc_exec_queue_process_msg + xe_gt_assert(guc_to_gt(guc), !(q->flags & EXEC_QUEUE_FLAG_PERMANENT)); + trace_xe_exec_queue_cleanup_entity(q); + +- if (exec_queue_registered(q)) ++ /* ++ * Expected state transitions for cleanup: ++ * - If the exec queue is registered and GuC firmware is running, we must first ++ * disable scheduling and deregister the queue to ensure proper teardown and ++ * resource release in the GuC, then destroy the exec queue on driver side. ++ * - If the GuC is already stopped (e.g., during driver unload or GPU reset), ++ * we cannot expect a response for the deregister request. In this case, ++ * it is safe to directly destroy the exec queue on driver side, as the GuC ++ * will not process further requests and all resources must be cleaned up locally. ++ */ ++ if (exec_queue_registered(q) && xe_uc_fw_is_running(&guc->fw)) + disable_scheduling_deregister(guc, q); + else + __guc_exec_queue_destroy(guc, q); diff --git a/queue-6.17/drm-xe-increase-global-invalidation-timeout-to-1000us.patch b/queue-6.17/drm-xe-increase-global-invalidation-timeout-to-1000us.patch new file mode 100644 index 0000000000..cca578f75b --- /dev/null +++ b/queue-6.17/drm-xe-increase-global-invalidation-timeout-to-1000us.patch @@ -0,0 +1,46 @@ +From e5ae8d1eb08a3e27fff4ae264af4c8056d908639 Mon Sep 17 00:00:00 2001 +From: Kenneth Graunke +Date: Fri, 12 Sep 2025 15:31:45 -0700 +Subject: drm/xe: Increase global invalidation timeout to 1000us + +From: Kenneth Graunke + +commit e5ae8d1eb08a3e27fff4ae264af4c8056d908639 upstream. + +The previous timeout of 500us seems to be too small; panning the map in +the Roll20 VTT in Firefox on a KDE/Wayland desktop reliably triggered +timeouts within a few seconds of usage, causing the monitor to freeze +and the following to be printed to dmesg: + +[Jul30 13:44] xe 0000:03:00.0: [drm] *ERROR* GT0: Global invalidation timeout +[Jul30 13:48] xe 0000:03:00.0: [drm] *ERROR* [CRTC:82:pipe A] flip_done timed out + +I haven't hit a single timeout since increasing it to 1000us even after +several multi-hour testing sessions. + +Fixes: 0dd2dd0182bc ("drm/xe: Move DSB l2 flush to a more sensible place") +Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5710 +Signed-off-by: Kenneth Graunke +Cc: stable@vger.kernel.org +Cc: Maarten Lankhorst +Reviewed-by: Shuicheng Lin +Link: https://lore.kernel.org/r/20250912223254.147940-1-kenneth@whitecape.org +Signed-off-by: Lucas De Marchi +(cherry picked from commit 146046907b56578263434107f5a7d5051847c459) +Signed-off-by: Lucas De Marchi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/xe/xe_device.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/xe/xe_device.c ++++ b/drivers/gpu/drm/xe/xe_device.c +@@ -1029,7 +1029,7 @@ void xe_device_l2_flush(struct xe_device + spin_lock(>->global_invl_lock); + + xe_mmio_write32(>->mmio, XE2_GLOBAL_INVAL, 0x1); +- if (xe_mmio_wait32(>->mmio, XE2_GLOBAL_INVAL, 0x1, 0x0, 500, NULL, true)) ++ if (xe_mmio_wait32(>->mmio, XE2_GLOBAL_INVAL, 0x1, 0x0, 1000, NULL, true)) + xe_gt_err_once(gt, "Global invalidation timeout\n"); + + spin_unlock(>->global_invl_lock); diff --git a/queue-6.17/ext4-detect-invalid-inline_data-extents-flag-combination.patch b/queue-6.17/ext4-detect-invalid-inline_data-extents-flag-combination.patch new file mode 100644 index 0000000000..a5d94e31f0 --- /dev/null +++ b/queue-6.17/ext4-detect-invalid-inline_data-extents-flag-combination.patch @@ -0,0 +1,63 @@ +From 1d3ad183943b38eec2acf72a0ae98e635dc8456b Mon Sep 17 00:00:00 2001 +From: Deepanshu Kartikey +Date: Tue, 30 Sep 2025 16:58:10 +0530 +Subject: ext4: detect invalid INLINE_DATA + EXTENTS flag combination + +From: Deepanshu Kartikey + +commit 1d3ad183943b38eec2acf72a0ae98e635dc8456b upstream. + +syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity +file on a corrupted ext4 filesystem mounted without a journal. + +The issue is that the filesystem has an inode with both the INLINE_DATA +and EXTENTS flags set: + + EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: + comm syz.0.17: corrupted extent tree: lblk 0 < prev 66 + +Investigation revealed that the inode has both flags set: + DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1 + +This is an invalid combination since an inode should have either: +- INLINE_DATA: data stored directly in the inode +- EXTENTS: data stored in extent-mapped blocks + +Having both flags causes ext4_has_inline_data() to return true, skipping +extent tree validation in __ext4_iget(). The unvalidated out-of-order +extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer +underflow when calculating hole sizes. + +Fix this by detecting this invalid flag combination early in ext4_iget() +and rejecting the corrupted inode. + +Cc: stable@kernel.org +Reported-and-tested-by: syzbot+038b7bf43423e132b308@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=038b7bf43423e132b308 +Suggested-by: Zhang Yi +Signed-off-by: Deepanshu Kartikey +Reviewed-by: Zhang Yi +Message-ID: <20250930112810.315095-1-kartikey406@gmail.com> +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/inode.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -5319,6 +5319,14 @@ struct inode *__ext4_iget(struct super_b + } + ei->i_flags = le32_to_cpu(raw_inode->i_flags); + ext4_set_inode_flags(inode, true); ++ /* Detect invalid flag combination - can't have both inline data and extents */ ++ if (ext4_test_inode_flag(inode, EXT4_INODE_INLINE_DATA) && ++ ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) { ++ ext4_error_inode(inode, function, line, 0, ++ "inode has both inline data and extents flags"); ++ ret = -EFSCORRUPTED; ++ goto bad_inode; ++ } + inode->i_blocks = ext4_inode_blocks(raw_inode, ei); + ei->i_file_acl = le32_to_cpu(raw_inode->i_file_acl_lo); + if (ext4_has_feature_64bit(sb)) diff --git a/queue-6.17/ext4-wait-for-ongoing-i-o-to-complete-before-freeing-blocks.patch b/queue-6.17/ext4-wait-for-ongoing-i-o-to-complete-before-freeing-blocks.patch new file mode 100644 index 0000000000..383fedd4b6 --- /dev/null +++ b/queue-6.17/ext4-wait-for-ongoing-i-o-to-complete-before-freeing-blocks.patch @@ -0,0 +1,56 @@ +From 328a782cb138029182e521c08f50eb1587db955d Mon Sep 17 00:00:00 2001 +From: Zhang Yi +Date: Tue, 16 Sep 2025 17:33:37 +0800 +Subject: ext4: wait for ongoing I/O to complete before freeing blocks + +From: Zhang Yi + +commit 328a782cb138029182e521c08f50eb1587db955d upstream. + +When freeing metadata blocks in nojournal mode, ext4_forget() calls +bforget() to clear the dirty flag on the buffer_head and remvoe +associated mappings. This is acceptable if the metadata has not yet +begun to be written back. However, if the write-back has already started +but is not yet completed, ext4_forget() will have no effect. +Subsequently, ext4_mb_clear_bb() will immediately return the block to +the mb allocator. This block can then be reallocated immediately, +potentially causing an data corruption issue. + +Fix this by clearing the buffer's dirty flag and waiting for the ongoing +I/O to complete, ensuring that no further writes to stale data will +occur. + +Fixes: 16e08b14a455 ("ext4: cleanup clean_bdev_aliases() calls") +Cc: stable@kernel.org +Reported-by: Gao Xiang +Closes: https://lore.kernel.org/linux-ext4/a9417096-9549-4441-9878-b1955b899b4e@huaweicloud.com/ +Signed-off-by: Zhang Yi +Reviewed-by: Jan Kara +Message-ID: <20250916093337.3161016-3-yi.zhang@huaweicloud.com> +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/ext4_jbd2.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/fs/ext4/ext4_jbd2.c ++++ b/fs/ext4/ext4_jbd2.c +@@ -280,9 +280,16 @@ int __ext4_forget(const char *where, uns + bh, is_metadata, inode->i_mode, + test_opt(inode->i_sb, DATA_FLAGS)); + +- /* In the no journal case, we can just do a bforget and return */ ++ /* ++ * In the no journal case, we should wait for the ongoing buffer ++ * to complete and do a forget. ++ */ + if (!ext4_handle_valid(handle)) { +- bforget(bh); ++ if (bh) { ++ clear_buffer_dirty(bh); ++ wait_on_buffer(bh); ++ __bforget(bh); ++ } + return 0; + } + diff --git a/queue-6.17/f2fs-fix-wrong-block-mapping-for-multi-devices.patch b/queue-6.17/f2fs-fix-wrong-block-mapping-for-multi-devices.patch new file mode 100644 index 0000000000..6241fa89b1 --- /dev/null +++ b/queue-6.17/f2fs-fix-wrong-block-mapping-for-multi-devices.patch @@ -0,0 +1,55 @@ +From 9d5c4f5c7a2c7677e1b3942772122b032c265aae Mon Sep 17 00:00:00 2001 +From: Jaegeuk Kim +Date: Tue, 7 Oct 2025 03:32:30 +0000 +Subject: f2fs: fix wrong block mapping for multi-devices + +From: Jaegeuk Kim + +commit 9d5c4f5c7a2c7677e1b3942772122b032c265aae upstream. + +Assuming the disk layout as below, + +disk0: 0 --- 0x00035abfff +disk1: 0x00035ac000 --- 0x00037abfff +disk2: 0x00037ac000 --- 0x00037ebfff + +and we want to read data from offset=13568 having len=128 across the block +devices, we can illustrate the block addresses like below. + +0 .. 0x00037ac000 ------------------- 0x00037ebfff, 0x00037ec000 ------- + | ^ ^ ^ + | fofs 0 13568 13568+128 + | ------------------------------------------------------ + | LBA 0x37e8aa9 0x37ebfa9 0x37ec029 + --- map 0x3caa9 0x3ffa9 + +In this example, we should give the relative map of the target block device +ranging from 0x3caa9 to 0x3ffa9 where the length should be calculated by +0x37ebfff + 1 - 0x37ebfa9. + +In the below equation, however, map->m_pblk was supposed to be the original +address instead of the one from the target block address. + + - map->m_len = min(map->m_len, dev->end_blk + 1 - map->m_pblk); + +Cc: stable@vger.kernel.org +Fixes: 71f2c8206202 ("f2fs: multidevice: support direct IO") +Reviewed-by: Chao Yu +Signed-off-by: Jaegeuk Kim +Signed-off-by: Greg Kroah-Hartman +--- + fs/f2fs/data.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/f2fs/data.c ++++ b/fs/f2fs/data.c +@@ -1504,8 +1504,8 @@ static bool f2fs_map_blocks_cached(struc + struct f2fs_dev_info *dev = &sbi->devs[bidx]; + + map->m_bdev = dev->bdev; +- map->m_pblk -= dev->start_blk; + map->m_len = min(map->m_len, dev->end_blk + 1 - map->m_pblk); ++ map->m_pblk -= dev->start_blk; + } else { + map->m_bdev = inode->i_sb->s_bdev; + } diff --git a/queue-6.17/gve-check-valid-ts-bit-on-rx-descriptor-before-hw-timestamping.patch b/queue-6.17/gve-check-valid-ts-bit-on-rx-descriptor-before-hw-timestamping.patch new file mode 100644 index 0000000000..21ae206513 --- /dev/null +++ b/queue-6.17/gve-check-valid-ts-bit-on-rx-descriptor-before-hw-timestamping.patch @@ -0,0 +1,90 @@ +From bfdd74166a639930baaba27a8d729edaacd46907 Mon Sep 17 00:00:00 2001 +From: Tim Hostetler +Date: Tue, 14 Oct 2025 00:47:39 +0000 +Subject: gve: Check valid ts bit on RX descriptor before hw timestamping + +From: Tim Hostetler + +commit bfdd74166a639930baaba27a8d729edaacd46907 upstream. + +The device returns a valid bit in the LSB of the low timestamp byte in +the completion descriptor that the driver should check before +setting the SKB's hardware timestamp. If the timestamp is not valid, do not +hardware timestamp the SKB. + +Cc: stable@vger.kernel.org +Fixes: b2c7aeb49056 ("gve: Implement ndo_hwtstamp_get/set for RX timestamping") +Reviewed-by: Joshua Washington +Signed-off-by: Tim Hostetler +Signed-off-by: Harshitha Ramamurthy +Reviewed-by: Simon Horman +Reviewed-by: Willem de Bruijn +Reviewed-by: Vadim Fedorenko +Link: https://patch.msgid.link/20251014004740.2775957-1-hramamurthy@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/google/gve/gve.h | 2 ++ + drivers/net/ethernet/google/gve/gve_desc_dqo.h | 3 ++- + drivers/net/ethernet/google/gve/gve_rx_dqo.c | 16 +++++++++++----- + 3 files changed, 15 insertions(+), 6 deletions(-) + +--- a/drivers/net/ethernet/google/gve/gve.h ++++ b/drivers/net/ethernet/google/gve/gve.h +@@ -100,6 +100,8 @@ + */ + #define GVE_DQO_QPL_ONDEMAND_ALLOC_THRESHOLD 96 + ++#define GVE_DQO_RX_HWTSTAMP_VALID 0x1 ++ + /* Each slot in the desc ring has a 1:1 mapping to a slot in the data ring */ + struct gve_rx_desc_queue { + struct gve_rx_desc *desc_ring; /* the descriptor ring */ +--- a/drivers/net/ethernet/google/gve/gve_desc_dqo.h ++++ b/drivers/net/ethernet/google/gve/gve_desc_dqo.h +@@ -236,7 +236,8 @@ struct gve_rx_compl_desc_dqo { + + u8 status_error1; + +- __le16 reserved5; ++ u8 reserved5; ++ u8 ts_sub_nsecs_low; + __le16 buf_id; /* Buffer ID which was sent on the buffer queue. */ + + union { +--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c ++++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c +@@ -456,14 +456,20 @@ static void gve_rx_skb_hash(struct sk_bu + * Note that this means if the time delta between packet reception and the last + * clock read is greater than ~2 seconds, this will provide invalid results. + */ +-static void gve_rx_skb_hwtstamp(struct gve_rx_ring *rx, u32 hwts) ++static void gve_rx_skb_hwtstamp(struct gve_rx_ring *rx, ++ const struct gve_rx_compl_desc_dqo *desc) + { + u64 last_read = READ_ONCE(rx->gve->last_sync_nic_counter); + struct sk_buff *skb = rx->ctx.skb_head; +- u32 low = (u32)last_read; +- s32 diff = hwts - low; ++ u32 ts, low; ++ s32 diff; + +- skb_hwtstamps(skb)->hwtstamp = ns_to_ktime(last_read + diff); ++ if (desc->ts_sub_nsecs_low & GVE_DQO_RX_HWTSTAMP_VALID) { ++ ts = le32_to_cpu(desc->ts); ++ low = (u32)last_read; ++ diff = ts - low; ++ skb_hwtstamps(skb)->hwtstamp = ns_to_ktime(last_read + diff); ++ } + } + + static void gve_rx_free_skb(struct napi_struct *napi, struct gve_rx_ring *rx) +@@ -919,7 +925,7 @@ static int gve_rx_complete_skb(struct gv + gve_rx_skb_csum(rx->ctx.skb_head, desc, ptype); + + if (rx->gve->ts_config.rx_filter == HWTSTAMP_FILTER_ALL) +- gve_rx_skb_hwtstamp(rx, le32_to_cpu(desc->ts)); ++ gve_rx_skb_hwtstamp(rx, desc); + + /* RSC packets must set gso_size otherwise the TCP stack will complain + * that packets are larger than MTU. diff --git a/queue-6.17/io_uring-protect-mem-region-deregistration.patch b/queue-6.17/io_uring-protect-mem-region-deregistration.patch new file mode 100644 index 0000000000..154e4ba7f3 --- /dev/null +++ b/queue-6.17/io_uring-protect-mem-region-deregistration.patch @@ -0,0 +1,34 @@ +From be7cab44ed099566c605a8dac686c3254db01b35 Mon Sep 17 00:00:00 2001 +From: Pavel Begunkov +Date: Wed, 15 Oct 2025 13:07:23 +0100 +Subject: io_uring: protect mem region deregistration + +From: Pavel Begunkov + +commit be7cab44ed099566c605a8dac686c3254db01b35 upstream. + +io_create_region_mmap_safe() protects publishing of a region against +concurrent mmap calls, however we should also protect against it when +removing a region. There is a gap io_register_mem_region() where it +safely publishes a region, but then copy_to_user goes wrong and it +unsafely frees the region. + +Cc: stable@vger.kernel.org +Fixes: 087f997870a94 ("io_uring/memmap: implement mmap for regions") +Signed-off-by: Pavel Begunkov +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/register.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/io_uring/register.c ++++ b/io_uring/register.c +@@ -618,6 +618,7 @@ static int io_register_mem_region(struct + if (ret) + return ret; + if (copy_to_user(rd_uptr, &rd, sizeof(rd))) { ++ guard(mutex)(&ctx->mmap_lock); + io_free_region(ctx, &ctx->param_region); + return -EFAULT; + } diff --git a/queue-6.17/ixgbevf-fix-getting-link-speed-data-for-e610-devices.patch b/queue-6.17/ixgbevf-fix-getting-link-speed-data-for-e610-devices.patch new file mode 100644 index 0000000000..9424be6489 --- /dev/null +++ b/queue-6.17/ixgbevf-fix-getting-link-speed-data-for-e610-devices.patch @@ -0,0 +1,301 @@ +From 53f0eb62b4d23d40686f2dd51776b8220f2887bb Mon Sep 17 00:00:00 2001 +From: Jedrzej Jagielski +Date: Thu, 9 Oct 2025 17:03:47 -0700 +Subject: ixgbevf: fix getting link speed data for E610 devices + +From: Jedrzej Jagielski + +commit 53f0eb62b4d23d40686f2dd51776b8220f2887bb upstream. + +E610 adapters no longer use the VFLINKS register to read PF's link +speed and linkup state. As a result VF driver cannot get actual link +state and it incorrectly reports 10G which is the default option. +It leads to a situation where even 1G adapters print 10G as actual +link speed. The same happens when PF driver set speed different than 10G. + +Add new mailbox operation to let the VF driver request a PF driver +to provide actual link data. Update the mailbox api to v1.6. + +Incorporate both ways of getting link status within the legacy +ixgbe_check_mac_link_vf() function. + +Fixes: 4c44b450c69b ("ixgbevf: Add support for Intel(R) E610 device") +Co-developed-by: Andrzej Wilczynski +Signed-off-by: Andrzej Wilczynski +Reviewed-by: Przemek Kitszel +Reviewed-by: Aleksandr Loktionov +Cc: stable@vger.kernel.org +Signed-off-by: Jedrzej Jagielski +Tested-by: Rafal Romanowski +Signed-off-by: Jacob Keller +Link: https://patch.msgid.link/20251009-jk-iwl-net-2025-10-01-v3-2-ef32a425b92a@intel.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/ixgbevf/defines.h | 1 + drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 + drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 + drivers/net/ethernet/intel/ixgbevf/vf.c | 137 +++++++++++++++++----- + 4 files changed, 116 insertions(+), 32 deletions(-) + +--- a/drivers/net/ethernet/intel/ixgbevf/defines.h ++++ b/drivers/net/ethernet/intel/ixgbevf/defines.h +@@ -28,6 +28,7 @@ + + /* Link speed */ + typedef u32 ixgbe_link_speed; ++#define IXGBE_LINK_SPEED_UNKNOWN 0 + #define IXGBE_LINK_SPEED_1GB_FULL 0x0020 + #define IXGBE_LINK_SPEED_10GB_FULL 0x0080 + #define IXGBE_LINK_SPEED_100_FULL 0x0008 +--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c ++++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +@@ -2275,6 +2275,7 @@ static void ixgbevf_negotiate_api(struct + { + struct ixgbe_hw *hw = &adapter->hw; + static const int api[] = { ++ ixgbe_mbox_api_16, + ixgbe_mbox_api_15, + ixgbe_mbox_api_14, + ixgbe_mbox_api_13, +@@ -2294,7 +2295,8 @@ static void ixgbevf_negotiate_api(struct + idx++; + } + +- if (hw->api_version >= ixgbe_mbox_api_15) { ++ /* Following is not supported by API 1.6, it is specific for 1.5 */ ++ if (hw->api_version == ixgbe_mbox_api_15) { + hw->mbx.ops.init_params(hw); + memcpy(&hw->mbx.ops, &ixgbevf_mbx_ops, + sizeof(struct ixgbe_mbx_operations)); +@@ -2651,6 +2653,7 @@ static void ixgbevf_set_num_queues(struc + case ixgbe_mbox_api_13: + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_15: ++ case ixgbe_mbox_api_16: + if (adapter->xdp_prog && + hw->mac.max_tx_queues == rss) + rss = rss > 3 ? 2 : 1; +@@ -4645,6 +4648,7 @@ static int ixgbevf_probe(struct pci_dev + case ixgbe_mbox_api_13: + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_15: ++ case ixgbe_mbox_api_16: + netdev->max_mtu = IXGBE_MAX_JUMBO_FRAME_SIZE - + (ETH_HLEN + ETH_FCS_LEN); + break; +--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h ++++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h +@@ -66,6 +66,7 @@ enum ixgbe_pfvf_api_rev { + ixgbe_mbox_api_13, /* API version 1.3, linux/freebsd VF driver */ + ixgbe_mbox_api_14, /* API version 1.4, linux/freebsd VF driver */ + ixgbe_mbox_api_15, /* API version 1.5, linux/freebsd VF driver */ ++ ixgbe_mbox_api_16, /* API version 1.6, linux/freebsd VF driver */ + /* This value should always be last */ + ixgbe_mbox_api_unknown, /* indicates that API version is not known */ + }; +@@ -102,6 +103,9 @@ enum ixgbe_pfvf_api_rev { + + #define IXGBE_VF_GET_LINK_STATE 0x10 /* get vf link state */ + ++/* mailbox API, version 1.6 VF requests */ ++#define IXGBE_VF_GET_PF_LINK_STATE 0x11 /* request PF to send link info */ ++ + /* length of permanent address message returned from PF */ + #define IXGBE_VF_PERMADDR_MSG_LEN 4 + /* word in permanent address message with the current multicast type */ +--- a/drivers/net/ethernet/intel/ixgbevf/vf.c ++++ b/drivers/net/ethernet/intel/ixgbevf/vf.c +@@ -313,6 +313,7 @@ int ixgbevf_get_reta_locked(struct ixgbe + * is not supported for this device type. + */ + switch (hw->api_version) { ++ case ixgbe_mbox_api_16: + case ixgbe_mbox_api_15: + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_13: +@@ -382,6 +383,7 @@ int ixgbevf_get_rss_key_locked(struct ix + * or if the operation is not supported for this device type. + */ + switch (hw->api_version) { ++ case ixgbe_mbox_api_16: + case ixgbe_mbox_api_15: + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_13: +@@ -552,6 +554,7 @@ static s32 ixgbevf_update_xcast_mode(str + case ixgbe_mbox_api_13: + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_15: ++ case ixgbe_mbox_api_16: + break; + default: + return -EOPNOTSUPP; +@@ -625,6 +628,48 @@ static s32 ixgbevf_hv_get_link_state_vf( + } + + /** ++ * ixgbevf_get_pf_link_state - Get PF's link status ++ * @hw: pointer to the HW structure ++ * @speed: link speed ++ * @link_up: indicate if link is up/down ++ * ++ * Ask PF to provide link_up state and speed of the link. ++ * ++ * Return: IXGBE_ERR_MBX in the case of mailbox error, ++ * -EOPNOTSUPP if the op is not supported or 0 on success. ++ */ ++static int ixgbevf_get_pf_link_state(struct ixgbe_hw *hw, ixgbe_link_speed *speed, ++ bool *link_up) ++{ ++ u32 msgbuf[3] = {}; ++ int err; ++ ++ switch (hw->api_version) { ++ case ixgbe_mbox_api_16: ++ break; ++ default: ++ return -EOPNOTSUPP; ++ } ++ ++ msgbuf[0] = IXGBE_VF_GET_PF_LINK_STATE; ++ ++ err = ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf, ++ ARRAY_SIZE(msgbuf)); ++ if (err || (msgbuf[0] & IXGBE_VT_MSGTYPE_FAILURE)) { ++ err = IXGBE_ERR_MBX; ++ *speed = IXGBE_LINK_SPEED_UNKNOWN; ++ /* No need to set @link_up to false as it will be done by ++ * ixgbe_check_mac_link_vf(). ++ */ ++ } else { ++ *speed = msgbuf[1]; ++ *link_up = msgbuf[2]; ++ } ++ ++ return err; ++} ++ ++/** + * ixgbevf_set_vfta_vf - Set/Unset VLAN filter table address + * @hw: pointer to the HW structure + * @vlan: 12 bit VLAN ID +@@ -659,6 +704,58 @@ mbx_err: + } + + /** ++ * ixgbe_read_vflinks - Read VFLINKS register ++ * @hw: pointer to the HW structure ++ * @speed: link speed ++ * @link_up: indicate if link is up/down ++ * ++ * Get linkup status and link speed from the VFLINKS register. ++ */ ++static void ixgbe_read_vflinks(struct ixgbe_hw *hw, ixgbe_link_speed *speed, ++ bool *link_up) ++{ ++ u32 vflinks = IXGBE_READ_REG(hw, IXGBE_VFLINKS); ++ ++ /* if link status is down no point in checking to see if PF is up */ ++ if (!(vflinks & IXGBE_LINKS_UP)) { ++ *link_up = false; ++ return; ++ } ++ ++ /* for SFP+ modules and DA cables on 82599 it can take up to 500usecs ++ * before the link status is correct ++ */ ++ if (hw->mac.type == ixgbe_mac_82599_vf) { ++ for (int i = 0; i < 5; i++) { ++ udelay(100); ++ vflinks = IXGBE_READ_REG(hw, IXGBE_VFLINKS); ++ ++ if (!(vflinks & IXGBE_LINKS_UP)) { ++ *link_up = false; ++ return; ++ } ++ } ++ } ++ ++ /* We reached this point so there's link */ ++ *link_up = true; ++ ++ switch (vflinks & IXGBE_LINKS_SPEED_82599) { ++ case IXGBE_LINKS_SPEED_10G_82599: ++ *speed = IXGBE_LINK_SPEED_10GB_FULL; ++ break; ++ case IXGBE_LINKS_SPEED_1G_82599: ++ *speed = IXGBE_LINK_SPEED_1GB_FULL; ++ break; ++ case IXGBE_LINKS_SPEED_100_82599: ++ *speed = IXGBE_LINK_SPEED_100_FULL; ++ break; ++ default: ++ *speed = IXGBE_LINK_SPEED_UNKNOWN; ++ } ++} ++ ++/** + * ixgbevf_hv_set_vfta_vf - * Hyper-V variant - just a stub. + * @hw: unused + * @vlan: unused +@@ -705,7 +802,6 @@ static s32 ixgbevf_check_mac_link_vf(str + struct ixgbe_mbx_info *mbx = &hw->mbx; + struct ixgbe_mac_info *mac = &hw->mac; + s32 ret_val = 0; +- u32 links_reg; + u32 in_msg = 0; + + /* If we were hit with a reset drop the link */ +@@ -715,36 +811,14 @@ static s32 ixgbevf_check_mac_link_vf(str + if (!mac->get_link_status) + goto out; + +- /* if link status is down no point in checking to see if pf is up */ +- links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS); +- if (!(links_reg & IXGBE_LINKS_UP)) +- goto out; +- +- /* for SFP+ modules and DA cables on 82599 it can take up to 500usecs +- * before the link status is correct +- */ +- if (mac->type == ixgbe_mac_82599_vf) { +- int i; +- +- for (i = 0; i < 5; i++) { +- udelay(100); +- links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS); +- +- if (!(links_reg & IXGBE_LINKS_UP)) +- goto out; +- } +- } +- +- switch (links_reg & IXGBE_LINKS_SPEED_82599) { +- case IXGBE_LINKS_SPEED_10G_82599: +- *speed = IXGBE_LINK_SPEED_10GB_FULL; +- break; +- case IXGBE_LINKS_SPEED_1G_82599: +- *speed = IXGBE_LINK_SPEED_1GB_FULL; +- break; +- case IXGBE_LINKS_SPEED_100_82599: +- *speed = IXGBE_LINK_SPEED_100_FULL; +- break; ++ if (hw->mac.type == ixgbe_mac_e610_vf) { ++ ret_val = ixgbevf_get_pf_link_state(hw, speed, link_up); ++ if (ret_val) ++ goto out; ++ } else { ++ ixgbe_read_vflinks(hw, speed, link_up); ++ if (*link_up == false) ++ goto out; + } + + /* if the read failed it could just be a mailbox collision, best wait +@@ -951,6 +1025,7 @@ int ixgbevf_get_queues(struct ixgbe_hw * + case ixgbe_mbox_api_13: + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_15: ++ case ixgbe_mbox_api_16: + break; + default: + return 0; diff --git a/queue-6.17/ixgbevf-fix-mailbox-api-compatibility-by-negotiating-supported-features.patch b/queue-6.17/ixgbevf-fix-mailbox-api-compatibility-by-negotiating-supported-features.patch new file mode 100644 index 0000000000..c8710193b1 --- /dev/null +++ b/queue-6.17/ixgbevf-fix-mailbox-api-compatibility-by-negotiating-supported-features.patch @@ -0,0 +1,323 @@ +From a7075f501bd33c93570af759b6f4302ef0175168 Mon Sep 17 00:00:00 2001 +From: Jedrzej Jagielski +Date: Thu, 9 Oct 2025 17:03:49 -0700 +Subject: ixgbevf: fix mailbox API compatibility by negotiating supported features + +From: Jedrzej Jagielski + +commit a7075f501bd33c93570af759b6f4302ef0175168 upstream. + +There was backward compatibility in the terms of mailbox API. Various +drivers from various OSes supporting 10G adapters from Intel portfolio +could easily negotiate mailbox API. + +This convention has been broken since introducing API 1.4. +Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support +for IPSec which is specific only for the kernel ixgbe driver. None of the +rest of the Intel 10G PF/VF drivers supports it. And actually lack of +support was not included in the IPSec implementation - there were no such +code paths. No possibility to negotiate support for the feature was +introduced along with introduction of the feature itself. + +Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication +between PF and VF") increasing API version to 1.5 did the same - it +introduced code supported specifically by the PF ESX driver. It altered API +version for the VF driver in the same time not touching the version +defined for the PF ixgbe driver. It led to additional discrepancies, +as the code provided within API 1.6 cannot be supported for Linux ixgbe +driver as it causes crashes. + +The issue was noticed some time ago and mitigated by Jake within the commit +d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5"). +As a result we have regression for IPsec support and after increasing API +to version 1.6 ixgbevf driver stopped to support ESX MBX. + +To fix this mess add new mailbox op asking PF driver about supported +features. Basing on a response determine whether to set support for IPSec +and ESX-specific enhanced mailbox. + +New mailbox op, for compatibility purposes, must be added within new API +revision, as API version of OOT PF & VF drivers is already increased to +1.6 and doesn't incorporate features negotiate op. + +Features negotiation mechanism gives possibility to be extended with new +features when needed in the future. + +Reported-by: Jacob Keller +Closes: https://lore.kernel.org/intel-wired-lan/20241101-jk-ixgbevf-mailbox-v1-5-fixes-v1-0-f556dc9a66ed@intel.com/ +Fixes: 0062e7cc955e ("ixgbevf: add VF IPsec offload code") +Fixes: 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF") +Reviewed-by: Jacob Keller +Reviewed-by: Przemek Kitszel +Reviewed-by: Aleksandr Loktionov +Cc: stable@vger.kernel.org +Signed-off-by: Jedrzej Jagielski +Tested-by: Rafal Romanowski +Signed-off-by: Jacob Keller +Link: https://patch.msgid.link/20251009-jk-iwl-net-2025-10-01-v3-4-ef32a425b92a@intel.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/ixgbevf/ipsec.c | 10 ++++ + drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 7 +++ + drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 32 ++++++++++++++- + drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 + + drivers/net/ethernet/intel/ixgbevf/vf.c | 45 +++++++++++++++++++++- + drivers/net/ethernet/intel/ixgbevf/vf.h | 1 + 6 files changed, 96 insertions(+), 3 deletions(-) + +--- a/drivers/net/ethernet/intel/ixgbevf/ipsec.c ++++ b/drivers/net/ethernet/intel/ixgbevf/ipsec.c +@@ -273,6 +273,9 @@ static int ixgbevf_ipsec_add_sa(struct n + adapter = netdev_priv(dev); + ipsec = adapter->ipsec; + ++ if (!(adapter->pf_features & IXGBEVF_PF_SUP_IPSEC)) ++ return -EOPNOTSUPP; ++ + if (xs->id.proto != IPPROTO_ESP && xs->id.proto != IPPROTO_AH) { + NL_SET_ERR_MSG_MOD(extack, "Unsupported protocol for IPsec offload"); + return -EINVAL; +@@ -405,6 +408,9 @@ static void ixgbevf_ipsec_del_sa(struct + adapter = netdev_priv(dev); + ipsec = adapter->ipsec; + ++ if (!(adapter->pf_features & IXGBEVF_PF_SUP_IPSEC)) ++ return; ++ + if (xs->xso.dir == XFRM_DEV_OFFLOAD_IN) { + sa_idx = xs->xso.offload_handle - IXGBE_IPSEC_BASE_RX_INDEX; + +@@ -612,6 +618,10 @@ void ixgbevf_init_ipsec_offload(struct i + size_t size; + + switch (adapter->hw.api_version) { ++ case ixgbe_mbox_api_17: ++ if (!(adapter->pf_features & IXGBEVF_PF_SUP_IPSEC)) ++ return; ++ break; + case ixgbe_mbox_api_14: + break; + default: +--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h ++++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h +@@ -363,6 +363,13 @@ struct ixgbevf_adapter { + struct ixgbe_hw hw; + u16 msg_enable; + ++ u32 pf_features; ++#define IXGBEVF_PF_SUP_IPSEC BIT(0) ++#define IXGBEVF_PF_SUP_ESX_MBX BIT(1) ++ ++#define IXGBEVF_SUPPORTED_FEATURES (IXGBEVF_PF_SUP_IPSEC | \ ++ IXGBEVF_PF_SUP_ESX_MBX) ++ + struct ixgbevf_hw_stats stats; + + unsigned long state; +--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c ++++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +@@ -2271,10 +2271,35 @@ static void ixgbevf_init_last_counter_st + adapter->stats.base_vfmprc = adapter->stats.last_vfmprc; + } + ++/** ++ * ixgbevf_set_features - Set features supported by PF ++ * @adapter: pointer to the adapter struct ++ * ++ * Negotiate with PF supported features and then set pf_features accordingly. ++ */ ++static void ixgbevf_set_features(struct ixgbevf_adapter *adapter) ++{ ++ u32 *pf_features = &adapter->pf_features; ++ struct ixgbe_hw *hw = &adapter->hw; ++ int err; ++ ++ err = hw->mac.ops.negotiate_features(hw, pf_features); ++ if (err && err != -EOPNOTSUPP) ++ netdev_dbg(adapter->netdev, ++ "PF feature negotiation failed.\n"); ++ ++ /* Address also pre API 1.7 cases */ ++ if (hw->api_version == ixgbe_mbox_api_14) ++ *pf_features |= IXGBEVF_PF_SUP_IPSEC; ++ else if (hw->api_version == ixgbe_mbox_api_15) ++ *pf_features |= IXGBEVF_PF_SUP_ESX_MBX; ++} ++ + static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter) + { + struct ixgbe_hw *hw = &adapter->hw; + static const int api[] = { ++ ixgbe_mbox_api_17, + ixgbe_mbox_api_16, + ixgbe_mbox_api_15, + ixgbe_mbox_api_14, +@@ -2295,8 +2320,9 @@ static void ixgbevf_negotiate_api(struct + idx++; + } + +- /* Following is not supported by API 1.6, it is specific for 1.5 */ +- if (hw->api_version == ixgbe_mbox_api_15) { ++ ixgbevf_set_features(adapter); ++ ++ if (adapter->pf_features & IXGBEVF_PF_SUP_ESX_MBX) { + hw->mbx.ops.init_params(hw); + memcpy(&hw->mbx.ops, &ixgbevf_mbx_ops, + sizeof(struct ixgbe_mbx_operations)); +@@ -2654,6 +2680,7 @@ static void ixgbevf_set_num_queues(struc + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_15: + case ixgbe_mbox_api_16: ++ case ixgbe_mbox_api_17: + if (adapter->xdp_prog && + hw->mac.max_tx_queues == rss) + rss = rss > 3 ? 2 : 1; +@@ -4649,6 +4676,7 @@ static int ixgbevf_probe(struct pci_dev + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_15: + case ixgbe_mbox_api_16: ++ case ixgbe_mbox_api_17: + netdev->max_mtu = IXGBE_MAX_JUMBO_FRAME_SIZE - + (ETH_HLEN + ETH_FCS_LEN); + break; +--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h ++++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h +@@ -67,6 +67,7 @@ enum ixgbe_pfvf_api_rev { + ixgbe_mbox_api_14, /* API version 1.4, linux/freebsd VF driver */ + ixgbe_mbox_api_15, /* API version 1.5, linux/freebsd VF driver */ + ixgbe_mbox_api_16, /* API version 1.6, linux/freebsd VF driver */ ++ ixgbe_mbox_api_17, /* API version 1.7, linux/freebsd VF driver */ + /* This value should always be last */ + ixgbe_mbox_api_unknown, /* indicates that API version is not known */ + }; +@@ -106,6 +107,9 @@ enum ixgbe_pfvf_api_rev { + /* mailbox API, version 1.6 VF requests */ + #define IXGBE_VF_GET_PF_LINK_STATE 0x11 /* request PF to send link info */ + ++/* mailbox API, version 1.7 VF requests */ ++#define IXGBE_VF_FEATURES_NEGOTIATE 0x12 /* get features supported by PF*/ ++ + /* length of permanent address message returned from PF */ + #define IXGBE_VF_PERMADDR_MSG_LEN 4 + /* word in permanent address message with the current multicast type */ +--- a/drivers/net/ethernet/intel/ixgbevf/vf.c ++++ b/drivers/net/ethernet/intel/ixgbevf/vf.c +@@ -313,6 +313,7 @@ int ixgbevf_get_reta_locked(struct ixgbe + * is not supported for this device type. + */ + switch (hw->api_version) { ++ case ixgbe_mbox_api_17: + case ixgbe_mbox_api_16: + case ixgbe_mbox_api_15: + case ixgbe_mbox_api_14: +@@ -383,6 +384,7 @@ int ixgbevf_get_rss_key_locked(struct ix + * or if the operation is not supported for this device type. + */ + switch (hw->api_version) { ++ case ixgbe_mbox_api_17: + case ixgbe_mbox_api_16: + case ixgbe_mbox_api_15: + case ixgbe_mbox_api_14: +@@ -555,6 +557,7 @@ static s32 ixgbevf_update_xcast_mode(str + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_15: + case ixgbe_mbox_api_16: ++ case ixgbe_mbox_api_17: + break; + default: + return -EOPNOTSUPP; +@@ -646,6 +649,7 @@ static int ixgbevf_get_pf_link_state(str + + switch (hw->api_version) { + case ixgbe_mbox_api_16: ++ case ixgbe_mbox_api_17: + break; + default: + return -EOPNOTSUPP; +@@ -670,6 +674,42 @@ static int ixgbevf_get_pf_link_state(str + } + + /** ++ * ixgbevf_negotiate_features_vf - negotiate supported features with PF driver ++ * @hw: pointer to the HW structure ++ * @pf_features: bitmask of features supported by PF ++ * ++ * Return: IXGBE_ERR_MBX in the case of mailbox error, ++ * -EOPNOTSUPP if the op is not supported or 0 on success. ++ */ ++static int ixgbevf_negotiate_features_vf(struct ixgbe_hw *hw, u32 *pf_features) ++{ ++ u32 msgbuf[2] = {}; ++ int err; ++ ++ switch (hw->api_version) { ++ case ixgbe_mbox_api_17: ++ break; ++ default: ++ return -EOPNOTSUPP; ++ } ++ ++ msgbuf[0] = IXGBE_VF_FEATURES_NEGOTIATE; ++ msgbuf[1] = IXGBEVF_SUPPORTED_FEATURES; ++ ++ err = ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf, ++ ARRAY_SIZE(msgbuf)); ++ ++ if (err || (msgbuf[0] & IXGBE_VT_MSGTYPE_FAILURE)) { ++ err = IXGBE_ERR_MBX; ++ *pf_features = 0x0; ++ } else { ++ *pf_features = msgbuf[1]; ++ } ++ ++ return err; ++} ++ ++/** + * ixgbevf_set_vfta_vf - Set/Unset VLAN filter table address + * @hw: pointer to the HW structure + * @vlan: 12 bit VLAN ID +@@ -799,6 +839,7 @@ static s32 ixgbevf_check_mac_link_vf(str + bool *link_up, + bool autoneg_wait_to_complete) + { ++ struct ixgbevf_adapter *adapter = hw->back; + struct ixgbe_mbx_info *mbx = &hw->mbx; + struct ixgbe_mac_info *mac = &hw->mac; + s32 ret_val = 0; +@@ -825,7 +866,7 @@ static s32 ixgbevf_check_mac_link_vf(str + * until we are called again and don't report an error + */ + if (mbx->ops.read(hw, &in_msg, 1)) { +- if (hw->api_version >= ixgbe_mbox_api_15) ++ if (adapter->pf_features & IXGBEVF_PF_SUP_ESX_MBX) + mac->get_link_status = false; + goto out; + } +@@ -1026,6 +1067,7 @@ int ixgbevf_get_queues(struct ixgbe_hw * + case ixgbe_mbox_api_14: + case ixgbe_mbox_api_15: + case ixgbe_mbox_api_16: ++ case ixgbe_mbox_api_17: + break; + default: + return 0; +@@ -1080,6 +1122,7 @@ static const struct ixgbe_mac_operations + .setup_link = ixgbevf_setup_mac_link_vf, + .check_link = ixgbevf_check_mac_link_vf, + .negotiate_api_version = ixgbevf_negotiate_api_version_vf, ++ .negotiate_features = ixgbevf_negotiate_features_vf, + .set_rar = ixgbevf_set_rar_vf, + .update_mc_addr_list = ixgbevf_update_mc_addr_list_vf, + .update_xcast_mode = ixgbevf_update_xcast_mode, +--- a/drivers/net/ethernet/intel/ixgbevf/vf.h ++++ b/drivers/net/ethernet/intel/ixgbevf/vf.h +@@ -26,6 +26,7 @@ struct ixgbe_mac_operations { + s32 (*stop_adapter)(struct ixgbe_hw *); + s32 (*get_bus_info)(struct ixgbe_hw *); + s32 (*negotiate_api_version)(struct ixgbe_hw *hw, int api); ++ int (*negotiate_features)(struct ixgbe_hw *hw, u32 *pf_features); + + /* Link */ + s32 (*setup_link)(struct ixgbe_hw *, ixgbe_link_speed, bool, bool); diff --git a/queue-6.17/jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch b/queue-6.17/jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch new file mode 100644 index 0000000000..1eab3ebba1 --- /dev/null +++ b/queue-6.17/jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch @@ -0,0 +1,85 @@ +From 3c652c3a71de1d30d72dc82c3bead8deb48eb749 Mon Sep 17 00:00:00 2001 +From: Zhang Yi +Date: Tue, 16 Sep 2025 17:33:36 +0800 +Subject: jbd2: ensure that all ongoing I/O complete before freeing blocks + +From: Zhang Yi + +commit 3c652c3a71de1d30d72dc82c3bead8deb48eb749 upstream. + +When releasing file system metadata blocks in jbd2_journal_forget(), if +this buffer has not yet been checkpointed, it may have already been +written back, currently be in the process of being written back, or has +not yet written back. jbd2_journal_forget() calls +jbd2_journal_try_remove_checkpoint() to check the buffer's status and +add it to the current transaction if it has not been written back. This +buffer can only be reallocated after the transaction is committed. + +jbd2_journal_try_remove_checkpoint() attempts to lock the buffer and +check its dirty status while holding the buffer lock. If the buffer has +already been written back, everything proceeds normally. However, there +are two issues. First, the function returns immediately if the buffer is +locked by the write-back process. It does not wait for the write-back to +complete. Consequently, until the current transaction is committed and +the block is reallocated, there is no guarantee that the I/O will +complete. This means that ongoing I/O could write stale metadata to the +newly allocated block, potentially corrupting data. Second, the function +unlocks the buffer as soon as it detects that the buffer is still dirty. +If a concurrent write-back occurs immediately after this unlocking and +before clear_buffer_dirty() is called in jbd2_journal_forget(), data +corruption can theoretically still occur. + +Although these two issues are unlikely to occur in practice since the +undergoing metadata writeback I/O does not take this long to complete, +it's better to explicitly ensure that all ongoing I/O operations are +completed. + +Fixes: 597599268e3b ("jbd2: discard dirty data when forgetting an un-journalled buffer") +Cc: stable@kernel.org +Suggested-by: Jan Kara +Signed-off-by: Zhang Yi +Reviewed-by: Jan Kara +Message-ID: <20250916093337.3161016-2-yi.zhang@huaweicloud.com> +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/jbd2/transaction.c | 13 +++++++++---- + 1 file changed, 9 insertions(+), 4 deletions(-) + +--- a/fs/jbd2/transaction.c ++++ b/fs/jbd2/transaction.c +@@ -1659,6 +1659,7 @@ int jbd2_journal_forget(handle_t *handle + int drop_reserve = 0; + int err = 0; + int was_modified = 0; ++ int wait_for_writeback = 0; + + if (is_handle_aborted(handle)) + return -EROFS; +@@ -1782,18 +1783,22 @@ int jbd2_journal_forget(handle_t *handle + } + + /* +- * The buffer is still not written to disk, we should +- * attach this buffer to current transaction so that the +- * buffer can be checkpointed only after the current +- * transaction commits. ++ * The buffer has not yet been written to disk. We should ++ * either clear the buffer or ensure that the ongoing I/O ++ * is completed, and attach this buffer to current ++ * transaction so that the buffer can be checkpointed only ++ * after the current transaction commits. + */ + clear_buffer_dirty(bh); ++ wait_for_writeback = 1; + __jbd2_journal_file_buffer(jh, transaction, BJ_Forget); + spin_unlock(&journal->j_list_lock); + } + drop: + __brelse(bh); + spin_unlock(&jh->b_state_lock); ++ if (wait_for_writeback) ++ wait_on_buffer(bh); + jbd2_journal_put_journal_head(jh); + if (drop_reserve) { + /* no need to reserve log space for this block -bzzz */ diff --git a/queue-6.17/kvm-arm64-prevent-access-to-vcpu-events-before-init.patch b/queue-6.17/kvm-arm64-prevent-access-to-vcpu-events-before-init.patch new file mode 100644 index 0000000000..e3d2f03761 --- /dev/null +++ b/queue-6.17/kvm-arm64-prevent-access-to-vcpu-events-before-init.patch @@ -0,0 +1,86 @@ +From 0aa1b76fe1429629215a7c79820e4b96233ac4a3 Mon Sep 17 00:00:00 2001 +From: Oliver Upton +Date: Tue, 30 Sep 2025 01:52:37 -0700 +Subject: KVM: arm64: Prevent access to vCPU events before init + +From: Oliver Upton + +commit 0aa1b76fe1429629215a7c79820e4b96233ac4a3 upstream. + +Another day, another syzkaller bug. KVM erroneously allows userspace to +pend vCPU events for a vCPU that hasn't been initialized yet, leading to +KVM interpreting a bunch of uninitialized garbage for routing / +injecting the exception. + +In one case the injection code and the hyp disagree on whether the vCPU +has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, +tripping the BUG() in exception_target_el() during the next injection: + + kernel BUG at arch/arm64/kvm/inject_fault.c:40! + Internal error: Oops - BUG: 00000000f2000800 [#1] SMP + CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT + Hardware name: linux,dummy-virt (DT) + pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) + pc : exception_target_el+0x88/0x8c + lr : pend_serror_exception+0x18/0x13c + sp : ffff800082f03a10 + x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 + x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 + x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 + x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 + x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 + x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 + x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 + x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 + x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 + x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 + Call trace: + exception_target_el+0x88/0x8c (P) + kvm_inject_serror_esr+0x40/0x3b4 + __kvm_arm_vcpu_set_events+0xf0/0x100 + kvm_arch_vcpu_ioctl+0x180/0x9d4 + kvm_vcpu_ioctl+0x60c/0x9f4 + __arm64_sys_ioctl+0xac/0x104 + invoke_syscall+0x48/0x110 + el0_svc_common.constprop.0+0x40/0xe0 + do_el0_svc+0x1c/0x28 + el0_svc+0x34/0xf0 + el0t_64_sync_handler+0xa0/0xe4 + el0t_64_sync+0x198/0x19c + Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) + +Reject the ioctls outright as no sane VMM would call these before +KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been +thrown away by the eventual reset of the vCPU's state. + +Cc: stable@vger.kernel.org # 6.17 +Fixes: b7b27facc7b5 ("arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS") +Signed-off-by: Oliver Upton +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kvm/arm.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/arch/arm64/kvm/arm.c ++++ b/arch/arm64/kvm/arm.c +@@ -1789,6 +1789,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi + case KVM_GET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + ++ if (!kvm_vcpu_initialized(vcpu)) ++ return -ENOEXEC; ++ + if (kvm_arm_vcpu_get_events(vcpu, &events)) + return -EINVAL; + +@@ -1800,6 +1803,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi + case KVM_SET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + ++ if (!kvm_vcpu_initialized(vcpu)) ++ return -ENOEXEC; ++ + if (copy_from_user(&events, argp, sizeof(events))) + return -EFAULT; + diff --git a/queue-6.17/net-usb-lan78xx-fix-lost-eeprom-write-timeout-error-etimedout-in-lan78xx_write_raw_eeprom.patch b/queue-6.17/net-usb-lan78xx-fix-lost-eeprom-write-timeout-error-etimedout-in-lan78xx_write_raw_eeprom.patch new file mode 100644 index 0000000000..fc5a362f06 --- /dev/null +++ b/queue-6.17/net-usb-lan78xx-fix-lost-eeprom-write-timeout-error-etimedout-in-lan78xx_write_raw_eeprom.patch @@ -0,0 +1,54 @@ +From d5d790ba1558dbb8d179054f514476e2ee970b8e Mon Sep 17 00:00:00 2001 +From: Bhanu Seshu Kumar Valluri +Date: Thu, 9 Oct 2025 11:00:09 +0530 +Subject: net: usb: lan78xx: Fix lost EEPROM write timeout error(-ETIMEDOUT) in lan78xx_write_raw_eeprom + +From: Bhanu Seshu Kumar Valluri + +commit d5d790ba1558dbb8d179054f514476e2ee970b8e upstream. + +The function lan78xx_write_raw_eeprom failed to properly propagate EEPROM +write timeout errors (-ETIMEDOUT). In the timeout fallthrough path, it first +attempted to restore the pin configuration for LED outputs and then +returned only the status of that restore operation, discarding the +original timeout error saved in ret. + +As a result, callers could mistakenly treat EEPROM write operation as +successful even though the EEPROM write had actually timed out with no +or partial data write. + +To fix this, handle errors in restoring the LED pin configuration separately. +If the restore succeeds, return any prior EEPROM write timeout error saved +in ret to the caller. + +Suggested-by: Oleksij Rempel +Fixes: 8b1b2ca83b20 ("net: usb: lan78xx: Improve error handling in EEPROM and OTP operations") +cc: stable@vger.kernel.org +Signed-off-by: Bhanu Seshu Kumar Valluri +Reviewed-by: Simon Horman +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/lan78xx.c | 11 +++++++---- + 1 file changed, 7 insertions(+), 4 deletions(-) + +--- a/drivers/net/usb/lan78xx.c ++++ b/drivers/net/usb/lan78xx.c +@@ -1174,10 +1174,13 @@ static int lan78xx_write_raw_eeprom(stru + } + + write_raw_eeprom_done: +- if (dev->chipid == ID_REV_CHIP_ID_7800_) +- return lan78xx_write_reg(dev, HW_CFG, saved); +- +- return 0; ++ if (dev->chipid == ID_REV_CHIP_ID_7800_) { ++ int rc = lan78xx_write_reg(dev, HW_CFG, saved); ++ /* If USB fails, there is nothing to do */ ++ if (rc < 0) ++ return rc; ++ } ++ return ret; + } + + static int lan78xx_read_raw_otp(struct lan78xx_net *dev, u32 offset, diff --git a/queue-6.17/pci-vmd-override-irq_startup-irq_shutdown-in-vmd_init_dev_msi_info.patch b/queue-6.17/pci-vmd-override-irq_startup-irq_shutdown-in-vmd_init_dev_msi_info.patch new file mode 100644 index 0000000000..da8434b703 --- /dev/null +++ b/queue-6.17/pci-vmd-override-irq_startup-irq_shutdown-in-vmd_init_dev_msi_info.patch @@ -0,0 +1,86 @@ +From e433110eb5bf067f74d3d15c5fb252206c66ae0b Mon Sep 17 00:00:00 2001 +From: Inochi Amaoto +Date: Tue, 14 Oct 2025 09:46:07 +0800 +Subject: PCI: vmd: Override irq_startup()/irq_shutdown() in vmd_init_dev_msi_info() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Inochi Amaoto + +commit e433110eb5bf067f74d3d15c5fb252206c66ae0b upstream. + +Since commit 54f45a30c0d0 ("PCI/MSI: Add startup/shutdown for per +device domains") set callback irq_startup() and irq_shutdown() of +the struct pci_msi[x]_template, __irq_startup() will always invokes +irq_startup() callback instead of irq_enable() callback overridden +in vmd_init_dev_msi_info(). This will not start the IRQ correctly. + +Also override irq_startup()/irq_shutdown() in vmd_init_dev_msi_info(), +so the irq_startup() can invoke the real logic. + +Fixes: 54f45a30c0d0 ("PCI/MSI: Add startup/shutdown for per device domains") +Reported-by: Kenneth Crudup +Closes: https://lore.kernel.org/r/8a923590-5b3a-406f-a324-7bd1cf894d8f@panix.com/ +Reported-by: Genes Lists +Closes: https://lore.kernel.org/r/4b392af8847cc19720ffcd53865f60ab3edc56b3.camel@sapience.com +Reported-by: Todd Brandt +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220658 +Reported-by: Oliver Hartkopp +Closes: https://lore.kernel.org/r/8d6887a5-60bc-423c-8f7a-87b4ab739f6a@hartkopp.net +Reported-by: Hervé +Signed-off-by: Inochi Amaoto +Signed-off-by: Bjorn Helgaas +Tested-by: Kenneth R. Crudup +Tested-by: Genes Lists +Tested-by: Oliver Hartkopp +Tested-by: Todd Brandt +Tested-by: Hervé +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20251014014607.612586-1-inochiama@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/vmd.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c +index 1bd5bf4a6097..b4b62b9ccc45 100644 +--- a/drivers/pci/controller/vmd.c ++++ b/drivers/pci/controller/vmd.c +@@ -192,6 +192,12 @@ static void vmd_pci_msi_enable(struct irq_data *data) + data->chip->irq_unmask(data); + } + ++static unsigned int vmd_pci_msi_startup(struct irq_data *data) ++{ ++ vmd_pci_msi_enable(data); ++ return 0; ++} ++ + static void vmd_irq_disable(struct irq_data *data) + { + struct vmd_irq *vmdirq = data->chip_data; +@@ -210,6 +216,11 @@ static void vmd_pci_msi_disable(struct irq_data *data) + vmd_irq_disable(data->parent_data); + } + ++static void vmd_pci_msi_shutdown(struct irq_data *data) ++{ ++ vmd_pci_msi_disable(data); ++} ++ + static struct irq_chip vmd_msi_controller = { + .name = "VMD-MSI", + .irq_compose_msi_msg = vmd_compose_msi_msg, +@@ -309,6 +320,8 @@ static bool vmd_init_dev_msi_info(struct device *dev, struct irq_domain *domain, + if (!msi_lib_init_dev_msi_info(dev, domain, real_parent, info)) + return false; + ++ info->chip->irq_startup = vmd_pci_msi_startup; ++ info->chip->irq_shutdown = vmd_pci_msi_shutdown; + info->chip->irq_enable = vmd_pci_msi_enable; + info->chip->irq_disable = vmd_pci_msi_disable; + return true; +-- +2.51.1.dirty + diff --git a/queue-6.17/perf-core-fix-address-filter-match-with-backing-files.patch b/queue-6.17/perf-core-fix-address-filter-match-with-backing-files.patch new file mode 100644 index 0000000000..4cebb877c3 --- /dev/null +++ b/queue-6.17/perf-core-fix-address-filter-match-with-backing-files.patch @@ -0,0 +1,87 @@ +From ebfc8542ad62d066771e46c8aa30f5624b89cad8 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Mon, 13 Oct 2025 10:22:42 +0300 +Subject: perf/core: Fix address filter match with backing files + +From: Adrian Hunter + +commit ebfc8542ad62d066771e46c8aa30f5624b89cad8 upstream. + +It was reported that Intel PT address filters do not work in Docker +containers. That relates to the use of overlayfs. + +overlayfs records the backing file in struct vm_area_struct vm_file, +instead of the user file that the user mmapped. In order for an address +filter to match, it must compare to the user file inode. There is an +existing helper file_user_inode() for that situation. + +Use file_user_inode() instead of file_inode() to get the inode for address +filter matching. + +Example: + + Setup: + + # cd /root + # mkdir test ; cd test ; mkdir lower upper work merged + # cp `which cat` lower + # mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merged + # perf record --buildid-mmap -e intel_pt//u --filter 'filter * @ /root/test/merged/cat' -- /root/test/merged/cat /proc/self/maps + ... + 55d61d246000-55d61d2e1000 r-xp 00018000 00:1a 3418 /root/test/merged/cat + ... + [ perf record: Woken up 1 times to write data ] + [ perf record: Captured and wrote 0.015 MB perf.data ] + # perf buildid-cache --add /root/test/merged/cat + + Before: + + Address filter does not match so there are no control flow packets + + # perf script --itrace=e + # perf script --itrace=b | wc -l + 0 + # perf script -D | grep 'TIP.PGE' | wc -l + 0 + # + + After: + + Address filter does match so there are control flow packets + + # perf script --itrace=e + # perf script --itrace=b | wc -l + 235 + # perf script -D | grep 'TIP.PGE' | wc -l + 57 + # + +With respect to stable kernels, overlayfs mmap function ovl_mmap() was +added in v4.19 but file_user_inode() was not added until v6.8 and never +back-ported to stable kernels. FMODE_BACKING that it depends on was added +in v6.5. This issue has gone largely unnoticed, so back-porting before +v6.8 is probably not worth it, so put 6.8 as the stable kernel prerequisite +version, although in practice the next long term kernel is 6.12. + +Closes: https://lore.kernel.org/linux-perf-users/aBCwoq7w8ohBRQCh@fremen.lan +Reported-by: Edd Barrett +Signed-off-by: Adrian Hunter +Signed-off-by: Peter Zijlstra (Intel) +Acked-by: Amir Goldstein +Cc: stable@vger.kernel.org # 6.8 +Signed-off-by: Greg Kroah-Hartman +--- + kernel/events/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -9479,7 +9479,7 @@ static bool perf_addr_filter_match(struc + if (!filter->path.dentry) + return false; + +- if (d_inode(filter->path.dentry) != file_inode(file)) ++ if (d_inode(filter->path.dentry) != file_user_inode(file)) + return false; + + if (filter->offset > offset + size) diff --git a/queue-6.17/perf-core-fix-mmap-event-path-names-with-backing-files.patch b/queue-6.17/perf-core-fix-mmap-event-path-names-with-backing-files.patch new file mode 100644 index 0000000000..2f6aab1acb --- /dev/null +++ b/queue-6.17/perf-core-fix-mmap-event-path-names-with-backing-files.patch @@ -0,0 +1,82 @@ +From 8818f507a9391019a3ec7c57b1a32e4b386e48a5 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Mon, 13 Oct 2025 10:22:43 +0300 +Subject: perf/core: Fix MMAP event path names with backing files + +From: Adrian Hunter + +commit 8818f507a9391019a3ec7c57b1a32e4b386e48a5 upstream. + +Some file systems like FUSE-based ones or overlayfs may record the backing +file in struct vm_area_struct vm_file, instead of the user file that the +user mmapped. + +Since commit def3ae83da02f ("fs: store real path instead of fake path in +backing file f_path"), file_path() no longer returns the user file path +when applied to a backing file. There is an existing helper +file_user_path() for that situation. + +Use file_user_path() instead of file_path() to get the path for MMAP +and MMAP2 events. + +Example: + + Setup: + + # cd /root + # mkdir test ; cd test ; mkdir lower upper work merged + # cp `which cat` lower + # mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merged + # perf record -e intel_pt//u -- /root/test/merged/cat /proc/self/maps + ... + 55b0ba399000-55b0ba434000 r-xp 00018000 00:1a 3419 /root/test/merged/cat + ... + [ perf record: Woken up 1 times to write data ] + [ perf record: Captured and wrote 0.060 MB perf.data ] + # + + Before: + + File name is wrong (/cat), so decoding fails: + + # perf script --no-itrace --show-mmap-events + cat 367 [016] 100.491492: PERF_RECORD_MMAP2 367/367: [0x55b0ba399000(0x9b000) @ 0x18000 00:02 3419 489959280]: r-xp /cat + ... + # perf script --itrace=e | wc -l + Warning: + 19 instruction trace errors + 19 + # + + After: + + File name is correct (/root/test/merged/cat), so decoding is ok: + + # perf script --no-itrace --show-mmap-events + cat 364 [016] 72.153006: PERF_RECORD_MMAP2 364/364: [0x55ce4003d000(0x9b000) @ 0x18000 00:02 3419 3132534314]: r-xp /root/test/merged/cat + # perf script --itrace=e + # perf script --itrace=e | wc -l + 0 + # + +Fixes: def3ae83da02f ("fs: store real path instead of fake path in backing file f_path") +Signed-off-by: Adrian Hunter +Signed-off-by: Peter Zijlstra (Intel) +Acked-by: Amir Goldstein +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + kernel/events/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -9403,7 +9403,7 @@ static void perf_event_mmap_event(struct + * need to add enough zero bytes after the string to handle + * the 64bit alignment we do later. + */ +- name = file_path(file, buf, PATH_MAX - sizeof(u64)); ++ name = d_path(file_user_path(file), buf, PATH_MAX - sizeof(u64)); + if (IS_ERR(name)) { + name = "//toolong"; + goto cpy_name; diff --git a/queue-6.17/perf-core-fix-mmap2-event-device-with-backing-files.patch b/queue-6.17/perf-core-fix-mmap2-event-device-with-backing-files.patch new file mode 100644 index 0000000000..ca7c64065a --- /dev/null +++ b/queue-6.17/perf-core-fix-mmap2-event-device-with-backing-files.patch @@ -0,0 +1,96 @@ +From fa4f4bae893fbce8a3edfff1ab7ece0c01dc1328 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Mon, 13 Oct 2025 10:22:44 +0300 +Subject: perf/core: Fix MMAP2 event device with backing files + +From: Adrian Hunter + +commit fa4f4bae893fbce8a3edfff1ab7ece0c01dc1328 upstream. + +Some file systems like FUSE-based ones or overlayfs may record the backing +file in struct vm_area_struct vm_file, instead of the user file that the +user mmapped. + +That causes perf to misreport the device major/minor numbers of the file +system of the file, and the generation of the file, and potentially other +inode details. There is an existing helper file_user_inode() for that +situation. + +Use file_user_inode() instead of file_inode() to get the inode for MMAP2 +events. + +Example: + + Setup: + + # cd /root + # mkdir test ; cd test ; mkdir lower upper work merged + # cp `which cat` lower + # mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merged + # perf record -e cycles:u -- /root/test/merged/cat /proc/self/maps + ... + 55b2c91d0000-55b2c926b000 r-xp 00018000 00:1a 3419 /root/test/merged/cat + ... + [ perf record: Woken up 1 times to write data ] + [ perf record: Captured and wrote 0.004 MB perf.data (5 samples) ] + # + # stat /root/test/merged/cat + File: /root/test/merged/cat + Size: 1127792 Blocks: 2208 IO Block: 4096 regular file + Device: 0,26 Inode: 3419 Links: 1 + Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) + Access: 2025-09-08 12:23:59.453309624 +0000 + Modify: 2025-09-08 12:23:59.454309624 +0000 + Change: 2025-09-08 12:23:59.454309624 +0000 + Birth: 2025-09-08 12:23:59.453309624 +0000 + + Before: + + Device reported 00:02 differs from stat output and /proc/self/maps + + # perf script --show-mmap-events | grep /root/test/merged/cat + cat 377 [-01] 243.078558: PERF_RECORD_MMAP2 377/377: [0x55b2c91d0000(0x9b000) @ 0x18000 00:02 3419 2068525940]: r-xp /root/test/merged/cat + + After: + + Device reported 00:1a is the same as stat output and /proc/self/maps + + # perf script --show-mmap-events | grep /root/test/merged/cat + cat 362 [-01] 127.755167: PERF_RECORD_MMAP2 362/362: [0x55ba6e781000(0x9b000) @ 0x18000 00:1a 3419 0]: r-xp /root/test/merged/cat + +With respect to stable kernels, overlayfs mmap function ovl_mmap() was +added in v4.19 but file_user_inode() was not added until v6.8 and never +back-ported to stable kernels. FMODE_BACKING that it depends on was added +in v6.5. This issue has gone largely unnoticed, so back-porting before +v6.8 is probably not worth it, so put 6.8 as the stable kernel prerequisite +version, although in practice the next long term kernel is 6.12. + +Signed-off-by: Adrian Hunter +Signed-off-by: Peter Zijlstra (Intel) +Acked-by: Amir Goldstein +Cc: stable@vger.kernel.org # 6.8 +Signed-off-by: Greg Kroah-Hartman +--- + kernel/events/core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -9390,7 +9390,7 @@ static void perf_event_mmap_event(struct + flags |= MAP_HUGETLB; + + if (file) { +- struct inode *inode; ++ const struct inode *inode; + dev_t dev; + + buf = kmalloc(PATH_MAX, GFP_KERNEL); +@@ -9408,7 +9408,7 @@ static void perf_event_mmap_event(struct + name = "//toolong"; + goto cpy_name; + } +- inode = file_inode(vma->vm_file); ++ inode = file_user_inode(vma->vm_file); + dev = inode->i_sb->s_dev; + ino = inode->i_ino; + gen = inode->i_generation; diff --git a/queue-6.17/r8152-add-error-handling-in-rtl8152_driver_init.patch b/queue-6.17/r8152-add-error-handling-in-rtl8152_driver_init.patch new file mode 100644 index 0000000000..4d005a4073 --- /dev/null +++ b/queue-6.17/r8152-add-error-handling-in-rtl8152_driver_init.patch @@ -0,0 +1,41 @@ +From 75527d61d60d493d1eb064f335071a20ca581f54 Mon Sep 17 00:00:00 2001 +From: Yi Cong +Date: Sat, 11 Oct 2025 16:24:15 +0800 +Subject: r8152: add error handling in rtl8152_driver_init + +From: Yi Cong + +commit 75527d61d60d493d1eb064f335071a20ca581f54 upstream. + +rtl8152_driver_init() is missing the error handling. +When rtl8152_driver registration fails, rtl8152_cfgselector_driver +should be deregistered. + +Fixes: ec51fbd1b8a2 ("r8152: add USB device driver for config selection") +Cc: stable@vger.kernel.org +Signed-off-by: Yi Cong +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20251011082415.580740-1-yicongsrfy@163.com +[pabeni@redhat.com: clarified the commit message] +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/r8152.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/net/usb/r8152.c ++++ b/drivers/net/usb/r8152.c +@@ -10122,7 +10122,12 @@ static int __init rtl8152_driver_init(vo + ret = usb_register_device_driver(&rtl8152_cfgselector_driver, THIS_MODULE); + if (ret) + return ret; +- return usb_register(&rtl8152_driver); ++ ++ ret = usb_register(&rtl8152_driver); ++ if (ret) ++ usb_deregister_device_driver(&rtl8152_cfgselector_driver); ++ ++ return ret; + } + + static void __exit rtl8152_driver_exit(void) diff --git a/queue-6.17/revert-drm-amd-display-only-restore-backlight-after-amdgpu_dm_init-or-dm_resume.patch b/queue-6.17/revert-drm-amd-display-only-restore-backlight-after-amdgpu_dm_init-or-dm_resume.patch new file mode 100644 index 0000000000..2023ffa0ed --- /dev/null +++ b/queue-6.17/revert-drm-amd-display-only-restore-backlight-after-amdgpu_dm_init-or-dm_resume.patch @@ -0,0 +1,95 @@ +From 9858ea4c29c283f0a8a3cdbb42108d464ece90a8 Mon Sep 17 00:00:00 2001 +From: Matthew Schwartz +Date: Thu, 9 Oct 2025 14:19:00 +0200 +Subject: Revert "drm/amd/display: Only restore backlight after amdgpu_dm_init or dm_resume" + +From: Matthew Schwartz + +commit 9858ea4c29c283f0a8a3cdbb42108d464ece90a8 upstream. + +This fix regressed the original issue that commit 7875afafba84 +("drm/amd/display: Fix brightness level not retained over reboot") solved, +so revert it until a different approach to solve the regression that +it caused with AMD_PRIVATE_COLOR is found. + +Fixes: a490c8d77d50 ("drm/amd/display: Only restore backlight after amdgpu_dm_init or dm_resume") +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4620 +Cc: stable@vger.kernel.org +Signed-off-by: Matthew Schwartz +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++++-------- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 ------- + 2 files changed, 4 insertions(+), 15 deletions(-) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -2041,8 +2041,6 @@ static int amdgpu_dm_init(struct amdgpu_ + + dc_hardware_init(adev->dm.dc); + +- adev->dm.restore_backlight = true; +- + adev->dm.hpd_rx_offload_wq = hpd_rx_irq_create_workqueue(adev); + if (!adev->dm.hpd_rx_offload_wq) { + drm_err(adev_to_drm(adev), "failed to create hpd rx offload workqueue.\n"); +@@ -3405,7 +3403,6 @@ static int dm_resume(struct amdgpu_ip_bl + dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D0); + + dc_resume(dm->dc); +- adev->dm.restore_backlight = true; + + amdgpu_dm_irq_resume_early(adev); + +@@ -9836,6 +9833,7 @@ static void amdgpu_dm_commit_streams(str + bool mode_set_reset_required = false; + u32 i; + struct dc_commit_streams_params params = {dc_state->streams, dc_state->stream_count}; ++ bool set_backlight_level = false; + + /* Disable writeback */ + for_each_old_connector_in_state(state, connector, old_con_state, i) { +@@ -9955,6 +9953,7 @@ static void amdgpu_dm_commit_streams(str + acrtc->hw_mode = new_crtc_state->mode; + crtc->hwmode = new_crtc_state->mode; + mode_set_reset_required = true; ++ set_backlight_level = true; + } else if (modereset_required(new_crtc_state)) { + drm_dbg_atomic(dev, + "Atomic commit: RESET. crtc id %d:[%p]\n", +@@ -10011,16 +10010,13 @@ static void amdgpu_dm_commit_streams(str + * to fix a flicker issue. + * It will cause the dm->actual_brightness is not the current panel brightness + * level. (the dm->brightness is the correct panel level) +- * So we set the backlight level with dm->brightness value after initial +- * set mode. Use restore_backlight flag to avoid setting backlight level +- * for every subsequent mode set. ++ * So we set the backlight level with dm->brightness value after set mode + */ +- if (dm->restore_backlight) { ++ if (set_backlight_level) { + for (i = 0; i < dm->num_of_edps; i++) { + if (dm->backlight_dev[i]) + amdgpu_dm_backlight_set_level(dm, i, dm->brightness[i]); + } +- dm->restore_backlight = false; + } + } + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h +@@ -611,13 +611,6 @@ struct amdgpu_display_manager { + u32 actual_brightness[AMDGPU_DM_MAX_NUM_EDP]; + + /** +- * @restore_backlight: +- * +- * Flag to indicate whether to restore backlight after modeset. +- */ +- bool restore_backlight; +- +- /** + * @aux_hpd_discon_quirk: + * + * quirk for hpd discon while aux is on-going. diff --git a/queue-6.17/revert-fs-make-vfs_fileattr_-return-eopnotsupp.patch b/queue-6.17/revert-fs-make-vfs_fileattr_-return-eopnotsupp.patch new file mode 100644 index 0000000000..6ae6175c22 --- /dev/null +++ b/queue-6.17/revert-fs-make-vfs_fileattr_-return-eopnotsupp.patch @@ -0,0 +1,138 @@ +From 4dd5b5ac089bb6ea719b7ffb748707ac9cbce4e4 Mon Sep 17 00:00:00 2001 +From: Andrey Albershteyn +Date: Wed, 8 Oct 2025 14:44:17 +0200 +Subject: Revert "fs: make vfs_fileattr_[get|set] return -EOPNOTSUPP" + +From: Andrey Albershteyn + +commit 4dd5b5ac089bb6ea719b7ffb748707ac9cbce4e4 upstream. + +This reverts commit 474b155adf3927d2c944423045757b54aa1ca4de. + +This patch caused regression in ioctl_setflags(). Underlying filesystems +use EOPNOTSUPP to indicate that flag is not supported. This error is +also gets converted in ioctl_setflags(). Therefore, for unsupported +flags error changed from EOPNOSUPP to ENOIOCTLCMD. + +Link: https://lore.kernel.org/linux-xfs/a622643f-1585-40b0-9441-cf7ece176e83@kernel.org/ +Signed-off-by: Andrey Albershteyn +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + fs/file_attr.c | 12 ++---------- + fs/fuse/ioctl.c | 4 ---- + fs/overlayfs/copy_up.c | 2 +- + fs/overlayfs/inode.c | 5 ++++- + 4 files changed, 7 insertions(+), 16 deletions(-) + +diff --git a/fs/file_attr.c b/fs/file_attr.c +index 12424d4945d0..460b2dd21a85 100644 +--- a/fs/file_attr.c ++++ b/fs/file_attr.c +@@ -84,7 +84,7 @@ int vfs_fileattr_get(struct dentry *dentry, struct file_kattr *fa) + int error; + + if (!inode->i_op->fileattr_get) +- return -EOPNOTSUPP; ++ return -ENOIOCTLCMD; + + error = security_inode_file_getattr(dentry, fa); + if (error) +@@ -270,7 +270,7 @@ int vfs_fileattr_set(struct mnt_idmap *idmap, struct dentry *dentry, + int err; + + if (!inode->i_op->fileattr_set) +- return -EOPNOTSUPP; ++ return -ENOIOCTLCMD; + + if (!inode_owner_or_capable(idmap, inode)) + return -EPERM; +@@ -312,8 +312,6 @@ int ioctl_getflags(struct file *file, unsigned int __user *argp) + int err; + + err = vfs_fileattr_get(file->f_path.dentry, &fa); +- if (err == -EOPNOTSUPP) +- err = -ENOIOCTLCMD; + if (!err) + err = put_user(fa.flags, argp); + return err; +@@ -335,8 +333,6 @@ int ioctl_setflags(struct file *file, unsigned int __user *argp) + fileattr_fill_flags(&fa, flags); + err = vfs_fileattr_set(idmap, dentry, &fa); + mnt_drop_write_file(file); +- if (err == -EOPNOTSUPP) +- err = -ENOIOCTLCMD; + } + } + return err; +@@ -349,8 +345,6 @@ int ioctl_fsgetxattr(struct file *file, void __user *argp) + int err; + + err = vfs_fileattr_get(file->f_path.dentry, &fa); +- if (err == -EOPNOTSUPP) +- err = -ENOIOCTLCMD; + if (!err) + err = copy_fsxattr_to_user(&fa, argp); + +@@ -371,8 +365,6 @@ int ioctl_fssetxattr(struct file *file, void __user *argp) + if (!err) { + err = vfs_fileattr_set(idmap, dentry, &fa); + mnt_drop_write_file(file); +- if (err == -EOPNOTSUPP) +- err = -ENOIOCTLCMD; + } + } + return err; +diff --git a/fs/fuse/ioctl.c b/fs/fuse/ioctl.c +index 57032eadca6c..fdc175e93f74 100644 +--- a/fs/fuse/ioctl.c ++++ b/fs/fuse/ioctl.c +@@ -536,8 +536,6 @@ int fuse_fileattr_get(struct dentry *dentry, struct file_kattr *fa) + cleanup: + fuse_priv_ioctl_cleanup(inode, ff); + +- if (err == -ENOTTY) +- err = -EOPNOTSUPP; + return err; + } + +@@ -574,7 +572,5 @@ int fuse_fileattr_set(struct mnt_idmap *idmap, + cleanup: + fuse_priv_ioctl_cleanup(inode, ff); + +- if (err == -ENOTTY) +- err = -EOPNOTSUPP; + return err; + } +diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c +index aac7e34f56c1..604a82acd164 100644 +--- a/fs/overlayfs/copy_up.c ++++ b/fs/overlayfs/copy_up.c +@@ -178,7 +178,7 @@ static int ovl_copy_fileattr(struct inode *inode, const struct path *old, + err = ovl_real_fileattr_get(old, &oldfa); + if (err) { + /* Ntfs-3g returns -EINVAL for "no fileattr support" */ +- if (err == -EOPNOTSUPP || err == -EINVAL) ++ if (err == -ENOTTY || err == -EINVAL) + return 0; + pr_warn("failed to retrieve lower fileattr (%pd2, err=%i)\n", + old->dentry, err); +diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c +index aaa4cf579561..e11f310ce092 100644 +--- a/fs/overlayfs/inode.c ++++ b/fs/overlayfs/inode.c +@@ -720,7 +720,10 @@ int ovl_real_fileattr_get(const struct path *realpath, struct file_kattr *fa) + if (err) + return err; + +- return vfs_fileattr_get(realpath->dentry, fa); ++ err = vfs_fileattr_get(realpath->dentry, fa); ++ if (err == -ENOIOCTLCMD) ++ err = -ENOTTY; ++ return err; + } + + int ovl_fileattr_get(struct dentry *dentry, struct file_kattr *fa) +-- +2.51.1.dirty + diff --git a/queue-6.17/revert-io_uring-rw-drop-eopnotsupp-check-in-__io_complete_rw_common.patch b/queue-6.17/revert-io_uring-rw-drop-eopnotsupp-check-in-__io_complete_rw_common.patch new file mode 100644 index 0000000000..50066ad2fb --- /dev/null +++ b/queue-6.17/revert-io_uring-rw-drop-eopnotsupp-check-in-__io_complete_rw_common.patch @@ -0,0 +1,41 @@ +From 927069c4ac2cd1a37efa468596fb5b8f86db9df0 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Mon, 13 Oct 2025 12:05:31 -0600 +Subject: Revert "io_uring/rw: drop -EOPNOTSUPP check in __io_complete_rw_common()" + +From: Jens Axboe + +commit 927069c4ac2cd1a37efa468596fb5b8f86db9df0 upstream. + +This reverts commit 90bfb28d5fa8127a113a140c9791ea0b40ab156a. + +Kevin reports that this commit causes an issue for him with LVM +snapshots, most likely because of turning off NOWAIT support while a +snapshot is being created. This makes -EOPNOTSUPP bubble back through +the completion handler, where io_uring read/write handling should just +retry it. + +Reinstate the previous check removed by the referenced commit. + +Cc: stable@vger.kernel.org +Fixes: 90bfb28d5fa8 ("io_uring/rw: drop -EOPNOTSUPP check in __io_complete_rw_common()") +Reported-by: Salvatore Bonaccorso +Reported-by: Kevin Lumik +Link: https://lore.kernel.org/io-uring/cceb723c-051b-4de2-9a4c-4aa82e1619ee@kernel.dk/ +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/rw.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/io_uring/rw.c ++++ b/io_uring/rw.c +@@ -540,7 +540,7 @@ static void __io_complete_rw_common(stru + { + if (res == req->cqe.res) + return; +- if (res == -EAGAIN && io_rw_should_reissue(req)) { ++ if ((res == -EOPNOTSUPP || res == -EAGAIN) && io_rw_should_reissue(req)) { + req->flags |= REQ_F_REISSUE | REQ_F_BL_NO_RECYCLE; + } else { + req_set_fail(req); diff --git a/queue-6.17/rust-cfi-only-64-bit-arm-and-x86-support-cfi_clang.patch b/queue-6.17/rust-cfi-only-64-bit-arm-and-x86-support-cfi_clang.patch new file mode 100644 index 0000000000..6c9099b820 --- /dev/null +++ b/queue-6.17/rust-cfi-only-64-bit-arm-and-x86-support-cfi_clang.patch @@ -0,0 +1,50 @@ +From 812258ff4166bcd41c7d44707e0591f9ae32ac8c Mon Sep 17 00:00:00 2001 +From: Conor Dooley +Date: Mon, 8 Sep 2025 14:12:35 +0100 +Subject: rust: cfi: only 64-bit arm and x86 support CFI_CLANG + +From: Conor Dooley + +commit 812258ff4166bcd41c7d44707e0591f9ae32ac8c upstream. + +The kernel uses the standard rustc targets for non-x86 targets, and out +of those only 64-bit arm's target has kcfi support enabled. For x86, the +custom 64-bit target enables kcfi. + +The HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC config option that allows +CFI_CLANG to be used in combination with RUST does not check whether the +rustc target supports kcfi. This breaks the build on riscv (and +presumably 32-bit arm) when CFI_CLANG and RUST are enabled at the same +time. + +Ordinarily, a rustc-option check would be used to detect target support +but unfortunately rustc-option filters out the target for reasons given +in commit 46e24a545cdb4 ("rust: kasan/kbuild: fix missing flags on first +build"). As a result, if the host supports kcfi but the target does not, +e.g. when building for riscv on x86_64, the build would remain broken. + +Instead, make HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC depend on the only +two architectures where the target used supports it to fix the build. + +CC: stable@vger.kernel.org +Fixes: ca627e636551e ("rust: cfi: add support for CFI_CLANG with Rust") +Signed-off-by: Conor Dooley +Acked-by: Miguel Ojeda +Reviewed-by: Alice Ryhl +Link: https://lore.kernel.org/r/20250908-distill-lint-1ae78bcf777c@spud +Signed-off-by: Paul Walmsley +Signed-off-by: Greg Kroah-Hartman +--- + arch/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/Kconfig ++++ b/arch/Kconfig +@@ -917,6 +917,7 @@ config HAVE_CFI_ICALL_NORMALIZE_INTEGERS + def_bool y + depends on HAVE_CFI_ICALL_NORMALIZE_INTEGERS_CLANG + depends on RUSTC_VERSION >= 107900 ++ depends on ARM64 || X86_64 + # With GCOV/KASAN we need this fix: https://github.com/rust-lang/rust/pull/129373 + depends on (RUSTC_LLVM_VERSION >= 190103 && RUSTC_VERSION >= 108200) || \ + (!GCOV_KERNEL && !KASAN_GENERIC && !KASAN_SW_TAGS) diff --git a/queue-6.17/series b/queue-6.17/series new file mode 100644 index 0000000000..677814aa74 --- /dev/null +++ b/queue-6.17/series @@ -0,0 +1,46 @@ +docs-kdoc-handle-the-obsolescensce-of-docutils.errorstring.patch +revert-fs-make-vfs_fileattr_-return-eopnotsupp.patch +pci-vmd-override-irq_startup-irq_shutdown-in-vmd_init_dev_msi_info.patch +vfs-don-t-leak-disconnected-dentries-on-umount.patch +ata-libata-core-relax-checks-in-ata_read_log_directory.patch +arm64-sysreg-fix-gic-cdeoi-instruction-encoding.patch +drm-xe-guc-check-guc-running-state-before-deregistering-exec-queue.patch +ixgbevf-fix-getting-link-speed-data-for-e610-devices.patch +ixgbevf-fix-mailbox-api-compatibility-by-negotiating-supported-features.patch +rust-cfi-only-64-bit-arm-and-x86-support-cfi_clang.patch +smb-client-fix-refcount-leak-for-cifs_sb_tlink.patch +x86-cpu-amd-prevent-reset-reasons-from-being-retained-across-reboot.patch +slab-reset-slab-obj_ext-when-freeing-and-it-is-objexts_alloc_fail.patch +revert-io_uring-rw-drop-eopnotsupp-check-in-__io_complete_rw_common.patch +io_uring-protect-mem-region-deregistration.patch +revert-drm-amd-display-only-restore-backlight-after-amdgpu_dm_init-or-dm_resume.patch +r8152-add-error-handling-in-rtl8152_driver_init.patch +net-usb-lan78xx-fix-lost-eeprom-write-timeout-error-etimedout-in-lan78xx_write_raw_eeprom.patch +kvm-arm64-prevent-access-to-vcpu-events-before-init.patch +f2fs-fix-wrong-block-mapping-for-multi-devices.patch +gve-check-valid-ts-bit-on-rx-descriptor-before-hw-timestamping.patch +jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch +ext4-wait-for-ongoing-i-o-to-complete-before-freeing-blocks.patch +ext4-detect-invalid-inline_data-extents-flag-combination.patch +btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch +btrfs-fix-memory-leak-on-duplicated-memory-in-the-qgroup-assign-ioctl.patch +btrfs-only-set-the-device-specific-options-after-devices-are-opened.patch +btrfs-fix-incorrect-readahead-expansion-length.patch +btrfs-fix-memory-leaks-when-rejecting-a-non-single-data-profile-without-an-rst.patch +btrfs-do-not-assert-we-found-block-group-item-when-creating-free-space-tree.patch +can-gs_usb-gs_make_candev-populate-net_device-dev_port.patch +can-gs_usb-increase-max-interface-to-u8_max.patch +cifs-parse_dfs_referrals-prevent-oob-on-malformed-input.patch +cxl-acpi-fix-setup-of-memory-resource-in-cxl_acpi_set_cache_size.patch +alsa-hda-intel-add-msi-x870e-tomahawk-to-denylist.patch +alsa-hda-realtek-add-quirk-entry-for-hp-zbook-17-g6.patch +alsa-hda-cs35l41-fix-null-pointer-dereference-in-cs35l41_get_acpi_mute_state.patch +alsa-hda-fix-missing-pointer-check-in-hda_component_manager_init-function.patch +drm-sched-fix-potential-double-free-in-drm_sched_job_add_resv_dependencies.patch +drm-ast-blank-with-vgacr17-sync-enable-always-clear-vgacrb6-sync-off.patch +drm-amdgpu-use-atomic-functions-with-memory-barriers-for-vm-fault-info.patch +drm-amdgpu-fix-gfx12-mes-packet-status-return-check.patch +drm-xe-increase-global-invalidation-timeout-to-1000us.patch +perf-core-fix-address-filter-match-with-backing-files.patch +perf-core-fix-mmap-event-path-names-with-backing-files.patch +perf-core-fix-mmap2-event-device-with-backing-files.patch diff --git a/queue-6.17/slab-reset-slab-obj_ext-when-freeing-and-it-is-objexts_alloc_fail.patch b/queue-6.17/slab-reset-slab-obj_ext-when-freeing-and-it-is-objexts_alloc_fail.patch new file mode 100644 index 0000000000..41af42f68e --- /dev/null +++ b/queue-6.17/slab-reset-slab-obj_ext-when-freeing-and-it-is-objexts_alloc_fail.patch @@ -0,0 +1,59 @@ +From 86f54f9b6c17d6567c69e3a6fed52fdf5d7dbe93 Mon Sep 17 00:00:00 2001 +From: Hao Ge +Date: Wed, 15 Oct 2025 22:16:42 +0800 +Subject: slab: reset slab->obj_ext when freeing and it is OBJEXTS_ALLOC_FAIL + +From: Hao Ge + +commit 86f54f9b6c17d6567c69e3a6fed52fdf5d7dbe93 upstream. + +If obj_exts allocation failed, slab->obj_exts is set to OBJEXTS_ALLOC_FAIL, +But we do not clear it when freeing the slab. Since OBJEXTS_ALLOC_FAIL and +MEMCG_DATA_OBJEXTS currently share the same bit position, during the +release of the associated folio, a VM_BUG_ON_FOLIO() check in +folio_memcg_kmem() is triggered because the OBJEXTS_ALLOC_FAIL flag was +not cleared, causing it to be interpreted as a kmem folio (non-slab) +with MEMCG_OBJEXTS_DATA flag set, which is invalid because +MEMCG_OBJEXTS_DATA is supposed to be set only on slabs. + +Another problem that predates sharing the OBJEXTS_ALLOC_FAIL and +MEMCG_DATA_OBJEXTS bits is that on configurations with +is_check_pages_enabled(), the non-cleared bit in page->memcg_data will +trigger a free_page_is_bad() failure "page still charged to cgroup" + +When freeing a slab, we clear slab->obj_exts if the obj_ext array has +been successfully allocated. So let's clear it also when the allocation +has failed. + +Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations") +Fixes: 7612833192d5 ("slab: Reuse first bit for OBJEXTS_ALLOC_FAIL") +Link: https://lore.kernel.org/all/20251015141642.700170-1-hao.ge@linux.dev/ +Cc: +Signed-off-by: Hao Ge +Reviewed-by: Suren Baghdasaryan +Reviewed-by: Harry Yoo +Signed-off-by: Vlastimil Babka +Signed-off-by: Greg Kroah-Hartman +--- + mm/slub.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -2073,8 +2073,15 @@ static inline void free_slab_obj_exts(st + struct slabobj_ext *obj_exts; + + obj_exts = slab_obj_exts(slab); +- if (!obj_exts) ++ if (!obj_exts) { ++ /* ++ * If obj_exts allocation failed, slab->obj_exts is set to ++ * OBJEXTS_ALLOC_FAIL. In this case, we end up here and should ++ * clear the flag. ++ */ ++ slab->obj_exts = 0; + return; ++ } + + /* + * obj_exts was created with __GFP_NO_OBJ_EXT flag, therefore its diff --git a/queue-6.17/smb-client-fix-refcount-leak-for-cifs_sb_tlink.patch b/queue-6.17/smb-client-fix-refcount-leak-for-cifs_sb_tlink.patch new file mode 100644 index 0000000000..6a7f608d05 --- /dev/null +++ b/queue-6.17/smb-client-fix-refcount-leak-for-cifs_sb_tlink.patch @@ -0,0 +1,80 @@ +From c2b77f42205ef485a647f62082c442c1cd69d3fc Mon Sep 17 00:00:00 2001 +From: Shuhao Fu +Date: Thu, 16 Oct 2025 02:52:55 +0000 +Subject: smb: client: Fix refcount leak for cifs_sb_tlink + +From: Shuhao Fu + +commit c2b77f42205ef485a647f62082c442c1cd69d3fc upstream. + +Fix three refcount inconsistency issues related to `cifs_sb_tlink`. + +Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be +called after successful calls to `cifs_sb_tlink()`. Three calls fail to +update refcount accordingly, leading to possible resource leaks. + +Fixes: 8ceb98437946 ("CIFS: Move rename to ops struct") +Fixes: 2f1afe25997f ("cifs: Use smb 2 - 3 and cifsacl mount options getacl functions") +Fixes: 366ed846df60 ("cifs: Use smb 2 - 3 and cifsacl mount options setacl function") +Cc: stable@vger.kernel.org +Signed-off-by: Shuhao Fu +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/inode.c | 6 ++++-- + fs/smb/client/smb2ops.c | 8 ++++---- + 2 files changed, 8 insertions(+), 6 deletions(-) + +--- a/fs/smb/client/inode.c ++++ b/fs/smb/client/inode.c +@@ -2431,8 +2431,10 @@ cifs_do_rename(const unsigned int xid, s + tcon = tlink_tcon(tlink); + server = tcon->ses->server; + +- if (!server->ops->rename) +- return -ENOSYS; ++ if (!server->ops->rename) { ++ rc = -ENOSYS; ++ goto do_rename_exit; ++ } + + /* try path-based rename first */ + rc = server->ops->rename(xid, tcon, from_dentry, +--- a/fs/smb/client/smb2ops.c ++++ b/fs/smb/client/smb2ops.c +@@ -3129,8 +3129,7 @@ get_smb2_acl_by_path(struct cifs_sb_info + utf16_path = cifs_convert_path_to_utf16(path, cifs_sb); + if (!utf16_path) { + rc = -ENOMEM; +- free_xid(xid); +- return ERR_PTR(rc); ++ goto put_tlink; + } + + oparms = (struct cifs_open_parms) { +@@ -3162,6 +3161,7 @@ get_smb2_acl_by_path(struct cifs_sb_info + SMB2_close(xid, tcon, fid.persistent_fid, fid.volatile_fid); + } + ++put_tlink: + cifs_put_tlink(tlink); + free_xid(xid); + +@@ -3202,8 +3202,7 @@ set_smb2_acl(struct smb_ntsd *pnntsd, __ + utf16_path = cifs_convert_path_to_utf16(path, cifs_sb); + if (!utf16_path) { + rc = -ENOMEM; +- free_xid(xid); +- return rc; ++ goto put_tlink; + } + + oparms = (struct cifs_open_parms) { +@@ -3224,6 +3223,7 @@ set_smb2_acl(struct smb_ntsd *pnntsd, __ + SMB2_close(xid, tcon, fid.persistent_fid, fid.volatile_fid); + } + ++put_tlink: + cifs_put_tlink(tlink); + free_xid(xid); + return rc; diff --git a/queue-6.17/vfs-don-t-leak-disconnected-dentries-on-umount.patch b/queue-6.17/vfs-don-t-leak-disconnected-dentries-on-umount.patch new file mode 100644 index 0000000000..98a9db05fa --- /dev/null +++ b/queue-6.17/vfs-don-t-leak-disconnected-dentries-on-umount.patch @@ -0,0 +1,53 @@ +From 56094ad3eaa21e6621396cc33811d8f72847a834 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Thu, 2 Oct 2025 17:55:07 +0200 +Subject: vfs: Don't leak disconnected dentries on umount + +From: Jan Kara + +commit 56094ad3eaa21e6621396cc33811d8f72847a834 upstream. + +When user calls open_by_handle_at() on some inode that is not cached, we +will create disconnected dentry for it. If such dentry is a directory, +exportfs_decode_fh_raw() will then try to connect this dentry to the +dentry tree through reconnect_path(). It may happen for various reasons +(such as corrupted fs or race with rename) that the call to +lookup_one_unlocked() in reconnect_one() will fail to find the dentry we +are trying to reconnect and instead create a new dentry under the +parent. Now this dentry will not be marked as disconnected although the +parent still may well be disconnected (at least in case this +inconsistency happened because the fs is corrupted and .. doesn't point +to the real parent directory). This creates inconsistency in +disconnected flags but AFAICS it was mostly harmless. At least until +commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") +which removed adding of most disconnected dentries to sb->s_anon list. +Thus after this commit cleanup of disconnected dentries implicitely +relies on the fact that dput() will immediately reclaim such dentries. +However when some leaf dentry isn't marked as disconnected, as in the +scenario described above, the reclaim doesn't happen and the dentries +are "leaked". Memory reclaim can eventually reclaim them but otherwise +they stay in memory and if umount comes first, we hit infamous "Busy +inodes after unmount" bug. Make sure all dentries created under a +disconnected parent are marked as disconnected as well. + +Reported-by: syzbot+1d79ebe5383fc016cf07@syzkaller.appspotmail.com +Fixes: f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") +CC: stable@vger.kernel.org +Signed-off-by: Jan Kara +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + fs/dcache.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/dcache.c ++++ b/fs/dcache.c +@@ -2557,6 +2557,8 @@ struct dentry *d_alloc_parallel(struct d + spin_lock(&parent->d_lock); + new->d_parent = dget_dlock(parent); + hlist_add_head(&new->d_sib, &parent->d_children); ++ if (parent->d_flags & DCACHE_DISCONNECTED) ++ new->d_flags |= DCACHE_DISCONNECTED; + spin_unlock(&parent->d_lock); + + retry: diff --git a/queue-6.17/x86-cpu-amd-prevent-reset-reasons-from-being-retained-across-reboot.patch b/queue-6.17/x86-cpu-amd-prevent-reset-reasons-from-being-retained-across-reboot.patch new file mode 100644 index 0000000000..c2ebc71d16 --- /dev/null +++ b/queue-6.17/x86-cpu-amd-prevent-reset-reasons-from-being-retained-across-reboot.patch @@ -0,0 +1,71 @@ +From e6416c2dfe23c9a6fec881fda22ebb9ae486cfc5 Mon Sep 17 00:00:00 2001 +From: Rong Zhang +Date: Sat, 11 Oct 2025 00:59:58 +0800 +Subject: x86/CPU/AMD: Prevent reset reasons from being retained across reboot + +From: Rong Zhang + +commit e6416c2dfe23c9a6fec881fda22ebb9ae486cfc5 upstream. + +The S5_RESET_STATUS register is parsed on boot and printed to kmsg. +However, this could sometimes be misleading and lead to users wasting a +lot of time on meaningless debugging for two reasons: + +* Some bits are never cleared by hardware. It's the software's +responsibility to clear them as per the Processor Programming Reference +(see [1]). + +* Some rare hardware-initiated platform resets do not update the +register at all. + +In both cases, a previous reboot could leave its trace in the register, +resulting in users seeing unrelated reboot reasons while debugging random +reboots afterward. + +Write the read value back to the register in order to clear all reason bits +since they are write-1-to-clear while the others must be preserved. + + [1]: https://bugzilla.kernel.org/show_bug.cgi?id=206537#attach_303991 + + [ bp: Massage commit message. ] + +Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset") +Signed-off-by: Rong Zhang +Signed-off-by: Borislav Petkov (AMD) +Reviewed-by: Mario Limonciello (AMD) +Reviewed-by: Yazen Ghannam +Cc: +Link: https://lore.kernel.org/all/20250913144245.23237-1-i@rong.moe/ +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/amd.c | 16 ++++++++++++++-- + 1 file changed, 14 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/cpu/amd.c ++++ b/arch/x86/kernel/cpu/amd.c +@@ -1338,11 +1338,23 @@ static __init int print_s5_reset_status_ + return 0; + + value = ioread32(addr); +- iounmap(addr); + + /* Value with "all bits set" is an error response and should be ignored. */ +- if (value == U32_MAX) ++ if (value == U32_MAX) { ++ iounmap(addr); + return 0; ++ } ++ ++ /* ++ * Clear all reason bits so they won't be retained if the next reset ++ * does not update the register. Besides, some bits are never cleared by ++ * hardware so it's software's responsibility to clear them. ++ * ++ * Writing the value back effectively clears all reason bits as they are ++ * write-1-to-clear. ++ */ ++ iowrite32(value, addr); ++ iounmap(addr); + + for (i = 0; i < ARRAY_SIZE(s5_reset_reason_txt); i++) { + if (!(value & BIT(i)))