--- /dev/null
+From 52fb36a5f9c15285b7d67c0ff87dc17b3206b5df Mon Sep 17 00:00:00 2001
+From: Gabor Juhos <j4g8y7@gmail.com>
+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 <j4g8y7@gmail.com>
+
+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 <j4g8y7@gmail.com>
+Link: https://lore.kernel.org/r/20260202-gpio-fan-stop-fix-v1-1-c7853183d93d@gmail.com
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From f5c092787c48296633c2dd7240752f88fa9710fc Mon Sep 17 00:00:00 2001
+From: Gabor Juhos <j4g8y7@gmail.com>
+Date: Sun, 1 Feb 2026 21:35:06 +0100
+Subject: hwmon: (gpio-fan) Fix set_rpm() return value
+
+From: Gabor Juhos <j4g8y7@gmail.com>
+
+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 <j4g8y7@gmail.com>
+Link: https://lore.kernel.org/r/20260201-gpio-fan-set_rpm-retval-fix-v1-1-dc39bc7693ca@gmail.com
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From b4d37cdb77a0015f51fee083598fa227cc07aaf1 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Tue, 13 Jan 2026 09:46:05 -0800
+Subject: KVM: Don't clobber irqfd routing type when deassigning irqfd
+
+From: Sean Christopherson <seanjc@google.com>
+
+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:
+ <TASK>
+ 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
+ </TASK>
+ ---[ 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:
+ <TASK>
+ 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
+ </TASK>
+ ---[ 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 <maz@kernel.org>
+Cc: Oliver Upton <oupton@kernel.org>
+Link: https://patch.msgid.link/20260113174606.104978-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From e396a74222654486d6ab45dca5d0c54c408b8b91 Mon Sep 17 00:00:00 2001
+From: Zhiquan Li <zhiquan_li@163.com>
+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 <zhiquan_li@163.com>
+
+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 <zhiquan_li@163.com>
+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 <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 \
projects / thirdparty / kernel / stable-queue.git / commitdiff
