CVE-2025-39843

In the Linux kernel, the following vulnerability has been resolved:

mm: slub: avoid wake up kswapd in set_track_prepare

set_track_prepare() can incur lock recursion.

The issue is that it is called from hrtimer_start_range_ns

holding the per_cpu(hrtimer_bases)[n].lock, but when enabled

CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,

and try to hold the per_cpu(hrtimer_bases)[n].lock.

Avoid deadlock caused by implicitly waking up kswapd by passing in

allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the

debug_objects_fill_pool() case. Inside stack depot they are processed by

gfp_nested_mask().

Since ___slab_alloc() has preemption disabled, we mask out

__GFP_DIRECT_RECLAIM from the flags there.

The oops looks something like:

BUG: spinlock recursion on CPU#3, swapper/3/0

lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3

Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)

Call trace:

spin_bug+0x0

_raw_spin_lock_irqsave+0x80

hrtimer_try_to_cancel+0x94

task_contending+0x10c

enqueue_dl_entity+0x2a4

dl_server_start+0x74

enqueue_task_fair+0x568

enqueue_task+0xac

do_activate_task+0x14c

ttwu_do_activate+0xcc

try_to_wake_up+0x6c8

default_wake_function+0x20

autoremove_wake_function+0x1c

__wake_up+0xac

wakeup_kswapd+0x19c

wake_all_kswapds+0x78

__alloc_pages_slowpath+0x1ac

__alloc_pages_noprof+0x298

stack_depot_save_flags+0x6b0

stack_depot_save+0x14

set_track_prepare+0x5c

___slab_alloc+0xccc

__kmalloc_cache_noprof+0x470

__set_page_owner+0x2bc

post_alloc_hook[jt]+0x1b8

prep_new_page+0x28

get_page_from_freelist+0x1edc

__alloc_pages_noprof+0x13c

alloc_slab_page+0x244

allocate_slab+0x7c

___slab_alloc+0x8e8

kmem_cache_alloc_noprof+0x450

debug_objects_fill_pool+0x22c

debug_object_activate+0x40

enqueue_hrtimer[jt]+0xdc

hrtimer_start_range_ns+0x5f8

...