From: Greg Kroah-Hartman Date: Fri, 22 Aug 2025 06:16:37 +0000 (+0200) Subject: 6.12-stable patches X-Git-Tag: v6.16.3~66 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=99b08c4b284320663f37235b73d55440ec6f5c3b;p=thirdparty%2Fkernel%2Fstable-queue.git 6.12-stable patches added patches: acpi-pfr_update-fix-the-driver-update-version-check.patch ipv6-sr-fix-mac-comparison-to-be-constant-time.patch loongarch-kvm-add-address-alignment-check-in-pch_pic-register-access.patch loongarch-kvm-make-function-kvm_own_lbt-robust.patch mptcp-drop-skb-if-mptcp-skb-extension-allocation-fails.patch mptcp-pm-kernel-flush-do-not-reset-add_addr-limit.patch net-hsr-reject-hsr-frame-if-skb-can-t-hold-tag.patch sched-ext-fix-invalid-task-state-transitions-on-class-switch.patch selftests-mptcp-pm-check-flush-doesn-t-reset-limits.patch --- diff --git a/queue-6.12/acpi-pfr_update-fix-the-driver-update-version-check.patch b/queue-6.12/acpi-pfr_update-fix-the-driver-update-version-check.patch new file mode 100644 index 0000000000..9e69eb0518 --- /dev/null +++ b/queue-6.12/acpi-pfr_update-fix-the-driver-update-version-check.patch @@ -0,0 +1,49 @@ +From 8151320c747efb22d30b035af989fed0d502176e Mon Sep 17 00:00:00 2001 +From: Chen Yu +Date: Tue, 22 Jul 2025 22:32:33 +0800 +Subject: ACPI: pfr_update: Fix the driver update version check + +From: Chen Yu + +commit 8151320c747efb22d30b035af989fed0d502176e upstream. + +The security-version-number check should be used rather +than the runtime version check for driver updates. + +Otherwise, the firmware update would fail when the update binary had +a lower runtime version number than the current one. + +Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver") +Cc: 5.17+ # 5.17+ +Reported-by: "Govindarajulu, Hariganesh" +Signed-off-by: Chen Yu +Link: https://patch.msgid.link/20250722143233.3970607-1-yu.c.chen@intel.com +[ rjw: Changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/pfr_update.c | 2 +- + include/uapi/linux/pfrut.h | 1 + + 2 files changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/acpi/pfr_update.c ++++ b/drivers/acpi/pfr_update.c +@@ -310,7 +310,7 @@ static bool applicable_image(const void + if (type == PFRU_CODE_INJECT_TYPE) + return payload_hdr->rt_ver >= cap->code_rt_version; + +- return payload_hdr->rt_ver >= cap->drv_rt_version; ++ return payload_hdr->svn_ver >= cap->drv_svn; + } + + static void print_update_debug_info(struct pfru_updated_result *result, +--- a/include/uapi/linux/pfrut.h ++++ b/include/uapi/linux/pfrut.h +@@ -89,6 +89,7 @@ struct pfru_payload_hdr { + __u32 hw_ver; + __u32 rt_ver; + __u8 platform_id[16]; ++ __u32 svn_ver; + }; + + enum pfru_dsm_status { diff --git a/queue-6.12/ipv6-sr-fix-mac-comparison-to-be-constant-time.patch b/queue-6.12/ipv6-sr-fix-mac-comparison-to-be-constant-time.patch new file mode 100644 index 0000000000..9f34314e3a --- /dev/null +++ b/queue-6.12/ipv6-sr-fix-mac-comparison-to-be-constant-time.patch @@ -0,0 +1,42 @@ +From a458b2902115b26a25d67393b12ddd57d1216aaa Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Mon, 18 Aug 2025 13:27:24 -0700 +Subject: ipv6: sr: Fix MAC comparison to be constant-time + +From: Eric Biggers + +commit a458b2902115b26a25d67393b12ddd57d1216aaa upstream. + +To prevent timing attacks, MACs need to be compared in constant time. +Use the appropriate helper function for this. + +Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") +Cc: stable@vger.kernel.org +Signed-off-by: Eric Biggers +Reviewed-by: Andrea Mayer +Link: https://patch.msgid.link/20250818202724.15713-1-ebiggers@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv6/seg6_hmac.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/ipv6/seg6_hmac.c ++++ b/net/ipv6/seg6_hmac.c +@@ -35,6 +35,7 @@ + #include + + #include ++#include + #include + #include + #include +@@ -271,7 +272,7 @@ bool seg6_hmac_validate_skb(struct sk_bu + if (seg6_hmac_compute(hinfo, srh, &ipv6_hdr(skb)->saddr, hmac_output)) + return false; + +- if (memcmp(hmac_output, tlv->hmac, SEG6_HMAC_FIELD_LEN) != 0) ++ if (crypto_memneq(hmac_output, tlv->hmac, SEG6_HMAC_FIELD_LEN)) + return false; + + return true; diff --git a/queue-6.12/loongarch-kvm-add-address-alignment-check-in-pch_pic-register-access.patch b/queue-6.12/loongarch-kvm-add-address-alignment-check-in-pch_pic-register-access.patch new file mode 100644 index 0000000000..35ba789048 --- /dev/null +++ b/queue-6.12/loongarch-kvm-add-address-alignment-check-in-pch_pic-register-access.patch @@ -0,0 +1,53 @@ +From 538c06e3964a8e94b645686cc58ccc4a06fa6330 Mon Sep 17 00:00:00 2001 +From: Bibo Mao +Date: Wed, 20 Aug 2025 22:51:15 +0800 +Subject: LoongArch: KVM: Add address alignment check in pch_pic register access + +From: Bibo Mao + +commit 538c06e3964a8e94b645686cc58ccc4a06fa6330 upstream. + +With pch_pic device, its register is based on MMIO address space, +different access size 1/2/4/8 is supported. And base address should +be naturally aligned with its access size, here add alignment check +in its register access emulation function. + +Cc: stable@vger.kernel.org +Signed-off-by: Bibo Mao +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kvm/intc/pch_pic.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +diff --git a/arch/loongarch/kvm/intc/pch_pic.c b/arch/loongarch/kvm/intc/pch_pic.c +index 6f00ffe05c54..119290bcea79 100644 +--- a/arch/loongarch/kvm/intc/pch_pic.c ++++ b/arch/loongarch/kvm/intc/pch_pic.c +@@ -195,6 +195,11 @@ static int kvm_pch_pic_read(struct kvm_vcpu *vcpu, + return -EINVAL; + } + ++ if (addr & (len - 1)) { ++ kvm_err("%s: pch pic not aligned addr %llx len %d\n", __func__, addr, len); ++ return -EINVAL; ++ } ++ + /* statistics of pch pic reading */ + vcpu->stat.pch_pic_read_exits++; + ret = loongarch_pch_pic_read(s, addr, len, val); +@@ -302,6 +307,11 @@ static int kvm_pch_pic_write(struct kvm_vcpu *vcpu, + return -EINVAL; + } + ++ if (addr & (len - 1)) { ++ kvm_err("%s: pch pic not aligned addr %llx len %d\n", __func__, addr, len); ++ return -EINVAL; ++ } ++ + /* statistics of pch pic writing */ + vcpu->stat.pch_pic_write_exits++; + ret = loongarch_pch_pic_write(s, addr, len, val); +-- +2.50.1 + diff --git a/queue-6.12/loongarch-kvm-make-function-kvm_own_lbt-robust.patch b/queue-6.12/loongarch-kvm-make-function-kvm_own_lbt-robust.patch new file mode 100644 index 0000000000..3a099dd302 --- /dev/null +++ b/queue-6.12/loongarch-kvm-make-function-kvm_own_lbt-robust.patch @@ -0,0 +1,37 @@ +From 4be8cefc132606b4a6e851f37f8e8c40c406c910 Mon Sep 17 00:00:00 2001 +From: Bibo Mao +Date: Wed, 20 Aug 2025 22:51:14 +0800 +Subject: LoongArch: KVM: Make function kvm_own_lbt() robust + +From: Bibo Mao + +commit 4be8cefc132606b4a6e851f37f8e8c40c406c910 upstream. + +Add the flag KVM_LARCH_LBT checking in function kvm_own_lbt(), so that +it can be called safely rather than duplicated enabling again. + +Cc: stable@vger.kernel.org +Signed-off-by: Bibo Mao +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kvm/vcpu.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/arch/loongarch/kvm/vcpu.c ++++ b/arch/loongarch/kvm/vcpu.c +@@ -1249,9 +1249,11 @@ int kvm_own_lbt(struct kvm_vcpu *vcpu) + return -EINVAL; + + preempt_disable(); +- set_csr_euen(CSR_EUEN_LBTEN); +- _restore_lbt(&vcpu->arch.lbt); +- vcpu->arch.aux_inuse |= KVM_LARCH_LBT; ++ if (!(vcpu->arch.aux_inuse & KVM_LARCH_LBT)) { ++ set_csr_euen(CSR_EUEN_LBTEN); ++ _restore_lbt(&vcpu->arch.lbt); ++ vcpu->arch.aux_inuse |= KVM_LARCH_LBT; ++ } + preempt_enable(); + + return 0; diff --git a/queue-6.12/mptcp-drop-skb-if-mptcp-skb-extension-allocation-fails.patch b/queue-6.12/mptcp-drop-skb-if-mptcp-skb-extension-allocation-fails.patch new file mode 100644 index 0000000000..13feae0606 --- /dev/null +++ b/queue-6.12/mptcp-drop-skb-if-mptcp-skb-extension-allocation-fails.patch @@ -0,0 +1,62 @@ +From ccab044697980c6c01ab51f43f48f13b8a3e5c33 Mon Sep 17 00:00:00 2001 +From: Christoph Paasch +Date: Fri, 15 Aug 2025 19:28:19 +0200 +Subject: mptcp: drop skb if MPTCP skb extension allocation fails + +From: Christoph Paasch + +commit ccab044697980c6c01ab51f43f48f13b8a3e5c33 upstream. + +When skb_ext_add(skb, SKB_EXT_MPTCP) fails in mptcp_incoming_options(), +we used to return true, letting the segment proceed through the TCP +receive path without a DSS mapping. Such segments can leave inconsistent +mapping state and trigger a mid-stream fallback to TCP, which in testing +collapsed (by artificially forcing failures in skb_ext_add) throughput +to zero. + +Return false instead so the TCP input path drops the skb (see +tcp_data_queue() and step-7 processing). This is the safer choice +under memory pressure: it preserves MPTCP correctness and provides +backpressure to the sender. + +Control packets remain unaffected: ACK updates and DATA_FIN handling +happen before attempting the extension allocation, and tcp_reset() +continues to ignore the return value. + +With this change, MPTCP continues to work at high throughput if we +artificially inject failures into skb_ext_add. + +Fixes: 6787b7e350d3 ("mptcp: avoid processing packet if a subflow reset") +Cc: stable@vger.kernel.org +Signed-off-by: Christoph Paasch +Reviewed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-1-521fe9957892@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/options.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/net/mptcp/options.c ++++ b/net/mptcp/options.c +@@ -1118,7 +1118,9 @@ static bool add_addr_hmac_valid(struct m + return hmac == mp_opt->ahmac; + } + +-/* Return false if a subflow has been reset, else return true */ ++/* Return false in case of error (or subflow has been reset), ++ * else return true. ++ */ + bool mptcp_incoming_options(struct sock *sk, struct sk_buff *skb) + { + struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(sk); +@@ -1222,7 +1224,7 @@ bool mptcp_incoming_options(struct sock + + mpext = skb_ext_add(skb, SKB_EXT_MPTCP); + if (!mpext) +- return true; ++ return false; + + memset(mpext, 0, sizeof(*mpext)); + diff --git a/queue-6.12/mptcp-pm-kernel-flush-do-not-reset-add_addr-limit.patch b/queue-6.12/mptcp-pm-kernel-flush-do-not-reset-add_addr-limit.patch new file mode 100644 index 0000000000..193795c674 --- /dev/null +++ b/queue-6.12/mptcp-pm-kernel-flush-do-not-reset-add_addr-limit.patch @@ -0,0 +1,40 @@ +From 68fc0f4b0d25692940cdc85c68e366cae63e1757 Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Fri, 15 Aug 2025 19:28:20 +0200 +Subject: mptcp: pm: kernel: flush: do not reset ADD_ADDR limit + +From: Matthieu Baerts (NGI0) + +commit 68fc0f4b0d25692940cdc85c68e366cae63e1757 upstream. + +A flush of the MPTCP endpoints should not affect the MPTCP limits. In +other words, 'ip mptcp endpoint flush' should not change 'ip mptcp +limits'. + +But it was the case: the MPTCP_PM_ATTR_RCV_ADD_ADDRS (add_addr_accepted) +limit was reset by accident. Removing the reset of this counter during a +flush fixes this issue. + +Fixes: 01cacb00b35c ("mptcp: add netlink-based PM") +Cc: stable@vger.kernel.org +Reported-by: Thomas Dreibholz +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/579 +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-2-521fe9957892@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/pm_netlink.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/net/mptcp/pm_netlink.c ++++ b/net/mptcp/pm_netlink.c +@@ -1737,7 +1737,6 @@ static void __flush_addrs(struct list_he + static void __reset_counters(struct pm_nl_pernet *pernet) + { + WRITE_ONCE(pernet->add_addr_signal_max, 0); +- WRITE_ONCE(pernet->add_addr_accept_max, 0); + WRITE_ONCE(pernet->local_addr_max, 0); + pernet->addrs = 0; + } diff --git a/queue-6.12/net-hsr-reject-hsr-frame-if-skb-can-t-hold-tag.patch b/queue-6.12/net-hsr-reject-hsr-frame-if-skb-can-t-hold-tag.patch new file mode 100644 index 0000000000..e5b82c8622 --- /dev/null +++ b/queue-6.12/net-hsr-reject-hsr-frame-if-skb-can-t-hold-tag.patch @@ -0,0 +1,189 @@ +From 7af76e9d18a9fd6f8611b3313c86c190f9b6a5a7 Mon Sep 17 00:00:00 2001 +From: Jakub Acs +Date: Tue, 19 Aug 2025 08:28:42 +0000 +Subject: net, hsr: reject HSR frame if skb can't hold tag +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jakub Acs + +commit 7af76e9d18a9fd6f8611b3313c86c190f9b6a5a7 upstream. + +Receiving HSR frame with insufficient space to hold HSR tag in the skb +can result in a crash (kernel BUG): + +[ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 +[ 45.392559] ------------[ cut here ]------------ +[ 45.392912] kernel BUG at net/core/skbuff.c:211! +[ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI +[ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) +[ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 +[ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0 + + + +[ 45.402911] Call Trace: +[ 45.403105] +[ 45.404470] skb_push+0xcd/0xf0 +[ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 +[ 45.406513] br_forward_finish+0x128/0x260 +[ 45.408483] __br_forward+0x42d/0x590 +[ 45.409464] maybe_deliver+0x2eb/0x420 +[ 45.409763] br_flood+0x174/0x4a0 +[ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0 +[ 45.411618] br_handle_frame+0xac3/0x1230 +[ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0 +[ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 +[ 45.424478] __netif_receive_skb+0x22/0x170 +[ 45.424806] process_backlog+0x242/0x6d0 +[ 45.425116] __napi_poll+0xbb/0x630 +[ 45.425394] net_rx_action+0x4d1/0xcc0 +[ 45.427613] handle_softirqs+0x1a4/0x580 +[ 45.427926] do_softirq+0x74/0x90 +[ 45.428196] + +This issue was found by syzkaller. + +The panic happens in br_dev_queue_push_xmit() once it receives a +corrupted skb with ETH header already pushed in linear data. When it +attempts the skb_push() call, there's not enough headroom and +skb_push() panics. + +The corrupted skb is put on the queue by HSR layer, which makes a +sequence of unintended transformations when it receives a specific +corrupted HSR frame (with incomplete TAG). + +Fix it by dropping and consuming frames that are not long enough to +contain both ethernet and hsr headers. + +Alternative fix would be to check for enough headroom before skb_push() +in br_dev_queue_push_xmit(). + +In the reproducer, this is injected via AF_PACKET, but I don't easily +see why it couldn't be sent over the wire from adjacent network. + +Further Details: + +In the reproducer, the following network interface chain is set up: + +┌────────────────┐ ┌────────────────┐ +│ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ +└────────────────┘ └────────────────┘ │ + │ ┌──────┐ + ├─┤ hsr0 ├───┐ + │ └──────┘ │ +┌────────────────┐ ┌────────────────┐ │ │┌────────┐ +│ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │ +└────────────────┘ └────────────────┘ ┌┼ bridge │ + ││ │ + │└────────┘ + │ + ┌───────┐ │ + │ ... ├──────┘ + └───────┘ + +To trigger the events leading up to crash, reproducer sends a corrupted +HSR frame with incomplete TAG, via AF_PACKET socket on 'veth0_to_hsr'. + +The first HSR-layer function to process this frame is +hsr_handle_frame(). It and then checks if the +protocol is ETH_P_PRP or ETH_P_HSR. If it is, it calls +skb_set_network_header(skb, ETH_HLEN + HSR_HLEN), without checking that +the skb is long enough. For the crashing frame it is not, and hence the +skb->network_header and skb->mac_len fields are set incorrectly, +pointing after the end of the linear buffer. + +I will call this a BUG#1 and it is what is addressed by this patch. In +the crashing scenario before the fix, the skb continues to go down the +hsr path as follows. + +hsr_handle_frame() then calls this sequence +hsr_forward_skb() + fill_frame_info() + hsr->proto_ops->fill_frame_info() + hsr_fill_frame_info() + +hsr_fill_frame_info() contains a check that intends to check whether the +skb actually contains the HSR header. But the check relies on the +skb->mac_len field which was erroneously setup due to BUG#1, so the +check passes and the execution continues back in the hsr_forward_skb(): + +hsr_forward_skb() + hsr_forward_do() + hsr->proto_ops->get_untagged_frame() + hsr_get_untagged_frame() + create_stripped_skb_hsr() + +In create_stripped_skb_hsr(), a copy of the skb is created and is +further corrupted by operation that attempts to strip the HSR tag in a +call to __pskb_copy(). + +The skb enters create_stripped_skb_hsr() with ethernet header pushed in +linear buffer. The skb_pull(skb_in, HSR_HLEN) thus pulls 6 bytes of +ethernet header into the headroom, creating skb_in with a headroom of +size 8. The subsequent __pskb_copy() then creates an skb with headroom +of just 2 and skb->len of just 12, this is how it looks after the copy: + +gdb) p skb->len +$10 = 12 +(gdb) p skb->data +$11 = (unsigned char *) 0xffff888041e45382 "\252\252\252\252\252!\210\373", +(gdb) p skb->head +$12 = (unsigned char *) 0xffff888041e45380 "" + +It seems create_stripped_skb_hsr() assumes that ETH header is pulled +in the headroom when it's entered, because it just pulls HSR header on +top. But that is not the case in our code-path and we end up with the +corrupted skb instead. I will call this BUG#2 + +*I got confused here because it seems that under no conditions can +create_stripped_skb_hsr() work well, the assumption it makes is not true +during the processing of hsr frames - since the skb_push() in +hsr_handle_frame to skb_pull in hsr_deliver_master(). I wonder whether I +missed something here.* + +Next, the execution arrives in hsr_deliver_master(). It calls +skb_pull(ETH_HLEN), which just returns NULL - the SKB does not have +enough space for the pull (as it only has 12 bytes in total at this +point). + +*The skb_pull() here further suggests that ethernet header is meant +to be pushed through the whole hsr processing and +create_stripped_skb_hsr() should pull it before doing the HSR header +pull.* + +hsr_deliver_master() then puts the corrupted skb on the queue, it is +then picked up from there by bridge frame handling layer and finally +lands in br_dev_queue_push_xmit where it panics. + +Cc: stable@kernel.org +Fixes: 48b491a5cc74 ("net: hsr: fix mac_len checks") +Reported-by: syzbot+a81f2759d022496b40ab@syzkaller.appspotmail.com +Signed-off-by: Jakub Acs +Reviewed-by: Eric Dumazet +Link: https://patch.msgid.link/20250819082842.94378-1-acsjakub@amazon.de +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/hsr/hsr_slave.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/net/hsr/hsr_slave.c ++++ b/net/hsr/hsr_slave.c +@@ -63,8 +63,14 @@ static rx_handler_result_t hsr_handle_fr + skb_push(skb, ETH_HLEN); + skb_reset_mac_header(skb); + if ((!hsr->prot_version && protocol == htons(ETH_P_PRP)) || +- protocol == htons(ETH_P_HSR)) ++ protocol == htons(ETH_P_HSR)) { ++ if (!pskb_may_pull(skb, ETH_HLEN + HSR_HLEN)) { ++ kfree_skb(skb); ++ goto finish_consume; ++ } ++ + skb_set_network_header(skb, ETH_HLEN + HSR_HLEN); ++ } + skb_reset_mac_len(skb); + + /* Only the frames received over the interlink port will assign a diff --git a/queue-6.12/sched-ext-fix-invalid-task-state-transitions-on-class-switch.patch b/queue-6.12/sched-ext-fix-invalid-task-state-transitions-on-class-switch.patch new file mode 100644 index 0000000000..c9ed49cc8e --- /dev/null +++ b/queue-6.12/sched-ext-fix-invalid-task-state-transitions-on-class-switch.patch @@ -0,0 +1,65 @@ +From ddf7233fcab6c247379d0928d46cc316ee122229 Mon Sep 17 00:00:00 2001 +From: Andrea Righi +Date: Tue, 5 Aug 2025 10:59:11 +0200 +Subject: sched/ext: Fix invalid task state transitions on class switch + +From: Andrea Righi + +commit ddf7233fcab6c247379d0928d46cc316ee122229 upstream. + +When enabling a sched_ext scheduler, we may trigger invalid task state +transitions, resulting in warnings like the following (which can be +easily reproduced by running the hotplug selftest in a loop): + + sched_ext: Invalid task state transition 0 -> 3 for fish[770] + WARNING: CPU: 18 PID: 787 at kernel/sched/ext.c:3862 scx_set_task_state+0x7c/0xc0 + ... + RIP: 0010:scx_set_task_state+0x7c/0xc0 + ... + Call Trace: + + scx_enable_task+0x11f/0x2e0 + switching_to_scx+0x24/0x110 + scx_enable.isra.0+0xd14/0x13d0 + bpf_struct_ops_link_create+0x136/0x1a0 + __sys_bpf+0x1edd/0x2c30 + __x64_sys_bpf+0x21/0x30 + do_syscall_64+0xbb/0x370 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + +This happens because we skip initialization for tasks that are already +dead (with their usage counter set to zero), but we don't exclude them +during the scheduling class transition phase. + +Fix this by also skipping dead tasks during class swiching, preventing +invalid task state transitions. + +Fixes: a8532fac7b5d2 ("sched_ext: TASK_DEAD tasks must be switched into SCX on ops_enable") +Cc: stable@vger.kernel.org # v6.12+ +Signed-off-by: Andrea Righi +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman +--- + kernel/sched/ext.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/kernel/sched/ext.c ++++ b/kernel/sched/ext.c +@@ -5372,6 +5372,9 @@ static int scx_ops_enable(struct sched_e + __setscheduler_class(p->policy, p->prio); + struct sched_enq_and_set_ctx ctx; + ++ if (!tryget_task_struct(p)) ++ continue; ++ + if (old_class != new_class && p->se.sched_delayed) + dequeue_task(task_rq(p), p, DEQUEUE_SLEEP | DEQUEUE_DELAYED); + +@@ -5384,6 +5387,7 @@ static int scx_ops_enable(struct sched_e + sched_enq_and_set_task(&ctx); + + check_class_changed(task_rq(p), p, old_class, p->prio); ++ put_task_struct(p); + } + scx_task_iter_stop(&sti); + percpu_up_write(&scx_fork_rwsem); diff --git a/queue-6.12/selftests-mptcp-pm-check-flush-doesn-t-reset-limits.patch b/queue-6.12/selftests-mptcp-pm-check-flush-doesn-t-reset-limits.patch new file mode 100644 index 0000000000..3e9ab705c3 --- /dev/null +++ b/queue-6.12/selftests-mptcp-pm-check-flush-doesn-t-reset-limits.patch @@ -0,0 +1,41 @@ +From 452690be7de2f91cc0de68cb9e95252875b33503 Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Fri, 15 Aug 2025 19:28:21 +0200 +Subject: selftests: mptcp: pm: check flush doesn't reset limits + +From: Matthieu Baerts (NGI0) + +commit 452690be7de2f91cc0de68cb9e95252875b33503 upstream. + +This modification is linked to the parent commit where the received +ADD_ADDR limit was accidentally reset when the endpoints were flushed. + +To validate that, the test is now flushing endpoints after having set +new limits, and before checking them. + +The 'Fixes' tag here below is the same as the one from the previous +commit: this patch here is not fixing anything wrong in the selftests, +but it validates the previous fix for an issue introduced by this commit +ID. + +Fixes: 01cacb00b35c ("mptcp: add netlink-based PM") +Cc: stable@vger.kernel.org +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-3-521fe9957892@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/net/mptcp/pm_netlink.sh | 1 + + 1 file changed, 1 insertion(+) + +--- a/tools/testing/selftests/net/mptcp/pm_netlink.sh ++++ b/tools/testing/selftests/net/mptcp/pm_netlink.sh +@@ -198,6 +198,7 @@ set_limits 1 9 2>/dev/null + check "get_limits" "${default_limits}" "subflows above hard limit" + + set_limits 8 8 ++flush_endpoint ## to make sure it doesn't affect the limits + check "get_limits" "$(format_limits 8 8)" "set limits" + + flush_endpoint diff --git a/queue-6.12/series b/queue-6.12/series index 26da927456..5260ab4fdd 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -127,3 +127,12 @@ drm-amdkfd-destroy-kfd-debugfs-after-destroy-kfd-wq.patch drm-amd-display-add-primary-plane-to-commits-for-correct-vrr-handling.patch drm-amd-display-fix-a-null-pointer-dereference-vulnerability.patch drm-amd-display-don-t-overwrite-dce60_clk_mgr.patch +loongarch-kvm-make-function-kvm_own_lbt-robust.patch +net-hsr-reject-hsr-frame-if-skb-can-t-hold-tag.patch +sched-ext-fix-invalid-task-state-transitions-on-class-switch.patch +ipv6-sr-fix-mac-comparison-to-be-constant-time.patch +acpi-pfr_update-fix-the-driver-update-version-check.patch +mptcp-drop-skb-if-mptcp-skb-extension-allocation-fails.patch +mptcp-pm-kernel-flush-do-not-reset-add_addr-limit.patch +selftests-mptcp-pm-check-flush-doesn-t-reset-limits.patch +loongarch-kvm-add-address-alignment-check-in-pch_pic-register-access.patch