--- /dev/null
+From 75c486cb1bcaa1a3ec3a6438498176a3a4998ae4 Mon Sep 17 00:00:00 2001
+From: Corey Minyard <corey@minyard.net>
+Date: Mon, 13 Apr 2026 08:00:23 -0500
+Subject: ipmi:ssif: Clean up kthread on errors
+
+From: Corey Minyard <corey@minyard.net>
+
+commit 75c486cb1bcaa1a3ec3a6438498176a3a4998ae4 upstream.
+
+If an error occurs after the ssif kthread is created, but before the
+main IPMI code starts the ssif interface, the ssif kthread will not
+be stopped.
+
+So make sure the kthread is stopped on an error condition if it is
+running.
+
+Fixes: 259307074bfc ("ipmi: Add SMBus interface driver (SSIF)")
+Reported-by: Li Xiao <<252270051@hdu.edu.cn>
+Cc: stable@vger.kernel.org
+Reviewed-by: Li Xiao <252270051@hdu.edu.cn>
+Signed-off-by: Corey Minyard <corey@minyard.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_ssif.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+--- a/drivers/char/ipmi/ipmi_ssif.c
++++ b/drivers/char/ipmi/ipmi_ssif.c
+@@ -1287,8 +1287,10 @@ static void shutdown_ssif(void *send_inf
+ ssif_info->stopping = true;
+ del_timer_sync(&ssif_info->watch_timer);
+ del_timer_sync(&ssif_info->retry_timer);
+- if (ssif_info->thread)
++ if (ssif_info->thread) {
+ kthread_stop(ssif_info->thread);
++ ssif_info->thread = NULL;
++ }
+ }
+
+ static void ssif_remove(struct i2c_client *client)
+@@ -1916,6 +1918,15 @@ static int ssif_probe(struct i2c_client
+
+ out:
+ if (rv) {
++ /*
++ * If ipmi_register_smi() starts the interface, it will
++ * call shutdown and that will free the thread and set
++ * it to NULL. Otherwise it must be freed here.
++ */
++ if (ssif_info->thread) {
++ kthread_stop(ssif_info->thread);
++ ssif_info->thread = NULL;
++ }
+ if (addr_info)
+ addr_info->client = NULL;
+
--- /dev/null
+From 6bd0eb6d759b9a22c5509ea04e19c2e8407ba418 Mon Sep 17 00:00:00 2001
+From: Corey Minyard <corey@minyard.net>
+Date: Thu, 10 Apr 2025 14:44:26 -0500
+Subject: ipmi:ssif: Fix a shutdown race
+
+From: Corey Minyard <corey@minyard.net>
+
+commit 6bd0eb6d759b9a22c5509ea04e19c2e8407ba418 upstream.
+
+It was possible for the SSIF thread to stop and quit before the
+kthread_stop() call because ssif->stopping was set before the
+stop. So only exit the SSIF thread is kthread_should_stop()
+returns true.
+
+There is no need to wake the thread, as the wait will be interrupted
+by kthread_stop().
+
+Signed-off-by: Corey Minyard <cminyard@mvista.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_ssif.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/drivers/char/ipmi/ipmi_ssif.c
++++ b/drivers/char/ipmi/ipmi_ssif.c
+@@ -490,8 +490,6 @@ static int ipmi_ssif_thread(void *data)
+ /* Wait for something to do */
+ result = wait_for_completion_interruptible(
+ &ssif_info->wake_thread);
+- if (ssif_info->stopping)
+- break;
+ if (result == -ERESTARTSYS)
+ continue;
+ init_completion(&ssif_info->wake_thread);
+@@ -1289,10 +1287,8 @@ static void shutdown_ssif(void *send_inf
+ ssif_info->stopping = true;
+ del_timer_sync(&ssif_info->watch_timer);
+ del_timer_sync(&ssif_info->retry_timer);
+- if (ssif_info->thread) {
+- complete(&ssif_info->wake_thread);
++ if (ssif_info->thread)
+ kthread_stop(ssif_info->thread);
+- }
+ }
+
+ static void ssif_remove(struct i2c_client *client)
--- /dev/null
+From 4ce98bf0865c349e7026ad9c14f48da264920953 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Thu, 23 Apr 2026 17:36:07 +0100
+Subject: KVM: arm64: Wake-up from WFI when iqrchip is in userspace
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit 4ce98bf0865c349e7026ad9c14f48da264920953 upstream.
+
+It appears that there is nothing in the wake-up path that
+evaluates whether the in-kernel interrupts are pending unless
+we have a vgic.
+
+This means that the userspace irqchip support has been broken for
+about four years, and nobody noticed. It was also broken before
+as we wouldn't wake-up on a PMU interrupt, but hey, who cares...
+
+It is probably time to remove the feature altogether, because it
+was a terrible idea 10 years ago, and it still is.
+
+Fixes: b57de4ffd7c6d ("KVM: arm64: Simplify kvm_cpu_has_pending_timer()")
+Link: https://patch.msgid.link/20260423163607.486345-1-maz@kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/arm.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/arm64/kvm/arm.c
++++ b/arch/arm64/kvm/arm.c
+@@ -540,6 +540,11 @@ int kvm_arch_vcpu_ioctl_set_mpstate(stru
+ int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
+ {
+ bool irq_lines = *vcpu_hcr(v) & (HCR_VI | HCR_VF);
++
++ irq_lines |= (!irqchip_in_kernel(v->kvm) &&
++ (kvm_timer_should_notify_user(v) ||
++ kvm_pmu_should_notify_user(v)));
++
+ return ((irq_lines || kvm_vgic_vcpu_pending_irq(v))
+ && !kvm_arm_vcpu_stopped(v) && !v->arch.pause);
+ }
--- /dev/null
+From 8c2f1288250a90a4b5cabed5d888d7e3aeed4035 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Sun, 12 Apr 2026 16:19:47 +0200
+Subject: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 8c2f1288250a90a4b5cabed5d888d7e3aeed4035 upstream.
+
+Yiming reports an integer underflow in mpi_read_raw_from_sgl() when
+subtracting "lzeros" from the unsigned "nbytes".
+
+For this to happen, the scatterlist "sgl" needs to occupy more bytes
+than the "nbytes" parameter and the first "nbytes + 1" bytes of the
+scatterlist must be zero. Under these conditions, the while loop
+iterating over the scatterlist will count more zeroes than "nbytes",
+subtract the number of zeroes from "nbytes" and cause the underflow.
+
+When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally
+introduced the bug, it couldn't be triggered because all callers of
+mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to
+"nbytes".
+
+However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto
+interface without scatterlists"), the underflow can now actually be
+triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a
+larger "out_len" than "in_len" and filling the "in" buffer with zeroes,
+crypto_akcipher_sync_prep() will create an all-zero scatterlist used for
+both the "src" and "dst" member of struct akcipher_request and thereby
+fulfil the conditions to trigger the bug:
+
+ sys_keyctl()
+ keyctl_pkey_e_d_s()
+ asymmetric_key_eds_op()
+ software_key_eds_op()
+ crypto_akcipher_sync_encrypt()
+ crypto_akcipher_sync_prep()
+ crypto_akcipher_encrypt()
+ rsa_enc()
+ mpi_read_raw_from_sgl()
+
+To the user this will be visible as a DoS as the kernel spins forever,
+causing soft lockup splats as a side effect.
+
+Fix it.
+
+Reported-by: Yiming Qian <yimingqian591@gmail.com> # off-list
+Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Cc: stable@vger.kernel.org # v4.4+
+Reviewed-by: Ignat Korchagin <ignat@linux.win>
+Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
+Link: https://lore.kernel.org/r/59eca92ff4f87e2081777f1423a0efaaadcfdb39.1776003111.git.lukas@wunner.de
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ lib/mpi/mpicoder.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/lib/mpi/mpicoder.c
++++ b/lib/mpi/mpicoder.c
+@@ -453,7 +453,7 @@ MPI mpi_read_raw_from_sgl(struct scatter
+ lzeros = 0;
+ len = 0;
+ while (nbytes > 0) {
+- while (len && !*buff) {
++ while (len && !*buff && lzeros < nbytes) {
+ lzeros++;
+ len--;
+ buff++;
--- /dev/null
+From 8bbde987c2b84f80da0853f739f0a920386f8b99 Mon Sep 17 00:00:00 2001
+From: SeongJae Park <sj@kernel.org>
+Date: Mon, 6 Apr 2026 17:31:52 -0700
+Subject: mm/damon/core: disallow time-quota setting zero esz
+
+From: SeongJae Park <sj@kernel.org>
+
+commit 8bbde987c2b84f80da0853f739f0a920386f8b99 upstream.
+
+When the throughput of a DAMOS scheme is very slow, DAMOS time quota can
+make the effective size quota smaller than damon_ctx->min_region_sz. In
+the case, damos_apply_scheme() will skip applying the action, because the
+action is tried at region level, which requires >=min_region_sz size.
+That is, the quota is effectively exceeded for the quota charge window.
+
+Because no action will be applied, the total_charged_sz and
+total_charged_ns are also not updated. damos_set_effective_quota() will
+try to update the effective size quota before starting the next charge
+window. However, because the total_charged_sz and total_charged_ns have
+not updated, the throughput and effective size quota are also not changed.
+Since effective size quota can only be decreased, other effective size
+quota update factors including DAMOS quota goals and size quota cannot
+make any change, either.
+
+As a result, the scheme is unexpectedly deactivated until the user notices
+and mitigates the situation. The users can mitigate this situation by
+changing the time quota online or re-install the scheme. While the
+mitigation is somewhat straightforward, finding the situation would be
+challenging, because DAMON is not providing good observabilities for that.
+Even if such observability is provided, doing the additional monitoring
+and the mitigation is somewhat cumbersome and not aligned to the intention
+of the time quota. The time quota was intended to help reduce the user's
+administration overhead.
+
+Fix the problem by setting time quota-modified effective size quota be at
+least min_region_sz always.
+
+The issue was discovered [1] by sashiko.
+
+Link: https://lore.kernel.org/20260407003153.79589-1-sj@kernel.org
+Link: https://lore.kernel.org/20260405192504.110014-1-sj@kernel.org [1]
+Fixes: 1cd243030059 ("mm/damon/schemes: implement time quota")
+Signed-off-by: SeongJae Park <sj@kernel.org>
+Cc: <stable@vger.kernel.org> # 5.16.x
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: SeongJae Park <sj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/damon/core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/mm/damon/core.c
++++ b/mm/damon/core.c
+@@ -802,6 +802,7 @@ static void damos_set_effective_quota(st
+ else
+ throughput = PAGE_SIZE * 1024;
+ esz = throughput * quota->ms;
++ esz = max(DAMON_MIN_REGION, esz);
+
+ if (quota->sz && quota->sz < esz)
+ esz = quota->sz;
--- /dev/null
+From 049a57421dd67a28c45ae7e92c36df758033e5fa Mon Sep 17 00:00:00 2001
+From: SeongJae Park <sj@kernel.org>
+Date: Sun, 29 Mar 2026 08:23:05 -0700
+Subject: mm/damon/core: use time_in_range_open() for damos quota window start
+
+From: SeongJae Park <sj@kernel.org>
+
+commit 049a57421dd67a28c45ae7e92c36df758033e5fa upstream.
+
+damos_adjust_quota() uses time_after_eq() to show if it is time to start a
+new quota charge window, comparing the current jiffies and the scheduled
+next charge window start time. If it is, the next charge window start
+time is updated and the new charge window starts.
+
+The time check and next window start time update is skipped while the
+scheme is deactivated by the watermarks. Let's suppose the deactivation
+is kept more than LONG_MAX jiffies (assuming CONFIG_HZ of 250, more than
+99 days in 32 bit systems and more than one billion years in 64 bit
+systems), resulting in having the jiffies larger than the next charge
+window start time + LONG_MAX. Then, the time_after_eq() call can return
+false until another LONG_MAX jiffies are passed.
+
+This means the scheme can continue working after being reactivated by the
+watermarks. But, soon, the quota will be exceeded and the scheme will
+again effectively stop working until the next charge window starts.
+Because the current charge window is extended to up to LONG_MAX jiffies,
+however, it will look like it stopped unexpectedly and indefinitely, from
+the user's perspective.
+
+Fix this by using !time_in_range_open() instead.
+
+The issue was discovered [1] by sashiko.
+
+Link: https://lore.kernel.org/20260329152306.45796-1-sj@kernel.org
+Link: https://lore.kernel.org/20260324040722.57944-1-sj@kernel.org [1]
+Fixes: ee801b7dd782 ("mm/damon/schemes: activate schemes based on a watermarks mechanism")
+Signed-off-by: SeongJae Park <sj@kernel.org>
+Cc: <stable@vger.kernel.org> # 5.16.x
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: SeongJae Park <sj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/damon/core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/damon/core.c
++++ b/mm/damon/core.c
+@@ -826,7 +826,8 @@ static void kdamond_apply_schemes(struct
+ continue;
+
+ /* New charge window starts */
+- if (time_after_eq(jiffies, quota->charged_from +
++ if (!time_in_range_open(jiffies, quota->charged_from,
++ quota->charged_from +
+ msecs_to_jiffies(
+ quota->reset_interval))) {
+ if (quota->esz && quota->charged_sz >= quota->esz)
perf-build-disable-fewer-bison-warnings.patch
tools-build-add-3-component-logical-version-comparators.patch
perf-build-remove-wno-unused-but-set-variable-from-the-flex-flags-when-building-with-clang-13.0.0.patch
+kvm-arm64-wake-up-from-wfi-when-iqrchip-is-in-userspace.patch
+ipmi-ssif-fix-a-shutdown-race.patch
+ipmi-ssif-clean-up-kthread-on-errors.patch
+mm-damon-core-use-time_in_range_open-for-damos-quota-window-start.patch
+mm-damon-core-disallow-time-quota-setting-zero-esz.patch
+usb-typec-tcpm-reset-internal-port-states-on-soft-reset-ams.patch
+lib-crypto-mpi-fix-integer-underflow-in-mpi_read_raw_from_sgl.patch
--- /dev/null
+From 2909f0d4994fb4306bf116df5ccee797791fce2c Mon Sep 17 00:00:00 2001
+From: Amit Sunil Dhamne <amitsd@google.com>
+Date: Tue, 14 Apr 2026 00:58:32 +0000
+Subject: usb: typec: tcpm: reset internal port states on soft reset AMS
+
+From: Amit Sunil Dhamne <amitsd@google.com>
+
+commit 2909f0d4994fb4306bf116df5ccee797791fce2c upstream.
+
+Reset internal port states (such as vdm_sm_running and
+explicit_contract) on soft reset AMS as the port needs to negotiate a
+new contract. The consequence of leaving the states in as-is cond are as
+follows:
+ * port is in SRC power role and an explicit contract is negotiated
+ with the port partner (in sink role)
+ * port partner sends a Soft Reset AMS while VDM State Machine is
+ running
+ * port accepts the Soft Reset request and the port advertises src caps
+ * port partner sends a Request message but since the explicit_contract
+ and vdm_sm_running are true from previous negotiation, the port ends
+ up sending Soft Reset instead of Accept msg.
+
+Stub Log:
+[ 203.653942] AMS DISCOVER_IDENTITY start
+[ 203.653947] PD TX, header: 0x176f
+[ 203.655901] PD TX complete, status: 0
+[ 203.657470] PD RX, header: 0x124f [1]
+[ 203.657477] Rx VDM cmd 0xff008081 type 2 cmd 1 len 1
+[ 203.657482] AMS DISCOVER_IDENTITY finished
+[ 203.657484] cc:=4
+[ 204.155698] PD RX, header: 0x144f [1]
+[ 204.155718] Rx VDM cmd 0xeeee8001 type 0 cmd 1 len 1
+[ 204.155741] PD TX, header: 0x196f
+[ 204.157622] PD TX complete, status: 0
+[ 204.160060] PD RX, header: 0x4d [1]
+[ 204.160066] state change SRC_READY -> SOFT_RESET [rev2 SOFT_RESET_AMS]
+[ 204.160076] PD TX, header: 0x163
+[ 204.162486] PD TX complete, status: 0
+[ 204.162832] AMS SOFT_RESET_AMS finished
+[ 204.162840] cc:=4
+[ 204.162891] AMS POWER_NEGOTIATION start
+[ 204.162896] state change SOFT_RESET -> AMS_START [rev2 POWER_NEGOTIATION]
+[ 204.162908] state change AMS_START -> SRC_SEND_CAPABILITIES [rev2 POWER_NEGOTIATION]
+[ 204.162913] PD TX, header: 0x1361
+[ 204.165529] PD TX complete, status: 0
+[ 204.165571] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES_TIMEOUT @ 60 ms [rev2 POWER_NEGOTIATION]
+[ 204.166996] PD RX, header: 0x1242 [1]
+[ 204.167009] state change SRC_SEND_CAPABILITIES -> SRC_SOFT_RESET_WAIT_SNK_TX [rev2 POWER_NEGOTIATION]
+[ 204.167019] AMS POWER_NEGOTIATION finished
+[ 204.167020] cc:=4
+[ 204.167083] AMS SOFT_RESET_AMS start
+[ 204.167086] state change SRC_SOFT_RESET_WAIT_SNK_TX -> SOFT_RESET_SEND [rev2 SOFT_RESET_AMS]
+[ 204.167092] PD TX, header: 0x16d
+[ 204.168824] PD TX complete, status: 0
+[ 204.168854] pending state change SOFT_RESET_SEND -> HARD_RESET_SEND @ 60 ms [rev2 SOFT_RESET_AMS]
+[ 204.171876] PD RX, header: 0x43 [1]
+[ 204.171879] AMS SOFT_RESET_AMS finished
+
+This causes COMMON.PROC.PD.11.2 check failure for
+TEST.PD.VDM.SRC.2_Rev2Src test on the PD compliance tester.
+
+Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
+Fixes: 8d3a0578ad1a ("usb: typec: tcpm: Respond Wait if VDM state machine is running")
+Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
+Cc: stable <stable@kernel.org>
+Reviewed-by: Badhri Jagan Sridharan <badhri@google.com>
+Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://patch.msgid.link/20260414-fix-soft-reset-v1-1-01d7cb9764e2@google.com
+Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/tcpm/tcpm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/usb/typec/tcpm/tcpm.c
++++ b/drivers/usb/typec/tcpm/tcpm.c
+@@ -4651,6 +4651,8 @@ static void run_state_machine(struct tcp
+ usb_power_delivery_unregister_capabilities(port->partner_source_caps);
+ port->partner_source_caps = NULL;
+ tcpm_pd_send_control(port, PD_CTRL_ACCEPT);
++ port->vdm_sm_running = false;
++ port->explicit_contract = false;
+ tcpm_ams_finish(port);
+ if (port->pwr_role == TYPEC_SOURCE) {
+ port->upcoming_state = SRC_SEND_CAPABILITIES;
projects / thirdparty / kernel / stable-queue.git / commitdiff
