July 2025 - Linux-stable-mirror

+ scripts-gdb-vfs-support-external-dentry-names.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: scripts: gdb: vfs: support external dentry names has been added to the -mm mm-hotfixes-unstable branch. Its filename is scripts-gdb-vfs-support-external-dentry-names.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Illia Ostapyshyn <illia(a)yshyn.com> Subject: scripts: gdb: vfs: support external dentry names Date: Sun, 29 Jun 2025 02:38:11 +0200 d_shortname of struct dentry only reserves D_NAME_INLINE_LEN characters and contains garbage for longer names. Use d_name instead, which always references the valid name. Link: https://lore.kernel.org/all/20250525213709.878287-2-illia@yshyn.com/ Link: https://lkml.kernel.org/r/20250629003811.2420418-1-illia@yshyn.com Fixes: 79300ac805b672a84b64 ("scripts/gdb: fix dentry_name() lookup") Signed-off-by: Illia Ostapyshyn <illia(a)yshyn.com> Tested-by: Florian Fainelli <florian.fainelli(a)broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli(a)broadcom.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Jan Kara <jack(a)suse.cz> Cc: Jan Kiszka <jan.kiszka(a)siemens.com> Cc: Kieran Bingham <kbingham(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- scripts/gdb/linux/vfs.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/scripts/gdb/linux/vfs.py~scripts-gdb-vfs-support-external-dentry-names +++ a/scripts/gdb/linux/vfs.py @@ -22,7 +22,7 @@ def dentry_name(d): if parent == d or parent == 0: return "" p = dentry_name(d['d_parent']) + "/" - return p + d['d_shortname']['string'].string() + return p + d['d_name']['name'].string() class DentryName(gdb.Function): """Return string of the full path of a dentry. _ Patches currently in -mm which might be from illia(a)yshyn.com are scripts-gdb-vfs-support-external-dentry-names.patch

1 month, 1 week

1
0
0 0

[to-be-updated] fix-do_pages_stat-to-use-compat_uptr_t.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/migrate.c: fix do_pages_stat to use compat_uptr_t has been removed from the -mm tree. Its filename was fix-do_pages_stat-to-use-compat_uptr_t.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Christoph Berg <myon(a)debian.org> Subject: mm/migrate.c: fix do_pages_stat to use compat_uptr_t Date: Wed, 25 Jun 2025 17:24:14 +0200 For arrays with more than 16 entries, the old code would incorrectly advance the pages pointer by 16 words instead of 16 compat_uptr_t. [akpm(a)linux-foundation.org: fix coding style] Link: https://lkml.kernel.org/r/aFwUnu7ObizycCZ8@msg.df7cb.de Signed-off-by: Christoph Berg <myon(a)debian.org> Suggested-by: Bertrand Drouvot <bertranddrouvot.pg(a)gmail.com> Suggested-by: David Hildenbrand <david(a)redhat.com> Cc: Alistair Popple <apopple(a)nvidia.com> Cc: Byungchul Park <byungchul(a)sk.com> Cc: Gregory Price <gourry(a)gourry.net> Cc: "Huang, Ying" <ying.huang(a)linux.alibaba.com> Cc: Joshua Hahn <joshua.hahnjy(a)gmail.com> Cc: Mathew Brost <matthew.brost(a)intel.com> Cc: Rakie Kim <rakie.kim(a)sk.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/migrate.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/mm/migrate.c~fix-do_pages_stat-to-use-compat_uptr_t +++ a/mm/migrate.c @@ -2444,7 +2444,14 @@ static int do_pages_stat(struct mm_struc if (copy_to_user(status, chunk_status, chunk_nr * sizeof(*status))) break; - pages += chunk_nr; + if (in_compat_syscall()) { + compat_uptr_t __user *pages32 = (compat_uptr_t __user *)pages; + + pages32 += chunk_nr; + pages = (const void __user * __user *) pages32; + } else { + pages += chunk_nr; + } status += chunk_nr; nr_pages -= chunk_nr; } _ Patches currently in -mm which might be from myon(a)debian.org are

1 month, 1 week

1
0
0 0

+ kallsyms-fix-build-without-execinfo.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kallsyms: fix build without execinfo has been added to the -mm mm-hotfixes-unstable branch. Its filename is kallsyms-fix-build-without-execinfo.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Achill Gilgenast <fossdd(a)pwned.life> Subject: kallsyms: fix build without execinfo Date: Sun, 22 Jun 2025 03:45:49 +0200 Some libc's like musl libc don't provide execinfo.h since it's not part of POSIX. In order to fix compilation on musl, only include execinfo.h if available (HAVE_BACKTRACE_SUPPORT) This was discovered with c104c16073b7 ("Kunit to check the longest symbol length") which starts to include linux/kallsyms.h with Alpine Linux' configs. Link: https://lkml.kernel.org/r/20250622014608.448718-1-fossdd@pwned.life Fixes: c104c16073b7 ("Kunit to check the longest symbol length") Signed-off-by: Achill Gilgenast <fossdd(a)pwned.life> Cc: Luis Henriques <luis(a)igalia.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/include/linux/kallsyms.h | 4 ++++ 1 file changed, 4 insertions(+) --- a/tools/include/linux/kallsyms.h~kallsyms-fix-build-without-execinfo +++ a/tools/include/linux/kallsyms.h @@ -18,6 +18,7 @@ static inline const char *kallsyms_looku return NULL; } +#ifdef HAVE_BACKTRACE_SUPPORT #include <execinfo.h> #include <stdlib.h> static inline void print_ip_sym(const char *loglvl, unsigned long ip) @@ -30,5 +31,8 @@ static inline void print_ip_sym(const ch free(name); } +#else +static inline void print_ip_sym(const char *loglvl, unsigned long ip) {} +#endif #endif _ Patches currently in -mm which might be from fossdd(a)pwned.life are kallsyms-fix-build-without-execinfo.patch

1 month, 1 week

1
0
0 0

[RESEND PATCH v2] kallsyms: fix build without execinfo

by Achill Gilgenast

Some libc's like musl libc don't provide execinfo.h since it's not part of POSIX. In order to fix compilation on musl, only include execinfo.h if available (HAVE_BACKTRACE_SUPPORT) This was discovered with c104c16073b7 ("Kunit to check the longest symbol length") which starts to include linux/kallsyms.h with Alpine Linux' configs. Signed-off-by: Achill Gilgenast <fossdd(a)pwned.life> Cc: stable(a)vger.kernel.org --- tools/include/linux/kallsyms.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/include/linux/kallsyms.h b/tools/include/linux/kallsyms.h index 5a37ccbec54f..f61a01dd7eb7 100644 --- a/tools/include/linux/kallsyms.h +++ b/tools/include/linux/kallsyms.h @@ -18,6 +18,7 @@ static inline const char *kallsyms_lookup(unsigned long addr, return NULL; } +#ifdef HAVE_BACKTRACE_SUPPORT #include <execinfo.h> #include <stdlib.h> static inline void print_ip_sym(const char *loglvl, unsigned long ip) @@ -30,5 +31,8 @@ static inline void print_ip_sym(const char *loglvl, unsigned long ip) free(name); } +#else +static inline void print_ip_sym(const char *loglvl, unsigned long ip) {} +#endif #endif -- 2.50.0

1 month, 1 week

3
5
0 0

[PATCH v2 2/8] vsock/virtio: Validate length in packet header before skb_put()

by Will Deacon

When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately, virtio_vsock_skb_rx_put() uses the length from the packet header as the length argument to skb_put(), potentially resulting in SKB overflow if the host has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put(). Cc: <stable(a)vger.kernel.org> Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") Signed-off-by: Will Deacon <will(a)kernel.org> --- net/vmw_vsock/virtio_transport.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c index f0e48e6911fc..bd2c6aaa1a93 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -624,8 +624,9 @@ static void virtio_transport_rx_work(struct work_struct *work) do { virtqueue_disable_cb(vq); for (;;) { + unsigned int len, payload_len; + struct virtio_vsock_hdr *hdr; struct sk_buff *skb; - unsigned int len; if (!virtio_transport_more_replies(vsock)) { /* Stop rx until the device processes already @@ -642,12 +643,19 @@ static void virtio_transport_rx_work(struct work_struct *work) vsock->rx_buf_nr--; /* Drop short/long packets */ - if (unlikely(len < sizeof(struct virtio_vsock_hdr) || + if (unlikely(len < sizeof(*hdr) || len > virtio_vsock_skb_len(skb))) { kfree_skb(skb); continue; } + hdr = virtio_vsock_hdr(skb); + payload_len = le32_to_cpu(hdr->len); + if (payload_len > len - sizeof(*hdr)) { + kfree_skb(skb); + continue; + } + virtio_vsock_skb_rx_put(skb); virtio_transport_deliver_tap_pkt(skb); virtio_transport_recv_pkt(&virtio_transport, skb); -- 2.50.0.727.gbf7dc18ff4-goog

1 month, 1 week

1
0
0 0

[PATCH v2 1/8] vhost/vsock: Avoid allocating arbitrarily-sized SKBs

by Will Deacon

vhost_vsock_alloc_skb() returns NULL for packets advertising a length larger than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE in the packet header. However, this is only checked once the SKB has been allocated and, if the length in the packet header is zero, the SKB may not be freed immediately. Hoist the size check before the SKB allocation so that an iovec larger than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE + the header size is rejected outright. The subsequent check on the length field in the header can then simply check that the allocated SKB is indeed large enough to hold the packet. Cc: <stable(a)vger.kernel.org> Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") Signed-off-by: Will Deacon <will(a)kernel.org> --- drivers/vhost/vsock.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c index 802153e23073..66a0f060770e 100644 --- a/drivers/vhost/vsock.c +++ b/drivers/vhost/vsock.c @@ -344,6 +344,9 @@ vhost_vsock_alloc_skb(struct vhost_virtqueue *vq, len = iov_length(vq->iov, out); + if (len > VIRTIO_VSOCK_MAX_PKT_BUF_SIZE + VIRTIO_VSOCK_SKB_HEADROOM) + return NULL; + /* len contains both payload and hdr */ skb = virtio_vsock_alloc_skb(len, GFP_KERNEL); if (!skb) @@ -367,8 +370,7 @@ vhost_vsock_alloc_skb(struct vhost_virtqueue *vq, return skb; /* The pkt is too big or the length in the header is invalid */ - if (payload_len > VIRTIO_VSOCK_MAX_PKT_BUF_SIZE || - payload_len + sizeof(*hdr) > len) { + if (payload_len + sizeof(*hdr) > len) { kfree_skb(skb); return NULL; } -- 2.50.0.727.gbf7dc18ff4-goog

1 month, 1 week

1
0
0 0

[PATCH v2] usb: musb: fix gadget state on disconnect

by Drew Hamilton

When unplugging the USB cable or disconnecting a gadget in usb peripheral mode with echo "" > /sys/kernel/config/usb_gadget/<your_gadget>/UDC, /sys/class/udc/musb-hdrc.0/state does not change from USB_STATE_CONFIGURED. Testing on dwc2/3 shows they both update the state to USB_STATE_NOTATTACHED. Add calls to usb_gadget_set_state in musb_g_disconnect and musb_gadget_stop to fix both cases. Fixes: 49401f4169c0 ("usb: gadget: introduce gadget state tracking") Cc: stable(a)vger.kernel.org Co-authored-by: Yehowshua Immanuel <yehowshua.immanuel(a)twosixtech.com> Signed-off-by: Yehowshua Immanuel <yehowshua.immanuel(a)twosixtech.com> Signed-off-by: Drew Hamilton <drew.hamilton(a)zetier.com> --- Changes in v2: - Cleaned up changelog and added Fixes and Cc tags --- drivers/usb/musb/musb_gadget.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 6869c58367f2..caf4d4cd4b75 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1913,6 +1913,7 @@ static int musb_gadget_stop(struct usb_gadget *g) * gadget driver here and have everything work; * that currently misbehaves. */ + usb_gadget_set_state(g, USB_STATE_NOTATTACHED); /* Force check of devctl register for PM runtime */ pm_runtime_mark_last_busy(musb->controller); @@ -2019,6 +2020,7 @@ void musb_g_disconnect(struct musb *musb) case OTG_STATE_B_PERIPHERAL: case OTG_STATE_B_IDLE: musb_set_state(musb, OTG_STATE_B_IDLE); + usb_gadget_set_state(&musb->g, USB_STATE_NOTATTACHED); break; case OTG_STATE_B_SRP_INIT: break; -- 2.34.1

1 month, 1 week

1
0
0 0

[PATCH v3 1/1] mm/rmap: fix potential out-of-bounds page table access during batched unmap

by Lance Yang

From: Lance Yang <lance.yang(a)linux.dev> As pointed out by David[1], the batched unmap logic in try_to_unmap_one() may read past the end of a PTE table when a large folio's PTE mappings are not fully contained within a single page table. While this scenario might be rare, an issue triggerable from userspace must be fixed regardless of its likelihood. This patch fixes the out-of-bounds access by refactoring the logic into a new helper, folio_unmap_pte_batch(). The new helper correctly calculates the safe batch size by capping the scan at both the VMA and PMD boundaries. To simplify the code, it also supports partial batching (i.e., any number of pages from 1 up to the calculated safe maximum), as there is no strong reason to special-case for fully mapped folios. [1] https://lore.kernel.org/linux-mm/a694398c-9f03-4737-81b9-7e49c857fcbe@redha… Fixes: 354dffd29575 ("mm: support batched unmap for lazyfree large folios during reclamation") Cc: <stable(a)vger.kernel.org> Acked-by: Barry Song <baohua(a)kernel.org> Suggested-by: David Hildenbrand <david(a)redhat.com> Suggested-by: Barry Song <baohua(a)kernel.org> Signed-off-by: Lance Yang <lance.yang(a)linux.dev> --- v2 -> v3: - Tweak changelog (per Barry and David) - Pick AB from Barry - thanks! - https://lore.kernel.org/linux-mm/20250627062319.84936-1-lance.yang@linux.dev v1 -> v2: - Update subject and changelog (per Barry) - https://lore.kernel.org/linux-mm/20250627025214.30887-1-lance.yang@linux.dev mm/rmap.c | 46 ++++++++++++++++++++++++++++------------------ 1 file changed, 28 insertions(+), 18 deletions(-) diff --git a/mm/rmap.c b/mm/rmap.c index fb63d9256f09..1320b88fab74 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1845,23 +1845,32 @@ void folio_remove_rmap_pud(struct folio *folio, struct page *page, #endif } -/* We support batch unmapping of PTEs for lazyfree large folios */ -static inline bool can_batch_unmap_folio_ptes(unsigned long addr, - struct folio *folio, pte_t *ptep) +static inline unsigned int folio_unmap_pte_batch(struct folio *folio, + struct page_vma_mapped_walk *pvmw, + enum ttu_flags flags, pte_t pte) { const fpb_t fpb_flags = FPB_IGNORE_DIRTY | FPB_IGNORE_SOFT_DIRTY; - int max_nr = folio_nr_pages(folio); - pte_t pte = ptep_get(ptep); + unsigned long end_addr, addr = pvmw->address; + struct vm_area_struct *vma = pvmw->vma; + unsigned int max_nr; + + if (flags & TTU_HWPOISON) + return 1; + if (!folio_test_large(folio)) + return 1; + /* We may only batch within a single VMA and a single page table. */ + end_addr = pmd_addr_end(addr, vma->vm_end); + max_nr = (end_addr - addr) >> PAGE_SHIFT; + + /* We only support lazyfree batching for now ... */ if (!folio_test_anon(folio) || folio_test_swapbacked(folio)) - return false; + return 1; if (pte_unused(pte)) - return false; - if (pte_pfn(pte) != folio_pfn(folio)) - return false; + return 1; - return folio_pte_batch(folio, addr, ptep, pte, max_nr, fpb_flags, NULL, - NULL, NULL) == max_nr; + return folio_pte_batch(folio, addr, pvmw->pte, pte, max_nr, fpb_flags, + NULL, NULL, NULL); } /* @@ -2024,9 +2033,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, if (pte_dirty(pteval)) folio_mark_dirty(folio); } else if (likely(pte_present(pteval))) { - if (folio_test_large(folio) && !(flags & TTU_HWPOISON) && - can_batch_unmap_folio_ptes(address, folio, pvmw.pte)) - nr_pages = folio_nr_pages(folio); + nr_pages = folio_unmap_pte_batch(folio, &pvmw, flags, pteval); end_addr = address + nr_pages * PAGE_SIZE; flush_cache_range(vma, address, end_addr); @@ -2206,13 +2213,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, hugetlb_remove_rmap(folio); } else { folio_remove_rmap_ptes(folio, subpage, nr_pages, vma); - folio_ref_sub(folio, nr_pages - 1); } if (vma->vm_flags & VM_LOCKED) mlock_drain_local(); - folio_put(folio); - /* We have already batched the entire folio */ - if (nr_pages > 1) + folio_put_refs(folio, nr_pages); + + /* + * If we are sure that we batched the entire folio and cleared + * all PTEs, we can just optimize and stop right here. + */ + if (nr_pages == folio_nr_pages(folio)) goto walk_done; continue; walk_abort: -- 2.49.0

1 month, 1 week

4
4
0 0

Fix forgotten in stable backports?

by Yann Sionneau

Hello Greg, all, I am wondering if by accident this fix would have been forgotten while backporting to stable branches: 2437513a814b3e93bd02879740a8a06e52e2cf7d ? It has been backported in 6.0 and 6.1: * https://lore.kernel.org/all/20221228144352.366979745@linuxfoundation.org/ * https://lore.kernel.org/all/20221228144356.096159479@linuxfoundation.org/ But not in 5.4, 5.10, 5.15 Even though, indeed, the patch would not apply as such, but it seems trivial to adapt. Downstream XCP-ng (Xen based distribution for virtualization solution) is about to package it https://github.com/xcp-ng-rpms/kernel/pull/20/files (that's how I noticed the lack of backport). Or maybe it was intentional? Thanks for your lights :) Regards, PS: please CC me in answer since I'm not subscribed to stable@ mailing list. -- Yann Sionneau Yann Sionneau | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech

1 month, 1 week

2
1
0 0

[PATCH v2 1/4] arm64: dts: imx8mp-venice-gw71xx: fix TPM SPI frequency

by Tim Harvey

The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 1a8f6ff6a291 ("arm64: dts: imx8mp-venice-gw71xx: add TPM device") Cc: stable(a)vger.kernel.org Signed-off-by: Tim Harvey <tharvey(a)gateworks.com> --- v2: add cc to stable --- arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi index 2f740d74707b..4bf818873fe3 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi @@ -70,7 +70,7 @@ &ecspi2 { tpm@1 { compatible = "atmel,attpm20p", "tcg,tpm_tis-spi"; reg = <0x1>; - spi-max-frequency = <36000000>; + spi-max-frequency = <25000000>; }; }; -- 2.25.1

1 month, 1 week

2
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2025