Re: KASAN: slab-use-after-free Read in cgroup_rstat_flush

Re: KASAN: slab-use-after-free Read in cgroup_rstat_flush

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 13870 bytes --]

Hello.

On Mon, Apr 07, 2025 at 07:59:58AM -0400, ffhgfv <xnxc22xnxc22@qq.com> wrote:
> Hello, I found a bug titled "   KASAN: slab-use-after-free Read in cgroup_rstat_flush " with modified syzkaller in the Linux6.14.
> If you fix this issue, please add the following tag to the commit:  Reported-by: Jianzhou Zhao <xnxc22xnxc22@qq.com>,    xingwei lee <xrivendell7@gmail.com>,Penglei Jiang <superman.xpt@gmail.com>
> I use the same kernel as syzbot instance upstream: f6e0150b2003fb2b9265028a618aa1732b3edc8f
> kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&amp;x=da4b04ae798b7ef6
> compiler: gcc version 11.4.0
> 
> Unfortunately, we do not have a repro.

Thanks for sharing the report.

> ------------[ cut here ]-----------------------------------------
>  TITLE:  KASAN: slab-use-after-free Read in cgroup_rstat_flush
> ==================================================================
> bridge_slave_0: left allmulticast mode
> bridge_slave_0: left promiscuous mode
> bridge0: port 1(bridge_slave_0) entered disabled state
> ==================================================================
> BUG: KASAN: slab-use-after-free in cgroup_rstat_cpu kernel/cgroup/rstat.c:19 [inline]
> BUG: KASAN: slab-use-after-free in cgroup_base_stat_flush kernel/cgroup/rstat.c:422 [inline]
> BUG: KASAN: slab-use-after-free in cgroup_rstat_flush+0x16ce/0x2180 kernel/cgroup/rstat.c:328

I read this like the struct cgroup is gone when the code try flushing
its respective stats (its ->rstat_cpu more precisely).

Namely,
	__mem_cgroup_flush_stats
		cgroup_rstat_flush(memcg->css.cgroup);
this reference is taken at cgroup creation in init_and_link_css()
and released only in css_free_rwork_fn().

> Read of size 8 at addr ffff888044f1a580 by task kworker/u8:3/10725
> 
> CPU: 0 UID: 0 PID: 10725 Comm: kworker/u8:3 Not tainted 6.14.0-03565-gf6e0150b2003-dirty #3 PREEMPT(full) 
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> Workqueue: netns cleanup_net
> Call Trace:
>  <task>
>  __dump_stack lib/dump_stack.c:94 [inline]
>  dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
>  print_address_description mm/kasan/report.c:408 [inline]
>  print_report+0xc1/0x630 mm/kasan/report.c:521
>  kasan_report+0xca/0x100 mm/kasan/report.c:634
>  cgroup_rstat_cpu kernel/cgroup/rstat.c:19 [inline]
>  cgroup_base_stat_flush kernel/cgroup/rstat.c:422 [inline]
>  cgroup_rstat_flush+0x16ce/0x2180 kernel/cgroup/rstat.c:328
>  zswap_shrinker_count+0x280/0x570 mm/zswap.c:1272
>  do_shrink_slab+0x80/0x1170 mm/shrinker.c:384
>  shrink_slab+0x33d/0x12c0 mm/shrinker.c:664
>  shrink_one+0x4a8/0x7c0 mm/vmscan.c:4868
>  shrink_many mm/vmscan.c:4929 [inline]


I'm looking at this:

        rcu_read_lock();

        hlist_nulls_for_each_entry_rcu(lrugen, pos, &pgdat->memcg_lru.fifo[gen][bin], list) {
                ...

                mem_cgroup_put(memcg);
                memcg = NULL;

                if (gen != READ_ONCE(lrugen->gen))
                        continue;

                lruvec = container_of(lrugen, struct lruvec, lrugen);
                memcg = lruvec_memcg(lruvec);

                if (!mem_cgroup_tryget(memcg)) {
                        lru_gen_release_memcg(memcg);
                        memcg = NULL;
                        continue;
                }

                rcu_read_unlock();

                op = shrink_one(lruvec, sc);

where shrink_one() may get a dead reference to memcg (where
shrink_slab_memcg() bails out when it's not online) but it's still _a_
reference, so css_free_rwork_fn() should not be executed yet.
And despite some indirections, the references of a chosen memcg seem
well-paired in shrink_many to me.

Then, I'm not so familiar with MGLRU to be able to tell whether
lrugens/memcgs are always properly referenced when stored into
pgdat->memcg_lru.fifo[gen][bin] (I Cc linux-mm). That'd be where I'd
look next...

>  lru_gen_shrink_node mm/vmscan.c:5007 [inline]
>  shrink_node+0x2687/0x3dc0 mm/vmscan.c:5978
>  shrink_zones mm/vmscan.c:6237 [inline]
>  do_try_to_free_pages+0x377/0x19b0 mm/vmscan.c:6299
>  try_to_free_pages+0x2a1/0x690 mm/vmscan.c:6549
>  __perform_reclaim mm/page_alloc.c:3929 [inline]
>  __alloc_pages_direct_reclaim mm/page_alloc.c:3951 [inline]
>  __alloc_pages_slowpath mm/page_alloc.c:4383 [inline]
>  __alloc_frozen_pages_noprof+0xaca/0x2200 mm/page_alloc.c:4753
>  alloc_pages_mpol+0x1f1/0x540 mm/mempolicy.c:2301
>  alloc_slab_page mm/slub.c:2446 [inline]
>  allocate_slab mm/slub.c:2610 [inline]
>  new_slab+0x242/0x340 mm/slub.c:2663
>  ___slab_alloc+0xb5f/0x1730 mm/slub.c:3849
>  __slab_alloc.constprop.0+0x56/0xb0 mm/slub.c:3939
>  __slab_alloc_node mm/slub.c:4014 [inline]
>  slab_alloc_node mm/slub.c:4175 [inline]
>  __kmalloc_cache_noprof+0x272/0x3f0 mm/slub.c:4344
>  kmalloc_noprof include/linux/slab.h:902 [inline]
>  netdevice_queue_work drivers/infiniband/core/roce_gid_mgmt.c:664 [inline]
>  netdevice_event+0x36b/0x9e0 drivers/infiniband/core/roce_gid_mgmt.c:823
>  notifier_call_chain+0xb9/0x420 kernel/notifier.c:85
>  call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2206
>  __netdev_upper_dev_unlink+0x14c/0x430 net/core/dev.c:8459
>  netdev_upper_dev_unlink+0x7f/0xb0 net/core/dev.c:8486
>  del_nbp+0x70d/0xd20 net/bridge/br_if.c:363
>  br_dev_delete+0x99/0x1a0 net/bridge/br_if.c:386
>  br_net_exit_batch_rtnl+0x116/0x1f0 net/bridge/br.c:376
>  cleanup_net+0x551/0xb80 net/core/net_namespace.c:645
>  process_one_work+0x9f9/0x1bd0 kernel/workqueue.c:3245
>  process_scheduled_works kernel/workqueue.c:3329 [inline]
>  worker_thread+0x674/0xe70 kernel/workqueue.c:3410
>  kthread+0x3af/0x760 kernel/kthread.c:464
>  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>  </task>
> 
> Allocated by task 1:
>  kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
>  kasan_save_track+0x14/0x30 mm/kasan/common.c:68
>  poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
>  __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
>  kasan_kmalloc include/linux/kasan.h:260 [inline]
>  __do_kmalloc_node mm/slub.c:4318 [inline]
>  __kmalloc_noprof+0x219/0x540 mm/slub.c:4330
>  kmalloc_noprof include/linux/slab.h:906 [inline]
>  kzalloc_noprof include/linux/slab.h:1036 [inline]
>  cgroup_create kernel/cgroup/cgroup.c:5677 [inline]
>  cgroup_mkdir+0x254/0x10d0 kernel/cgroup/cgroup.c:5827
>  kernfs_iop_mkdir+0x15a/0x1f0 fs/kernfs/dir.c:1247
>  vfs_mkdir+0x593/0x8d0 fs/namei.c:4324
>  do_mkdirat+0x2dc/0x3d0 fs/namei.c:4357
>  __do_sys_mkdir fs/namei.c:4379 [inline]
>  __se_sys_mkdir fs/namei.c:4377 [inline]
>  __x64_sys_mkdir+0xf3/0x140 fs/namei.c:4377
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xcb/0x250 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Freed by task 12064:
>  kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
>  kasan_save_track+0x14/0x30 mm/kasan/common.c:68
>  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576
>  poison_slab_object mm/kasan/common.c:247 [inline]
>  __kasan_slab_free+0x54/0x70 mm/kasan/common.c:264
>  kasan_slab_free include/linux/kasan.h:233 [inline]
>  slab_free_hook mm/slub.c:2376 [inline]
>  slab_free mm/slub.c:4633 [inline]
>  kfree+0x148/0x4d0 mm/slub.c:4832
>  css_free_rwork_fn+0x58f/0x1250 kernel/cgroup/cgroup.c:5435
>  process_one_work+0x9f9/0x1bd0 kernel/workqueue.c:3245
>  process_scheduled_works kernel/workqueue.c:3329 [inline]
>  worker_thread+0x674/0xe70 kernel/workqueue.c:3410
>  kthread+0x3af/0x760 kernel/kthread.c:464
>  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> 
> Last potentially related work creation:
>  kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
>  kasan_record_aux_stack+0xb8/0xd0 mm/kasan/generic.c:548
>  insert_work+0x36/0x230 kernel/workqueue.c:2183
>  __queue_work+0x9d1/0x1110 kernel/workqueue.c:2344
>  rcu_work_rcufn+0x5c/0x90 kernel/workqueue.c:2613
>  rcu_do_batch kernel/rcu/tree.c:2568 [inline]
>  rcu_core+0x79e/0x14f0 kernel/rcu/tree.c:2824
>  handle_softirqs+0x1d1/0x870 kernel/softirq.c:561
>  __do_softirq kernel/softirq.c:595 [inline]
>  invoke_softirq kernel/softirq.c:435 [inline]
>  __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662
>  irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
>  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
>  sysvec_apic_timer_interrupt+0xa8/0xc0 arch/x86/kernel/apic/apic.c:1049
>  asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
> 
> Second to last potentially related work creation:
>  kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
>  kasan_record_aux_stack+0xb8/0xd0 mm/kasan/generic.c:548
>  __call_rcu_common.constprop.0+0x99/0x9e0 kernel/rcu/tree.c:3082
>  call_rcu_hurry include/linux/rcupdate.h:115 [inline]
>  queue_rcu_work+0xa9/0xe0 kernel/workqueue.c:2638
>  process_one_work+0x9f9/0x1bd0 kernel/workqueue.c:3245
>  process_scheduled_works kernel/workqueue.c:3329 [inline]
>  worker_thread+0x674/0xe70 kernel/workqueue.c:3410
>  kthread+0x3af/0x760 kernel/kthread.c:464
>  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> 
> The buggy address belongs to the object at ffff888044f1a000
>  which belongs to the cache kmalloc-4k of size 4096
> The buggy address is located 1408 bytes inside of
>  freed 4096-byte region [ffff888044f1a000, ffff888044f1b000)
> 
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x44f18
> head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> anon flags: 0x4fff00000000040(head|node=1|zone=1|lastcpupid=0x7ff)
> page_type: f5(slab)
> raw: 04fff00000000040 ffff88801b042140 0000000000000000 dead000000000001
> raw: 0000000000000000 0000000000040004 00000000f5000000 0000000000000000
> head: 04fff00000000040 ffff88801b042140 0000000000000000 dead000000000001
> head: 0000000000000000 0000000000040004 00000000f5000000 0000000000000000
> head: 04fff00000000003 ffffea000113c601 ffffffffffffffff 0000000000000000
> head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2040(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (systemd), ts 113702677351, free_ts 113428419852
>  set_page_owner include/linux/page_owner.h:32 [inline]
>  post_alloc_hook+0x193/0x1c0 mm/page_alloc.c:1551
>  prep_new_page mm/page_alloc.c:1559 [inline]
>  get_page_from_freelist+0xe41/0x2b40 mm/page_alloc.c:3477
>  __alloc_frozen_pages_noprof+0x21b/0x2200 mm/page_alloc.c:4740
>  alloc_pages_mpol+0x1f1/0x540 mm/mempolicy.c:2301
>  alloc_slab_page mm/slub.c:2446 [inline]
>  allocate_slab mm/slub.c:2610 [inline]
>  new_slab+0x242/0x340 mm/slub.c:2663
>  ___slab_alloc+0xb5f/0x1730 mm/slub.c:3849
>  __slab_alloc.constprop.0+0x56/0xb0 mm/slub.c:3939
>  __slab_alloc_node mm/slub.c:4014 [inline]
>  slab_alloc_node mm/slub.c:4175 [inline]
>  __do_kmalloc_node mm/slub.c:4317 [inline]
>  __kmalloc_noprof+0x2b2/0x540 mm/slub.c:4330
>  kmalloc_noprof include/linux/slab.h:906 [inline]
>  tomoyo_realpath_from_path+0xc3/0x600 security/tomoyo/realpath.c:251
>  tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
>  tomoyo_check_open_permission+0x298/0x3a0 security/tomoyo/file.c:771
>  tomoyo_file_open+0x69/0x90 security/tomoyo/tomoyo.c:334
>  security_file_open+0x88/0x200 security/security.c:3114
>  do_dentry_open+0x575/0x1c20 fs/open.c:933
>  vfs_open+0x82/0x3f0 fs/open.c:1086
>  do_open fs/namei.c:3845 [inline]
>  path_openat+0x1d53/0x2960 fs/namei.c:4004
>  do_filp_open+0x1f7/0x460 fs/namei.c:4031
> page last free pid 1 tgid 1 stack trace:
>  reset_page_owner include/linux/page_owner.h:25 [inline]
>  free_pages_prepare mm/page_alloc.c:1127 [inline]
>  free_frozen_pages+0x719/0xfe0 mm/page_alloc.c:2660
>  discard_slab mm/slub.c:2707 [inline]
>  __put_partials+0x176/0x1d0 mm/slub.c:3176
>  qlink_free mm/kasan/quarantine.c:163 [inline]
>  qlist_free_all+0x50/0x120 mm/kasan/quarantine.c:179
>  kasan_quarantine_reduce+0x195/0x1e0 mm/kasan/quarantine.c:286
>  __kasan_slab_alloc+0x67/0x90 mm/kasan/common.c:329
>  kasan_slab_alloc include/linux/kasan.h:250 [inline]
>  slab_post_alloc_hook mm/slub.c:4138 [inline]
>  slab_alloc_node mm/slub.c:4187 [inline]
>  kmem_cache_alloc_noprof+0x160/0x3e0 mm/slub.c:4194
>  getname_flags.part.0+0x48/0x540 fs/namei.c:146
>  getname_flags+0x95/0xe0 include/linux/audit.h:322
>  user_path_at+0x27/0x90 fs/namei.c:3084
>  __do_sys_chdir fs/open.c:557 [inline]
>  __se_sys_chdir fs/open.c:551 [inline]
>  __x64_sys_chdir+0xb6/0x260 fs/open.c:551
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xcb/0x250 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Memory state around the buggy address:
>  ffff888044f1a480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff888044f1a500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> &gt;ffff888044f1a580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                    ^
>  ffff888044f1a600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff888044f1a680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
> 
> 
> I hope it helps.
> Best regards
> Jianzhou Zhao</superman.xpt@gmail.com></xrivendell7@gmail.com></xnxc22xnxc22@qq.com>


Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: KASAN: slab-use-after-free Read in cgroup_rstat_flush

[tj]

On Mon, Apr 14, 2025 at 07:40:04PM +0200, Michal Koutný wrote:
> Hello.
> 
> On Mon, Apr 07, 2025 at 07:59:58AM -0400, ffhgfv <xnxc22xnxc22@qq.com> wrote:
> > Hello, I found a bug titled "   KASAN: slab-use-after-free Read in cgroup_rstat_flush " with modified syzkaller in the Linux6.14.
> > If you fix this issue, please add the following tag to the commit:  Reported-by: Jianzhou Zhao <xnxc22xnxc22@qq.com>,    xingwei lee <xrivendell7@gmail.com>,Penglei Jiang <superman.xpt@gmail.com>
> > I use the same kernel as syzbot instance upstream: f6e0150b2003fb2b9265028a618aa1732b3edc8f
> > kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&amp;x=da4b04ae798b7ef6
> > compiler: gcc version 11.4.0
> > 
> > Unfortunately, we do not have a repro.
> 
> Thanks for sharing the report.
> 
> > ------------[ cut here ]-----------------------------------------
> >  TITLE:  KASAN: slab-use-after-free Read in cgroup_rstat_flush
> > ==================================================================
> > bridge_slave_0: left allmulticast mode
> > bridge_slave_0: left promiscuous mode
> > bridge0: port 1(bridge_slave_0) entered disabled state
> > ==================================================================
> > BUG: KASAN: slab-use-after-free in cgroup_rstat_cpu kernel/cgroup/rstat.c:19 [inline]
> > BUG: KASAN: slab-use-after-free in cgroup_base_stat_flush kernel/cgroup/rstat.c:422 [inline]
> > BUG: KASAN: slab-use-after-free in cgroup_rstat_flush+0x16ce/0x2180 kernel/cgroup/rstat.c:328
> 
> I read this like the struct cgroup is gone when the code try flushing
> its respective stats (its ->rstat_cpu more precisely).
> 
> Namely,
> 	__mem_cgroup_flush_stats
> 		cgroup_rstat_flush(memcg->css.cgroup);
> this reference is taken at cgroup creation in init_and_link_css()
> and released only in css_free_rwork_fn().

Maybe another casualty of the bug fixed by a22b3d54de94 ("cgroup/cpuset: Fix
race between newly created partition and dying one")?

Thanks.

-- 
tejun

Re: KASAN: slab-use-after-free Read in cgroup_rstat_flush

[Waiman Long]

On 4/14/25 1:42 PM, tj wrote:
> On Mon, Apr 14, 2025 at 07:40:04PM +0200, Michal Koutný wrote:
>> Hello.
>>
>> On Mon, Apr 07, 2025 at 07:59:58AM -0400, ffhgfv <xnxc22xnxc22@qq.com> wrote:
>>> Hello, I found a bug titled "   KASAN: slab-use-after-free Read in cgroup_rstat_flush " with modified syzkaller in the Linux6.14.
>>> If you fix this issue, please add the following tag to the commit:  Reported-by: Jianzhou Zhao <xnxc22xnxc22@qq.com>,    xingwei lee <xrivendell7@gmail.com>,Penglei Jiang <superman.xpt@gmail.com>
>>> I use the same kernel as syzbot instance upstream: f6e0150b2003fb2b9265028a618aa1732b3edc8f
>>> kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&amp;x=da4b04ae798b7ef6
>>> compiler: gcc version 11.4.0
>>>
>>> Unfortunately, we do not have a repro.
>> Thanks for sharing the report.
>>
>>> ------------[ cut here ]-----------------------------------------
>>>   TITLE:  KASAN: slab-use-after-free Read in cgroup_rstat_flush
>>> ==================================================================
>>> bridge_slave_0: left allmulticast mode
>>> bridge_slave_0: left promiscuous mode
>>> bridge0: port 1(bridge_slave_0) entered disabled state
>>> ==================================================================
>>> BUG: KASAN: slab-use-after-free in cgroup_rstat_cpu kernel/cgroup/rstat.c:19 [inline]
>>> BUG: KASAN: slab-use-after-free in cgroup_base_stat_flush kernel/cgroup/rstat.c:422 [inline]
>>> BUG: KASAN: slab-use-after-free in cgroup_rstat_flush+0x16ce/0x2180 kernel/cgroup/rstat.c:328
>> I read this like the struct cgroup is gone when the code try flushing
>> its respective stats (its ->rstat_cpu more precisely).
>>
>> Namely,
>> 	__mem_cgroup_flush_stats
>> 		cgroup_rstat_flush(memcg->css.cgroup);
>> this reference is taken at cgroup creation in init_and_link_css()
>> and released only in css_free_rwork_fn().
> Maybe another casualty of the bug fixed by a22b3d54de94 ("cgroup/cpuset: Fix
> race between newly created partition and dying one")?

You mean the rcu_read_lock isn't held for the entire flushing operation 
so that the cgroup structure itself may have been freed near the end. Right?

Cheers,
Longman

>
> Thanks.
>

Re: KASAN: slab-use-after-free Read in cgroup_rstat_flush

[Penglei Jiang]

On Mon, 14 Apr 2025 07:42:30 -1000, tj <tj@kernel.org> wrote:

> Maybe another casualty of the bug fixed by a22b3d54de94 ("cgroup/cpuset: Fix
> race between newly created partition and dying one")?

This issue was maybe caused by commit 093c8812de2d3, and was later fixed
by commit 7d6c63c319142.

Re: KASAN: slab-use-after-free Read in cgroup_rstat_flush

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Sat, Apr 19, 2025 at 08:38:43AM -0700, Penglei Jiang <superman.xpt@gmail.com> wrote:
> On Mon, 14 Apr 2025 07:42:30 -1000, tj <tj@kernel.org> wrote:
> 
> > Maybe another casualty of the bug fixed by a22b3d54de94 ("cgroup/cpuset: Fix
> > race between newly created partition and dying one")?
> 
> This issue was maybe caused by commit 093c8812de2d3, and was later fixed
> by commit 7d6c63c319142.

Ah, I overlooked that the original report is not for v6.14 but
f6e0150b2003 actually (correct?), so this is sensible in that context.

Does it mean you cannot attain the KASAN report post 7d6c63c319142?

Thanks,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]