"value":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Disable page allocation in task_tick_mm_cid()\n\nWith KASAN and PREEMPT_RT enabled, calling task_work_add() in\ntask_tick_mm_cid() may cause the following splat.\n\n[ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe\n[ 63.696416] preempt_count: 10001, expected: 0\n[ 63.696416] RCU nest depth: 1, expected: 1\n\nThis problem is caused by the following call trace.\n\n sched_tick() [ acquire rq->__lock ]\n -> task_tick_mm_cid()\n -> task_work_add()\n -> __kasan_record_aux_stack()\n -> kasan_save_stack()\n -> stack_depot_save_flags()\n -> alloc_pages_mpol_noprof()\n -> __alloc_pages_noprof()\n\t -> get_page_from_freelist()\n\t -> rmqueue()\n\t -> rmqueue_pcplist()\n\t -> __rmqueue_pcplist()\n\t -> rmqueue_bulk()\n\t -> rt_spin_lock()\n\nThe rq lock is a raw_spinlock_t. We can't sleep while holding\nit. IOW, we can't call alloc_pages() in stack_depot_save_flags().\n\nThe task_tick_mm_cid() function with its task_work_add() call was\nintroduced by commit 223baf9d17f2 (\"sched: Fix performance regression\nintroduced by mm_cid\") in v6.4 kernel.\n\nFortunately, there is a kasan_record_aux_stack_noalloc() variant that\ncalls stack_depot_save_flags() while not allowing it to allocate\nnew pages. To allow task_tick_mm_cid() to use task_work without\npage allocation, a new TWAF_NO_ALLOC flag is added to enable calling\nkasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()\nif set. The task_tick_mm_cid() function is modified to add this new flag.\n\nThe possible downside is the missing stack trace in a KASAN report due\nto new page allocation required when task_work_add_noallloc() is called\nwhich should be rare."
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/core: Deshabilitar la asignaci\u00f3n de p\u00e1ginas en task_tick_mm_cid() Con KASAN y PREEMPT_RT habilitados, llamar a task_work_add() en task_tick_mm_cid() puede causar el siguiente splat. [ 63.696416] ERROR: funci\u00f3n inactiva llamada desde un contexto no v\u00e1lido en 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, esperado: 0 [ 63.696416] Profundidad de anidaci\u00f3n de RCU: 1, esperado: 1 Este problema es causado por el siguiente seguimiento de llamada. sched_tick() [ adquirir 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() El bloqueo rq es un raw_spinlock_t. No podemos dormir mientras lo mantenemos. Es decir, no podemos llamar a alloc_pages() en stack_depot_save_flags(). La funci\u00f3n task_tick_mm_cid() con su llamada task_work_add() fue introducida por el commit 223baf9d17f2 (\"sched: Fix performance regression presented by mm_cid\") en el kernel v6.4. Afortunadamente, hay una variante kasan_record_aux_stack_noalloc() que llama a stack_depot_save_flags() pero no le permite asignar nuevas p\u00e1ginas. Para permitir que task_tick_mm_cid() use task_work sin asignaci\u00f3n de p\u00e1ginas, se agrega un nuevo indicador TWAF_NO_ALLOC para habilitar la llamada a kasan_record_aux_stack_noalloc() en lugar de kasan_record_aux_stack() si est\u00e1 configurado. La funci\u00f3n task_tick_mm_cid() se modifica para agregar este nuevo indicador. La posible desventaja es la falta de seguimiento de pila en un informe KASAN debido a la nueva asignaci\u00f3n de p\u00e1gina requerida cuando se llama a task_work_add_noallloc(), lo que deber\u00eda ser poco com\u00fan."
