CVE-2025-37772 in Linux
Zusammenfassung
von VulDB • 29.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
RDMA/cma: Behebung eines Workqueue-Crashes in cma_netevent_work_handler
Die Struktur `struct rdma_cm_id` verfügt über das Mitglied „struct work_struct net_work", das zur Wiederverwendung für das Einreihen von `cma_netevent_work_handler()`-Aufrufen in `cma_wq` dient.
Der unten beschriebene Crash [1] kann auftreten, wenn mehrere Aufrufe von `cma_netevent_callback()` schnell nacheinander erfolgen, wodurch weitere `cma_netevent_work_handler()`-Aufrufe für dieselbe `rdma_cm_id` eingereiht werden. Dabei werden zuvor eingereihte Work-Items überschrieben, die gerade zur Ausführung geplant waren. Es gibt keine Garantie, dass das eingereihte Work-Item zwischen zwei aufeinanderfolgenden Aufrufen von `cma_netevent_callback()` ausgeführt wird, und der zweite `INIT_WORK`-Aufruf würde das erste Work-Item (für dieselbe `rdma_cm_id`) überschreiben, obwohl während des Einreihens die `id_table_lock` gehalten wird.
Auch die drgn-Analyse [2] deutet darauf hin, dass das Work-Item wahrscheinlich überschrieben wurde.
Behoben wird dies durch Verschieben von `INIT_WORK()` nach `__rdma_create_id()`, sodass kein Race Condition mit bestehenden `queue_work()`-Aufrufen oder deren Worker-Threads entsteht.
[1] Eingekürzter 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-Crashanalyse:
>>> 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:3500:2) (10) worker_thread (kernel/workqueue.c:3646:13) (11) kthread (kernel/kthread.c:400:19) (12) ret_from_fork (arch/x86/entry/entry_64.S:130:1) (13) ret_from_fork_asm (arch/x86/entry/entry_64.S:120:1)
>>> trace[8]["pwq"]
(struct pool_workqueue *)<absent>
In process_one_work() wird pwq zugewiesen aus: struct pool_workqueue *pwq = get_work_pwq(work);
und get_work_pwq() ist: 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 ist 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ']))
Object(prog, 'enum work_flags', value=4)
Aber work->data ist 536870912, was 0x20000000 entspricht. Somit gibt get_work_pwq() NULL zurück und wir stürzen in process_one_work() ab: 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
If you want to get the best quality for vulnerability data then you always have to consider VulDB.