🛡️ AZL-53537 — kernel

CVE-2024-50140 affecting package kernel for versions less than 6.6.64.2-1

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

sched/core: Disable page allocation in task_tick_mm_cid()

With KASAN and PREEMPT_RT enabled, calling task_work_add() in

task_tick_mm_cid() may cause the following splat.

[ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48

[ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 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.

sched_tick() [ acquire rq->__lock ]

-> task_tick_mm_cid()

-> task_work_add()

-> __kasan_record_aux_stack()

-> kasan_save_stack()

-> stack_depot_save_flags()

-> alloc_pages_mpol_noprof()

-> __alloc_pages_noprof()

-> get_page_from_freelist()

-> rmqueue()

-> rmqueue_pcplist()

-> __rmqueue_pcplist()

-> rmqueue_bulk()

-> rt_spin_lock()

The rq lock is a raw_spinlock_t. We can't sleep while holding

it. IOW, we can't call alloc_pages() in stack_depot_save_flags().

The task_tick_mm_cid() function with its task_work_add() call was

introduced by commit 223baf9d17f2 ("sched: Fix performance regression

introduced by mm_cid") in v6.4 kernel.

Fortunately, there is a kasan_record_aux_stack_noalloc() variant that

calls stack_depot_save_flags() while not allowing it to allocate

new pages. To allow task_tick_mm_cid() to use task_work without

page allocation, a new TWAF_NO_ALLOC flag is added to enable calling

kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()

if set. The task_tick_mm_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 task_work_add_noallloc() is called

which should be rare.