From: Thomas Gleixner <tglx@kernel.org>
To: syzbot <syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com>,
anna-maria@linutronix.de, frederic@kernel.org,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Cc: Surya Sai Madhu <suryasaimadhu369@gmail.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: [PATCH] debugobjects: Plug race against a concurrent OOM disable
Date: Sun, 21 Jun 2026 16:47:44 +0200 [thread overview]
Message-ID: <874iiwlzlb.ffs@fw13> (raw)
In-Reply-To: <87y0g8nbe4.ffs@fw13>
syzbot reported a puzzling splat:
WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20
stub_timer() is installed as timer callback function in
hrtimer_fixup_assert_init(), which is invoked when
debug_object_assert_init() can't find a shadow object. In that case debug
objects emits a warning about it before invoking the fixup.
Though the provided console log lacks this warning and instead has the
following a few seconds before the splat:
ODEBUG: Out of memory. ODEBUG disabled
So the object was looked up in debug_object_assert_init() and the lookup
failed due a concurrent out of memory situation which disabled debug
objects and freed the shadow objects:
debug_object_assert_init()
if (!debug_objects_enabled)
return; obj = alloc();
if (!obj) {
// Out of memory
debug_objects_enabled = false;
free_objects();
obj = lookup_or_alloc();
// The lookup failed because the other side
// removed the objects, so this returns
// an error code as the object in question
// is not statically initialized
if (!IS_ERR_OR_NULL(obj))
return;
if (!obj) {
debug_oom();
return;
}
print(...)
if (!debug_objects_enabled)
return;
fixup(...)
The debug object splat is skipped because debug_objects_enabled is false,
but the fixup callback is invoked unconditionally, which makes the timer
disfunctional.
This is only a problem in debug_object_assert_init() and
debug_object_activate() as both have to handle statically initialized
objects and therefore must handle the error pointer return case
gracefully. All other places only handle the found/not found case and the
NULL pointer return is a signal for OOM. Otherwise they get a valid shadow
object.
Plug the hole by checking whether debug objects are still enabled before
invoking the print and fixup function in those two places.
Fixes: b84d435cc228 ("debugobjects: Extend to assert that an object is initialized")
Reported-by: syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: stable@vger.kernel.org
---
lib/debugobjects.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -894,6 +894,14 @@ int debug_object_activate(void *addr, co
}
raw_spin_unlock_irqrestore(&db->lock, flags);
+
+ /*
+ * lookup_object_or_alloc() might have raced with a concurrent
+ * allocation failure which disabled debug objects.
+ */
+ if (!debug_objects_enabled)
+ return 0;
+
debug_print_object(&o, "activate");
switch (o.state) {
@@ -1071,6 +1079,15 @@ void debug_object_assert_init(void *addr
return;
}
+ /*
+ * lookup_object_or_alloc() might have raced with a concurrent
+ * allocation failure which disabled debug objects. Don't run the fixup
+ * as it might turn a valid object useless. See for example
+ * hrtimer_fixup_assert_init().
+ */
+ if (!debug_objects_enabled)
+ return;
+
/* Object is neither tracked nor static. It's not initialized. */
debug_print_object(&o, "assert_init");
debug_object_fixup(descr->fixup_assert_init, addr, ODEBUG_STATE_NOTAVAILABLE);
prev parent reply other threads:[~2026-06-21 14:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 7:39 [syzbot] [kernel?] WARNING in stub_timer (2) syzbot
2026-06-20 21:35 ` Thomas Gleixner
2026-06-21 14:47 ` Thomas Gleixner [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=874iiwlzlb.ffs@fw13 \
--to=tglx@kernel.org \
--cc=anna-maria@linutronix.de \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=suryasaimadhu369@gmail.com \
--cc=syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox