CVE-2025-38285 in Linux
Summary
by MITRE • 07/10/2025
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]
bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]
__bpf_prog_run include/linux/filter.h:718 [inline]
bpf_prog_run include/linux/filter.h:725 [inline]
__bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]
bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]
trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]
__mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]
mmap_read_trylock include/linux/mmap_lock.h:204 [inline]
stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]
bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]
bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47
Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 12/19/2025
The vulnerability identified as CVE-2025-38285 affects the Linux kernel's eBPF (extended Berkeley Packet Filter) subsystem, specifically within the bpf_trace.c file at line 1861 in the get_bpf_raw_tp_regs function. This issue manifests as a WARNING message triggered by a WARN_ON_ONCE macro, indicating a potential kernel instability or improper handling of tracepoint events. The problem was discovered through syzkaller, an automated fuzzer designed to identify kernel vulnerabilities, and demonstrates a condition where nested tracepoint calls can lead to unexpected behavior during kernel execution. The call trace reveals a complex chain of function calls involving bpf_get_stack_raw_tp, bpf_trace_run3, and mmap_lock tracepoint handlers, ultimately leading to a situation where the kernel's warning mechanism is activated due to an internal inconsistency.
The technical flaw stems from improper handling of tracepoint events when nested calls occur within the bpf subsystem. When tracepoints like trace_mmap_lock_acquire_returned are triggered, they can cause nested function calls that the current implementation does not properly account for, resulting in the WARN_ON_ONCE condition being met. This condition is particularly concerning because it indicates that the kernel's internal state management is not robust enough to handle certain edge cases in tracepoint execution. The issue is rooted in the kernel's approach to managing raw tracepoint registers and the synchronization mechanisms used during bpf program execution. According to CWE-691, this represents an insufficient control flow management problem where the kernel fails to properly handle nested or recursive function calls in its tracing infrastructure.
The operational impact of this vulnerability could be significant for systems running Linux kernels with active eBPF tracing capabilities, particularly in environments where tracepoints are frequently triggered or where complex tracing scenarios are common. While the immediate effect is a kernel warning message rather than a system crash or security breach, the underlying instability could potentially lead to more serious issues if the condition persists or if similar edge cases exist elsewhere in the kernel's tracing subsystem. Systems utilizing eBPF for monitoring, security instrumentation, or performance analysis may experience unexpected behavior or reduced reliability when tracepoint events occur in certain patterns. The vulnerability is classified under ATT&CK technique T1547.006 (Elevation of privileges through kernel exploits) in the context of potential escalation paths, though this particular CVE does not directly enable privilege escalation.
Mitigation strategies should focus on implementing the patch that removes the WARN_ON_ONCE macro as suggested by the fix. This temporary solution addresses the immediate symptom by preventing the warning from being triggered, though a more comprehensive approach would involve redesigning the tracepoint handling mechanism to properly account for nested calls. System administrators should ensure that affected kernels are updated with the patched version as soon as available, particularly in production environments where kernel stability is critical. Monitoring for warning messages related to get_bpf_raw_tp_regs should be implemented to detect potential recurrence of this condition. Additionally, organizations using extensive eBPF tracing should consider reviewing their tracepoint configurations to minimize the likelihood of triggering nested call scenarios that could lead to similar issues in other parts of the kernel's tracing infrastructure.