November 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] selftests: mptcp: join: endpoints: longer transfer" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 6457595db9870298ee30b6d75287b8548e33fe19 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112027-clench-amazingly-fc3f@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6457595db9870298ee30b6d75287b8548e33fe19 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 10 Nov 2025 19:23:42 +0100 Subject: [PATCH] selftests: mptcp: join: endpoints: longer transfer In rare cases, when the test environment is very slow, some userspace tests can fail because some expected events have not been seen. Because the tests are expecting a long on-going connection, and they are not waiting for the end of the transfer, it is fine to make the connection longer. This connection will be killed at the end, after the verifications, so making it longer doesn't change anything, apart from avoid it to end before the end of the verifications To play it safe, all endpoints tests not waiting for the end of the transfer are now sharing a longer file (128KB) at slow speed. Fixes: 69c6ce7b6eca ("selftests: mptcp: add implicit endpoint test case") Cc: stable(a)vger.kernel.org Fixes: e274f7154008 ("selftests: mptcp: add subflow limits test-cases") Fixes: b5e2fb832f48 ("selftests: mptcp: add explicit test case for remove/readd") Fixes: e06959e9eebd ("selftests: mptcp: join: test for flush/re-add endpoints") Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-3-a4332c71… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index 9ed9ec7202d6..97af8d89ac5c 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -3943,7 +3943,7 @@ endpoint_tests() pm_nl_set_limits $ns1 2 2 pm_nl_set_limits $ns2 2 2 pm_nl_add_endpoint $ns1 10.0.2.1 flags signal - { speed=slow \ + { test_linkfail=128 speed=slow \ run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null local tests_pid=$! @@ -3970,7 +3970,7 @@ endpoint_tests() pm_nl_set_limits $ns2 0 3 pm_nl_add_endpoint $ns2 10.0.1.2 id 1 dev ns2eth1 flags subflow pm_nl_add_endpoint $ns2 10.0.2.2 id 2 dev ns2eth2 flags subflow - { test_linkfail=4 speed=5 \ + { test_linkfail=128 speed=5 \ run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null local tests_pid=$! @@ -4048,7 +4048,7 @@ endpoint_tests() # broadcast IP: no packet for this address will be received on ns1 pm_nl_add_endpoint $ns1 224.0.0.1 id 2 flags signal pm_nl_add_endpoint $ns1 10.0.1.1 id 42 flags signal - { test_linkfail=4 speed=5 \ + { test_linkfail=128 speed=5 \ run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null local tests_pid=$! @@ -4121,7 +4121,7 @@ endpoint_tests() # broadcast IP: no packet for this address will be received on ns1 pm_nl_add_endpoint $ns1 224.0.0.1 id 2 flags signal pm_nl_add_endpoint $ns2 10.0.3.2 id 3 flags subflow - { test_linkfail=4 speed=20 \ + { test_linkfail=128 speed=20 \ run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null local tests_pid=$!

3 weeks, 4 days

2
1
0 0

[PATCH] net: dsa: microchip: fix mdio parent bus reference leak

by Ma Ke

In ksz_mdio_register(), when of_mdio_find_bus() is called to get the parent MDIO bus, it increments the reference count of the underlying device. However, the reference are not released in error paths or during switch teardown, causing a reference leak. Add put_device() in the error path of ksz_mdio_register() and ksz_teardown() to release the parent bus. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 9afaf0eec2ab ("net: dsa: microchip: Refactor MDIO handling for side MDIO access") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/net/dsa/microchip/ksz_common.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c index 933ae8dc6337..49c0420a6df8 100644 --- a/drivers/net/dsa/microchip/ksz_common.c +++ b/drivers/net/dsa/microchip/ksz_common.c @@ -2795,6 +2795,11 @@ static int ksz_mdio_register(struct ksz_device *dev) } put_mdio_node: + if (ret && dev->parent_mdio_bus) { + put_device(&dev->parent_mdio_bus->dev); + dev->parent_mdio_bus = NULL; + } + of_node_put(mdio_np); of_node_put(parent_bus_node); @@ -3110,6 +3115,11 @@ static void ksz_teardown(struct dsa_switch *ds) ksz_irq_free(&dev->girq); } + if (dev->parent_mdio_bus) { + put_device(&dev->parent_mdio_bus->dev); + dev->parent_mdio_bus = NULL; + } + if (dev->dev_ops->teardown) dev->dev_ops->teardown(ds); } -- 2.17.1

3 weeks, 5 days

3
2
0 0

IAA Mobility 2025 Attendees Contacts!

by Grace Taylor

Hi, Great news — the final verified attendee list of the IAA Mobility 2025 is now available. This exclusive database includes 501,847 high-value contacts, complete with all last-minute registrations and walk-ins. For a short time, we’re offering an exclusive 30% discount, making this the perfect opportunity to strengthen your pipeline and accelerate your outreach. If you want to review the full details, simply reply “Send the Price” and I’ll send everything over immediately. Your list will be delivered within 48 hours. Don’t miss out on this limited offer — happy to assist you in getting started. Kind regards, Grace Taylor Sr. Demand Generation If you’d prefer not to receive these updates, reply “No.”

3 weeks, 5 days

1
0
0 0

[PATCH v3] powerpc, mm: Fix mprotect on book3s 32-bit

by Dave Vasilevsky

On 32-bit book3s with hash-MMUs, tlb_flush() was a no-op. This was unnoticed because all uses until recently were for unmaps, and thus handled by __tlb_remove_tlb_entry(). After commit 4a18419f71cd ("mm/mprotect: use mmu_gather") in kernel 5.19, tlb_gather_mmu() started being used for mprotect as well. This caused mprotect to simply not work on these machines: int *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); *ptr = 1; // force HPTE to be created mprotect(ptr, 4096, PROT_READ); *ptr = 2; // should segfault, but succeeds Fixed by making tlb_flush() actually flush TLB pages. This finally agrees with the behaviour of boot3s64's tlb_flush(). Fixes: 4a18419f71cd ("mm/mprotect: use mmu_gather") Cc: stable(a)vger.kernel.org Reviewed-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Signed-off-by: Dave Vasilevsky <dave(a)vasilevsky.ca> --- Changes in v3: - Fix formatting - Link to v2: https://lore.kernel.org/r/20251111-vasi-mprotect-g3-v2-1-881c94afbc42@vasil… Changes in v2: - Flush entire TLB if full mm is requested. - Link to v1: https://lore.kernel.org/r/20251027-vasi-mprotect-g3-v1-1-3c5187085f9a@vasil… --- arch/powerpc/include/asm/book3s/32/tlbflush.h | 5 ++++- arch/powerpc/mm/book3s32/tlb.c | 9 +++++++++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/book3s/32/tlbflush.h b/arch/powerpc/include/asm/book3s/32/tlbflush.h index e43534da5207aa3b0cb3c07b78e29b833c141f3f..4be2200a3c7e1e8307f5ce1f1d5d28047429c106 100644 --- a/arch/powerpc/include/asm/book3s/32/tlbflush.h +++ b/arch/powerpc/include/asm/book3s/32/tlbflush.h @@ -11,6 +11,7 @@ void hash__flush_tlb_mm(struct mm_struct *mm); void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr); void hash__flush_range(struct mm_struct *mm, unsigned long start, unsigned long end); +void hash__flush_gather(struct mmu_gather *tlb); #ifdef CONFIG_SMP void _tlbie(unsigned long address); @@ -29,7 +30,9 @@ void _tlbia(void); static inline void tlb_flush(struct mmu_gather *tlb) { /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ - if (!mmu_has_feature(MMU_FTR_HPTE_TABLE)) + if (mmu_has_feature(MMU_FTR_HPTE_TABLE)) + hash__flush_gather(tlb); + else _tlbia(); } diff --git a/arch/powerpc/mm/book3s32/tlb.c b/arch/powerpc/mm/book3s32/tlb.c index 9ad6b56bfec96e989b96f027d075ad5812500854..e54a7b0112322e5818d80facd2e3c7722e6dd520 100644 --- a/arch/powerpc/mm/book3s32/tlb.c +++ b/arch/powerpc/mm/book3s32/tlb.c @@ -105,3 +105,12 @@ void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr) flush_hash_pages(mm->context.id, vmaddr, pmd_val(*pmd), 1); } EXPORT_SYMBOL(hash__flush_tlb_page); + +void hash__flush_gather(struct mmu_gather *tlb) +{ + if (tlb->fullmm || tlb->need_flush_all) + hash__flush_tlb_mm(tlb->mm); + else + hash__flush_range(tlb->mm, tlb->start, tlb->end); +} +EXPORT_SYMBOL(hash__flush_gather); --- base-commit: 24172e0d79900908cf5ebf366600616d29c9b417 change-id: 20251027-vasi-mprotect-g3-f8f5278d4140 Best regards, -- Dave Vasilevsky <dave(a)vasilevsky.ca>

3 weeks, 5 days

2
1
0 0

[PATCH] net: dsa: Fix error handling in dsa_port_parse_of

by Ma Ke

When of_find_net_device_by_node() successfully acquires a reference to a network device but the subsequent call to dsa_port_parse_cpu() fails, dsa_port_parse_of() returns without releasing the reference count on the network device. of_find_net_device_by_node() increments the reference count of the returned structure, which should be balanced with a corresponding put_device() when the reference is no longer needed. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 6ca80638b90c ("net: dsa: Use conduit and user terms") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- net/dsa/dsa.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c index 5b01a0e43ebe..632e0d716d62 100644 --- a/net/dsa/dsa.c +++ b/net/dsa/dsa.c @@ -1246,6 +1246,7 @@ static int dsa_port_parse_of(struct dsa_port *dp, struct device_node *dn) struct device_node *ethernet = of_parse_phandle(dn, "ethernet", 0); const char *name = of_get_property(dn, "label", NULL); bool link = of_property_read_bool(dn, "link"); + int err; dp->dn = dn; @@ -1259,7 +1260,13 @@ static int dsa_port_parse_of(struct dsa_port *dp, struct device_node *dn) return -EPROBE_DEFER; user_protocol = of_get_property(dn, "dsa-tag-protocol", NULL); - return dsa_port_parse_cpu(dp, conduit, user_protocol); + err = dsa_port_parse_cpu(dp, conduit, user_protocol); + if (err) { + put_device(conduit); + return err; + } + + return 0; } if (link) -- 2.17.1

3 weeks, 5 days

5
5
0 0

[PATCH v2] mm/memfd: fix information leak in hugetlb folios

by Deepanshu Kartikey

When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd. Reported-by: syzbot+f64019ba229e3a5c411b(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/20251112031631.2315651-1-kartikey406@gmail.com/ [v1] Closes: https://syzkaller.appspot.com/bug?extid=f64019ba229e3a5c411b Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios") Cc: stable(a)vger.kernel.org Suggested-by: Oscar Salvador <osalvador(a)suse.de> Suggested-by: David Hildenbrand <david(a)redhat.com> Tested-by: syzbot+f64019ba229e3a5c411b(a)syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> --- v1 -> v2: - Use folio_zero_user() instead of folio_zero_range() (optimized for huge pages) - Add folio_mark_uptodate() before adding to page cache - Add hugetlb_fault_mutex locking around hugetlb_add_to_page_cache() - Add Fixes: tag and Cc: stable for backporting - Add Suggested-by: tags for Oscar and David --- mm/memfd.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/mm/memfd.c b/mm/memfd.c index 1d109c1acf21..d32eef58d154 100644 --- a/mm/memfd.c +++ b/mm/memfd.c @@ -96,9 +96,36 @@ struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx) NULL, gfp_mask); if (folio) { + u32 hash; + + /* + * Zero the folio to prevent information leaks to userspace. + * Use folio_zero_user() which is optimized for huge/gigantic + * pages. Pass 0 as addr_hint since this is not a faulting path + * and we don't have a user virtual address yet. + */ + folio_zero_user(folio, 0); + + /* + * Mark the folio uptodate before adding to page cache, + * as required by filemap.c and other hugetlb paths. + */ + __folio_mark_uptodate(folio); + + /* + * Serialize hugepage allocation and instantiation to prevent + * races with concurrent allocations, as required by all other + * callers of hugetlb_add_to_page_cache(). + */ + hash = hugetlb_fault_mutex_hash(memfd->f_mapping, idx); + mutex_lock(&hugetlb_fault_mutex_table[hash]); + err = hugetlb_add_to_page_cache(folio, memfd->f_mapping, idx); + + mutex_unlock(&hugetlb_fault_mutex_table[hash]); + if (err) { folio_put(folio); goto err_unresv; -- 2.43.0

3 weeks, 5 days

4
4
0 0

[tip: timers/urgent] timers: Fix NULL function pointer race in timer_shutdown_sync()

by tip-bot2 for Yipeng Zou

The following commit has been merged into the timers/urgent branch of tip: Commit-ID: 20739af07383e6eb1ec59dcd70b72ebfa9ac362c Gitweb: https://git.kernel.org/tip/20739af07383e6eb1ec59dcd70b72ebfa9ac362c Author: Yipeng Zou <zouyipeng(a)huawei.com> AuthorDate: Sat, 22 Nov 2025 09:39:42 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Sat, 22 Nov 2025 22:55:26 +01:00 timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. Fixes: 0cc04e80458a ("timers: Add shutdown mechanism to the internal functions") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251122093942.301559-1-zouyipeng@huawei.com --- kernel/time/timer.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 553fa46..d5ebb1d 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1458,10 +1458,11 @@ static int __try_to_del_timer_sync(struct timer_list *timer, bool shutdown) base = lock_timer_base(timer, &flags); - if (base->running_timer != timer) + if (base->running_timer != timer) { ret = detach_if_pending(timer, base, true); - if (shutdown) - timer->function = NULL; + if (shutdown) + timer->function = NULL; + } raw_spin_unlock_irqrestore(&base->lock, flags);

3 weeks, 5 days

1
0
0 0

Urgent Financial Management Opportunity.

by Dr. Malik

3 weeks, 5 days

1
0
0 0

MEDICA 2025 – Access to Attendee Data

by Mike Jarvis

Hi, As you have been an exhibitor at “MEDICA 2025” has successfully concluded, and the final verified attendees list is now available for your post-show outreach. It includes over 80,147 verified professionals and 4,906 exhibiting companies — Featuring medical technology manufacturers, healthcare suppliers, distributors, and service providers with complete and verified contact details. Note: All data is verified and fully GDPR compliant. If interested, share your target audience for relevant counts and pricing. Kind Regards, Mike Jarvis Sr. Demand Generation To opt out, reply “Unsubscribe.”

3 weeks, 6 days

1
0
0 0

Re: [PATCH 6.12 000/565] 6.12.58-rc1 review

by Jari Ruusu

Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote: > This is the start of the stable review cycle for the 6.12.58 release. > There are 565 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. [SNIP] > Zizhi Wo <wozizhi(a)huaweicloud.com> > tty/vt: Add missing return value for VT_RESIZE in vt_ioctl() Locking seems to be messed up in backport of above mentioned patch. That patch is viewable here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/… Upstream uses guard() locking: | case VT_RESIZE: | { | .... | guard(console_lock)(); | ^^^^^^^^^^^^^^^^^^^^^-------this generates auto-unlock code | .... | ret = __vc_resize(vc_cons[i].d, cc, ll, true); | if (ret) | return ret; | ^^^^^^^^^^----------this releases console lock | .... | break; | } Older stable branches use old-school locking: | case VT_RESIZE: | { | .... | console_lock(); | .... | ret = __vc_resize(vc_cons[i].d, cc, ll, true); | if (ret) | return ret; | ^^^^^^^^^^----------this does not release console lock | .... | console_unlock(); | break; | } Backporting upstream fixes that use guard() locking to older stable branches that use old-school locking need "extra sports". Please consider dropping or fixing above mentioned patch. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189

3 weeks, 6 days

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2025