KMSAN reports uninitialized reads in __memcg_slab_free_hook
when freeing sigqueue objects. Although kmalloc_nolock(__GFP_ZERO)
and kcalloc_node normally zero memory, some allocation paths
(fallbacks, early boot, reused slabs, or races) may leave objcg undefined.

Explicitly memset the obj_exts array after allocation to guarantee no
uninitialized reads in __memcg_slab_free_hook and preserve correct memcg
accounting.

Reported-by: syzbot+6e04171f00f33c0d62fb@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6e04171f00f33c0d62fb
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
---
 mm/slub.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/mm/slub.c b/mm/slub.c
index f77b7407c51b..e66d17ee7fa8 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2123,7 +2123,17 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
 		vec = kcalloc_node(objects, sizeof(struct slabobj_ext), gfp,
 				   slab_nid(slab));
 	}
-	if (!vec) {
+	/*
+	 * Explicitly zero the obj_exts array to ensure KMSAN recognizes it
+	 * as initialized. Although kmalloc_nolock and kcalloc_node normally
+	 * zero memory, KMSAN may not track this initialization in all cases,
+	 * especially during early boot or with certain allocation paths.
+	 * This explicit memset ensures KMSAN sees the initialization and
+	 * prevents uninitialized value warnings when accessing objcg fields.
+	 */
+	if (vec)
+		memset(vec, 0, objects * sizeof(*vec));
+	else {
 		/*
 		 * Try to mark vectors which failed to allocate.
 		 * If this operation fails, there may be a racing process
-- 
2.43.0

On 2/4/26 20:57, Osama Abdelkader wrote:
> KMSAN reports uninitialized reads in __memcg_slab_free_hook
> when freeing sigqueue objects. Although kmalloc_nolock(__GFP_ZERO)
> and kcalloc_node normally zero memory, some allocation paths
> (fallbacks, early boot, reused slabs, or races) may leave objcg undefined.
> 
> Explicitly memset the obj_exts array after allocation to guarantee no
> uninitialized reads in __memcg_slab_free_hook and preserve correct memcg
> accounting.
> 
> Reported-by: syzbot+6e04171f00f33c0d62fb@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=6e04171f00f33c0d62fb
> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> ---
>  mm/slub.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index f77b7407c51b..e66d17ee7fa8 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2123,7 +2123,17 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
>  		vec = kcalloc_node(objects, sizeof(struct slabobj_ext), gfp,
>  				   slab_nid(slab));
>  	}
> -	if (!vec) {
> +	/*
> +	 * Explicitly zero the obj_exts array to ensure KMSAN recognizes it
> +	 * as initialized. Although kmalloc_nolock and kcalloc_node normally
> +	 * zero memory, KMSAN may not track this initialization in all cases,
> +	 * especially during early boot or with certain allocation paths.
> +	 * This explicit memset ensures KMSAN sees the initialization and
> +	 * prevents uninitialized value warnings when accessing objcg fields.
> +	 */

This explanation makes no sense to me. The kcalloc or kmalloc with
__GFP_ZERO above has just cleared the object, and this is just clearing it
again. It didn't happen sometimes in the past where KMSAN wouldn't track this.

The bug must have a different explanation, such as getting an invalid
pointer to kmem_cache_free(). Too bad it doesn't report any details about
the address.

> +	if (vec)
> +		memset(vec, 0, objects * sizeof(*vec));
> +	else {
>  		/*
>  		 * Try to mark vectors which failed to allocate.
>  		 * If this operation fails, there may be a racing process