CVE-2025-39843

What it actually does

Lock recursion deadlock in SLUB allocator: set_track_prepare() called under hrtimer lock can wake kswapd via __GFP_KSWAPD_RECLAIM, leading to spinlock recursion on per-CPU hrtimer_bases when CONFIG_DEBUG_OBJECTS_TIMERS is enabled.

Why it matters to the business

Systems may experience kernel oops, hangs, or crashes during memory allocation under timer debugging, reducing availability and requiring reboots; high prevalence in Linux distributions amplifies operational disruption for servers and embedded devices.

How an attack unfolds

An attacker with local access triggers slab allocations (e.g., via kmem_cache or debug object activation) while hrtimer_start_range_ns holds the lock; the GFP flags cause kswapd wake-up, recursing on the same lock and producing the spinlock recursion BUG.

How to fix it

Upgrade Linux kernel packages to the fixed versions: Debian 11/12/13/14 to 3.16.2-2 or later; mainline/stable git trees to commit 994b03b9605d36d814c611385fbf90ca6db20aa8 or equivalent backports that pass non-reclaim GFP flags to debug_objects_fill_pool and mask __GFP_DIRECT_RECLAIM in ___slub_alloc.

How to confirm the fix worked

Verify running kernel version matches or exceeds the fixed package/commit; confirm CONFIG_DEBUG_OBJECTS_TIMERS is either disabled or the patch applied by checking for the gfp_nested_mask and allocation flag changes; attempt to reproduce the original oops under the debug config to validate absence of recursion.

Typical attack path

1. Obtain local code execution or trigger memory pressure
2. Invoke paths that call hrtimer_start_range_ns under CONFIG_DEBUG_OBJECTS_TIMERS
3. Trigger slab allocation in debug_objects_fill_pool or set_track_prepare
4. Cause kswapd wake-up while holding per-CPU hrtimer lock
5. Induce spinlock recursion and kernel panic

How to detect it

Search kernel logs and dmesg for the exact BUG string 'spinlock recursion on CPU' combined with 'swapper' and the call trace containing hrtimer_try_to_cancel, wakeup_kswapd, set_track_prepare, and debug_objects_fill_pool; look for occurrences on systems with CONFIG_DEBUG_OBJECTS_TIMERS enabled.

• BUG: spinlock recursion on CPU
• lock: 0xffffff8a4bf29c80
• hrtimer_try_to_cancel+0x94
• wakeup_kswapd+0x19c
• set_track_prepare+0x5c
• debug_objects_fill_pool+0x22c
• Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850

What your security team should do

• Immediately prioritize kernel upgrades on all affected Debian and custom Linux deployments due to 400+ days since publication
• Audit systems for CONFIG_DEBUG_OBJECTS_TIMERS=y in production kernels and consider disabling it where feasible
• Monitor for spinlock recursion oopses in dmesg and kernel logs as a temporary detection measure
• Apply the exact fixed versions listed for each distribution to eliminate the GFP flag recursion path