All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+4d078516add5f4f12cea@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org
Subject: Forwarded: [PATCH] mm/slub: fix kmemleak false positive in RCU sheaves
Date: Thu, 05 Nov 2026 04:59:54 -0800	[thread overview]
Message-ID: <6aec7dca.77d491d2.267b55.000b.GAE@google.com> (raw)
In-Reply-To: <6aebbd06.21d05368.325ed5.0000.GAE@google.com>

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: [PATCH] mm/slub: fix kmemleak false positive in RCU sheaves
Author: gowtham398gs@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

The SLUB allocator's sheaf caching layer allocates `struct slab_sheaf`
objects via `kmalloc_flags()`, which registers them with kmemleak
for leak tracking. When full RCU sheaves are retired in
`__kfree_rcu_sheaf()`, they are queued into RCU via
`call_rcu(&rcu_sheaf->rcu_head, rcu_free_sheaf)`.

While pending in RCU's singly-linked callback list, if any preceding
callback resides in memory untracked or ignored by kmemleak
(such as `struct slab` from `call_rcu(&slab->rcu_head, rcu_free_slab)`),
kmemleak cannot traverse the chain to reach subsequent callbacks.
Because `__alloc_empty_sheaf()` does not mark the sheaf with
`kmemleak_not_leak()`,kmemleak falsely flags pending RCU sheaves
as unreferenced memory leaks.

Applying `kmemleak_not_leak()` marks the sheaf metadata as grey,
preventing the false leak report while ensuring kmemleak still scans the
cached objects within `sheaf->objects[]`, whose freeing hooks
are deferred until `rcu_free_sheaf()` runs.

Reported-by: syzbot+4d078516add5f4f12cea@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=4d078516add5f4f12cea
Fixes: 36aad21d50d1 ("mm/slub: add RCU sheaf caching")

Signed-off-by: Gowtham S Bhushan <gowtham398gs@gmail.com>
---
 mm/slub.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/slub.c b/mm/slub.c
index 45e077c7526c..61cd77644c3b 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2856,6 +2856,8 @@ static struct slab_sheaf *__alloc_empty_sheaf(struct kmem_cache *s, gfp_t gfp,
 	if (unlikely(!sheaf))
 		return NULL;
 
+	kmemleak_not_leak(sheaf);
+
 	sheaf->cache = s;
 
 	stat(s, SHEAF_ALLOC);
-- 
2.56.0


      reply	other threads:[~2026-11-05 12:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 23:17 [syzbot] [btrfs?] [ext4?] [ntfs3?] memory leak in __pcs_replace_full_main syzbot
2026-11-05 12:59 ` syzbot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6aec7dca.77d491d2.267b55.000b.GAE@google.com \
    --to=syzbot+4d078516add5f4f12cea@syzkaller.appspotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.