CVE-2026-68090
Low risk· EPSS 7%Exploitation Probability (EPSS)
Low risk7th percentile - higher than 7% of all known CVEs
Summary
A vulnerability in the Linux kernel's debugobjects mechanism allows a race condition during concurrent OOM disable. This can cause debug_object_assert_init() and debug_object_activate() to invoke fixup callbacks even when debugging is disabled, leading to malfunctioning timers (e.g., hrtimer).
Risk Assessment
The vulnerability may cause system crashes or unpredictable behavior, especially in memory-constrained environments where the race can be triggered. This could disrupt critical services relying on kernel timers.
Recommendation
Apply the official patch from your Linux kernel distributor as soon as possible. Also monitor ODEBUG messages in system logs and consider increasing memory limits for kernel processes if feasible.
Other vulnerabilities in Linux kernel
See all- CVE-2026-99259Unknown
In the Linux kernel, the soc/tegra: pmc driver has an uninitialised early_pmc->rate variable for legacy 32-bit Tegra devices. The variable is never configured and remains 0, triggering a warning in tegra_pmc_enter_suspend_mode(). The issue appeared after the PMC driver was changed to create the PMC context dynamically, updating rate only in the new context.
- CVE-2026-99258Unknown
In the Linux kernel, hv_apicid_to_vp_index() uses per-CPU hypercall input and output pages. In an SEV-SNP CoCo VM without a paravisor the output page is not allocated, so the hypervisor stores the resulting VP index into memory not allocated by the guest. The fix uses the input page for both input and output.
- CVE-2026-99257Unknown
In the Linux kernel, the shared GPIO mechanism based on platform lookup tables requires an associated struct device. An fwnode-based lookup with no associated device currently causes a NULL-pointer dereference. The fix adds a check that lets the kernel gracefully handle this situation with an error.
- CVE-2026-99256Unknown
In the Linux kernel, the dm cache module used a rw_semaphore for background_work_lock, although write locks on rw_semaphores have strict owner semantics. The locking process was not always the same as the unlocking one, triggering a warning with CONFIG_DEBUG_RWSEMS during suspend/resume of a cache device. The fix replaces the rw_semaphore with a spinlock and a wait queue.
- CVE-2026-99251Unknown
In the Linux kernel, init_vp_index() contains a retry loop that strips CPUs from a node if they are already in the allocated cpumask or outside the HK_TYPE_MANAGED_IRQ housekeeping cpumask. If the housekeeping cpumask contains no CPU in that node, the loop becomes infinite. The fix skips NUMA nodes with no housekeeping CPU and aborts early when no online housekeeping CPUs exist.
- CVE-2026-99250Unknown
In the Linux kernel, the NBCON console printing kthreads are started very early during boot via early_initcall(). Asynchronously enabling/disabling interrupts during early boot may interfere with early SMP setup on some hardware platforms, causing hangs. The fix postpones kthread startup until after all arch initcalls have completed.
- CVE-2026-99249Unknown
In the Linux kernel, zap_pid_ns_processes() waiting for PID namespace cleanup was not freezable. A tracer outside the namespace that does not reap its traced zombies keeps PIDs allocated, making the wait unbounded and causing every suspend attempt to fail. The fix makes the wait loops use TASK_FREEZABLE states so the freezer can freeze waiting tasks.
- CVE-2026-99248Unknown
In the Linux kernel, the i2c: xiic driver was changed to restore non-managed runtime PM instead of the devres-based approach to fix a clk WARN flood. The managed release tore down runtime PM in the wrong order, causing the clock to be disabled twice and triggering "clkN already disabled" warnings on every teardown.
- CVE-2026-99247Unknown
In the Linux kernel, if trace buffer allocation fails during early boot, tracing_disabled remains set and the global trace array events list stays uninitialized. tracer_init_tracefs_work_func() runs asynchronously without checking this state and calls event_trace_init() and init_tracer_tracefs(), leading to a NULL pointer dereference Oops during boot. The fix checks tracing_disabled at the start of the work function.
- CVE-2026-99215Unknown
In the Linux kernel power supply subsystem, a use-after-free vulnerability exists. If a power supply is unregistered while its external_power_changed() callback is still running, the driver may free data that the callback is still accessing, leading to a kernel crash (NULL pointer dereference).
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

