CVE-2025-37772 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix workqueue crash in cma_netevent_work_handler
struct rdma_cm_id has member "struct work_struct net_work" that is reused for enqueuing cma_netevent_work_handler()s onto cma_wq.
Below crash[1] can occur if more than one call to
cma_netevent_callback() occurs in quick succession, which further enqueues cma_netevent_work_handler()s for the same rdma_cm_id, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee the queued work item may run between two successive calls to cma_netevent_callback() and the 2nd INIT_WORK would overwrite the 1st work item (for the same rdma_cm_id), despite grabbing id_table_lock during enqueue.
Also drgn analysis [2] indicates the work item was likely overwritten.
Fix this by moving the INIT_WORK() to __rdma_create_id(), so that it doesn't race with any existing queue_work() or its worker thread.
[1] Trimmed crash stack:
============================================= BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.0-0... Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)
RIP: 0010:process_one_work+0xba/0x31a Call Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 =============================================
[2] drgn crash analysis:
>>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9)
Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
>>> trace[8]["work"]
*(struct work_struct *)0xffff92577d0a21d8 = {
.data = (atomic_long_t){
.counter = (s64)536870912, <=== Note }, .entry = (struct list_head){
.next = (struct list_head *)0xffff924d075924c0, .prev = (struct list_head *)0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, }
Suspicion is that pwq is NULL: >>> trace[8]["pwq"]
(struct pool_workqueue *)<absent>
In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work);
and get_work_pwq() is: static struct pool_workqueue *get_work_pwq(struct work_struct *work) {
unsigned long data = atomic_long_read(&work->data);
if (data & WORK_STRUCT_PWQ) return work_struct_pwq(data); else return NULL; }
WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ']))
Object(prog, 'enum work_flags', value=4)
But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); =============================================
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 03/16/2026
The vulnerability described in CVE-2025-37772 resides within the Linux kernel's RDMA (Remote Direct Memory Access) communication management subsystem, specifically within the rdma_cm module. This flaw manifests as a race condition during the handling of network events, leading to a potential kernel crash due to a workqueue misuse. The core issue occurs when multiple rapid calls to the cma_netevent_callback function trigger the scheduling of work items for the same rdma_cm_id structure. Each call to this callback enqueues a new work item using cma_netevent_work_handler, but the mechanism used to initialize these work items in the workqueue causes a conflict when the work item is overwritten before it has a chance to execute.
The technical flaw lies in the improper initialization of the work_struct member net_work within the struct rdma_cm_id. The INIT_WORK() macro is invoked during the callback processing rather than during the creation of the rdma_cm_id structure itself. This timing issue allows for a race condition where a second call to cma_netevent_callback can overwrite a previously scheduled work item before the worker thread has a chance to process it. The race condition is further exacerbated by the fact that although the id_table_lock is acquired during enqueue operations, it does not prevent the overwriting of work items that have already been scheduled but not yet executed. This scenario leads to a NULL pointer dereference in the kernel's workqueue processing logic, specifically within the process_one_work function where it attempts to access a NULL pool_workqueue pointer.
The operational impact of this vulnerability is severe as it can result in a kernel panic and system crash, particularly in environments where RDMA network events occur frequently or in high-throughput scenarios. The crash occurs in the kernel workqueue subsystem when the system attempts to process a work item that has been overwritten, leading to a NULL pointer dereference at line 3168 in process_one_work. This vulnerability affects systems using the RDMA communication manager and can be exploited to cause denial of service conditions. The issue is particularly concerning in data center and high-performance computing environments where RDMA is extensively used for low-latency network communication, as it could lead to unexpected system failures and service disruptions.
The fix implemented addresses the root cause by moving the INIT_WORK() initialization to the __rdma_create_id() function, ensuring that work items are properly initialized before any network event callbacks can attempt to schedule them. This change eliminates the race condition by guaranteeing that work items are initialized once during the creation of the rdma_cm_id structure, rather than during potentially concurrent callback processing. This approach aligns with best practices for workqueue management in kernel code and prevents the overwriting of work items that are already scheduled for execution. The solution follows the principle of avoiding races in kernel synchronization and ensures that the workqueue subsystem operates correctly even under high concurrency conditions. This fix is consistent with CWE-362, which describes race conditions in concurrent systems, and addresses the specific threat of workqueue corruption in kernel space. The mitigation strategy also aligns with ATT&CK techniques related to kernel exploitation and system stability compromise, as it prevents a fundamental flaw that could be leveraged to cause system instability.