CVE-2026-53326

What it actually does

This is a local availability flaw in the Linux kernel debugobjects subsystem affecting early boot behavior, particularly on debug PREEMPT_RT ARM64 kernels. During the brief boot phase after interrupts are enabled but before the scheduler is fully active, a hard interrupt handler can attempt to refill the debugobjects pool through fill_pool(). That allocation path can require locks that may already be held by the interrupted code path, creating an inconsistent lock context and potential deadlock. The practical technical result is a kernel hang or boot-time denial of service, not privilege escalation, data theft, or remote code execution.

Why it matters to the business

Systems running affected debug or real-time Linux kernel builds may fail to boot reliably or may hang during early startup, causing service unavailability, delayed maintenance windows, failed restarts, and operational disruption. The risk is highest for ARM64 systems using PREEMPT_RT and kernel debugging options in production-like or embedded environments. Public exploitation is not currently indicated, EPSS is very low, and the issue is not in CISA KEV, so remediation should be handled through normal kernel patching unless affected systems are safety-critical, real-time, or require high reboot reliability.

How an attack unfolds

An attacker would need local access or another way to influence reboot or early-boot behavior on a vulnerable system. The vulnerable condition occurs only during a narrow early-boot window after interrupts are enabled and before normal scheduling is initialized. If an interrupt fires while the kernel is holding a lock that is also needed by the debugobjects allocation path, the interrupt handler can attempt to call fill_pool(), re-enter locking in an unsafe context, and deadlock the kernel. Successful exploitation would typically manifest as a boot hang, lockdep warning, or system unavailability rather than code execution or persistence. Because the bug depends on kernel configuration and timing, exploitation is environment-specific and more plausible as a reliability issue or local denial-of-service condition than as a broadly weaponized attack.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix preventing debugobjects pool refills from hard interrupt context during early boot. If a distribution or vendor has not listed a specific fixed version, track the vendor kernel advisory and update to the first patched kernel available for the affected release stream. Where immediate patching is not possible, reduce exposure by avoiding debug PREEMPT_RT kernels in production, disabling CONFIG_DEBUG_OBJECTS where operationally acceptable, booting a non-debug or non-RT kernel for critical workloads, and limiting local users or automation that can reboot systems. For embedded or appliance deployments, incorporate the fixed kernel into the next firmware or image release and test early-boot behavior under interrupt-heavy conditions before rollout.

How to confirm the fix worked

Confirm that the running kernel package or source tree contains the debugobjects change that adds the early-boot hardirq guard for pool refilling, often reflected by a can_fill_pool() helper or equivalent logic in the debugobjects code path. Verify affected configuration flags such as CONFIG_DEBUG_OBJECTS, CONFIG_PREEMPT_RT, and ARM64 platform use to determine exposure. After updating, reboot representative systems and review dmesg, journalctl -k, serial console, and persistent boot logs for absence of lockdep warnings involving debugobjects, fill_pool(), HARDIRQ, or IN-HARDIRQ contexts. Validate that systems complete repeated cold boots and warm reboots without hanging, especially on hardware that previously reproduced the issue.

Typical attack path

1. Identify a target running an affected Linux kernel build, especially ARM64 with PREEMPT_RT and debugobjects enabled.
2. Obtain local privileges or operational influence sufficient to trigger reboots, kernel restarts, or early-boot interrupt-heavy conditions.
3. Cause or wait for a reboot into the vulnerable kernel.
4. During the early boot window before the scheduler is fully enabled, trigger or rely on hardware/software interrupts.
5. The interrupt handler attempts to refill the debugobjects pool from hard interrupt context.
6. The allocation path attempts to acquire a lock already held by the interrupted path, causing lockdep warnings or a kernel deadlock.
7. The system hangs or becomes unavailable until manual recovery, watchdog reset, rollback, or booting a fixed/non-vulnerable kernel.

How to detect it

Look for evidence of boot-time kernel deadlock or lockdep warnings rather than traditional intrusion indicators. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, serial console logs, netconsole output, pstore/ramoops records, kdump vmcores, watchdog reset logs, and out-of-band management event logs. Search for lockdep messages that mention transitions from HARDIRQ-ON to IN-HARDIRQ, debugobjects, fill_pool(), allocation paths during early boot, or PREEMPT_RT. Correlate repeated failed boots, watchdog resets, or systems stuck before normal service startup with vulnerable kernel versions and configuration flags. Because no public exploitation or named threat actor activity is currently indicated, treat findings primarily as reliability or local denial-of-service evidence unless accompanied by suspicious local access, unauthorized reboot activity, or tampering with boot configuration.

• inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage
• debugobjects:
• fill_pool()
• fill_pool
• can_fill_pool
• IN-HARDIRQ-W
• HARDIRQ-ON-W
• lockdep
• PREEMPT_RT
• CONFIG_DEBUG_OBJECTS
• CONFIG_PREEMPT_RT
• lib/debugobjects.c
• possible circular locking dependency detected
• watchdog: BUG: soft lockup
• watchdog: BUG: hard lockup
• Kernel panic - not syncing

What your security team should do

• Prioritize patching for ARM64, PREEMPT_RT, embedded, industrial, telecom, or other high-availability systems that use debug kernel builds or kernel debugobjects.
• Inventory Linux kernels for CONFIG_DEBUG_OBJECTS and CONFIG_PREEMPT_RT to identify systems where this issue is relevant.
• Move production workloads away from debug kernels unless there is a specific operational requirement.
• Restrict local reboot privileges and automation that can repeatedly restart critical systems until patched.
• Add monitoring for boot hangs, watchdog resets, and kernel lockdep warnings related to debugobjects and hard interrupt context.
• Coordinate with platform, firmware, and kernel engineering teams to ensure patched kernels are included in golden images and device firmware baselines.
• If the issue is observed, preserve serial console output, pstore logs, kdump artifacts, and boot journals before rebooting or rolling back.