CVE-2024-56610

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcsan: Turn report_filterlist_lock into a raw_spinlock<br /> <br /> Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see<br /> splats like:<br /> <br /> | BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1<br /> | preempt_count: 10002, expected: 0<br /> | RCU nest depth: 0, expected: 0<br /> | no locks held by swapper/1/0.<br /> | irq event stamp: 156674<br /> | hardirqs last enabled at (156673): [] do_idle+0x1f9/0x240<br /> | hardirqs last disabled at (156674): [] sysvec_apic_timer_interrupt+0x14/0xc0<br /> | softirqs last enabled at (0): [] copy_process+0xfc7/0x4b60<br /> | softirqs last disabled at (0): [] 0x0<br /> | Preemption disabled at:<br /> | [] paint_ptr+0x2a/0x90<br /> | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3<br /> | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014<br /> | Call Trace:<br /> | <br /> | dump_stack_lvl+0x7e/0xc0<br /> | dump_stack+0x1d/0x30<br /> | __might_resched+0x1a2/0x270<br /> | rt_spin_lock+0x68/0x170<br /> | kcsan_skip_report_debugfs+0x43/0xe0<br /> | print_report+0xb5/0x590<br /> | kcsan_report_known_origin+0x1b1/0x1d0<br /> | kcsan_setup_watchpoint+0x348/0x650<br /> | __tsan_unaligned_write1+0x16d/0x1d0<br /> | hrtimer_interrupt+0x3d6/0x430<br /> | __sysvec_apic_timer_interrupt+0xe8/0x3a0<br /> | sysvec_apic_timer_interrupt+0x97/0xc0<br /> | <br /> <br /> On a detected data race, KCSAN&amp;#39;s reporting logic checks if it should<br /> filter the report. That list is protected by the report_filterlist_lock<br /> *non-raw* spinlock which may sleep on RT kernels.<br /> <br /> Since KCSAN may report data races in any context, convert it to a<br /> raw_spinlock.<br /> <br /> This requires being careful about when to allocate memory for the filter<br /> list itself which can be done via KCSAN&amp;#39;s debugfs interface. Concurrent<br /> modification of the filter list via debugfs should be rare: the chosen<br /> strategy is to optimistically pre-allocate memory before the critical<br /> section and discard if unused.