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 debugobjectsfillpool() case. Inside stack depot they are processed by gfpnestedmask(). Since _slaballoc() has preemption disabled, we mask out _GFPDIRECT_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, .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 stackdepotsaveflags+0x6b0 stackdepotsave+0x14 settrackprepare+0x5c _slaballoc+0xccc kmalloccachenoprof+0x470 _setpageowner+0x2bc postallochook[jt]+0x1b8 prepnewpage+0x28 getpagefromfreelist+0x1edc _allocpagesnoprof+0x13c allocslabpage+0x244 allocateslab+0x7c slaballoc+0x8e8 kmemcacheallocnoprof+0x450 debugobjectsfillpool+0x22c debugobjectactivate+0x40 enqueuehrtimer[jt]+0xdc hrtimerstartrangens+0x5f8 ...