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 &#39;make -j $(nproc)&#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->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&#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---
Impact
Base Score 3.x
5.50
Severity 3.x
MEDIUM
Vulnerable products and versions
| CPE | From | Up to |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.9 (including) | 6.12.4 (excluding) |
To consult the complete list of CPE names with products and versions, see this page



