← All Advisories

Linux Kernel debugobjects OOM Disable Path Races Against a Concurrent hrtimer_fixup_assert_init Call, Producing a Spurious stub_timer Callback Warning

Last refreshed2026-09-28

Status: NEW  |  Advisory ID: CVE-2026-68090

Key Details

CVECVE-2026-68090

What to Know

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 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. (NVD)

References

SourceReference
NVDhttps://nvd.nist.gov/vuln/detail/CVE-2026-68090
CVEhttps://www.cve.org/CVERecord?id=CVE-2026-68090