From: Greg Kroah-Hartman Date: Tue, 16 Jun 2026 10:20:23 +0000 (+0530) Subject: 6.1-stable patches X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=133aecbaa3dd272ac9d8709fa34a5fcc1362dffe;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: ipmi-ssif-clean-up-kthread-on-errors.patch ipmi-ssif-fix-a-shutdown-race.patch kvm-arm64-wake-up-from-wfi-when-iqrchip-is-in-userspace.patch lib-crypto-mpi-fix-integer-underflow-in-mpi_read_raw_from_sgl.patch mm-damon-core-disallow-time-quota-setting-zero-esz.patch mm-damon-core-use-time_in_range_open-for-damos-quota-window-start.patch usb-typec-tcpm-reset-internal-port-states-on-soft-reset-ams.patch --- diff --git a/queue-6.1/ipmi-ssif-clean-up-kthread-on-errors.patch b/queue-6.1/ipmi-ssif-clean-up-kthread-on-errors.patch new file mode 100644 index 0000000000..9244c47422 --- /dev/null +++ b/queue-6.1/ipmi-ssif-clean-up-kthread-on-errors.patch @@ -0,0 +1,56 @@ +From 75c486cb1bcaa1a3ec3a6438498176a3a4998ae4 Mon Sep 17 00:00:00 2001 +From: Corey Minyard +Date: Mon, 13 Apr 2026 08:00:23 -0500 +Subject: ipmi:ssif: Clean up kthread on errors + +From: Corey Minyard + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-6.1/ipmi-ssif-fix-a-shutdown-race.patch b/queue-6.1/ipmi-ssif-fix-a-shutdown-race.patch new file mode 100644 index 0000000000..40aa321fd0 --- /dev/null +++ b/queue-6.1/ipmi-ssif-fix-a-shutdown-race.patch @@ -0,0 +1,46 @@ +From 6bd0eb6d759b9a22c5509ea04e19c2e8407ba418 Mon Sep 17 00:00:00 2001 +From: Corey Minyard +Date: Thu, 10 Apr 2025 14:44:26 -0500 +Subject: ipmi:ssif: Fix a shutdown race + +From: Corey Minyard + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.1/kvm-arm64-wake-up-from-wfi-when-iqrchip-is-in-userspace.patch b/queue-6.1/kvm-arm64-wake-up-from-wfi-when-iqrchip-is-in-userspace.patch new file mode 100644 index 0000000000..8e6095d186 --- /dev/null +++ b/queue-6.1/kvm-arm64-wake-up-from-wfi-when-iqrchip-is-in-userspace.patch @@ -0,0 +1,44 @@ +From 4ce98bf0865c349e7026ad9c14f48da264920953 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Thu, 23 Apr 2026 17:36:07 +0100 +Subject: KVM: arm64: Wake-up from WFI when iqrchip is in userspace + +From: Marc Zyngier + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-6.1/lib-crypto-mpi-fix-integer-underflow-in-mpi_read_raw_from_sgl.patch b/queue-6.1/lib-crypto-mpi-fix-integer-underflow-in-mpi_read_raw_from_sgl.patch new file mode 100644 index 0000000000..344170ba9f --- /dev/null +++ b/queue-6.1/lib-crypto-mpi-fix-integer-underflow-in-mpi_read_raw_from_sgl.patch @@ -0,0 +1,70 @@ +From 8c2f1288250a90a4b5cabed5d888d7e3aeed4035 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +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 + +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 # off-list +Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") +Signed-off-by: Lukas Wunner +Cc: stable@vger.kernel.org # v4.4+ +Reviewed-by: Ignat Korchagin +Reviewed-by: Jarkko Sakkinen +Link: https://lore.kernel.org/r/59eca92ff4f87e2081777f1423a0efaaadcfdb39.1776003111.git.lukas@wunner.de +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + 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++; diff --git a/queue-6.1/mm-damon-core-disallow-time-quota-setting-zero-esz.patch b/queue-6.1/mm-damon-core-disallow-time-quota-setting-zero-esz.patch new file mode 100644 index 0000000000..64abff8925 --- /dev/null +++ b/queue-6.1/mm-damon-core-disallow-time-quota-setting-zero-esz.patch @@ -0,0 +1,61 @@ +From 8bbde987c2b84f80da0853f739f0a920386f8b99 Mon Sep 17 00:00:00 2001 +From: SeongJae Park +Date: Mon, 6 Apr 2026 17:31:52 -0700 +Subject: mm/damon/core: disallow time-quota setting zero esz + +From: SeongJae Park + +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 +Cc: # 5.16.x +Signed-off-by: Andrew Morton +Signed-off-by: SeongJae Park +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/mm-damon-core-use-time_in_range_open-for-damos-quota-window-start.patch b/queue-6.1/mm-damon-core-use-time_in_range_open-for-damos-quota-window-start.patch new file mode 100644 index 0000000000..31016627aa --- /dev/null +++ b/queue-6.1/mm-damon-core-use-time_in_range_open-for-damos-quota-window-start.patch @@ -0,0 +1,57 @@ +From 049a57421dd67a28c45ae7e92c36df758033e5fa Mon Sep 17 00:00:00 2001 +From: SeongJae Park +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 + +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 +Cc: # 5.16.x +Signed-off-by: Andrew Morton +Signed-off-by: SeongJae Park +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.1/series b/queue-6.1/series index f40269c527..8681530198 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -497,3 +497,10 @@ perf-parse-events-make-yydebug-dependent-on-doing-a-debug-build.patch 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 diff --git a/queue-6.1/usb-typec-tcpm-reset-internal-port-states-on-soft-reset-ams.patch b/queue-6.1/usb-typec-tcpm-reset-internal-port-states-on-soft-reset-ams.patch new file mode 100644 index 0000000000..1c1bc07105 --- /dev/null +++ b/queue-6.1/usb-typec-tcpm-reset-internal-port-states-on-soft-reset-ams.patch @@ -0,0 +1,85 @@ +From 2909f0d4994fb4306bf116df5ccee797791fce2c Mon Sep 17 00:00:00 2001 +From: Amit Sunil Dhamne +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 + +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 +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 +Reviewed-by: Badhri Jagan Sridharan +Acked-by: Heikki Krogerus +Link: https://patch.msgid.link/20260414-fix-soft-reset-v1-1-01d7cb9764e2@google.com +Signed-off-by: Amit Sunil Dhamne +Signed-off-by: Greg Kroah-Hartman +--- + 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;