Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

265 participants
124084 discussions

[PATCH] clk: keystone: syscon-clk: fix regmap leak on probe failure

by Johan Hovold

The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: a250cd4c1901 ("clk: keystone: syscon-clk: Do not use syscon helper to build regmap") Cc: stable(a)vger.kernel.org # 6.15 Cc: Andrew Davis <afd(a)ti.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/clk/keystone/syscon-clk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/keystone/syscon-clk.c b/drivers/clk/keystone/syscon-clk.c index c509929da854..ecf180a7949c 100644 --- a/drivers/clk/keystone/syscon-clk.c +++ b/drivers/clk/keystone/syscon-clk.c @@ -129,7 +129,7 @@ static int ti_syscon_gate_clk_probe(struct platform_device *pdev) if (IS_ERR(base)) return PTR_ERR(base); - regmap = regmap_init_mmio(dev, base, &ti_syscon_regmap_cfg); + regmap = devm_regmap_init_mmio(dev, base, &ti_syscon_regmap_cfg); if (IS_ERR(regmap)) return dev_err_probe(dev, PTR_ERR(regmap), "failed to get regmap\n"); -- 2.51.2

1 month, 1 week

[PATCH] clk: samsung: exynos-clkout: Assign .num before accessing .hws

by Nathan Chancellor

Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS) about the number of elements in .hws[], so that it can warn when .hws[] is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in exynos_clkout_probe() due to .num being assigned after .hws[] has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/samsung/clk-exynos-clkout.c:178:18 index 0 is out of range for type 'clk_hw *[*]' Move the .num initialization to before the first access of .hws[], clearing up the warning. Cc: stable(a)vger.kernel.org Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Reported-by: Jochen Sprickerhof <jochen(a)sprickerhof.de> Closes: https://lore.kernel.org/aSIYDN5eyKFKoXKL@eldamar.lan/ Tested-by: Jochen Sprickerhof <jochen(a)sprickerhof.de> Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- drivers/clk/samsung/clk-exynos-clkout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/samsung/clk-exynos-clkout.c b/drivers/clk/samsung/clk-exynos-clkout.c index 5f1a4f5e2e59..5b21025338bd 100644 --- a/drivers/clk/samsung/clk-exynos-clkout.c +++ b/drivers/clk/samsung/clk-exynos-clkout.c @@ -175,6 +175,7 @@ static int exynos_clkout_probe(struct platform_device *pdev) clkout->mux.shift = EXYNOS_CLKOUT_MUX_SHIFT; clkout->mux.lock = &clkout->slock; + clkout->data.num = EXYNOS_CLKOUT_NR_CLKS; clkout->data.hws[0] = clk_hw_register_composite(NULL, "clkout", parent_names, parent_count, &clkout->mux.hw, &clk_mux_ops, NULL, NULL, &clkout->gate.hw, @@ -185,7 +186,6 @@ static int exynos_clkout_probe(struct platform_device *pdev) goto err_unmap; } - clkout->data.num = EXYNOS_CLKOUT_NR_CLKS; ret = of_clk_add_hw_provider(clkout->np, of_clk_hw_onecell_get, &clkout->data); if (ret) goto err_clk_unreg; --- base-commit: b6430552c8cd95e90bb842ce2f421e7a5381859f change-id: 20251124-exynos-clkout-fix-ubsan-bounds-error-93071375ec78 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 month, 1 week

[PATCH] bcache: call bio_endio() to replace directly calling bio->bi_end_io()

by colyli＠fnnas.com

From: Coly Li <colyli(a)fnnas.com> When a bcache device is not attached to a cache device, current code calls the request's bi_end_io() callback directly. The correct method is to call bio_endio(bio) instead of bio->bi_end_io(bio). This patch fixes the incorrect calling. Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached bcache devices") Fixes: 40f567bbb3b0 ("md: bcache: check the return value of kzalloc() in detached_dev_do_request()") Reported-by: Shida Zhang <zhangshida(a)kylinos.cn> Closes: https://lore.kernel.org/linux-block/20251121081748.1443507-1-zhangshida@kyl… Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Jia-Ju Bai <baijiaju1990(a)gmail.com> Cc: stable(a)vger.kernel.org #4.17+ Signed-off-by: Coly Li <colyli(a)fnnas.com> --- drivers/md/bcache/request.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c index af345dc6fde1..7b815064db54 100644 --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -1104,7 +1104,7 @@ static void detached_dev_end_io(struct bio *bio) } kfree(ddip); - bio->bi_end_io(bio); + bio_endio(bio); } static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, @@ -1121,7 +1121,7 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO); if (!ddip) { bio->bi_status = BLK_STS_RESOURCE; - bio->bi_end_io(bio); + bio_endio(bio); return; } @@ -1136,7 +1136,7 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, if ((bio_op(bio) == REQ_OP_DISCARD) && !bdev_max_discard_sectors(dc->bdev)) - bio->bi_end_io(bio); + bio_endio(bio); else submit_bio_noacct(bio); } -- 2.47.3

1 month, 1 week

[PATCH] counter: interrupt-cnt: Drop IRQF_NO_THREAD flag

by A. Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> An IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as CONFIG_PROVE_RAW_LOCK_NESTING warns: ============================= [ BUG: Invalid wait context ] 6.18.0-rc1+git... #1 ----------------------------- some-user-space-process/1251 is trying to lock: (&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter] other info that might help us debug this: context-{2:2} no locks held by some-user-space-process/.... stack backtrace: CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT Call trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq ... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an alternative to switching to raw_spinlock_t, because the latter would limit all potential nested locks to raw_spinlock_t only. Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20251117151314.xwLAZrWY@linutronix.de/ Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter") Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> --- drivers/counter/interrupt-cnt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/counter/interrupt-cnt.c b/drivers/counter/interrupt-cnt.c index 6c0c1d2d7027d..e6100b5fb082e 100644 --- a/drivers/counter/interrupt-cnt.c +++ b/drivers/counter/interrupt-cnt.c @@ -229,8 +229,7 @@ static int interrupt_cnt_probe(struct platform_device *pdev) irq_set_status_flags(priv->irq, IRQ_NOAUTOEN); ret = devm_request_irq(dev, priv->irq, interrupt_cnt_isr, - IRQF_TRIGGER_RISING | IRQF_NO_THREAD, - dev_name(dev), counter); + IRQF_TRIGGER_RISING, dev_name(dev), counter); if (ret) return ret; -- 2.51.1

1 month, 1 week

[PATCH] fs: ocfs2: fix kernel BUG in ocfs2_find_victim_chain

by Prithvi Tambewagh

syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the `cl_next_free_rec` field of the allocation chain list is 0, triggring the BUG_ON(!cl->cl_next_free_rec) condition and panicking the kernel. To fix this, `cl_next_free_rec` is checked inside the caller of ocfs2_find_victim_chain() i.e. ocfs2_claim_suballoc_bits() and if it is equal to 0, ocfs2_error() is called, to log the corruption and force the filesystem into read-only mode, to prevent further damage. Reported-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72 Tested-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- fs/ocfs2/suballoc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c index 6ac4dcd54588..84bb2d11c2aa 100644 --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -1993,6 +1993,13 @@ static int ocfs2_claim_suballoc_bits(struct ocfs2_alloc_context *ac, cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; + if (le16_to_cpu(cl->cl_next_free_rec) == 0) { + status = ocfs2_error(ac->ac_inode->i_sb, + "Chain allocator dinode %llu has 0 chains\n", + (unsigned long long)le64_to_cpu(fe->i_blkno)); + goto bail; + } + victim = ocfs2_find_victim_chain(cl); ac->ac_chain = victim; base-commit: 939f15e640f193616691d3bcde0089760e75b0d3 -- 2.34.1

1 month, 1 week

[PATCH] fs: ocfs2: fix kernel BUG in ocfs2_find_victim_chain

by Prithvi Tambewagh

syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the `cl_next_free_rec` field of the allocation chain list is 0, triggring the BUG_ON(!cl->cl_next_free_rec) condition and panicking the kernel. To fix this, `cl_next_free_rec` is checked inside the caller of ocfs2_find_victim_chain() i.e. ocfs2_claim_suballoc_bits() and if it is equal to 0, ocfs2_error() is called, to log the corruption and force the filesystem into read-only mode, to prevent further damage. Reported-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Tested-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72 Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- fs/ocfs2/suballoc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c index 6ac4dcd54588..c7eb6efc00b4 100644 --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -1993,6 +1993,13 @@ static int ocfs2_claim_suballoc_bits(struct ocfs2_alloc_context *ac, cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; + if( le16_to_cpu(cl->cl_next_free_rec) == 0) { + status = ocfs2_error(ac->ac_inode->i_sb, + "Chain allocator dinode %llu has 0 chains\n", + (unsigned long long)le64_to_cpu(fe->i_blkno)); + goto bail; + } + victim = ocfs2_find_victim_chain(cl); ac->ac_chain = victim; base-commit: 939f15e640f193616691d3bcde0089760e75b0d3 -- 2.34.1

1 month, 1 week

👉 DUOONE OLED SPAN/FOLD Launch — Black Friday & Cyber Monday Rewards on Kickstarter🎉

by InnLead Innovative

👉 DUOONE OLED SPAN/FOLD Launch — Black Friday & Cyber Monday Rewards on Kickstarter🎉 Multiplayer Gaming, Dual Fun & Work | OLED | Duel & Tabletop Games | 1ms Respones Time ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ We need your feedback! Having trouble seeing this email? View it online ( https://eeenew.com/index.php/component/acym/archive/93-duoone-oled-span-fol… ) ‍DUOONE OLED SPAN/FOLD Multiplayer Gaming, Dual Fun & Work! Live on Kickstarter ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) Hi there, Experience dual OLED touchscreens built for multiplayer gaming and next-level productivity. With 4-input connectivity and multi-display modes, it works seamlessly with PC, Mac, NS, Android, DeX, Xbox, PS, and handheld consoles. Double the screens. Double the power. Double the fun. 👉Back us on Kickstarter and unlock exclusive launch rewards! ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) 👉 Back DUOONE OLED on Kickstarter ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) For work. For play. For everyone. Multiplayer gaming + productivity in one device Board Game - Revolutionize Traditional Gaming on a Stunning OLED Screen! Infinity Game Table-Limitless Gaming with Endless Content and Digital Magic! ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) VS Opponent Gaming Table - Challenge Friends Head-to-Head on Dual Displays! ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) At just 2.3 lbs. Ultra-portable design to bring your gaming, work, and fun wherever you go Book Mode-Book lover, Literary enthusiast, Bibliophile Graphic design, Photo editing, and Professional content creation ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) Experience epic multiplayer gaming, seamless multitasking, and stunning OLED brilliance. ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) 👉Don’t miss out — Claim your Black Friday & Cyber Monday rewards on Kickstarter!🎉 ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) We’re truly grateful to have you with us. Let’s build something remarkable together — see you on Kickstarter for the next big step. Best, InnLead Innovative Unsubscribe ( https://eeenew.com/index.php/component/acym/frontusers/unsubscribe/93-duoon… )

1 month, 1 week

Re: Patch "mptcp: Fix proto fallback detection with BPF" has been added to the 6.1-stable tree

by Matthieu Baerts

Hi Greg, Sasha, Jiayuan, On 27/11/2025 14:41, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > mptcp: Fix proto fallback detection with BPF > > to the 6.1-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > mptcp-fix-proto-fallback-detection-with-bpf.patch > and it can be found in the queue-6.1 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. @Sasha: thank you for having resolved the conflicts for this patch (and many others related to MPTCP recently). Sadly, it is causing troubles. @Greg/Sasha: is it possible to remove it from 6.1, 5.15 and 5.10 queues please? (The related patch in 6.6 and above is OK) @Jiayuan: did you not specify you initially saw this issue on a v6.1 kernel? By chance, do you already have a fix for that version? Cheers, Matt -- Sponsored by the NGI0 Core fund.

1 month, 1 week

[PATCH] kasan: hw_tags: fix a false positive case of vrealloc in alloced size

by Yeoreum Yun

When a memory region is allocated with vmalloc() and later expanded with vrealloc() — while still within the originally allocated size — KASAN may report a false positive because it does not update the tags for the newly expanded portion of the memory. A typical example of this pattern occurs in the BPF verifier, and the following is a related false positive report: [ 2206.486476] ================================================================== [ 2206.486509] BUG: KASAN: invalid-access in __memcpy+0xc/0x30 [ 2206.486607] Write at addr f5ff800083765270 by task test_progs/205 [ 2206.486664] Pointer tag: [f5], memory tag: [fe] [ 2206.486703] [ 2206.486745] CPU: 4 UID: 0 PID: 205 Comm: test_progs Tainted: G OE 6.18.0-rc7+ #145 PREEMPT(full) [ 2206.486861] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 2206.486897] Hardware name: , BIOS [ 2206.486932] Call trace: [ 2206.486961] show_stack+0x24/0x40 (C) [ 2206.487071] __dump_stack+0x28/0x48 [ 2206.487182] dump_stack_lvl+0x7c/0xb0 [ 2206.487293] print_address_description+0x80/0x270 [ 2206.487403] print_report+0x94/0x100 [ 2206.487505] kasan_report+0xd8/0x150 [ 2206.487606] __do_kernel_fault+0x64/0x268 [ 2206.487717] do_bad_area+0x38/0x110 [ 2206.487820] do_tag_check_fault+0x38/0x60 [ 2206.487936] do_mem_abort+0x48/0xc8 [ 2206.488042] el1_abort+0x40/0x70 [ 2206.488127] el1h_64_sync_handler+0x50/0x118 [ 2206.488217] el1h_64_sync+0xa4/0xa8 [ 2206.488303] __memcpy+0xc/0x30 (P) [ 2206.488412] do_misc_fixups+0x4f8/0x1950 [ 2206.488528] bpf_check+0x31c/0x840 [ 2206.488638] bpf_prog_load+0x58c/0x658 [ 2206.488737] __sys_bpf+0x364/0x488 [ 2206.488833] __arm64_sys_bpf+0x30/0x58 [ 2206.488920] invoke_syscall+0x68/0xe8 [ 2206.489033] el0_svc_common+0xb0/0xf8 [ 2206.489143] do_el0_svc+0x28/0x48 [ 2206.489249] el0_svc+0x40/0xe8 [ 2206.489337] el0t_64_sync_handler+0x84/0x140 [ 2206.489427] el0t_64_sync+0x1bc/0x1c0 Here, 0xf5ff800083765000 is vmalloc()ed address for env->insn_aux_data with the size of 0x268. While this region is expanded size by 0x478 and initialise increased region to apply patched instructions, a false positive is triggered at the address 0xf5ff800083765270 because __kasan_unpoison_vmalloc() with KASAN_VMALLOC_PROT_NORMAL flag only doesn't update the tag on increaed region. To address this, introduces KASAN_VMALLOC_EXPAND flag which is used to expand vmalloc()ed memory in range of real allocated size to update tag for increased region. Fixes: 23689e91fb22 ("kasan, vmalloc: add vmalloc tagging for HW_TAGS”) Cc: <stable(a)vger.kernel.org> Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> --- include/linux/kasan.h | 1 + mm/kasan/hw_tags.c | 11 +++++++++-- mm/vmalloc.c | 1 + 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index d12e1a5f5a9a..0608c5d4e6cf 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -28,6 +28,7 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t; #define KASAN_VMALLOC_INIT ((__force kasan_vmalloc_flags_t)0x01u) #define KASAN_VMALLOC_VM_ALLOC ((__force kasan_vmalloc_flags_t)0x02u) #define KASAN_VMALLOC_PROT_NORMAL ((__force kasan_vmalloc_flags_t)0x04u) +#define KASAN_VMALLOC_EXPAND ((__force kasan_vmalloc_flags_t)0x08u) #define KASAN_VMALLOC_PAGE_RANGE 0x1 /* Apply exsiting page range */ #define KASAN_VMALLOC_TLB_FLUSH 0x2 /* TLB flush */ diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c index 1c373cc4b3fa..d768c7360093 100644 --- a/mm/kasan/hw_tags.c +++ b/mm/kasan/hw_tags.c @@ -347,7 +347,7 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, * * For non-VM_ALLOC allocations, page_alloc memory is tagged as usual. */ - if (!(flags & KASAN_VMALLOC_VM_ALLOC)) { + if (!(flags & (KASAN_VMALLOC_VM_ALLOC | KASAN_VMALLOC_EXPAND))) { WARN_ON(flags & KASAN_VMALLOC_INIT); return (void *)start; } @@ -361,7 +361,14 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, return (void *)start; } - tag = kasan_random_tag(); + if (flags & KASAN_VMALLOC_EXPAND) { + size = round_up(size + ((unsigned long)start & KASAN_GRANULE_MASK), + KASAN_GRANULE_SIZE); + start = PTR_ALIGN_DOWN(start, KASAN_GRANULE_SIZE); + tag = get_tag(start); + } else + tag = kasan_random_tag(); + start = set_tag(start, tag); /* Unpoison and initialize memory up to size. */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 798b2ed21e46..6bfbf26fea3b 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4176,6 +4176,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align */ if (size <= alloced_size) { kasan_unpoison_vmalloc(p + old_size, size - old_size, + KASAN_VMALLOC_EXPAND | KASAN_VMALLOC_PROT_NORMAL); /* * No need to zero memory here, as unused memory will have -- LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

1 month, 1 week

+ idr-fix-idr_alloc-returning-an-id-out-of-range.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: idr: fix idr_alloc() returning an ID out of range has been added to the -mm mm-hotfixes-unstable branch. Its filename is idr-fix-idr_alloc-returning-an-id-out-of-range.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: "Matthew Wilcox (Oracle)" <willy(a)infradead.org> Subject: idr: fix idr_alloc() returning an ID out of range Date: Fri, 28 Nov 2025 16:18:32 +0000 If you use an IDR with a non-zero base, and specify a range that lies entirely below the base, 'max - base' becomes very large and idr_get_free() can return an ID that lies outside of the requested range. Link: https://lkml.kernel.org/r/20251128161853.3200058-1-willy@infradead.org Fixes: 6ce711f27500 ("idr: Make 1-based IDRs more efficient") Signed-off-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Reported-by: Jan Sokolowski <jan.sokolowski(a)intel.com> Reported-by: Koen Koning <koen.koning(a)intel.com> Reported-by: Peter Senna Tschudin <peter.senna(a)linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6449 Reviewed-by: Christian K��nig <christian.koenig(a)amd.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/idr.c | 2 ++ tools/testing/radix-tree/idr-test.c | 21 +++++++++++++++++++++ 2 files changed, 23 insertions(+) --- a/lib/idr.c~idr-fix-idr_alloc-returning-an-id-out-of-range +++ a/lib/idr.c @@ -40,6 +40,8 @@ int idr_alloc_u32(struct idr *idr, void if (WARN_ON_ONCE(!(idr->idr_rt.xa_flags & ROOT_IS_IDR))) idr->idr_rt.xa_flags |= IDR_RT_MARKER; + if (max < base) + return -ENOSPC; id = (id < base) ? 0 : id - base; radix_tree_iter_init(&iter, id); --- a/tools/testing/radix-tree/idr-test.c~idr-fix-idr_alloc-returning-an-id-out-of-range +++ a/tools/testing/radix-tree/idr-test.c @@ -57,6 +57,26 @@ void idr_alloc_test(void) idr_destroy(&idr); } +void idr_alloc2_test(void) +{ + int id; + struct idr idr = IDR_INIT_BASE(idr, 1); + + id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL); + assert(id == -ENOSPC); + + id = idr_alloc(&idr, idr_alloc2_test, 1, 2, GFP_KERNEL); + assert(id == 1); + + id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL); + assert(id == -ENOSPC); + + id = idr_alloc(&idr, idr_alloc2_test, 0, 2, GFP_KERNEL); + assert(id == -ENOSPC); + + idr_destroy(&idr); +} + void idr_replace_test(void) { DEFINE_IDR(idr); @@ -409,6 +429,7 @@ void idr_checks(void) idr_replace_test(); idr_alloc_test(); + idr_alloc2_test(); idr_null_test(); idr_nowait_test(); idr_get_next_test(0); _ Patches currently in -mm which might be from willy(a)infradead.org are idr-fix-idr_alloc-returning-an-id-out-of-range.patch mm-fix-vma_start_write_killable-signal-handling.patch

1 month, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror