CVE-2024-56610

Nel kernel Linux, è stata risolta la seguente vulnerabilità:

kcsan: Trasformare report_filterlist_lock in un raw_spinlock

Ran Xiaokai segnala che, con un kernel PREEMPT_RT abilitato a KCSAN, è possibile osservare
messaggi come:

| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
| preempt_count: 10002, expected: 0
| RCU nest depth: 0, expected: 0
| no locks held by swapper/1/0.
| irq event stamp: 156674
| hardirqs last enabled at (156673): [<ffffffff81130bd9>] do_idle+0x1f9/0x240
| hardirqs last disabled at (156674): [<ffffffff82254f84>] sysvec_apic_timer_interrupt+0x14/0xc0
| softirqs last enabled at (0): [<ffffffff81099f47>] copy_process+0xfc7/0x4b60
| softirqs last disabled at (0): [<0000000000000000>] 0x0
| Preemption disabled at:
| [<ffffffff814a3e2a>] paint_ptr+0x2a/0x90
| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
| Call Trace:
| <IRQ>
| dump_stack_lvl+0x7e/0xc0
| dump_stack+0x1d/0x30
| __might_resched+0x1a2/0x270
| rt_spin_lock+0x68/0x170
| kcsan_skip_report_debugfs+0x43/0xe0
| print_report+0xb5/0x590
| kcsan_report_known_origin+0x1b1/0x1d0
| kcsan_setup_watchpoint+0x348/0x650
| __tsan_unaligned_write1+0x16d/0x1d0
| hrtimer_interrupt+0x3d6/0x430
| __sysvec_apic_timer_interrupt+0xe8/0x3a0
| sysvec_apic_timer_interrupt+0x97/0xc0
| </IRQ>

In presenza di una race condition rilevata, la logica di reporting di KCSAN verifica se
debba filtrare il report. Tale lista è protetta dal spinlock report_filterlist_lock
*non-raw*, che può causare sleep sui kernel RT.

Poiché KCSAN può segnalare race condition in qualsiasi contesto, è stato convertito in
un raw_spinlock.

Ciò richiede attenzione nel momento in cui si alloca memoria per la lista di filtri,
che può essere gestito tramite l'interfaccia debugfs di KCSAN. La modifica concorrente
della lista di filtri tramite debugfs dovrebbe essere rara: la strategia adottata è
quella di pre-allocare ottimisticamente la memoria prima della sezione critica e
scartarla se non utilizzata.