CVE-2026-68090: debugobjects: Plug race against a concurrent OOM disable

In the Linux kernel, the following vulnerability has been resolved:

debugobjects: Plug race against a concurrent OOM disable

syzbot reported a puzzling splat:

WARNING: kernel/time/hrtimer.c:443 at stubtimer+0xa/0x20

stubtimer() is installed as timer callback function in hrtimerfixupassertinit(), which is invoked when debugobjectassertinit() 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 debugobjectassertinit() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects:

debugobjectassertinit() if (!debugobjectsenabled) return; obj = alloc(); if (!obj) { // Out of memory debugobjectsenabled = false; freeobjects(); obj = lookuporalloc();

// 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 (!ISERRORNULL(obj)) return; if (!obj) { debugoom(); return; }

print(...) if (!debugobjectsenabled) return;

fixup(...)

The debug object splat is skipped because debugobjectsenabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional.

This is only a problem in debugobjectassertinit() and debugobjectactivate() 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.