July 2025 - Linux-stable-mirror

[REGRESSION] Linux 6.15.1 xen/dom0 domain_crash_sync called from entry.S

by Chuck Zmudzinski

Hi, I am seeing the following regression between Linux 6.14.8 and 6.15.1. Kernel version 6.14.8 boots fine but version 6.15.1 crashes and reboots on Xen. I don't know if 6.14.9 or 6.14.10 is affected, or if 6.15 or the 6.15 release candidates are affected because I did not test them. Also, Linux 6.15.1 boots fine on bare metal without Xen. Hardware: Intel i5-14500 Raptor Lake CPU, and ASRock B760M PG motherboard and 32 GB RAM. Xen version: 4.19.2 (mockbuild(a)dynavirt.com) (gcc (GCC) 13.3.1 20240611 (Red Hat 13.3.1-2)) debug=n Sun Apr 13 15:24:29 PDT 2025 Xen Command line: placeholder dom0_mem=2G,max:2G conring_size=32k com1=9600,8n1,0x40c0,16,1:0.0 console=com1 Linux version 6.15.1-1.el9.elrepo.x86_64 (mockbuild@5b7a5dab3b71429898b4f8474fab8fa0) (gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), GNU ld version 2.35.2-63.el9) #1 SMP PREEMPT_DYNAMIC Wed Jun 4 16:42:58 EDT 2025 Linux Kernel Command line: placeholder root=/dev/mapper/systems-rootalma ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=UUID=2ddc2e3b-8f7b-498b-a4e8-bb4d33a1e5a7 console=hvc0 The Linux 6.15.1 dom0 kernel causes Xen to crash and reboot, here are the last messages on the serial console (includes messages from both dom0 and Xen) before crash: [ 0.301573] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl [ 0.301577] Register File Data Sampling: Vulnerable: No microcode [ 0.301581] ITS: Mitigation: Aligned branch/return thunks [ 0.301594] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [ 0.301598] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 0.301602] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 0.301605] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 0.301609] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. (XEN) Pagetable walk from ffffc9003ffffff8: (XEN) L4[0x192] = 0000000855bee067 0000000000060e56 (XEN) L3[0x000] = 0000000855bed067 0000000000060e55 (XEN) L2[0x1ff] = 0000000855bf0067 0000000000060e58 (XEN) L1[0x1ff] = 8010000855bf2025 0000000000060e5a (XEN) domain_crash_sync called from entry.S: fault at ffff82d04036e5b0 x86_64/entry.S#domain_crash_page_fault_6x8+0/0x4 (XEN) Domain 0 (vcpu#0) crashed on cpu#11: (XEN) ----[ Xen-4.19.2 x86_64 debug=n Not tainted ]---- (XEN) CPU: 11 (XEN) RIP: e033:[<ffffffff810014fe>] (XEN) RFLAGS: 0000000000010206 EM: 1 CONTEXT: pv guest (d0v0) (XEN) rax: ffffffff81fb12d0 rbx: 000000000000029a rcx: 000000000000000c (XEN) rdx: 000000000000029a rsi: ffffffff81000b99 rdi: ffffc900400000f0 (XEN) rbp: 000000000000014d rsp: ffffc90040000000 r8: 0000000000000f9c (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 000000000000000c r13: ffffffff82771530 r14: ffffffff827724cc (XEN) r15: ffffc900400000f0 cr0: 0000000080050033 cr4: 0000000000b526e0 (XEN) cr3: 000000086ae24000 cr2: ffffc9003ffffff8 (XEN) fsb: 0000000000000000 gsb: ffff88819ac55000 gss: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffc90040000000: (XEN) Stack empty. (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. I searched mailing lists but could not find a report similar to what I am seeing here. I don't know what to try except to git bisect, but I have not done that yet. Chuck Zmudzinski

2 weeks, 4 days

3
3
0 0

6.12.y longterm regression - IPv6 UDP packet fragmentation

by Brett Sheffield

Hello Stable Maintainers, Longterm kernel 6.12.y backports commit: - a18dfa9925b9ef6107ea3aa5814ca3c704d34a8a "ipv6: save dontfrag in cork" but does not backport these related commits: - 54580ccdd8a9c6821fd6f72171d435480867e4c3 "ipv6: remove leftover ip6 cookie initializer" - 096208592b09c2f5fc0c1a174694efa41c04209d "ipv6: replace ipcm6_init calls with ipcm6_init_sk" This causes a regression when sending IPv6 UDP packets by preventing fragmentation and instead returning EMSGSIZE. I have attached a program which demonstrates the issue. sendmsg() returns correctly (8192) on a working kernel, and returns -1 (EMSGSIZE) when the regression is present. The regression is not present in the mainline kernel. Applying the two missing commits to 6.12.y fixes the regression. Cheers, Brett -- Brett Sheffield (he/him) Librecast - Decentralising the Internet with Multicast https://librecast.net/ https://blog.brettsheffield.com/

2 weeks, 4 days

6
14
0 0

[PATCH 5.15.y] xen: replace xen_remap() with memremap()

by Teddy Astie

From: Juergen Gross <jgross(a)suse.com> [ upstream commit 41925b105e345ebc84cedb64f59d20cb14a62613 ] xen_remap() is used to establish mappings for frames not under direct control of the kernel: for Xenstore and console ring pages, and for grant pages of non-PV guests. Today xen_remap() is defined to use ioremap() on x86 (doing uncached mappings), and ioremap_cache() on Arm (doing cached mappings). Uncached mappings for those use cases are bad for performance, so they should be avoided if possible. As all use cases of xen_remap() don't require uncached mappings (the mapped area is always physical RAM), a mapping using the standard WB cache mode is fine. As sparse is flagging some of the xen_remap() use cases to be not appropriate for iomem(), as the result is not annotated with the __iomem modifier, eliminate xen_remap() completely and replace all use cases with memremap() specifying the MEMREMAP_WB caching mode. xen_unmap() can be replaced with memunmap(). Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Acked-by: Stefano Stabellini <sstabellini(a)kernel.org> Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Teddy Astie <teddy.astie(a)vates.tech> [backport to 5.15.y] --- arch/x86/include/asm/xen/page.h | 3 --- drivers/xen/grant-table.c | 6 +++--- drivers/xen/xenbus/xenbus_probe.c | 3 +-- 3 files changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h index 1a162e559753..c183b7f9efef 100644 --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -355,9 +355,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr); void make_lowmem_page_readonly(void *vaddr); void make_lowmem_page_readwrite(void *vaddr); -#define xen_remap(cookie, size) ioremap((cookie), (size)) -#define xen_unmap(cookie) iounmap((cookie)) - static inline bool xen_arch_need_swiotlb(struct device *dev, phys_addr_t phys, dma_addr_t dev_addr) diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 0a2d24d6ac6f..a10e0741bec5 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -743,7 +743,7 @@ int gnttab_setup_auto_xlat_frames(phys_addr_t addr) if (xen_auto_xlat_grant_frames.count) return -EINVAL; - vaddr = xen_remap(addr, XEN_PAGE_SIZE * max_nr_gframes); + vaddr = memremap(addr, XEN_PAGE_SIZE * max_nr_gframes, MEMREMAP_WB); if (vaddr == NULL) { pr_warn("Failed to ioremap gnttab share frames (addr=%pa)!\n", &addr); @@ -751,7 +751,7 @@ int gnttab_setup_auto_xlat_frames(phys_addr_t addr) } pfn = kcalloc(max_nr_gframes, sizeof(pfn[0]), GFP_KERNEL); if (!pfn) { - xen_unmap(vaddr); + memunmap(vaddr); return -ENOMEM; } for (i = 0; i < max_nr_gframes; i++) @@ -770,7 +770,7 @@ void gnttab_free_auto_xlat_frames(void) if (!xen_auto_xlat_grant_frames.count) return; kfree(xen_auto_xlat_grant_frames.pfn); - xen_unmap(xen_auto_xlat_grant_frames.vaddr); + memunmap(xen_auto_xlat_grant_frames.vaddr); xen_auto_xlat_grant_frames.pfn = NULL; xen_auto_xlat_grant_frames.count = 0; diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c index 2068f83556b7..77ca24611293 100644 --- a/drivers/xen/xenbus/xenbus_probe.c +++ b/drivers/xen/xenbus/xenbus_probe.c @@ -982,8 +982,7 @@ static int __init xenbus_init(void) #endif xen_store_gfn = (unsigned long)v; xen_store_interface = - xen_remap(xen_store_gfn << XEN_PAGE_SHIFT, - XEN_PAGE_SIZE); + memremap(xen_store_gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE, MEMREMAP_WB); break; default: pr_warn("Xenstore state unknown\n"); -- 2.50.0 Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech

2 weeks, 4 days

2
1
0 0

[PATCH 5.15.y v2] xen: replace xen_remap() with memremap()

by Teddy Astie

From: Juergen Gross <jgross(a)suse.com> [ upstream commit 41925b105e345ebc84cedb64f59d20cb14a62613 ] xen_remap() is used to establish mappings for frames not under direct control of the kernel: for Xenstore and console ring pages, and for grant pages of non-PV guests. Today xen_remap() is defined to use ioremap() on x86 (doing uncached mappings), and ioremap_cache() on Arm (doing cached mappings). Uncached mappings for those use cases are bad for performance, so they should be avoided if possible. As all use cases of xen_remap() don't require uncached mappings (the mapped area is always physical RAM), a mapping using the standard WB cache mode is fine. As sparse is flagging some of the xen_remap() use cases to be not appropriate for iomem(), as the result is not annotated with the __iomem modifier, eliminate xen_remap() completely and replace all use cases with memremap() specifying the MEMREMAP_WB caching mode. xen_unmap() can be replaced with memunmap(). Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Acked-by: Stefano Stabellini <sstabellini(a)kernel.org> Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Teddy Astie <teddy.astie(a)vates.tech> [backport to 5.15.y] --- v2: - also remove xen_remap/xen_unmap on ARM --- arch/x86/include/asm/xen/page.h | 3 --- drivers/xen/grant-table.c | 6 +++--- drivers/xen/xenbus/xenbus_probe.c | 3 +-- include/xen/arm/page.h | 3 --- 4 files changed, 4 insertions(+), 11 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h index 1a162e559753..c183b7f9efef 100644 --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -355,9 +355,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr); void make_lowmem_page_readonly(void *vaddr); void make_lowmem_page_readwrite(void *vaddr); -#define xen_remap(cookie, size) ioremap((cookie), (size)) -#define xen_unmap(cookie) iounmap((cookie)) - static inline bool xen_arch_need_swiotlb(struct device *dev, phys_addr_t phys, dma_addr_t dev_addr) diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 0a2d24d6ac6f..a10e0741bec5 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -743,7 +743,7 @@ int gnttab_setup_auto_xlat_frames(phys_addr_t addr) if (xen_auto_xlat_grant_frames.count) return -EINVAL; - vaddr = xen_remap(addr, XEN_PAGE_SIZE * max_nr_gframes); + vaddr = memremap(addr, XEN_PAGE_SIZE * max_nr_gframes, MEMREMAP_WB); if (vaddr == NULL) { pr_warn("Failed to ioremap gnttab share frames (addr=%pa)!\n", &addr); @@ -751,7 +751,7 @@ int gnttab_setup_auto_xlat_frames(phys_addr_t addr) } pfn = kcalloc(max_nr_gframes, sizeof(pfn[0]), GFP_KERNEL); if (!pfn) { - xen_unmap(vaddr); + memunmap(vaddr); return -ENOMEM; } for (i = 0; i < max_nr_gframes; i++) @@ -770,7 +770,7 @@ void gnttab_free_auto_xlat_frames(void) if (!xen_auto_xlat_grant_frames.count) return; kfree(xen_auto_xlat_grant_frames.pfn); - xen_unmap(xen_auto_xlat_grant_frames.vaddr); + memunmap(xen_auto_xlat_grant_frames.vaddr); xen_auto_xlat_grant_frames.pfn = NULL; xen_auto_xlat_grant_frames.count = 0; diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c index 2068f83556b7..77ca24611293 100644 --- a/drivers/xen/xenbus/xenbus_probe.c +++ b/drivers/xen/xenbus/xenbus_probe.c @@ -982,8 +982,7 @@ static int __init xenbus_init(void) #endif xen_store_gfn = (unsigned long)v; xen_store_interface = - xen_remap(xen_store_gfn << XEN_PAGE_SHIFT, - XEN_PAGE_SIZE); + memremap(xen_store_gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE, MEMREMAP_WB); break; default: pr_warn("Xenstore state unknown\n"); diff --git a/include/xen/arm/page.h b/include/xen/arm/page.h index ac1b65470563..f831cfeca000 100644 --- a/include/xen/arm/page.h +++ b/include/xen/arm/page.h @@ -109,9 +109,6 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn) return __set_phys_to_machine(pfn, mfn); } -#define xen_remap(cookie, size) ioremap_cache((cookie), (size)) -#define xen_unmap(cookie) iounmap((cookie)) - bool xen_arch_need_swiotlb(struct device *dev, phys_addr_t phys, dma_addr_t dev_addr); -- 2.50.0 Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech

2 weeks, 4 days

2
1
0 0

[PATCH 5.15.y] jfs: fix null ptr deref in dtInsertEntry

by Aditya Dutt

From: Edward Adam Davis <eadavis(a)qq.com> [ Upstream commit ce6dede912f064a855acf6f04a04cbb2c25b8c8c ] [syzbot reported] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713 ... [Analyze] In dtInsertEntry(), when the pointer h has the same value as p, after writing name in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the previously true judgment "p->header.flag & BT-LEAF" to change to no after writing the name operation, this leads to entering an incorrect branch and accessing the uninitialized object ih when judging this condition for the second time. [Fix] After got the page, check freelist first, if freelist == 0 then exit dtInsert() and return -EINVAL. Closes: https://syzkaller.appspot.com/bug?extid=30b3e48dc48dd2ad45b6 Reported-by: syzbot+30b3e48dc48dd2ad45b6(a)syzkaller.appspotmail.com Reported-by: syzbot+bba84aef3a26fb93deb9(a)syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis(a)qq.com> Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com> Signed-off-by: Aditya Dutt <duttaditya18(a)gmail.com> --- I tested the patch manually using the C reproducer: https://syzkaller.appspot.com/text?tag=ReproC&x=135c9b70580000 given in the syzkaller dashboard above. fs/jfs/jfs_dtree.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c index 27ca98614b0b..cb57d4f1161f 100644 --- a/fs/jfs/jfs_dtree.c +++ b/fs/jfs/jfs_dtree.c @@ -835,6 +835,8 @@ int dtInsert(tid_t tid, struct inode *ip, * the full page. */ DT_GETSEARCH(ip, btstack->top, bn, mp, p, index); + if (p->header.freelist == 0) + return -EINVAL; /* * insert entry for new key -- 2.34.1

2 weeks, 4 days

2
1
0 0

[PATCH v2] crypto: s390/sha - Fix uninitialized variable in SHA-1 and SHA-2

by Eric Biggers

Commit 88c02b3f79a6 ("s390/sha3: Support sha3 performance enhancements") added the field s390_sha_ctx::first_message_part and made it be used by s390_sha_update() (now s390_sha_update_blocks()). At the time, s390_sha_update() was used by all the s390 SHA-1, SHA-2, and SHA-3 algorithms. However, only the initialization functions for SHA-3 were updated, leaving SHA-1 and SHA-2 using first_message_part uninitialized. This could cause e.g. the function code CPACF_KIMD_SHA_512 | CPACF_KIMD_NIP to be used instead of just CPACF_KIMD_SHA_512. This apparently was harmless, as the SHA-1 and SHA-2 function codes ignore CPACF_KIMD_NIP; it is recognized only by the SHA-3 function codes (https://lore.kernel.org/r/73477fe9-a1dc-4e38-98a6-eba9921e8afa@linux.ibm.co…). Therefore, this bug was found only when first_message_part was later converted to a boolean and UBSAN detected its uninitialized use. Regardless, let's fix this by just initializing to zero. Note: in 6.16, we need to patch SHA-1, SHA-384, and SHA-512. In 6.15 and earlier, we'll also need to patch SHA-224 and SHA-256, as they hadn't yet been librarified (which incidentally fixed this bug). Fixes: 88c02b3f79a6 ("s390/sha3: Support sha3 performance enhancements") Cc: stable(a)vger.kernel.org Reported-by: Ingo Franzki <ifranzki(a)linux.ibm.com> Closes: https://lore.kernel.org/r/12740696-595c-4604-873e-aefe8b405fbf@linux.ibm.com Acked-by: Heiko Carstens <hca(a)linux.ibm.com> Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- v2: - Also fix s390_sha1_import() and sha512_import() - Use 0 instead of false - Improved commit message arch/s390/crypto/sha1_s390.c | 2 ++ arch/s390/crypto/sha512_s390.c | 3 +++ 2 files changed, 5 insertions(+) diff --git a/arch/s390/crypto/sha1_s390.c b/arch/s390/crypto/sha1_s390.c index d229cbd2ba229..9b0d55be12394 100644 --- a/arch/s390/crypto/sha1_s390.c +++ b/arch/s390/crypto/sha1_s390.c @@ -36,10 +36,11 @@ static int s390_sha1_init(struct shash_desc *desc) sctx->state[2] = SHA1_H2; sctx->state[3] = SHA1_H3; sctx->state[4] = SHA1_H4; sctx->count = 0; sctx->func = CPACF_KIMD_SHA_1; + sctx->first_message_part = 0; return 0; } static int s390_sha1_export(struct shash_desc *desc, void *out) @@ -58,10 +59,11 @@ static int s390_sha1_import(struct shash_desc *desc, const void *in) const struct sha1_state *ictx = in; sctx->count = ictx->count; memcpy(sctx->state, ictx->state, sizeof(ictx->state)); sctx->func = CPACF_KIMD_SHA_1; + sctx->first_message_part = 0; return 0; } static struct shash_alg alg = { .digestsize = SHA1_DIGEST_SIZE, diff --git a/arch/s390/crypto/sha512_s390.c b/arch/s390/crypto/sha512_s390.c index 33711a29618c3..6cbbf5e8555f8 100644 --- a/arch/s390/crypto/sha512_s390.c +++ b/arch/s390/crypto/sha512_s390.c @@ -30,10 +30,11 @@ static int sha512_init(struct shash_desc *desc) ctx->sha512.state[6] = SHA512_H6; ctx->sha512.state[7] = SHA512_H7; ctx->count = 0; ctx->sha512.count_hi = 0; ctx->func = CPACF_KIMD_SHA_512; + ctx->first_message_part = 0; return 0; } static int sha512_export(struct shash_desc *desc, void *out) @@ -55,10 +56,11 @@ static int sha512_import(struct shash_desc *desc, const void *in) sctx->count = ictx->count[0]; sctx->sha512.count_hi = ictx->count[1]; memcpy(sctx->state, ictx->state, sizeof(ictx->state)); sctx->func = CPACF_KIMD_SHA_512; + sctx->first_message_part = 0; return 0; } static struct shash_alg sha512_alg = { .digestsize = SHA512_DIGEST_SIZE, @@ -95,10 +97,11 @@ static int sha384_init(struct shash_desc *desc) ctx->sha512.state[6] = SHA384_H6; ctx->sha512.state[7] = SHA384_H7; ctx->count = 0; ctx->sha512.count_hi = 0; ctx->func = CPACF_KIMD_SHA_512; + ctx->first_message_part = 0; return 0; } static struct shash_alg sha384_alg = { base-commit: 64f7548aad63d2fbca2eeb6eb33361c218ebd5a5 -- 2.50.0

2 weeks, 4 days

1
0
0 0

[REGRESSION] stable-rc/linux-6.6.y: (build) call to undeclared function 'FIELD_GET'; ISO C99 and later do not ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.6.y: --- call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] in drivers/hwtracing/coresight/coresight-core.o (drivers/hwtracing/coresight/coresight-core.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:82b0ad35fbcaafb1583fddab63ee2110454491ce - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: cd39aa2833d237e301befa5db1902e33872ba3c7 Log excerpt: ===================================================== drivers/hwtracing/coresight/coresight-core.c:138:9: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 138 | return FIELD_GET(CORESIGHT_CLAIM_MASK, | ^ 1 error generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:6866682c5c2cf25042fae1f6 #kernelci issue maestro:82b0ad35fbcaafb1583fddab63ee2110454491ce Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

2 weeks, 4 days

1
0
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) ./include/linux/regulator/consumer.h:613:51: warning: declaration ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- ./include/linux/regulator/consumer.h:613:51: warning: declaration of 'struct regulator_dev' will not be visible outside of this function [-Wvisibility] in drivers/ata/ahci.o (drivers/ata/ahci.h) [logspec:kbuild,kbuild.compiler.warning] --- - dashboard: https://d.kernelci.org/i/maestro:e328869b26a76c83d9b30c60ae3469908d116c3f - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: f4010b99ef529ae2ba2db6f124d91a187d5e23ed Log excerpt: ===================================================== In file included from drivers/ata/ahci.h:25: In file included from ./include/linux/phy/phy.h:17: ./include/linux/regulator/consumer.h:613:51: warning: declaration of 'struct regulator_dev' will not be visible outside of this function [-Wvisibility] 613 | static inline int regulator_suspend_enable(struct regulator_dev *rdev, | ^ ./include/linux/regulator/consumer.h:614:9: error: unknown type name 'suspend_state_t' 614 | suspend_state_t state) | ^ ./include/linux/regulator/consumer.h:619:52: warning: declaration of 'struct regulator_dev' will not be visible outside of this function [-Wvisibility] 619 | static inline int regulator_suspend_disable(struct regulator_dev *rdev, | ^ ./include/linux/regulator/consumer.h:620:10: error: unknown type name 'suspend_state_t' 620 | suspend_state_t state) | ^ ./include/linux/regulator/consumer.h:627:7: error: unknown type name 'suspend_state_t' 627 | suspend_state_t state) | ^ 2 warnings and 3 errors generated. ===================================================== # Builds where the incident occurred: ## x86_64_defconfig on (x86_64): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:68669dc85c2cf25042fb8139 #kernelci issue maestro:e328869b26a76c83d9b30c60ae3469908d116c3f Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

2 weeks, 4 days

1
0
0 0

[PATCH] regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods

by Manivannan Sadhasivam

drvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. But the memory is allocated for only one pointer. This will lead to out-of-bounds access later in the code if 'config::ngpios' is > 1. So fix the code to allocate enough memory to hold 'config::ngpios' of GPIO descriptors. While at it, also move the check for memory allocation failure to be below the allocation to make it more readable. Cc: stable(a)vger.kernel.org # 5.0 Fixes: d6cd33ad7102 ("regulator: gpio: Convert to use descriptors") Signed-off-by: Manivannan Sadhasivam <mani(a)kernel.org> --- drivers/regulator/gpio-regulator.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c index 75bd53445ba7..6351ceefdb3e 100644 --- a/drivers/regulator/gpio-regulator.c +++ b/drivers/regulator/gpio-regulator.c @@ -260,8 +260,10 @@ static int gpio_regulator_probe(struct platform_device *pdev) return -ENOMEM; } - drvdata->gpiods = devm_kzalloc(dev, sizeof(struct gpio_desc *), - GFP_KERNEL); + drvdata->gpiods = devm_kcalloc(dev, config->ngpios, + sizeof(struct gpio_desc *), GFP_KERNEL); + if (!drvdata->gpiods) + return -ENOMEM; if (config->input_supply) { drvdata->desc.supply_name = devm_kstrdup(&pdev->dev, @@ -274,8 +276,6 @@ static int gpio_regulator_probe(struct platform_device *pdev) } } - if (!drvdata->gpiods) - return -ENOMEM; for (i = 0; i < config->ngpios; i++) { drvdata->gpiods[i] = devm_gpiod_get_index(dev, NULL, -- 2.45.2

2 weeks, 4 days

2
1
0 0

[PATCH 5.10] Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event

by Anastasia Belova

From: Sean Wang <sean.wang(a)mediatek.com> [ Upstream commit 0fab6361c4ba17d1b43a991bef4238a3c1754d35 ] We should not access skb buffer data anymore after hci_recv_frame was called. [ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0 [ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker [ 39.634962] Call trace: [ 39.634974] dump_backtrace+0x0/0x3b8 [ 39.634999] show_stack+0x20/0x2c [ 39.635016] dump_stack_lvl+0x60/0x78 [ 39.635040] print_address_description+0x70/0x2f0 [ 39.635062] kasan_report+0x154/0x194 [ 39.635079] __asan_report_load1_noabort+0x44/0x50 [ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4 [ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4 [ 39.635157] process_one_work+0x560/0xc5c [ 39.635177] worker_thread+0x7ec/0xcc0 [ 39.635195] kthread+0x2d0/0x3d0 [ 39.635215] ret_from_fork+0x10/0x20 [ 39.635247] Allocated by task 0: [ 39.635260] (stack is not available) [ 39.635281] Freed by task 2392: [ 39.635295] kasan_save_stack+0x38/0x68 [ 39.635319] kasan_set_track+0x28/0x3c [ 39.635338] kasan_set_free_info+0x28/0x4c [ 39.635357] ____kasan_slab_free+0x104/0x150 [ 39.635374] __kasan_slab_free+0x18/0x28 [ 39.635391] slab_free_freelist_hook+0x114/0x248 [ 39.635410] kfree+0xf8/0x2b4 [ 39.635427] skb_free_head+0x58/0x98 [ 39.635447] skb_release_data+0x2f4/0x410 [ 39.635464] skb_release_all+0x50/0x60 [ 39.635481] kfree_skb+0xc8/0x25c [ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth] [ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth] [ 39.635925] process_one_work+0x560/0xc5c [ 39.635951] worker_thread+0x7ec/0xcc0 [ 39.635970] kthread+0x2d0/0x3d0 [ 39.635990] ret_from_fork+0x10/0x20 [ 39.636021] The buggy address belongs to the object at ffffff80cf28a600 which belongs to the cache kmalloc-512 of size 512 [ 39.636039] The buggy address is located 13 bytes inside of 512-byte region [ffffff80cf28a600, ffffff80cf28a800) Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Co-developed-by: Yake Yang <yake.yang(a)mediatek.com> Signed-off-by: Yake Yang <yake.yang(a)mediatek.com> Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Anastasia Belova <abelova(a)astralinux.ru> --- Backport fix for CVE-2022-49470 drivers/bluetooth/btmtksdio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c index c41560be39fb..6b31ee1a1dd9 100644 --- a/drivers/bluetooth/btmtksdio.c +++ b/drivers/bluetooth/btmtksdio.c @@ -331,6 +331,7 @@ static int btmtksdio_recv_event(struct hci_dev *hdev, struct sk_buff *skb) { struct btmtksdio_dev *bdev = hci_get_drvdata(hdev); struct hci_event_hdr *hdr = (void *)skb->data; + u8 evt = hdr->evt; int err; /* Fix up the vendor event id with 0xff for vendor specific instead @@ -355,7 +356,7 @@ static int btmtksdio_recv_event(struct hci_dev *hdev, struct sk_buff *skb) if (err < 0) goto err_free_skb; - if (hdr->evt == HCI_EV_VENDOR) { + if (evt == HCI_EV_VENDOR) { if (test_and_clear_bit(BTMTKSDIO_TX_WAIT_VND_EVT, &bdev->tx_state)) { /* Barrier to sync with other CPUs */ -- 2.43.0

2 weeks, 4 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2025