November 2025 - Linux-stable-mirror

[PATCH 1/2] x86/amd_node: fix integer divide by zero during init

by Steven Noonan

On a Xen dom0 boot, this feature does not behave, and we end up calculating: num_roots = 1 num_nodes = 2 roots_per_node = 0 This causes a divide-by-zero in the modulus inside the loop. This change adds a couple of guards for invalid states where we might get a divide-by-zero. Signed-off-by: Steven Noonan <steven(a)uplinklabs.net> Signed-off-by: Ariadne Conill <ariadne(a)ariadne.space> CC: Yazen Ghannam <yazen.ghannam(a)amd.com> CC: x86(a)vger.kernel.org CC: stable(a)vger.kernel.org --- arch/x86/kernel/amd_node.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c index 3d0a4768d603c..cdc6ba224d4ad 100644 --- a/arch/x86/kernel/amd_node.c +++ b/arch/x86/kernel/amd_node.c @@ -282,6 +282,17 @@ static int __init amd_smn_init(void) return -ENODEV; num_nodes = amd_num_nodes(); + + if (!num_nodes) + return -ENODEV; + + /* Possibly a virtualized environment (e.g. Xen) where we wi ll get + * roots_per_node=0 if the number of roots is fewer than number of + * nodes + */ + if (num_roots < num_nodes) + return -ENODEV; + amd_roots = kcalloc(num_nodes, sizeof(*amd_roots), GFP_KERNEL); if (!amd_roots) return -ENOMEM; -- 2.51.2

14 hours, 20 minutes

3
7
0 0

[PATCH] drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors

by Luca Ceresoli

On hardware based on Toradex Verdin AM62 the recovery mechanism added by commit ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error recovery mechanism") has been reported [0] to make the display turn on and off and and the kernel logging "Unexpected link status 0x01". According to the report, the error recovery mechanism is triggered by the PLL_UNLOCK error going active. Analysis suggested the board is unable to provide the correct DSI clock neede by the SN65DSI84, to which the TI SN65DSI84 reacts by raising the PLL_UNLOCK, while the display still works apparently without issues. On other hardware, where all the clocks are within the components specifications, the PLL_UNLOCK bit does not trigger while the display is in normal use. It can trigger for e.g. electromagnetic interference, which is a transient event and exactly the reason why the error recovery mechanism has been implemented. Idelly the PLL_UNLOCK bit could be ignored when working out of specification, but this requires to detect in software whether it triggers because the device is working out of specification but visually correctly for the user or for good reasons (e.g. EMI, or even because working out of specifications but compromising the visual output). The ongoing analysis as of this writing [1][2] has not yet found a way for the driver to discriminate among the two cases. So as a temporary measure mask the PLL_UNLOCK error bit unconditionally. [0] https://lore.kernel.org/r/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsjsd… [1] https://lore.kernel.org/all/b71e941c-fc8a-4ac1-9407-0fe7df73b412@gmail.com/ [2] https://lore.kernel.org/all/20251125103900.31750-1-francesco@dolcini.it/ Closes: https://lore.kernel.org/r/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsjsd… Cc: stable(a)vger.kernel.org # 6.15+ Co-developed-by: Hervé Codina <herve.codina(a)bootlin.com> Signed-off-by: Hervé Codina <herve.codina(a)bootlin.com> Signed-off-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> --- Francesco, Emanuele, João: can you please apply this patch and report whether the display on the affected boards gets back to working as before? Cc: João Paulo Gonçalves <jpaulo.silvagoncalves(a)gmail.com> Cc: Francesco Dolcini <francesco(a)dolcini.it> Cc: Emanuele Ghidoli <ghidoliemanuele(a)gmail.com> --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 033c44326552..fffb47b62f43 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -429,7 +429,14 @@ static void sn65dsi83_handle_errors(struct sn65dsi83 *ctx) */ ret = regmap_read(ctx->regmap, REG_IRQ_STAT, &irq_stat); - if (ret || irq_stat) { + + /* + * Some hardware (Toradex Verdin AM62) is known to report the + * PLL_UNLOCK error interrupt while working without visible + * problems. In lack of a reliable way to discriminate such cases + * from user-visible PLL_UNLOCK cases, ignore that bit entirely. + */ + if (ret || irq_stat & ~REG_IRQ_STAT_CHA_PLL_UNLOCK) { /* * IRQ acknowledged is not always possible (the bridge can be in * a state where it doesn't answer anymore). To prevent an @@ -654,7 +661,7 @@ static void sn65dsi83_atomic_enable(struct drm_bridge *bridge, if (ctx->irq) { /* Enable irq to detect errors */ regmap_write(ctx->regmap, REG_IRQ_GLOBAL, REG_IRQ_GLOBAL_IRQ_EN); - regmap_write(ctx->regmap, REG_IRQ_EN, 0xff); + regmap_write(ctx->regmap, REG_IRQ_EN, 0xff & ~REG_IRQ_EN_CHA_PLL_UNLOCK_EN); } else { /* Use the polling task */ sn65dsi83_monitor_start(ctx); --- base-commit: c884ee70b15a8d63184d7c1e02eba99676a6fcf7 change-id: 20251126-drm-ti-sn65dsi83-ignore-pll-unlock-4a28aa29eb5c Best regards, -- Luca Ceresoli <luca.ceresoli(a)bootlin.com>

20 hours, 51 minutes

3
4
0 0

[PATCH v2] usb: dwc3: gadget: Prevent EPs resource conflict during StartTransfer

by Selvarasu Ganesan

The below “No resource for ep” warning appears when a StartTransfer command is issued for bulk or interrupt endpoints in `dwc3_gadget_ep_enable` while a previous StartTransfer on the same endpoint is still in progress. The gadget functions drivers can invoke `usb_ep_enable` (which triggers a new StartTransfer command) before the earlier transfer has completed. Because the previous StartTransfer is still active, `dwc3_gadget_ep_disable` can skip the required `EndTransfer` due to `DWC3_EP_DELAY_STOP`, leading to the endpoint resources are busy for previous StartTransfer and warning ("No resource for ep") from dwc3 driver. To resolve this, a check is added to `dwc3_gadget_ep_enable` that checks the `DWC3_EP_TRANSFER_STARTED` flag before issuing a new StartTransfer. By preventing a second StartTransfer on an already busy endpoint, the resource conflict is eliminated, the warning disappears, and potential kernel panics caused by `panic_on_warn` are avoided. ------------[ cut here ]------------ dwc3 13200000.dwc3: No resource for ep1out WARNING: CPU: 0 PID: 700 at drivers/usb/dwc3/gadget.c:398 dwc3_send_gadget_ep_cmd+0x2f8/0x76c Call trace: dwc3_send_gadget_ep_cmd+0x2f8/0x76c __dwc3_gadget_ep_enable+0x490/0x7c0 dwc3_gadget_ep_enable+0x6c/0xe4 usb_ep_enable+0x5c/0x15c mp_eth_stop+0xd4/0x11c __dev_close_many+0x160/0x1c8 __dev_change_flags+0xfc/0x220 dev_change_flags+0x24/0x70 devinet_ioctl+0x434/0x524 inet_ioctl+0xa8/0x224 sock_do_ioctl+0x74/0x128 sock_ioctl+0x3bc/0x468 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x38/0x88 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac Fixes: a97ea994605e ("usb: dwc3: gadget: offset Start Transfer latency for bulk EPs") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- Changes in v2: - Removed change-id. - Updated commit message. Link to v1: https://lore.kernel.org/linux-usb/20251117152812.622-1-selvarasu.g@samsung.… --- drivers/usb/dwc3/gadget.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 1f67fb6aead5..8d3caa71ea12 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -963,8 +963,9 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action) * Issue StartTransfer here with no-op TRB so we can always rely on No * Response Update Transfer command. */ - if (usb_endpoint_xfer_bulk(desc) || - usb_endpoint_xfer_int(desc)) { + if ((usb_endpoint_xfer_bulk(desc) || + usb_endpoint_xfer_int(desc)) && + !(dep->flags & DWC3_EP_TRANSFER_STARTED)) { struct dwc3_gadget_ep_cmd_params params; struct dwc3_trb *trb; dma_addr_t trb_dma; -- 2.34.1

1 day, 4 hours

3
16
0 0

[PATCH v1 0/2] mm: skip wait in wait_sb_inodes() for hangable-writeback mappings

by Joanne Koong

As reported by Athul upstream in [1], there is a userspace regression caused by commit 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree") where if there is a bug in a fuse server that causes the server to never complete writeback, it will make wait_sb_inodes() wait forever, causing sync paths to hang. This is a resubmission of this patch [2] that was dropped from the original series due to a buggy/malicious server still being able to hold up sync() / the system in other ways if they wanted to, but the wait_sb_inodes() path is particularly common and easier to hit for malfunctioning servers. Thanks, Joanne [1] https://lore.kernel.org/regressions/CAJnrk1ZjQ8W8NzojsvJPRXiv9TuYPNdj8Ye7=C… [2] https://lore.kernel.org/linux-fsdevel/20241122232359.429647-4-joannelkoong@… Joanne Koong (2): mm: rename AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM to AS_WRITEBACK_MAY_HANG fs/writeback: skip inodes with potential writeback hang in wait_sb_inodes() fs/fs-writeback.c | 3 +++ fs/fuse/file.c | 2 +- include/linux/pagemap.h | 10 +++++----- mm/vmscan.c | 3 +-- 4 files changed, 10 insertions(+), 8 deletions(-) -- 2.47.3

1 day, 11 hours

4
16
0 0

+ mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.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: Jiayuan Chen <jiayuan.chen(a)linux.dev> Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN Date: Fri, 28 Nov 2025 19:15:14 +0800 Syzkaller reported a memory out-of-bounds bug [1]. This patch fixes two issues: 1. In vrealloc, we were missing the KASAN_VMALLOC_VM_ALLOC flag when unpoisoning the extended region. This flag is required to correctly associate the allocation with KASAN's vmalloc tracking. Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it. vrealloc must behave consistently �� especially when reusing existing vmalloc regions �� to ensure KASAN can track allocations correctly. 2. When vrealloc reuses an existing vmalloc region (without allocating new pages), KASAN previously generated a new tag, which broke tag-based memory access tracking. We now add a 'reuse_tag' parameter to __kasan_unpoison_vmalloc() to preserve the original tag in such cases. A new helper kasan_unpoison_vralloc() is introduced to handle this reuse scenario, ensuring consistent tag behavior during reallocation. Link: https://lkml.kernel.org/r/20251128111516.244497-1-jiayuan.chen@linux.dev Link: https://syzkaller.appspot.com/bug?extid=997752115a851cb0cf36 [1] Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing") Signed-off-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Reported-by: syzbot+997752115a851cb0cf36(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68e243a2.050a0220.1696c6.007d.GAE@google.com/T/ Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Kees Cook <kees(a)kernel.org> Cc: "Uladzislau Rezki (Sony)" <urezki(a)gmail.com> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/kasan.h | 21 +++++++++++++++++++-- mm/kasan/hw_tags.c | 4 ++-- mm/kasan/shadow.c | 6 ++++-- mm/vmalloc.c | 4 ++-- 4 files changed, 27 insertions(+), 8 deletions(-) --- a/include/linux/kasan.h~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/include/linux/kasan.h @@ -596,13 +596,23 @@ static inline void kasan_release_vmalloc #endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, - kasan_vmalloc_flags_t flags); + kasan_vmalloc_flags_t flags, bool reuse_tag); + +static __always_inline void *kasan_unpoison_vrealloc(const void *start, + unsigned long size, + kasan_vmalloc_flags_t flags) +{ + if (kasan_enabled()) + return __kasan_unpoison_vmalloc(start, size, flags, true); + return (void *)start; +} + static __always_inline void *kasan_unpoison_vmalloc(const void *start, unsigned long size, kasan_vmalloc_flags_t flags) { if (kasan_enabled()) - return __kasan_unpoison_vmalloc(start, size, flags); + return __kasan_unpoison_vmalloc(start, size, flags, false); return (void *)start; } @@ -629,6 +639,13 @@ static inline void kasan_release_vmalloc unsigned long free_region_end, unsigned long flags) { } +static inline void *kasan_unpoison_vrealloc(const void *start, + unsigned long size, + kasan_vmalloc_flags_t flags) +{ + return (void *)start; +} + static inline void *kasan_unpoison_vmalloc(const void *start, unsigned long size, kasan_vmalloc_flags_t flags) --- a/mm/kasan/hw_tags.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/mm/kasan/hw_tags.c @@ -317,7 +317,7 @@ static void init_vmalloc_pages(const voi } void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, - kasan_vmalloc_flags_t flags) + kasan_vmalloc_flags_t flags, bool reuse_tag) { u8 tag; unsigned long redzone_start, redzone_size; @@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const voi return (void *)start; } - tag = kasan_random_tag(); + tag = reuse_tag ? get_tag(start) : kasan_random_tag(); start = set_tag(start, tag); /* Unpoison and initialize memory up to size. */ --- a/mm/kasan/shadow.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/mm/kasan/shadow.c @@ -625,7 +625,7 @@ void kasan_release_vmalloc(unsigned long } void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, - kasan_vmalloc_flags_t flags) + kasan_vmalloc_flags_t flags, bool reuse_tag) { /* * Software KASAN modes unpoison both VM_ALLOC and non-VM_ALLOC @@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const voi !(flags & KASAN_VMALLOC_PROT_NORMAL)) return (void *)start; - start = set_tag(start, kasan_random_tag()); + if (!reuse_tag) + start = set_tag(start, kasan_random_tag()); + kasan_unpoison(start, size, false); return (void *)start; } --- a/mm/vmalloc.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/mm/vmalloc.c @@ -4175,8 +4175,8 @@ void *vrealloc_node_align_noprof(const v * We already have the bytes available in the allocation; use them. */ if (size <= alloced_size) { - kasan_unpoison_vmalloc(p + old_size, size - old_size, - KASAN_VMALLOC_PROT_NORMAL); + kasan_unpoison_vrealloc(p, size, + KASAN_VMALLOC_PROT_NORMAL | KASAN_VMALLOC_VM_ALLOC); /* * No need to zero memory here, as unused memory will have * already been zeroed at initial allocation time or during _ Patches currently in -mm which might be from jiayuan.chen(a)linux.dev are mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch mm-vmscan-skip-increasing-kswapd_failures-when-reclaim-was-boosted.patch

1 day, 14 hours

3
3
0 0

[PATCH v2] drm/xe/exec: Validate num_syncs to prevent oversized allocations

by Shuicheng Lin

The exec ioctl allows userspace to specify an arbitrary num_syncs value. Without bounds checking, a very large num_syncs can force an excessively large allocation, leading to kernel warnings from the page allocator as below. Introduce XE_EXEC_MAX_SYNCS (set to 64) and reject any request exceeding this limit. " ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124 ... Call Trace: <TASK> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416 ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388 kmalloc_noprof include/linux/slab.h:909 [inline] kmalloc_array_noprof include/linux/slab.h:948 [inline] xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158 drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797 drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894 xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... " v2: Add "Reported-by" and Cc stable kernels. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6450 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Koen Koning <koen.koning(a)intel.com> Reported-by: Peter Senna Tschudin <peter.senna(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Cc: Matthew Brost <matthew.brost(a)intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin(a)intel.com> --- drivers/gpu/drm/xe/xe_exec.c | 5 +++++ include/uapi/drm/xe_drm.h | 1 + 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_exec.c b/drivers/gpu/drm/xe/xe_exec.c index 4d81210e41f5..01c56fd95d5b 100644 --- a/drivers/gpu/drm/xe/xe_exec.c +++ b/drivers/gpu/drm/xe/xe_exec.c @@ -162,6 +162,11 @@ int xe_exec_ioctl(struct drm_device *dev, void *data, struct drm_file *file) } if (args->num_syncs) { + if (XE_IOCTL_DBG(xe, args->num_syncs > XE_EXEC_MAX_SYNCS)) { + err = -EINVAL; + goto err_exec_queue; + } + syncs = kcalloc(args->num_syncs, sizeof(*syncs), GFP_KERNEL); if (!syncs) { err = -ENOMEM; diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h index 47853659a705..1901ca26621a 100644 --- a/include/uapi/drm/xe_drm.h +++ b/include/uapi/drm/xe_drm.h @@ -1463,6 +1463,7 @@ struct drm_xe_exec { /** @exec_queue_id: Exec queue ID for the batch buffer */ __u32 exec_queue_id; +#define XE_EXEC_MAX_SYNCS 64 /** @num_syncs: Amount of struct drm_xe_sync in array. */ __u32 num_syncs; -- 2.49.0

1 day, 19 hours

3
2
0 0

[PATCH net v3] net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()

by Shaurya Rane

prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_std but doesn't check if the allocation failed. If __pskb_copy() returns NULL, skb_clone() is called with a NULL pointer, causing a crash: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041 Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0c RSP: 0018:ffffc9000d00f200 EFLAGS: 00010207 RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480 RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000 RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1ee R10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000 R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00 FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0 Call Trace: <TASK> hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84 __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [inline] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c:6278 [inline] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0449f8e1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48 RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ff RDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8 RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001 R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 </TASK> Add a NULL check immediately after __pskb_copy() to handle allocation failures gracefully. Reported-by: syzbot+2fa344348a579b779e05(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2fa344348a579b779e05 Fixes: f266a683a480 ("net/hsr: Better frame dispatch") Cc: stable(a)vger.kernel.org Signed-off-by: Shaurya Rane <ssrane_b23(a)ee.vjti.ac.in> --- v3: - Keep only prp_get_untagged_frame() fix as the other two NETIF_F_HW_HSR_TAG_INS checks are not needed for this bug - Move NULL check immediately after __pskb_copy() call v2: - Add stack trace to commit message - Target net tree with [PATCH net] - Add Cc: stable(a)vger.kernel.org --- net/hsr/hsr_forward.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c index 339f0d220212..aefc9b6936ba 100644 --- a/net/hsr/hsr_forward.c +++ b/net/hsr/hsr_forward.c @@ -205,6 +205,8 @@ struct sk_buff *prp_get_untagged_frame(struct hsr_frame_info *frame, __pskb_copy(frame->skb_prp, skb_headroom(frame->skb_prp), GFP_ATOMIC); + if (!frame->skb_std) + return NULL; } else { /* Unexpected */ WARN_ONCE(1, "%s:%d: Unexpected frame received (port_src %s)\n", -- 2.34.1

1 day, 19 hours

4
3
0 0

[REGRESSION] stable-rc/linux-6.12.y: (build) variable 'val' is uninitialized when passed as a const pointer arg...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.12.y: --- variable 'val' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] in drivers/staging/rtl8712/rtl8712_cmd.o (drivers/staging/rtl8712/rtl8712_cmd.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:5b83acc62508c670164c5fceb3079a2d7d74e154 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: d5dc97879a97b328a89ec092271faa3db9f2bff3 - tags: v6.12.59 Log excerpt: ===================================================== drivers/staging/rtl8712/rtl8712_cmd.c:148:28: error: variable 'val' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 148 | memcpy(pcmd->rsp, (u8 *)&val, pcmd->rspsz); | ^~~ 1 error generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig on (arm64): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm64-allmodconfig-6924331af5b87… - dashboard: https://d.kernelci.org/build/maestro:6924331af5b8743b1f5e538f ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm-allmodconfig-69243317f5b8743… - dashboard: https://d.kernelci.org/build/maestro:69243317f5b8743b1f5e538c ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-i386-allmodconfig-69243353f5b874… - dashboard: https://d.kernelci.org/build/maestro:69243353f5b8743b1f5e53bf ## x86_64_defconfig+allmodconfig on (x86_64): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-x86-allmodconfig-69243323f5b8743… - dashboard: https://d.kernelci.org/build/maestro:69243323f5b8743b1f5e5395 #kernelci issue maestro:5b83acc62508c670164c5fceb3079a2d7d74e154 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 days, 3 hours

4
7
0 0

[PATCH v4] dmaengine: fsl-edma: Fix clk leak on alloc_chan_resources failure

by Zhen Ni

When fsl_edma_alloc_chan_resources() fails after clk_prepare_enable(), the error paths only free IRQs and destroy the TCD pool, but forget to call clk_disable_unprepare(). This causes the channel clock to remain enabled, leaking power and resources. Fix it by disabling the channel clock in the error unwind path. Fixes: d8d4355861d8 ("dmaengine: fsl-edma: add i.MX8ULP edma support") Cc: stable(a)vger.kernel.org Suggested-by: Frank Li <Frank.Li(a)nxp.com> Signed-off-by: Zhen Ni <zhen.ni(a)easystack.cn> --- Changes in v2: - Remove FSL_EDMA_DRV_HAS_CHCLK check Changes in v3: - Remove cleanup Changes in v4: - Re-send as a new thread --- drivers/dma/fsl-edma-common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c index 4976d7dde080..11655dcc4d6c 100644 --- a/drivers/dma/fsl-edma-common.c +++ b/drivers/dma/fsl-edma-common.c @@ -852,6 +852,7 @@ int fsl_edma_alloc_chan_resources(struct dma_chan *chan) free_irq(fsl_chan->txirq, fsl_chan); err_txirq: dma_pool_destroy(fsl_chan->tcd_pool); + clk_disable_unprepare(fsl_chan->clk); return ret; } -- 2.20.1

2 days, 7 hours

2
2
0 0

Bug: Performance regression in 1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race

by Uschakow, Stanislav

Hello. We have observed a huge latency increase using `fork()` after ingesting the CVE-2025-38085 fix which leads to the commit `1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race`. On large machines with 1.5TB of memory with 196 cores, we identified mmapping of 1.2TB of shared memory and forking itself dozens or hundreds of times we see a increase of execution times of a factor of 4. The reproducer is at the end of the email. Comparing the a kernel without this patch with a kernel with this patch applied when spawning 1000 children we see those execution times: Patched kernel: $ time make stress ... real 0m11.275s user 0m0.177s sys 0m23.905s Original kernel : $ time make stress ...real 0m2.475s user 0m1.398s sys 0m2.501s The patch in question: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… My observation/assumption is: each child touches 100 random pages and despawns on each despawn `huge_pmd_unshare()` is called each call to `huge_pmd_unshare()` syncrhonizes all threads using `tlb_remove_table_sync_one()` leading to the regression I'm happy to provide more information. Thank you Stanislav Uschakow === Reproducer === Setup: #!/bin/bash echo "Setting up hugepages for reproduction..." # hugepages (1.2TB / 2MB = 614400 pages) REQUIRED_PAGES=614400 # Check current hugepage allocation CURRENT_PAGES=$(cat /proc/sys/vm/nr_hugepages) echo "Current hugepages: $CURRENT_PAGES" if [ "$CURRENT_PAGES" -lt "$REQUIRED_PAGES" ]; then echo "Allocating $REQUIRED_PAGES hugepages..." echo $REQUIRED_PAGES | sudo tee /proc/sys/vm/nr_hugepages ALLOCATED=$(cat /proc/sys/vm/nr_hugepages) echo "Allocated hugepages: $ALLOCATED" if [ "$ALLOCATED" -lt "$REQUIRED_PAGES" ]; then echo "Warning: Could not allocate all required hugepages" echo "Available: $ALLOCATED, Required: $REQUIRED_PAGES" fi fi echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled echo -e "\nHugepage information:" cat /proc/meminfo | grep -i huge echo -e "\nSetup complete. You can now run the reproduction test." Makefile: CXX = gcc CXXFLAGS = -O2 -Wall TARGET = hugepage_repro SOURCE = hugepage_repro.c $(TARGET): $(SOURCE) $(CXX) $(CXXFLAGS) -o $(TARGET) $(SOURCE) clean: rm -f $(TARGET) setup: chmod +x setup_hugepages.sh ./setup_hugepages.sh test: $(TARGET) ./$(TARGET) 20 3 stress: $(TARGET) ./$(TARGET) 1000 1 .PHONY: clean setup test stress hugepage_repro.c: #include <sys/mman.h> #include <sys/wait.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <time.h> #include <stdio.h> #define HUGEPAGE_SIZE (2 * 1024 * 1024) // 2MB #define TOTAL_SIZE (1200ULL * 1024 * 1024 * 1024) // 1.2TB #define NUM_HUGEPAGES (TOTAL_SIZE / HUGEPAGE_SIZE) void* create_hugepage_mapping() { void* addr = mmap(NULL, TOTAL_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0); if (addr == MAP_FAILED) { perror("mmap hugepages failed"); exit(1); } return addr; } void touch_random_pages(void* addr, int num_touches) { char* base = (char*)addr; for (int i = 0; i < num_touches; ++i) { size_t offset = (rand() % NUM_HUGEPAGES) * HUGEPAGE_SIZE; volatile char val = base[offset]; (void)val; } } void child_process(void* shared_mem, int child_id) { struct timespec start, end; clock_gettime(CLOCK_MONOTONIC, &start); touch_random_pages(shared_mem, 100); clock_gettime(CLOCK_MONOTONIC, &end); long duration = (end.tv_sec - start.tv_sec) * 1000000 + (end.tv_nsec - start.tv_nsec) / 1000; printf("Child %d completed in %ld μs\n", child_id, duration); } int main(int argc, char* argv[]) { int num_processes = argc > 1 ? atoi(argv[1]) : 50; int iterations = argc > 2 ? atoi(argv[2]) : 5; printf("Creating %lluGB hugepage mapping...\n", TOTAL_SIZE / (1024*1024*1024)); void* shared_mem = create_hugepage_mapping(); for (int iter = 0; iter < iterations; ++iter) { printf("\nIteration %d: Forking %d processes\n", iter + 1, num_processes); pid_t children[num_processes]; struct timespec iter_start, iter_end; clock_gettime(CLOCK_MONOTONIC, &iter_start); for (int i = 0; i < num_processes; ++i) { pid_t pid = fork(); if (pid == 0) { child_process(shared_mem, i); exit(0); } else if (pid > 0) { children[i] = pid; } } for (int i = 0; i < num_processes; ++i) { waitpid(children[i], NULL, 0); } clock_gettime(CLOCK_MONOTONIC, &iter_end); long iter_duration = (iter_end.tv_sec - iter_start.tv_sec) * 1000 + (iter_end.tv_nsec - iter_start.tv_nsec) / 1000000; printf("Iteration completed in %ld ms\n", iter_duration); } munmap(shared_mem, TOTAL_SIZE); return 0; } Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

2 days, 10 hours

6
34
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2025