CVE-2024-53687

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix IPIs usage in kfence_protect_page()<br /> <br /> flush_tlb_kernel_range() may use IPIs to flush the TLBs of all the<br /> cores, which triggers the following warning when the irqs are disabled:<br /> <br /> [ 3.455330] WARNING: CPU: 1 PID: 0 at kernel/smp.c:815 smp_call_function_many_cond+0x452/0x520<br /> [ 3.456647] Modules linked in:<br /> [ 3.457218] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7-00010-g91d3de7240b8 #1<br /> [ 3.457416] Hardware name: QEMU QEMU Virtual Machine, BIOS<br /> [ 3.457633] epc : smp_call_function_many_cond+0x452/0x520<br /> [ 3.457736] ra : on_each_cpu_cond_mask+0x1e/0x30<br /> [ 3.457786] epc : ffffffff800b669a ra : ffffffff800b67c2 sp : ff2000000000bb50<br /> [ 3.457824] gp : ffffffff815212b8 tp : ff6000008014f080 t0 : 000000000000003f<br /> [ 3.457859] t1 : ffffffff815221e0 t2 : 000000000000000f s0 : ff2000000000bc10<br /> [ 3.457920] s1 : 0000000000000040 a0 : ffffffff815221e0 a1 : 0000000000000001<br /> [ 3.457953] a2 : 0000000000010000 a3 : 0000000000000003 a4 : 0000000000000000<br /> [ 3.458006] a5 : 0000000000000000 a6 : ffffffffffffffff a7 : 0000000000000000<br /> [ 3.458042] s2 : ffffffff815223be s3 : 00fffffffffff000 s4 : ff600001ffe38fc0<br /> [ 3.458076] s5 : ff600001ff950d00 s6 : 0000000200000120 s7 : 0000000000000001<br /> [ 3.458109] s8 : 0000000000000001 s9 : ff60000080841ef0 s10: 0000000000000001<br /> [ 3.458141] s11: ffffffff81524812 t3 : 0000000000000001 t4 : ff60000080092bc0<br /> [ 3.458172] t5 : 0000000000000000 t6 : ff200000000236d0<br /> [ 3.458203] status: 0000000200000100 badaddr: ffffffff800b669a cause: 0000000000000003<br /> [ 3.458373] [] smp_call_function_many_cond+0x452/0x520<br /> [ 3.458593] [] on_each_cpu_cond_mask+0x1e/0x30<br /> [ 3.458625] [] __flush_tlb_range+0x118/0x1ca<br /> [ 3.458656] [] flush_tlb_kernel_range+0x1e/0x26<br /> [ 3.458683] [] kfence_protect+0xc0/0xce<br /> [ 3.458717] [] kfence_guarded_free+0xc6/0x1c0<br /> [ 3.458742] [] __kfence_free+0x62/0xc6<br /> [ 3.458764] [] kfree+0x106/0x32c<br /> [ 3.458786] [] detach_buf_split+0x188/0x1a8<br /> [ 3.458816] [] virtqueue_get_buf_ctx+0xb6/0x1f6<br /> [ 3.458839] [] virtqueue_get_buf+0xe/0x16<br /> [ 3.458880] [] virtblk_done+0x5c/0xe2<br /> [ 3.458908] [] vring_interrupt+0x6a/0x74<br /> [ 3.458930] [] __handle_irq_event_percpu+0x7c/0xe2<br /> [ 3.458956] [] handle_irq_event+0x3c/0x86<br /> [ 3.458978] [] handle_simple_irq+0x9e/0xbe<br /> [ 3.459004] [] generic_handle_domain_irq+0x1c/0x2a<br /> [ 3.459027] [] imsic_handle_irq+0xba/0x120<br /> [ 3.459056] [] generic_handle_domain_irq+0x1c/0x2a<br /> [ 3.459080] [] riscv_intc_aia_irq+0x24/0x34<br /> [ 3.459103] [] handle_riscv_irq+0x2e/0x4c<br /> [ 3.459133] [] call_on_irq_stack+0x32/0x40<br /> <br /> So only flush the local TLB and let the lazy kfence page fault handling<br /> deal with the faults which could happen when a core has an old protected<br /> pte version cached in its TLB. That leads to potential inaccuracies which<br /> can be tolerated when using kfence.