CVE-2024-50140

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

sched/core: Disable page allocation in tasktickmm_cid()

With KASAN and PREEMPTRT enabled, calling taskworkadd() in tasktickmmcid() may cause the following splat.

[ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 [ 63.696416] inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 610, name: modprobe [ 63.696416] preempt_count: 10001, expected: 0 [ 63.696416] RCU nest depth: 1, expected: 1

This problem is caused by the following call trace.

schedtick() [ acquire rq->lock ] -> tasktickmmcid() -> taskworkadd() -> _kasanrecordauxstack() -> kasansavestack() -> stackdepotsaveflags() -> allocpagesmpolnoprof() -> _allocpagesnoprof() -> getpagefromfreelist() -> rmqueue() -> rmqueuepcplist() -> _rmqueuepcplist() -> rmqueuebulk() -> rtspinlock()

The rq lock is a rawspinlockt. We can't sleep while holding it. IOW, we can't call allocpages() in stackdepotsaveflags().

The tasktickmmcid() function with its taskworkadd() call was introduced by commit 223baf9d17f2 ("sched: Fix performance regression introduced by mmcid") in v6.4 kernel.

Fortunately, there is a kasanrecordauxstacknoalloc() variant that calls stackdepotsaveflags() while not allowing it to allocate new pages. To allow tasktickmmcid() to use taskwork without page allocation, a new TWAFNOALLOC flag is added to enable calling kasanrecordauxstacknoalloc() instead of kasanrecordauxstack() if set. The tasktickmm_cid() function is modified to add this new flag.

The possible downside is the missing stack trace in a KASAN report due to new page allocation required when taskworkadd_noallloc() is called which should be rare.