CVE-2026-68090

debugobjects: Plug race against a concurrent OOM disable

No scoreFix available

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.

Exploit likelihood

0.18%Unchanged since Aug 11, 2026

What each source reports

CVE List No score

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 stub_timer+0xa/0x20

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.

Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.

Record: CVE-2026-68090
Updated: 2026-11-02

EUVDEUVD-2026-55271 No score

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

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.

Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.

Record: EUVD-2026-55271
Updated: 2026-11-02

GitHub AdvisoriesGHSA-qrrw-365j-cfxh No score

In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race...

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

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.

Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.

Record: GHSA-qrrw-365j-cfxh
Updated: 2026-11-02

NVD No score

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

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.

Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.

Record: CVE-2026-68090
Updated: 2026-11-02

OSVCLSA-2026-1789986443 No score

kernel: Fix of 121 CVEs

dlm: validate length in dlm_search_rsb_tree {CVE-2026-43125}
mm/damon/core: validate ranges in damon_set_regions() {CVE-2026-68165}
netpoll: Fix deadlock in memory allocation under spinlock {CVE-2025-68169}
drm/amdkfd: Check bounds on CRIU restore queue type and mqd size {CVE-2026-68258}
gve: fix Rx queue stall on alloc failure {CVE-2026-68129}
drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved {CVE-2026-68234}
libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE {CVE-2026-68159}
media: v4l2-ctrls: validate HEVC active reference counts {CVE-2026-68206}
drm/i915/hdcp: check streams[] bounds before overflow {CVE-2026-68253}
drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() {CVE-2026-68245}
drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() {CVE-2026-68115}
drm/i915: Return NULL on error in active_instance {CVE-2026-68248}
smb: client: validate DFS referral PathConsumed {CVE-2026-68343}
ext4: fix use-after-free in update_super_work when racing with umount {CVE-2026-31446}
debugobjects: Plug race against a concurrent OOM disable {CVE-2026-68090}
HID: wacom: stop hardware after post-start probe failures {CVE-2026-68091}
drm/xe/pt: Reset current_op in xe_pt_update_ops_init() {CVE-2026-68264}
net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD {CVE-2026-68288}
drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() {CVE-2026-68113}
openvswitch: fix GSO userspace truncation underflow {CVE-2026-68123}
drm/amd/display: use kvzalloc to allocate struct dc {CVE-2026-68436}
drm/i915/gem: Add missing nospec on parallel submit slot {CVE-2026-68269}
Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update {CVE-2026-68394}
sctp: avoid auth_enable sysctl UAF during netns teardown {CVE-2026-68162}
wifi: mt76: mt7925: fix crash in reset link replay {CVE-2026-68307}
Bluetooth: hci_sync: extend conn_hash lookup critical sections {CVE-2026-68393}
drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU {CVE-2026-68243}
block: fix memory leak in __blkdev_issue_zero_pages {CVE-2026-68348}
drm/amdgpu/gfx: fix cleaner shader IB buffer overflow {CVE-2026-68276}
tracing: Do not call map->ops->elt_free() if elt_alloc() fails {CVE-2026-64173}
wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin {CVE-2026-68362}
ovl: check access to copy_file_range source with src mounter creds {CVE-2026-68448}
drm/nouveau: fix reversed error cleanup order in ucopy functions {CVE-2026-68271}
vxlan: require CAP_NET_ADMIN in the device netns for changelink {CVE-2026-68432}
drm/vmwgfx: Validate vmw_surface_metadata::array_size {CVE-2026-68446}
net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM {CVE-2026-68296}
Input: elan_i2c - prevent division by zero and arithmetic underflow {CVE-2026-64275}
iomap: fix out-of-bounds bitmap_set() with zero-length range {CVE-2026-68145}
vsock: fix lock inversion in vsock_assign_transport() {CVE-2025-40231}
ASoC: nau8821: Cancel delayed work on component remove {CVE-2026-45963}
ext4: validate p_idx bounds in ext4_ext_correct_indexes {CVE-2026-31449}
ipc: fix memleak if msg_init_ns failed in create_ipc_ns {CVE-2024-53175}
tls: make sure to abort the stream if headers are bogus {CVE-2025-39946}
ipv6: prevent infinite loop in rt6_nlmsg_size() {CVE-2025-38588}
gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPL {CVE-2026-23386}
xsk: validate MTU against usable frame size on bind {CVE-2026-43092}
RDMA/irdma: Harden depth calculation functions {CVE-2026-31491}
iavf: fix out-of-bounds writes in iavf_get_ethtool_stats() {CVE-2026-31505}
net/ip6_tunnel: Prevent perpetual tunnel growth {CVE-2025-40173}
net/mlx5: Fix deadlock between devlink lock and esw->wq {CVE-2026-43468}
mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0] {CVE-2026-31458}
fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling {CVE-2026-52946}
nvmet: move async event…

Record: CLSA-2026-1789986443
Updated: 2026-11-02

OSV No score

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 stub_timer+0xa/0x20

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.

Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.

Record: CVE-2026-68090
Updated: 2026-11-02

Show 22 moreShow less

OSVDEBIAN-CVE-2026-68090 No score

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.

Record: DEBIAN-CVE-2026-68090
Updated: 2026-11-02

OSVUBUNTU-CVE-2026-68090 No score

Record: UBUNTU-CVE-2026-68090
Updated: 2026-11-10

OSVUSN-8726-1 No score

linux, linux-aws, linux-aws-7.0, linux-gcp, linux-gke, linux-hwe-7.0, linux-realtime vulnerabilities

It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB) invalidation before memory writes made through the invalidated translation were globally observed. A local attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing memory protections or escalating privileges. (CVE-2025-10263)