linux-kernel - Re: [PATCH] mm/slub: zero-initialize slab object extensions to fix KMSAN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <82dafb42-ca29-4ea7-9c1f-114c10443237@suse.cz>
Date: Wed, 4 Feb 2026 22:34:11 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Osama Abdelkader <osama.abdelkader@...il.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Christoph Lameter
 <cl@...two.org>, David Rientjes <rientjes@...gle.com>,
 Roman Gushchin <roman.gushchin@...ux.dev>, Harry Yoo <harry.yoo@...cle.com>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Cc: syzbot+6e04171f00f33c0d62fb@...kaller.appspotmail.com
Subject: Re: [PATCH] mm/slub: zero-initialize slab object extensions to fix
 KMSAN

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@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=6e04171f00f33c0d62fb
> Signed-off-by: Osama Abdelkader <osama.abdelkader@...il.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