April 2025 - Linux-stable-mirror

+ mm-compaction-fix-bug-in-hugetlb-handling-pathway.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/compaction: fix bug in hugetlb handling pathway has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-compaction-fix-bug-in-hugetlb-handling-pathway.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: "Vishal Moola (Oracle)" <vishal.moola(a)gmail.com> Subject: mm/compaction: fix bug in hugetlb handling pathway Date: Mon, 31 Mar 2025 19:10:24 -0700 The compaction code doesn't take references on pages until we're certain we should attempt to handle it. In the hugetlb case, isolate_or_dissolve_huge_page() may return -EBUSY without taking a reference to the folio associated with our pfn. If our folio's refcount drops to 0, compound_nr() becomes unpredictable, making low_pfn and nr_scanned unreliable. The user-visible effect is minimal - this should rarely happen (if ever). Fix this by storing the folio statistics earlier on the stack (just like the THP and Buddy cases). Also revert commit 66fe1cf7f581 ("mm: compaction: use helper compound_nr in isolate_migratepages_block") to make backporting easier. Link: https://lkml.kernel.org/r/20250401021025.637333-1-vishal.moola@gmail.com Fixes: 369fa227c219 ("mm: make alloc_contig_range handle free hugetlb pages") Signed-off-by: Vishal Moola (Oracle) <vishal.moola(a)gmail.com> Acked-by: Oscar Salvador <osalvador(a)suse.de> Reviewed-by: Zi Yan <ziy(a)nvidia.com> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/compaction.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/mm/compaction.c~mm-compaction-fix-bug-in-hugetlb-handling-pathway +++ a/mm/compaction.c @@ -981,13 +981,13 @@ isolate_migratepages_block(struct compac } if (PageHuge(page)) { + const unsigned int order = compound_order(page); /* * skip hugetlbfs if we are not compacting for pages * bigger than its order. THPs and other compound pages * are handled below. */ if (!cc->alloc_contig) { - const unsigned int order = compound_order(page); if (order <= MAX_PAGE_ORDER) { low_pfn += (1UL << order) - 1; @@ -1011,8 +1011,8 @@ isolate_migratepages_block(struct compac /* Do not report -EBUSY down the chain */ if (ret == -EBUSY) ret = 0; - low_pfn += compound_nr(page) - 1; - nr_scanned += compound_nr(page) - 1; + low_pfn += (1UL << order) - 1; + nr_scanned += (1UL << order) - 1; goto isolate_fail; } _ Patches currently in -mm which might be from vishal.moola(a)gmail.com are mm-compaction-fix-bug-in-hugetlb-handling-pathway.patch

6 hours, 51 minutes

1
0
0 0

[PATCH v2 1/9] 9p: Add a migrate_folio method

by Matthew Wilcox (Oracle)

The migration code used to be able to migrate dirty 9p folios by writing them back using writepage. When the writepage method was removed, we neglected to add a migrate_folio method, which means that dirty 9p folios have been unmovable ever since. This reduced our success at defragmenting memory on machines which use 9p heavily. Fixes: 80105ed2fd27 (9p: Use netfslib read/write_iter) Cc: stable(a)vger.kernel.org Cc: David Howells <dhowells(a)redhat.com> Cc: v9fs(a)lists.linux.dev Signed-off-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> --- fs/9p/vfs_addr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c index 32619d146cbc..1286d96a29bc 100644 --- a/fs/9p/vfs_addr.c +++ b/fs/9p/vfs_addr.c @@ -164,4 +164,5 @@ const struct address_space_operations v9fs_addr_operations = { .invalidate_folio = netfs_invalidate_folio, .direct_IO = noop_direct_IO, .writepages = netfs_writepages, + .migrate_folio = filemap_migrate_folio, }; -- 2.47.2

6 hours, 57 minutes

4
3
0 0

[PATCH 5.15.y] scsi: lpfc: Fix a possible data race in lpfc_unregister_fcf_rescan()

by bin.lan.cn＠windriver.com

From: Tuo Li <islituo(a)gmail.com> [ Upstream commit 0e881c0a4b6146b7e856735226208f48251facd8 ] The variable phba->fcf.fcf_flag is often protected by the lock phba->hbalock() when is accessed. Here is an example in lpfc_unregister_fcf_rescan(): spin_lock_irq(&phba->hbalock); phba->fcf.fcf_flag |= FCF_INIT_DISC; spin_unlock_irq(&phba->hbalock); However, in the same function, phba->fcf.fcf_flag is assigned with 0 without holding the lock, and thus can cause a data race: phba->fcf.fcf_flag = 0; To fix this possible data race, a lock and unlock pair is added when accessing the variable phba->fcf.fcf_flag. Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Tuo Li <islituo(a)gmail.com> Link: https://lore.kernel.org/r/20230630024748.1035993-1-islituo@gmail.com Reviewed-by: Justin Tee <justin.tee(a)broadcom.com> Reviewed-by: Laurence Oberman <loberman(a)redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Bin Lan <bin.lan.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Build test passed. --- drivers/scsi/lpfc/lpfc_hbadisc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c index 4bb0a15cfcc0..54aff304cdcf 100644 --- a/drivers/scsi/lpfc/lpfc_hbadisc.c +++ b/drivers/scsi/lpfc/lpfc_hbadisc.c @@ -6954,7 +6954,9 @@ lpfc_unregister_fcf_rescan(struct lpfc_hba *phba) if (rc) return; /* Reset HBA FCF states after successful unregister FCF */ + spin_lock_irq(&phba->hbalock); phba->fcf.fcf_flag = 0; + spin_unlock_irq(&phba->hbalock); phba->fcf.current_rec.flag = 0; /* -- 2.34.1

7 hours, 22 minutes

1
1
0 0

+ lib-iov_iter-fix-to-increase-non-slab-folio-refcount.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: lib/iov_iter: fix to increase non slab folio refcount has been added to the -mm mm-hotfixes-unstable branch. Its filename is lib-iov_iter-fix-to-increase-non-slab-folio-refcount.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: Sheng Yong <shengyong1(a)xiaomi.com> Subject: lib/iov_iter: fix to increase non slab folio refcount Date: Tue, 1 Apr 2025 22:47:12 +0800 When testing EROFS file-backed mount over v9fs on qemu, I encountered a folio UAF issue. The page sanity check reports the following call trace. The root cause is that pages in bvec are coalesced across a folio bounary. The refcount of all non-slab folios should be increased to ensure p9_releas_pages can put them correctly. BUG: Bad page state in process md5sum pfn:18300 page: refcount:0 mapcount:0 mapping:00000000d5ad8e4e index:0x60 pfn:0x18300 head: order:0 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 aops:z_erofs_aops ino:30b0f dentry name(?):"GoogleExtServicesCn.apk" flags: 0x100000000000041(locked|head|node=0|zone=1) raw: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0 raw: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000 head: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0 head: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000 head: 0100000000000000 0000000000000000 ffffffffffffffff 0000000000000000 head: 0000000000000010 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Call Trace: dump_stack_lvl+0x53/0x70 bad_page+0xd4/0x220 __free_pages_ok+0x76d/0xf30 __folio_put+0x230/0x320 p9_release_pages+0x179/0x1f0 p9_virtio_zc_request+0xa2a/0x1230 p9_client_zc_rpc.constprop.0+0x247/0x700 p9_client_read_once+0x34d/0x810 p9_client_read+0xf3/0x150 v9fs_issue_read+0x111/0x360 netfs_unbuffered_read_iter_locked+0x927/0x1390 netfs_unbuffered_read_iter+0xa2/0xe0 vfs_iocb_iter_read+0x2c7/0x460 erofs_fileio_rq_submit+0x46b/0x5b0 z_erofs_runqueue+0x1203/0x21e0 z_erofs_readahead+0x579/0x8b0 read_pages+0x19f/0xa70 page_cache_ra_order+0x4ad/0xb80 filemap_readahead.isra.0+0xe7/0x150 filemap_get_pages+0x7aa/0x1890 filemap_read+0x320/0xc80 vfs_read+0x6c6/0xa30 ksys_read+0xf9/0x1c0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x71/0x79 Link: https://lkml.kernel.org/r/20250401144712.1377719-1-shengyong1@xiaomi.com Fixes: b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page") Signed-off-by: Sheng Yong <shengyong1(a)xiaomi.com> Reviewed-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/iov_iter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/lib/iov_iter.c~lib-iov_iter-fix-to-increase-non-slab-folio-refcount +++ a/lib/iov_iter.c @@ -1191,7 +1191,7 @@ static ssize_t __iov_iter_get_pages_allo return -ENOMEM; p = *pages; for (int k = 0; k < n; k++) { - struct folio *folio = page_folio(page); + struct folio *folio = page_folio(page + k); p[k] = page + k; if (!folio_test_slab(folio)) folio_get(folio); _ Patches currently in -mm which might be from shengyong1(a)xiaomi.com are lib-iov_iter-fix-to-increase-non-slab-folio-refcount.patch

7 hours, 29 minutes

1
0
0 0

[PATCH 5.15 v2 00/10] KVM: arm64: Backport of SVE fixes to v5.15

by Mark Brown

This series backports some recent fixes for SVE/KVM interactions from Mark Rutland to v5.15. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Changes in v2: - Resend with Greg and the stable list added. - Link to v1: https://lore.kernel.org/r/20250402-stable-sve-5-15-v1-0-84d0e5ff1102@kernel… --- Fuad Tabba (1): KVM: arm64: Calculate cptr_el2 traps on activating traps Marc Zyngier (1): KVM: arm64: Get rid of host SVE tracking/saving Mark Brown (4): KVM: arm64: Discard any SVE state when entering KVM guests arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE arm64/fpsimd: Have KVM explicitly say which FP registers to save arm64/fpsimd: Stop using TIF_SVE to manage register saving in KVM Mark Rutland (4): KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state KVM: arm64: Remove host FPSIMD saving for non-protected KVM KVM: arm64: Remove VHE host restore of CPACR_EL1.ZEN KVM: arm64: Eagerly switch ZCR_EL{1,2} arch/arm64/include/asm/fpsimd.h | 4 +- arch/arm64/include/asm/kvm_host.h | 17 +++-- arch/arm64/include/asm/kvm_hyp.h | 7 ++ arch/arm64/include/asm/processor.h | 7 ++ arch/arm64/kernel/fpsimd.c | 117 +++++++++++++++++++++++--------- arch/arm64/kernel/process.c | 3 + arch/arm64/kernel/ptrace.c | 3 + arch/arm64/kernel/signal.c | 3 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/fpsimd.c | 72 +++++++++----------- arch/arm64/kvm/hyp/entry.S | 5 ++ arch/arm64/kvm/hyp/include/hyp/switch.h | 86 +++++++++++++++-------- arch/arm64/kvm/hyp/nvhe/hyp-main.c | 9 ++- arch/arm64/kvm/hyp/nvhe/switch.c | 52 +++++++++----- arch/arm64/kvm/hyp/vhe/switch.c | 4 ++ arch/arm64/kvm/reset.c | 3 + 16 files changed, 266 insertions(+), 127 deletions(-) --- base-commit: 0c935c049b5c196b83b968c72d348ae6fff83ea2 change-id: 20250326-stable-sve-5-15-bfd75482dcfa Best regards, -- Mark Brown <broonie(a)kernel.org>

11 hours, 30 minutes

1
10
0 0

[for-linus][PATCH 4/4] ring-buffer: Use flush_kernel_vmap_range() over flush_dcache_folio()

by Steven Rostedt

From: Steven Rostedt <rostedt(a)goodmis.org> Some architectures do not have data cache coherency between user and kernel space. For these architectures, the cache needs to be flushed on both the kernel and user addresses so that user space can see the updates the kernel has made. Instead of using flush_dcache_folio() and playing with virt_to_folio() within the call to that function, use flush_kernel_vmap_range() which takes the virtual address and does the work for those architectures that need it. This also fixes a bug where the flush of the reader page only flushed one page. If the sub-buffer order is 1 or more, where the sub-buffer size would be greater than a page, it would miss the rest of the sub-buffer content, as the "reader page" is not just a page, but the size of a sub-buffer. Link: https://lore.kernel.org/all/CAG48ez3w0my4Rwttbc5tEbNsme6tc0mrSN95thjXUFaJ3a… Cc: stable(a)vger.kernel.org Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Vincent Donnefort <vdonnefort(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Mike Rapoport <rppt(a)kernel.org> Link: https://lore.kernel.org/20250402144953.920792197@goodmis.org Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions"); Suggested-by: Jann Horn <jannh(a)google.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ring_buffer.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index f25966b3a1fc..d4b0f7b55cce 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -6016,7 +6016,7 @@ static void rb_update_meta_page(struct ring_buffer_per_cpu *cpu_buffer) meta->read = cpu_buffer->read; /* Some archs do not have data cache coherency between kernel and user-space */ - flush_dcache_folio(virt_to_folio(cpu_buffer->meta_page)); + flush_kernel_vmap_range(cpu_buffer->meta_page, PAGE_SIZE); } static void @@ -7319,7 +7319,8 @@ int ring_buffer_map_get_reader(struct trace_buffer *buffer, int cpu) out: /* Some archs do not have data cache coherency between kernel and user-space */ - flush_dcache_folio(virt_to_folio(cpu_buffer->reader_page->page)); + flush_kernel_vmap_range(cpu_buffer->reader_page->page, + buffer->subbuf_size + BUF_PAGE_HDR_SIZE); rb_update_meta_page(cpu_buffer); -- 2.47.2

11 hours, 53 minutes

1
0
0 0

[PATCH v4] usb: dwc3: gadget: check that event count does not exceed event buffer length

by Frode Isaksen

From: Frode Isaksen <frode(a)meta.com> The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34 Signed-off-by: Frode Isaksen <frode(a)meta.com> Fixes: ebbb2d59398f ("usb: dwc3: gadget: use evt->cache for processing events") Cc: stable(a)vger.kernel.org --- v1 -> v2: Added Fixes and Cc tag. v2 -> v3: Added error log v3 -> v4: Rate limit error log drivers/usb/dwc3/gadget.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 89a4dc8ebf94..b75b4c5ca7fc 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -4564,6 +4564,12 @@ static irqreturn_t dwc3_check_event_buf(struct dwc3_event_buffer *evt) if (!count) return IRQ_NONE; + if (count > evt->length) { + dev_err_ratelimited(dwc->dev, "invalid count(%u) > evt->length(%u)\n", + count, evt->length); + return IRQ_NONE; + } + evt->count = count; evt->flags |= DWC3_EVENT_PENDING; -- 2.49.0

12 hours, 20 minutes

2
1
0 0

[PATCH v2] usb: dwc3: gadget: check that event count does not exceed event buffer length

by Frode Isaksen

From: Frode Isaksen <frode(a)meta.com> The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34 Signed-off-by: Frode Isaksen <frode(a)meta.com> Fixes: ebbb2d59398f ("usb: dwc3: gadget: use evt->cache for processing events") Cc: stable(a)vger.kernel.org --- v1 -> v2: Added Fixes and Cc tag. This bug was discovered, tested and fixed (no more crashes seen) on Meta Quest 3 device. Also tested on T.I. AM62x board. drivers/usb/dwc3/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 63fef4a1a498..548e112167f3 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -4564,7 +4564,7 @@ static irqreturn_t dwc3_check_event_buf(struct dwc3_event_buffer *evt) count = dwc3_readl(dwc->regs, DWC3_GEVNTCOUNT(0)); count &= DWC3_GEVNTCOUNT_MASK; - if (!count) + if (!count || count > evt->length) return IRQ_NONE; evt->count = count; -- 2.48.1

12 hours, 28 minutes

3
7
0 0

[PATCH] x86/ioremap: Maintain consistent IORES_MAP_ENCRYPTED for BIOS data

by Dan Williams

Nikolay reports [1] that accessing BIOS data (first 1MB of the physical address space) via /dev/mem results in an SEPT violation. The cause is ioremap() (via xlate_dev_mem_ptr()) establishing an unencrypted mapping where the kernel had established an encrypted mapping previously. Teach __ioremap_check_other() that this address space shall always be mapped as encrypted as historically it is memory resident data, not MMIO with side-effects. Cc: <x86(a)kernel.org> Cc: Vishal Annapurve <vannapurve(a)google.com> Cc: Kirill Shutemov <kirill.shutemov(a)linux.intel.com> Reported-by: Nikolay Borisov <nik.borisov(a)suse.com> Closes: http://lore.kernel.org/20250318113604.297726-1-nik.borisov@suse.com [1] Tested-by: Nikolay Borisov <nik.borisov(a)suse.com> Fixes: 9aa6ea69852c ("x86/tdx: Make pages shared in ioremap()") Cc: <stable(a)vger.kernel.org> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- arch/x86/mm/ioremap.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 42c90b420773..9e81286a631e 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -122,6 +122,10 @@ static void __ioremap_check_other(resource_size_t addr, struct ioremap_desc *des return; } + /* Ensure BIOS data (see devmem_is_allowed()) is consistently mapped */ + if (PHYS_PFN(addr) < 256) + desc->flags |= IORES_MAP_ENCRYPTED; + if (!IS_ENABLED(CONFIG_EFI)) return;

13 hours, 14 minutes

6
9
0 0

[PATCH 6.6.y 0/6] Backported patches to fix selftest tpdir2

by Kang Wenlin

From: Wenlin Kang <wenlin.kang(a)windriver.com> The selftest tpdir2 terminated with a 'Segmentation fault' during loading. root@localhost:~# cd linux-kenel/tools/testing/selftests/arm64/abi && make root@localhost:~/linux-kernel/tools/testing/selftests/arm64/abi# ./tpidr2 Segmentation fault The cause of this is the __arch_clear_user() failure. load_elf_binary() [fs/binfmt_elf.c] -> if (likely(elf_bss != elf_brk) && unlikely(padzero(elf_bes))) -> padzero() -> clear_user() [arch/arm64/include/asm/uaccess.h] -> __arch_clear_user() [arch/arm64/lib/clear_user.S] For more details, please see: https://lore.kernel.org/lkml/1d0342f3-0474-482b-b6db-81ca7820a462@t-8ch.de/… This issue has been fixed in the mainline. Here I have backported the relevant commits for the linux-6.6.y branch and attached them. With these patches, tpdir2 works as: root@localhost:~/linux-kernel/tools/testing/selftests/arm64/abi# ./tpidr2 TAP version 13 1..5 ok 0 skipped, TPIDR2 not supported ok 1 skipped, TPIDR2 not supported ok 2 skipped, TPIDR2 not supported ok 3 skipped, TPIDR2 not supported ok 4 skipped, TPIDR2 not supported This issue is resolved by the first patch. However, to ensure functional completeness, all related patches were backported according to the following link. https://lore.kernel.org/all/20230929031716.it.155-kees@kernel.org/#t Eric W. Biederman (1): binfmt_elf: Support segments with 0 filesz and misaligned starts Kees Cook (5): binfmt_elf: elf_bss no longer used by load_elf_binary() binfmt_elf: Use elf_load() for interpreter binfmt_elf: Use elf_load() for library binfmt_elf: Only report padzero() errors when PROT_WRITE mm: Remove unused vm_brk() fs/binfmt_elf.c | 215 ++++++++++++++++----------------------------- include/linux/mm.h | 3 +- mm/mmap.c | 6 -- mm/nommu.c | 5 -- 4 files changed, 76 insertions(+), 153 deletions(-) -- 2.43.0

13 hours, 25 minutes

2
12
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025