From: Greg Kroah-Hartman Date: Sat, 7 Feb 2026 15:17:41 +0000 (+0100) Subject: 6.18-stable patches X-Git-Tag: v5.10.250~39 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7e9bb58e6de2489785e5bdc333e8c215700233e1;p=thirdparty%2Fkernel%2Fstable-queue.git 6.18-stable patches added patches: hwmon-gpio-fan-allow-to-stop-fans-when-config_pm-is-disabled.patch hwmon-gpio-fan-fix-set_rpm-return-value.patch kvm-don-t-clobber-irqfd-routing-type-when-deassigning-irqfd.patch kvm-selftests-add-u_fortify_source-to-avoid-some-unpredictable-test-failures.patch --- diff --git a/queue-6.18/hwmon-gpio-fan-allow-to-stop-fans-when-config_pm-is-disabled.patch b/queue-6.18/hwmon-gpio-fan-allow-to-stop-fans-when-config_pm-is-disabled.patch new file mode 100644 index 0000000000..f6bf3204f1 --- /dev/null +++ b/queue-6.18/hwmon-gpio-fan-allow-to-stop-fans-when-config_pm-is-disabled.patch @@ -0,0 +1,55 @@ +From 52fb36a5f9c15285b7d67c0ff87dc17b3206b5df Mon Sep 17 00:00:00 2001 +From: Gabor Juhos +Date: Mon, 2 Feb 2026 16:58:57 +0100 +Subject: hwmon: (gpio-fan) Allow to stop FANs when CONFIG_PM is disabled + +From: Gabor Juhos + +commit 52fb36a5f9c15285b7d67c0ff87dc17b3206b5df upstream. + +When CONFIG_PM is disabled, the GPIO controlled FANs can't be stopped by +using the sysfs attributes since commit 0d01110e6356 ("hwmon: (gpio-fan) +Add regulator support"). + +Using either the 'pwm1' or the 'fan1_target' attribute fails the same way: + + $ echo 0 > /sys/class/hwmon/hwmon1/pwm1 + ash: write error: Function not implemented + $ echo 0 > /sys/class/hwmon/hwmon1/fan1_target + ash: write error: Function not implemented + +Both commands were working flawlessly before the mentioned commit. + +The issue happens because pm_runtime_put_sync() returns with -ENOSYS +when CONFIG_PM is disabled, and the set_fan_speed() function handles +this as an error. + +In order to restore the previous behaviour, change the error check in +the set_fan_speed() function to ignore the -ENOSYS error code. + +Cc: stable@vger.kernel.org +Fixes: 0d01110e6356 ("hwmon: (gpio-fan) Add regulator support") +Signed-off-by: Gabor Juhos +Link: https://lore.kernel.org/r/20260202-gpio-fan-stop-fix-v1-1-c7853183d93d@gmail.com +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwmon/gpio-fan.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c +index d7fa021f376e..a8892ced1e54 100644 +--- a/drivers/hwmon/gpio-fan.c ++++ b/drivers/hwmon/gpio-fan.c +@@ -148,7 +148,7 @@ static int set_fan_speed(struct gpio_fan_data *fan_data, int speed_index) + int ret; + + ret = pm_runtime_put_sync(fan_data->dev); +- if (ret < 0) ++ if (ret < 0 && ret != -ENOSYS) + return ret; + } + +-- +2.53.0 + diff --git a/queue-6.18/hwmon-gpio-fan-fix-set_rpm-return-value.patch b/queue-6.18/hwmon-gpio-fan-fix-set_rpm-return-value.patch new file mode 100644 index 0000000000..a9cf0c086a --- /dev/null +++ b/queue-6.18/hwmon-gpio-fan-fix-set_rpm-return-value.patch @@ -0,0 +1,59 @@ +From f5c092787c48296633c2dd7240752f88fa9710fc Mon Sep 17 00:00:00 2001 +From: Gabor Juhos +Date: Sun, 1 Feb 2026 21:35:06 +0100 +Subject: hwmon: (gpio-fan) Fix set_rpm() return value + +From: Gabor Juhos + +commit f5c092787c48296633c2dd7240752f88fa9710fc upstream. + +The set_rpm function is used as a 'store' callback of a device attribute, +and as such it should return with the number of bytes consumed. However +since commit 0d01110e6356 ("hwmon: (gpio-fan) Add regulator support"), +the function returns with zero on success. + +Due to this, the function gets called again and again whenever the user +tries to change the FAN speed by writing the desired RPM value into the +'fan1_target' sysfs attribute. + +The broken behaviour can be reproduced easily. For example, the following +command never returns unless it gets terminated: + + $ echo 500 > /sys/class/hwmon/hwmon1/fan1_target + ^C + $ + +Change the code to return with the same value as the 'count' parameter +on success to indicate that all bytes from the input buffer are consumed. +The function behaved the same way prior to the offending change. + +Cc: stable@vger.kernel.org +Fixes: 0d01110e6356 ("hwmon: (gpio-fan) Add regulator support") +Signed-off-by: Gabor Juhos +Link: https://lore.kernel.org/r/20260201-gpio-fan-set_rpm-retval-fix-v1-1-dc39bc7693ca@gmail.com +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwmon/gpio-fan.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/hwmon/gpio-fan.c ++++ b/drivers/hwmon/gpio-fan.c +@@ -291,7 +291,7 @@ static ssize_t set_rpm(struct device *de + { + struct gpio_fan_data *fan_data = dev_get_drvdata(dev); + unsigned long rpm; +- int ret = count; ++ int ret; + + if (kstrtoul(buf, 10, &rpm)) + return -EINVAL; +@@ -308,7 +308,7 @@ static ssize_t set_rpm(struct device *de + exit_unlock: + mutex_unlock(&fan_data->lock); + +- return ret; ++ return ret ? ret : count; + } + + static DEVICE_ATTR_RW(pwm1); diff --git a/queue-6.18/kvm-don-t-clobber-irqfd-routing-type-when-deassigning-irqfd.patch b/queue-6.18/kvm-don-t-clobber-irqfd-routing-type-when-deassigning-irqfd.patch new file mode 100644 index 0000000000..1ef66d5748 --- /dev/null +++ b/queue-6.18/kvm-don-t-clobber-irqfd-routing-type-when-deassigning-irqfd.patch @@ -0,0 +1,203 @@ +From b4d37cdb77a0015f51fee083598fa227cc07aaf1 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 13 Jan 2026 09:46:05 -0800 +Subject: KVM: Don't clobber irqfd routing type when deassigning irqfd + +From: Sean Christopherson + +commit b4d37cdb77a0015f51fee083598fa227cc07aaf1 upstream. + +When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's +routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 +and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to +handle a concurrent routing update, verify that the irqfd is still active +before consuming the routing information. As evidenced by the x86 and +arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below), +clobbering the entry type without notifying arch code is surprising and +error prone. + +As a bonus, checking that the irqfd is active provides a convenient +location for documenting _why_ KVM must not consume the routing entry for +an irqfd that is in the process of being deassigned: once the irqfd is +deleted from the list (which happens *before* the eventfd is detached), it +will no longer receive updates via kvm_irq_routing_update(), and so KVM +could deliver an event using stale routing information (relative to +KVM_SET_GSI_ROUTING returning to userspace). + +As an even better bonus, explicitly checking for the irqfd being active +fixes a similar bug to the one the clobbering is trying to prevent: if an +irqfd is deactivated, and then its routing is changed, +kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing() +(because the irqfd isn't in the list). And so if the irqfd is in bypass +mode, IRQs will continue to be posted using the old routing information. + +As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type +results in KVM incorrectly keeping the IRQ in bypass mode, which is +especially problematic on AMD as KVM tracks IRQs that are being posted to +a vCPU in a list whose lifetime is tied to the irqfd. + +Without the help of KASAN to detect use-after-free, the most common +sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to +the memory for irqfd structure being re-allocated and zeroed, resulting +in irqfd->irq_bypass_data being NULL when read by +avic_update_iommu_vcpu_affinity(): + + BUG: kernel NULL pointer dereference, address: 0000000000000018 + #PF: supervisor read access in kernel mode + #PF: error_code(0x0000) - not-present page + PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 + Oops: Oops: 0000 [#1] SMP + CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test + Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE + Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE + Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 + RIP: 0010:amd_iommu_update_ga+0x19/0xe0 + Call Trace: + + avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] + __avic_vcpu_load+0xf4/0x130 [kvm_amd] + kvm_arch_vcpu_load+0x89/0x210 [kvm] + vcpu_load+0x30/0x40 [kvm] + kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] + kvm_vcpu_ioctl+0x571/0x6a0 [kvm] + __se_sys_ioctl+0x6d/0xb0 + do_syscall_64+0x6f/0x9d0 + entry_SYSCALL_64_after_hwframe+0x4b/0x53 + RIP: 0033:0x46893b + + ---[ end trace 0000000000000000 ]--- + +If AVIC is inhibited when the irfd is deassigned, the bug will manifest as +list corruption, e.g. on the next irqfd assignment. + + list_add corruption. next->prev should be prev (ffff8d474d5cd588), + but was 0000000000000000. (next=ffff8d8658f86530). + ------------[ cut here ]------------ + kernel BUG at lib/list_debug.c:31! + Oops: invalid opcode: 0000 [#1] SMP + CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test + Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE + Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE + Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 + RIP: 0010:__list_add_valid_or_report+0x97/0xc0 + Call Trace: + + avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] + kvm_pi_update_irte+0xbf/0x190 [kvm] + kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] + irq_bypass_register_consumer+0xcd/0x170 [irqbypass] + kvm_irqfd+0x4c6/0x540 [kvm] + kvm_vm_ioctl+0x118/0x5d0 [kvm] + __se_sys_ioctl+0x6d/0xb0 + do_syscall_64+0x6f/0x9d0 + entry_SYSCALL_64_after_hwframe+0x4b/0x53 + + ---[ end trace 0000000000000000 ]--- + +On Intel and arm64, the bug is less noisy, as the end result is that the +device keeps posting IRQs to the vCPU even after it's been deassigned. + +Note, the worst of the breakage can be traced back to commit cb210737675e +("KVM: Pass new routing entries and irqfd when updating IRTEs"), as before +that commit KVM would pull the routing information from the per-VM routing +table. But as above, similar bugs have existed since support for IRQ +bypass was added. E.g. if a routing change finished before irq_shutdown() +invoked kvm_arch_irq_bypass_del_producer(), VMX and SVM would see stale +routing information and potentially leave the irqfd in bypass mode. + +Alternatively, x86 could be fixed by explicitly checking irq_bypass_vcpu +instead of irq_entry.type in kvm_arch_irq_bypass_del_producer(), and arm64 +could be modified to utilize irq_bypass_vcpu in a similar manner. But (a) +that wouldn't fix the routing updates bug, and (b) fixing core code doesn't +preclude x86 (or arm64) from adding such code as a sanity check (spoiler +alert). + +Fixes: f70c20aaf141 ("KVM: Add an arch specific hooks in 'struct kvm_kernel_irqfd'") +Fixes: cb210737675e ("KVM: Pass new routing entries and irqfd when updating IRTEs") +Fixes: a0d7e2fc61ab ("KVM: arm64: vgic-v4: Only attempt vLPI mapping for actual MSIs") +Cc: stable@vger.kernel.org +Cc: Marc Zyngier +Cc: Oliver Upton +Link: https://patch.msgid.link/20260113174606.104978-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + virt/kvm/eventfd.c | 44 ++++++++++++++++++++++++-------------------- + 1 file changed, 24 insertions(+), 20 deletions(-) + +--- a/virt/kvm/eventfd.c ++++ b/virt/kvm/eventfd.c +@@ -157,21 +157,28 @@ irqfd_shutdown(struct work_struct *work) + } + + +-/* assumes kvm->irqfds.lock is held */ +-static bool +-irqfd_is_active(struct kvm_kernel_irqfd *irqfd) ++static bool irqfd_is_active(struct kvm_kernel_irqfd *irqfd) + { ++ /* ++ * Assert that either irqfds.lock or SRCU is held, as irqfds.lock must ++ * be held to prevent false positives (on the irqfd being active), and ++ * while false negatives are impossible as irqfds are never added back ++ * to the list once they're deactivated, the caller must at least hold ++ * SRCU to guard against routing changes if the irqfd is deactivated. ++ */ ++ lockdep_assert_once(lockdep_is_held(&irqfd->kvm->irqfds.lock) || ++ srcu_read_lock_held(&irqfd->kvm->irq_srcu)); ++ + return list_empty(&irqfd->list) ? false : true; + } + + /* + * Mark the irqfd as inactive and schedule it for removal +- * +- * assumes kvm->irqfds.lock is held + */ +-static void +-irqfd_deactivate(struct kvm_kernel_irqfd *irqfd) ++static void irqfd_deactivate(struct kvm_kernel_irqfd *irqfd) + { ++ lockdep_assert_held(&irqfd->kvm->irqfds.lock); ++ + BUG_ON(!irqfd_is_active(irqfd)); + + list_del_init(&irqfd->list); +@@ -217,8 +224,15 @@ irqfd_wakeup(wait_queue_entry_t *wait, u + seq = read_seqcount_begin(&irqfd->irq_entry_sc); + irq = irqfd->irq_entry; + } while (read_seqcount_retry(&irqfd->irq_entry_sc, seq)); +- /* An event has been signaled, inject an interrupt */ +- if (kvm_arch_set_irq_inatomic(&irq, kvm, ++ ++ /* ++ * An event has been signaled, inject an interrupt unless the ++ * irqfd is being deassigned (isn't active), in which case the ++ * routing information may be stale (once the irqfd is removed ++ * from the list, it will stop receiving routing updates). ++ */ ++ if (unlikely(!irqfd_is_active(irqfd)) || ++ kvm_arch_set_irq_inatomic(&irq, kvm, + KVM_USERSPACE_IRQ_SOURCE_ID, 1, + false) == -EWOULDBLOCK) + schedule_work(&irqfd->inject); +@@ -585,18 +599,8 @@ kvm_irqfd_deassign(struct kvm *kvm, stru + spin_lock_irq(&kvm->irqfds.lock); + + list_for_each_entry_safe(irqfd, tmp, &kvm->irqfds.items, list) { +- if (irqfd->eventfd == eventfd && irqfd->gsi == args->gsi) { +- /* +- * This clearing of irq_entry.type is needed for when +- * another thread calls kvm_irq_routing_update before +- * we flush workqueue below (we synchronize with +- * kvm_irq_routing_update using irqfds.lock). +- */ +- write_seqcount_begin(&irqfd->irq_entry_sc); +- irqfd->irq_entry.type = 0; +- write_seqcount_end(&irqfd->irq_entry_sc); ++ if (irqfd->eventfd == eventfd && irqfd->gsi == args->gsi) + irqfd_deactivate(irqfd); +- } + } + + spin_unlock_irq(&kvm->irqfds.lock); diff --git a/queue-6.18/kvm-selftests-add-u_fortify_source-to-avoid-some-unpredictable-test-failures.patch b/queue-6.18/kvm-selftests-add-u_fortify_source-to-avoid-some-unpredictable-test-failures.patch new file mode 100644 index 0000000000..10c5bf04fc --- /dev/null +++ b/queue-6.18/kvm-selftests-add-u_fortify_source-to-avoid-some-unpredictable-test-failures.patch @@ -0,0 +1,48 @@ +From e396a74222654486d6ab45dca5d0c54c408b8b91 Mon Sep 17 00:00:00 2001 +From: Zhiquan Li +Date: Thu, 22 Jan 2026 13:35:50 +0800 +Subject: KVM: selftests: Add -U_FORTIFY_SOURCE to avoid some unpredictable test failures + +From: Zhiquan Li + +commit e396a74222654486d6ab45dca5d0c54c408b8b91 upstream. + +Some distributions (such as Ubuntu) configure GCC so that +_FORTIFY_SOURCE is automatically enabled at -O1 or above. This results +in some fortified version of definitions of standard library functions +are included. While linker resolves the symbols, the fortified versions +might override the definitions in lib/string_override.c and reference to +those PLT entries in GLIBC. This is not a problem for the code in host, +but it is a disaster for the guest code. E.g., if build and run +x86/nested_emulation_test on Ubuntu 24.04 will encounter a L1 #PF due to +memset() reference to __memset_chk@plt. + +The option -fno-builtin-memset is not helpful here, because those +fortified versions are not built-in but some definitions which are +included by header, they are for different intentions. + +In order to eliminate the unpredictable behaviors may vary depending on +the linker and platform, add the "-U_FORTIFY_SOURCE" into CFLAGS to +prevent from introducing the fortified definitions. + +Signed-off-by: Zhiquan Li +Link: https://patch.msgid.link/20260122053551.548229-1-zhiquan_li@163.com +Fixes: 6b6f71484bf4 ("KVM: selftests: Implement memcmp(), memcpy(), and memset() for guest use") +Cc: stable@vger.kernel.org +[sean: tag for stable] +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/kvm/Makefile.kvm | 1 + + 1 file changed, 1 insertion(+) + +--- a/tools/testing/selftests/kvm/Makefile.kvm ++++ b/tools/testing/selftests/kvm/Makefile.kvm +@@ -245,6 +245,7 @@ LINUX_TOOL_INCLUDE = $(top_srcdir)/tools + LINUX_TOOL_ARCH_INCLUDE = $(top_srcdir)/tools/arch/$(ARCH)/include + CFLAGS += -Wall -Wstrict-prototypes -Wuninitialized -O2 -g -std=gnu99 \ + -Wno-gnu-variable-sized-type-not-at-end -MD -MP -DCONFIG_64BIT \ ++ -U_FORTIFY_SOURCE \ + -fno-builtin-memcmp -fno-builtin-memcpy \ + -fno-builtin-memset -fno-builtin-strnlen \ + -fno-stack-protector -fno-PIE -fno-strict-aliasing \ diff --git a/queue-6.18/series b/queue-6.18/series index 5e70164a36..fbcc953f1a 100644 --- a/queue-6.18/series +++ b/queue-6.18/series @@ -29,3 +29,7 @@ nouveau-gsp-fix-suspend-resume-regression-on-r570-firmware.patch net-cpsw-execute-ndo_set_rx_mode-callback-in-a-work-queue.patch net-cpsw_new-execute-ndo_set_rx_mode-callback-in-a-work-queue.patch net-spacemit-k1-emac-fix-jumbo-frame-support.patch +kvm-selftests-add-u_fortify_source-to-avoid-some-unpredictable-test-failures.patch +kvm-don-t-clobber-irqfd-routing-type-when-deassigning-irqfd.patch +hwmon-gpio-fan-fix-set_rpm-return-value.patch +hwmon-gpio-fan-allow-to-stop-fans-when-config_pm-is-disabled.patch