DEBIAN-CVE-2024-50140

In the Linux kernel, the following vulnerability has been resolved: sched/core: Disable page allocation in tasktickmmcid() 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] preemptcount: 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 tasktickmmcid() 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 taskworkaddnoallloc() is called which should be rare.