[PATCH] mm/vmalloc: fix KMSAN uninit-value warning in decay_va_pool_node()

[PATCH] mm/vmalloc: fix KMSAN uninit-value warning in decay_va_pool_node()

[Qing Wang]

KMSAN reported an uninit-value warning when accessing vmap_area->list
in decay_va_pool_node():

  BUG: KMSAN: uninit-value in __list_del_entry_valid include/linux/list.h:-1 [inline]
  BUG: KMSAN: uninit-value in __list_del_entry include/linux/list.h:223 [inline]
  BUG: KMSAN: uninit-value in list_del_init include/linux/list.h:295 [inline]
  BUG: KMSAN: uninit-value in decay_va_pool_node+0xf78/0x1dd0 mm/vmalloc.c:2255

  Uninit was created at:
   kmem_cache_alloc_node_noprof+0x3cd/0x12d0 mm/slub.c:4918
   alloc_vmap_area+0x327/0x2e30 mm/vmalloc.c:2065

The root cause is that if node_alloc() fail and the va is allocated via
kmem_cache_alloc_node() by alloc_vmap_area(), va->list will be uninitialized.

Fix this by explicitly initializing va->list after allocation.

Reported-by: syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=37b7f6cd519f7fb8d32a
Signed-off-by: Qing Wang <wangqing7171@gmail.com>
---
 mm/vmalloc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 61caa55a4402..8aebbb51e178 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2071,6 +2071,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
 		 * to avoid false negatives.
 		 */
 		kmemleak_scan_area(&va->rb_node, SIZE_MAX, gfp_mask);
+		INIT_LIST_HEAD(&va->list);
 	}
 
 retry:
-- 
2.34.1

Re: [PATCH] mm/vmalloc: fix KMSAN uninit-value warning in decay_va_pool_node()

[Uladzislau Rezki]

Hello, Qing Wang!

Let me check it close!

On Thu, Apr 2, 2026 at 10:14 AM Qing Wang <wangqing7171@gmail.com> wrote:
>
> KMSAN reported an uninit-value warning when accessing vmap_area->list
> in decay_va_pool_node():
>
>   BUG: KMSAN: uninit-value in __list_del_entry_valid include/linux/list.h:-1 [inline]
>   BUG: KMSAN: uninit-value in __list_del_entry include/linux/list.h:223 [inline]
>   BUG: KMSAN: uninit-value in list_del_init include/linux/list.h:295 [inline]
>   BUG: KMSAN: uninit-value in decay_va_pool_node+0xf78/0x1dd0 mm/vmalloc.c:2255
>
>   Uninit was created at:
>    kmem_cache_alloc_node_noprof+0x3cd/0x12d0 mm/slub.c:4918
>    alloc_vmap_area+0x327/0x2e30 mm/vmalloc.c:2065
>
> The root cause is that if node_alloc() fail and the va is allocated via
> kmem_cache_alloc_node() by alloc_vmap_area(), va->list will be uninitialized.
>
> Fix this by explicitly initializing va->list after allocation.
>
> Reported-by: syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=37b7f6cd519f7fb8d32a
> Signed-off-by: Qing Wang <wangqing7171@gmail.com>
> ---
>  mm/vmalloc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 61caa55a4402..8aebbb51e178 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2071,6 +2071,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
>                  * to avoid false negatives.
>                  */
>                 kmemleak_scan_area(&va->rb_node, SIZE_MAX, gfp_mask);
> +               INIT_LIST_HEAD(&va->list);
>         }
>
>  retry:
> --
> 2.34.1
>


-- 
Uladzislau Rezki

Re: [PATCH] mm/vmalloc: fix KMSAN uninit-value warning in decay_va_pool_node()

[Uladzislau Rezki]

On Thu, Apr 02, 2026 at 04:14:13PM +0800, Qing Wang wrote:
> KMSAN reported an uninit-value warning when accessing vmap_area->list
> in decay_va_pool_node():
> 
>   BUG: KMSAN: uninit-value in __list_del_entry_valid include/linux/list.h:-1 [inline]
>   BUG: KMSAN: uninit-value in __list_del_entry include/linux/list.h:223 [inline]
>   BUG: KMSAN: uninit-value in list_del_init include/linux/list.h:295 [inline]
>   BUG: KMSAN: uninit-value in decay_va_pool_node+0xf78/0x1dd0 mm/vmalloc.c:2255
> 
>   Uninit was created at:
>    kmem_cache_alloc_node_noprof+0x3cd/0x12d0 mm/slub.c:4918
>    alloc_vmap_area+0x327/0x2e30 mm/vmalloc.c:2065
> 
> The root cause is that if node_alloc() fail and the va is allocated via
> kmem_cache_alloc_node() by alloc_vmap_area(), va->list will be uninitialized.
> 
> Fix this by explicitly initializing va->list after allocation.
> 
> Reported-by: syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=37b7f6cd519f7fb8d32a
>
I can not access two above links. Are they valid? I would like to have
a look at report.

> Signed-off-by: Qing Wang <wangqing7171@gmail.com>
> ---
>  mm/vmalloc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 61caa55a4402..8aebbb51e178 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2071,6 +2071,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
>  		 * to avoid false negatives.
>  		 */
>  		kmemleak_scan_area(&va->rb_node, SIZE_MAX, gfp_mask);
> +		INIT_LIST_HEAD(&va->list);
>  	}
>
va->list does not require to be initialized. Because:

	spin_lock(&vn->busy.lock);
	insert_vmap_area(va, &vn->busy.root, &vn->busy.head);
	spin_unlock(&vn->busy.lock);

when a node is inserted into list_head, its next/prev pointers are
properly set by the list_add().

Or, am i missing something?

--
Uladzislau Rezki

Re: [PATCH] mm/vmalloc: fix KMSAN uninit-value warning in decay_va_pool_node()

[Qing Wang]

On Thu, 02 Apr 2026 at 23:45, Uladzislau Rezki <urezki@gmail.com> wrote:
> > KMSAN reported an uninit-value warning when accessing vmap_area->list
> > in decay_va_pool_node():
> > 
> >   BUG: KMSAN: uninit-value in __list_del_entry_valid include/linux/list.h:-1 [inline]
> >   BUG: KMSAN: uninit-value in __list_del_entry include/linux/list.h:223 [inline]
> >   BUG: KMSAN: uninit-value in list_del_init include/linux/list.h:295 [inline]
> >   BUG: KMSAN: uninit-value in decay_va_pool_node+0xf78/0x1dd0 mm/vmalloc.c:2255
> > 
> >   Uninit was created at:
> >    kmem_cache_alloc_node_noprof+0x3cd/0x12d0 mm/slub.c:4918
> >    alloc_vmap_area+0x327/0x2e30 mm/vmalloc.c:2065
> > 
> > The root cause is that if node_alloc() fail and the va is allocated via
> > kmem_cache_alloc_node() by alloc_vmap_area(), va->list will be uninitialized.
> > 
> > Fix this by explicitly initializing va->list after allocation.
> > 
> > Reported-by: syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=37b7f6cd519f7fb8d32a
> >
> I can not access two above links. Are they valid? I would like to have
> a look at report.

I recheck the 'Closes' link and it's valid.

> 
> > Signed-off-by: Qing Wang <wangqing7171@gmail.com>
> > ---
> >  mm/vmalloc.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 61caa55a4402..8aebbb51e178 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -2071,6 +2071,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
> >  		 * to avoid false negatives.
> >  		 */
> >  		kmemleak_scan_area(&va->rb_node, SIZE_MAX, gfp_mask);
> > +		INIT_LIST_HEAD(&va->list);
> >  	}
> >
> va->list does not require to be initialized. Because:
> 
> 	spin_lock(&vn->busy.lock);
> 	insert_vmap_area(va, &vn->busy.root, &vn->busy.head);
> 	spin_unlock(&vn->busy.lock);
> 
> when a node is inserted into list_head, its next/prev pointers are
> properly set by the list_add().
> 
> Or, am i missing something?
> 
> --
> Uladzislau Rezki

First, va->list is inserted into the list_head when insert_vmap_area()
calls link_va(). However, if find_va_links() returns NULL, link_va()
will not be called, leaving va->list uninitialized.

Second, even if link_va() is called, list_add() will still invoke
__list_add_valid() which reads va->list fields (prev/next). Under KMSAN,
this will also report a same uninit-value error.

--
Best Regards,
Qing

Re: [PATCH] mm/vmalloc: fix KMSAN uninit-value warning in decay_va_pool_node()

[Morduan Zang]

On Fri, 03 Apr 2026, Qing Wang wrote:
> First, va->list is inserted into the list_head when insert_vmap_area()
> calls link_va(). However, if find_va_links() returns NULL, link_va()
> will not be called, leaving va->list uninitialized.
> 
> Second, even if link_va() is called, list_add() will still invoke
> __list_add_valid() which reads va->list fields (prev/next). Under KMSAN,
> this will also report a same uninit-value error.

Hi Qing,

While adding INIT_LIST_HEAD(&va->list) in alloc_vmap_area() would indeed
silence the KMSAN warning, I'm concerned that it might only be masking 
a deeper issue rather than fixing the root cause.

It seems that the uninitialized access in decay_va_pool_node() suggests 
a potential race condition where nodes from a concurrently repopulated 
pool might be lost or the list structure could be incorrectly overwritten 
during list_replace_init().

Instead of just initializing the list head to satisfy KMSAN, should we 
consider modifying decay_va_pool_node() to avoid using list_replace_init() 
which might drop concurrent repopulate nodes? Perhaps using list_splice() 
or a proper merge of the leftover VAs would be a more robust fix for 
the underlying synchronization issue.

What do you and Uladzislau think?

Best regards,
Morduang

Re: [PATCH] mm/vmalloc: fix KMSAN uninit-value warning in decay_va_pool_node()

[Qing Wang]

On Fri, 03 Apr 2026 at 11:30, Morduan Zang <zhangdandan@uniontech.com> wrote:
> While adding INIT_LIST_HEAD(&va->list) in alloc_vmap_area() would indeed
> silence the KMSAN warning, I'm concerned that it might only be masking 
> a deeper issue rather than fixing the root cause.
> 
> It seems that the uninitialized access in decay_va_pool_node() suggests 
> a potential race condition where nodes from a concurrently repopulated 
> pool might be lost or the list structure could be incorrectly overwritten 
> during list_replace_init().
> 
> Instead of just initializing the list head to satisfy KMSAN, should we 
> consider modifying decay_va_pool_node() to avoid using list_replace_init() 
> which might drop concurrent repopulate nodes? Perhaps using list_splice() 
> or a proper merge of the leftover VAs would be a more robust fix for 
> the underlying synchronization issue.

Thank you very much for the reminder. I realized that my patch does not fix
the real issue(concurrent corruption of the list). Please ignore this patch
and let's focus on analyzing this concurrency issue.

---
Best Regards,
Qing

Re: [PATCH] mm/vmalloc: fix KMSAN uninit-value warning in decay_va_pool_node()

[Qing Wang]

On Thu, 02 Apr 2026 at 23:45, Uladzislau Rezki <urezki@gmail.com> wrote:
> > KMSAN reported an uninit-value warning when accessing vmap_area->list
> > in decay_va_pool_node():
> > 
> >   BUG: KMSAN: uninit-value in __list_del_entry_valid include/linux/list.h:-1 [inline]
> >   BUG: KMSAN: uninit-value in __list_del_entry include/linux/list.h:223 [inline]
> >   BUG: KMSAN: uninit-value in list_del_init include/linux/list.h:295 [inline]
> >   BUG: KMSAN: uninit-value in decay_va_pool_node+0xf78/0x1dd0 mm/vmalloc.c:2255
> > 
> >   Uninit was created at:
> >    kmem_cache_alloc_node_noprof+0x3cd/0x12d0 mm/slub.c:4918
> >    alloc_vmap_area+0x327/0x2e30 mm/vmalloc.c:2065
> > 
> > The root cause is that if node_alloc() fail and the va is allocated via
> > kmem_cache_alloc_node() by alloc_vmap_area(), va->list will be uninitialized.
> > 
> > Fix this by explicitly initializing va->list after allocation.
> > 
> > Reported-by: syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=37b7f6cd519f7fb8d32a
> >
> I can not access two above links. Are they valid? I would like to have
> a look at report.

Try to it?

https://lore.kernel.org/all/69cdff26.050a0220.2dbe29.0001.GAE@google.com/T/

[PATCH] mm/vmalloc: fix KMSAN uninit in decay_va_pool_node list handling

[chenyichong]

Prevent decay_va_pool_node from overwriting concurrent repopulation of
vmap_node pool[i].head while purging. Read/reset pool[i].len under
pool_lock and splice leftover vmap_area nodes back into the pool
instead of replacing the list.

Reported-by: syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=37b7f6cd519f7fb8d32a
Fixes: 7679ba6b36db ("mm: vmalloc: add a shrinker to drain vmap pools")
Signed-off-by: chenyichong <chenyichong@uniontech.com>
---
 mm/vmalloc.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ecbac900c35f..72fb60553a71 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2233,10 +2233,9 @@ decay_va_pool_node(struct vmap_node *vn, bool full_decay)
 		/* Detach the pool, so no-one can access it. */
 		spin_lock(&vn->pool_lock);
 		list_replace_init(&vn->pool[i].head, &tmp_list);
-		spin_unlock(&vn->pool_lock);
-
 		pool_len = n_decay = vn->pool[i].len;
 		WRITE_ONCE(vn->pool[i].len, 0);
+		spin_unlock(&vn->pool_lock);
 
 		/* Decay a pool by ~25% out of left objects. */
 		if (!full_decay)
@@ -2259,8 +2258,14 @@ decay_va_pool_node(struct vmap_node *vn, bool full_decay)
 		 */
 		if (!list_empty(&tmp_list)) {
 			spin_lock(&vn->pool_lock);
-			list_replace_init(&tmp_list, &vn->pool[i].head);
-			WRITE_ONCE(vn->pool[i].len, pool_len);
+			/*
+			 * Merge leftover areas back into the pool rather than
+			 * replacing the whole list. A concurrent allocator can
+			 * repopulate vn->pool[i].head while we are decaying
+			 * tmp_list, and replacing would drop those nodes.
+			 */
+			list_splice_tail_init(&tmp_list, &vn->pool[i].head);
+			WRITE_ONCE(vn->pool[i].len, vn->pool[i].len + pool_len);
 			spin_unlock(&vn->pool_lock);
 		}
 	}
-- 
2.50.1

Re: [PATCH] mm/vmalloc: fix KMSAN uninit in decay_va_pool_node list handling

[Uladzislau Rezki]

On Fri, Apr 03, 2026 at 03:52:03PM +0800, chenyichong wrote:
> Prevent decay_va_pool_node from overwriting concurrent repopulation of
> vmap_node pool[i].head while purging. Read/reset pool[i].len under
> pool_lock and splice leftover vmap_area nodes back into the pool
> instead of replacing the list.
> 
> Reported-by: syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=37b7f6cd519f7fb8d32a
> Fixes: 7679ba6b36db ("mm: vmalloc: add a shrinker to drain vmap pools")
> Signed-off-by: chenyichong <chenyichong@uniontech.com>
> ---
>  mm/vmalloc.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index ecbac900c35f..72fb60553a71 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2233,10 +2233,9 @@ decay_va_pool_node(struct vmap_node *vn, bool full_decay)
>  		/* Detach the pool, so no-one can access it. */
>  		spin_lock(&vn->pool_lock);
>  		list_replace_init(&vn->pool[i].head, &tmp_list);
> -		spin_unlock(&vn->pool_lock);
> -
>  		pool_len = n_decay = vn->pool[i].len;
>  		WRITE_ONCE(vn->pool[i].len, 0);
> +		spin_unlock(&vn->pool_lock);
>  
>  		/* Decay a pool by ~25% out of left objects. */
>  		if (!full_decay)
> @@ -2259,8 +2258,14 @@ decay_va_pool_node(struct vmap_node *vn, bool full_decay)
>  		 */
>  		if (!list_empty(&tmp_list)) {
>  			spin_lock(&vn->pool_lock);
> -			list_replace_init(&tmp_list, &vn->pool[i].head);
> -			WRITE_ONCE(vn->pool[i].len, pool_len);
> +			/*
> +			 * Merge leftover areas back into the pool rather than
> +			 * replacing the whole list. A concurrent allocator can
> +			 * repopulate vn->pool[i].head while we are decaying
> +			 * tmp_list, and replacing would drop those nodes.
> +			 */
> +			list_splice_tail_init(&tmp_list, &vn->pool[i].head);
> +			WRITE_ONCE(vn->pool[i].len, vn->pool[i].len + pool_len);
>
"A concurrent allocator can repopulate..." - Where is it done? Probably
you meant something different.

--
Uladzislau Rezki

Re: [PATCH] mm/vmalloc: fix KMSAN uninit in decay_va_pool_node list handling

[Uladzislau Rezki]

On Fri, Apr 03, 2026 at 12:55:31PM +0200, Uladzislau Rezki wrote:
> On Fri, Apr 03, 2026 at 03:52:03PM +0800, chenyichong wrote:
> > Prevent decay_va_pool_node from overwriting concurrent repopulation of
> > vmap_node pool[i].head while purging. Read/reset pool[i].len under
> > pool_lock and splice leftover vmap_area nodes back into the pool
> > instead of replacing the list.
> > 
> > Reported-by: syzbot+37b7f6cd519f7fb8d32a@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=37b7f6cd519f7fb8d32a
> > Fixes: 7679ba6b36db ("mm: vmalloc: add a shrinker to drain vmap pools")
> > Signed-off-by: chenyichong <chenyichong@uniontech.com>
> > ---
> >  mm/vmalloc.c | 13 +++++++++----
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index ecbac900c35f..72fb60553a71 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -2233,10 +2233,9 @@ decay_va_pool_node(struct vmap_node *vn, bool full_decay)
> >  		/* Detach the pool, so no-one can access it. */
> >  		spin_lock(&vn->pool_lock);
> >  		list_replace_init(&vn->pool[i].head, &tmp_list);
> > -		spin_unlock(&vn->pool_lock);
> > -
> >  		pool_len = n_decay = vn->pool[i].len;
> >  		WRITE_ONCE(vn->pool[i].len, 0);
> > +		spin_unlock(&vn->pool_lock);
> >  
> >  		/* Decay a pool by ~25% out of left objects. */
> >  		if (!full_decay)
> > @@ -2259,8 +2258,14 @@ decay_va_pool_node(struct vmap_node *vn, bool full_decay)
> >  		 */
> >  		if (!list_empty(&tmp_list)) {
> >  			spin_lock(&vn->pool_lock);
> > -			list_replace_init(&tmp_list, &vn->pool[i].head);
> > -			WRITE_ONCE(vn->pool[i].len, pool_len);
> > +			/*
> > +			 * Merge leftover areas back into the pool rather than
> > +			 * replacing the whole list. A concurrent allocator can
> > +			 * repopulate vn->pool[i].head while we are decaying
> > +			 * tmp_list, and replacing would drop those nodes.
> > +			 */
> > +			list_splice_tail_init(&tmp_list, &vn->pool[i].head);
> > +			WRITE_ONCE(vn->pool[i].len, vn->pool[i].len + pool_len);
> >
> "A concurrent allocator can repopulate..." - Where is it done? Probably
> you meant something different.
> 
Actually decay_va_pool_node() is not designed to be called concurrently.
See the comment:

<snip>
/*
 * Attach the pool back if it has been partly decayed.
 * Please note, it is supposed that nobody(other contexts)
 * can populate the pool therefore a simple list replace
 * operation takes place here.
 */
<snip>

but after adding the shrinker it may be called concurrently to
free some memory, if high memory pressure occurs. This is not good
because we can lose added VAs by the __purge_vmap_area_lazy()
helper. So it might leak memory.

That problem has been introduced by the  "mm: vmalloc: add a shrinker
to drain vmap pools" patch.

IMO, the best what we should do is to follow the design reflected
by the comment. It implies that shrinker has to decay holding the
vmap_purge_lock mutex.

--
Uladzislau Rezki