CVE-2024-56559

Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
27/12/2024
Last modified:
23/09/2025

Description

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: combine all TLB flush operations of KASAN shadow virtual address into one operation<br /> <br /> When compiling kernel source &amp;#39;make -j $(nproc)&amp;#39; with the up-and-running<br /> KASAN-enabled kernel on a 256-core machine, the following soft lockup is<br /> shown:<br /> <br /> watchdog: BUG: soft lockup - CPU#28 stuck for 22s! [kworker/28:1:1760]<br /> CPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: loaded Not tainted 6.10.0-rc5 #95<br /> Workqueue: events drain_vmap_area_work<br /> RIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0<br /> Code: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75<br /> RSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202<br /> RAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949<br /> RDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50<br /> RBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800<br /> R10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39<br /> R13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003<br /> FS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> ? watchdog_timer_fn+0x2cd/0x390<br /> ? __pfx_watchdog_timer_fn+0x10/0x10<br /> ? __hrtimer_run_queues+0x300/0x6d0<br /> ? sched_clock_cpu+0x69/0x4e0<br /> ? __pfx___hrtimer_run_queues+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? ktime_get_update_offsets_now+0x7f/0x2a0<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? hrtimer_interrupt+0x2ca/0x760<br /> ? __sysvec_apic_timer_interrupt+0x8c/0x2b0<br /> ? sysvec_apic_timer_interrupt+0x6a/0x90<br /> <br /> <br /> ? asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> ? smp_call_function_many_cond+0x1d8/0xbb0<br /> ? __pfx_do_kernel_range_flush+0x10/0x10<br /> on_each_cpu_cond_mask+0x20/0x40<br /> flush_tlb_kernel_range+0x19b/0x250<br /> ? srso_return_thunk+0x5/0x5f<br /> ? kasan_release_vmalloc+0xa7/0xc0<br /> purge_vmap_node+0x357/0x820<br /> ? __pfx_purge_vmap_node+0x10/0x10<br /> __purge_vmap_area_lazy+0x5b8/0xa10<br /> drain_vmap_area_work+0x21/0x30<br /> process_one_work+0x661/0x10b0<br /> worker_thread+0x844/0x10e0<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __kthread_parkme+0x82/0x140<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x2a5/0x370<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Debugging Analysis:<br /> <br /> 1. The following ftrace log shows that the lockup CPU spends too much<br /> time iterating vmap_nodes and flushing TLB when purging vm_area<br /> structures. (Some info is trimmed).<br /> <br /> kworker: funcgraph_entry: | drain_vmap_area_work() {<br /> kworker: funcgraph_entry: | mutex_lock() {<br /> kworker: funcgraph_entry: 1.092 us | __cond_resched();<br /> kworker: funcgraph_exit: 3.306 us | }<br /> ... ...<br /> kworker: funcgraph_entry: | flush_tlb_kernel_range() {<br /> ... ...<br /> kworker: funcgraph_exit: # 7533.649 us | }<br /> ... ...<br /> kworker: funcgraph_entry: 2.344 us | mutex_unlock();<br /> kworker: funcgraph_exit: $ 23871554 us | }<br /> <br /> The drain_vmap_area_work() spends over 23 seconds.<br /> <br /> There are 2805 flush_tlb_kernel_range() calls in the ftrace log.<br /> * One is called in __purge_vmap_area_lazy().<br /> * Others are called by purge_vmap_node-&gt;kasan_release_vmalloc.<br /> purge_vmap_node() iteratively releases kasan vmalloc<br /> allocations and flushes TLB for each vmap_area.<br /> - [Rough calculation] Each flush_tlb_kernel_range() runs<br /> about 7.5ms.<br /> -- 2804 * 7.5ms = 21.03 seconds.<br /> -- That&amp;#39;s why a soft lock is triggered.<br /> <br /> 2. Extending the soft lockup time can work around the issue (For example,<br /> # echo<br /> ---truncated---

Vulnerable products and versions

CPE From Up to
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 6.9 (including) 6.12.4 (excluding)