CVE-2025-39843

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

mm: slub: avoid wake up kswapd in settrackprepare

settrackprepare() can incur lock recursion. The issue is that it is called from hrtimerstartrangens holding the percpu(hrtimerbases)[n].lock, but when enabled CONFIGDEBUGOBJECTSTIMERS, may wake up kswapd in settrackprepare, and try to hold the percpu(hrtimerbases)[n].lock.

Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFPKSWAPDRECLAIM in the debug_objectsfillpool() case. Inside stack depot they are processed by gfpnestedmask(). Since ___slab_alloc() has preemption disabled, we mask out __GFPDIRECTRECLAIM 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, .ownercpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spinbug+0x0 rawspinlockirqsave+0x80 hrtimertrytocancel+0x94 taskcontending+0x10c enqueuedlentity+0x2a4 dlserverstart+0x74 enqueuetaskfair+0x568 enqueuetask+0xac doactivatetask+0x14c ttwudoactivate+0xcc trytowakeup+0x6c8 defaultwakefunction+0x20 autoremovewakefunction+0x1c __wakeup+0xac wakeupkswapd+0x19c wakeallkswapds+0x78 __allocpagesslowpath+0x1ac __allocpagesnoprof+0x298 stackdepotsave_flags+0x6b0 stackdepotsave+0x14 settrackprepare+0x5c ___slab_alloc+0xccc __kmalloccachenoprof+0x470 __setpageowner+0x2bc postallochook[jt]+0x1b8 prepnewpage+0x28 getpagefrom_freelist+0x1edc __allocpagesnoprof+0x13c allocslabpage+0x244 allocate_slab+0x7c __slaballoc+0x8e8 kmemcacheallocnoprof+0x450 debugobjectsfillpool+0x22c debugobjectactivate+0x40 enqueuehrtimer[jt]+0xdc hrtimerstartrangens+0x5f8 ...