CVE-2025-37772 in Linux
Sumário
de VulDB • 24/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
RDMA/cma: Corrige falha no workqueue em cma_netevent_work_handler
A estrutura `struct rdma_cm_id` possui o membro `"struct work_struct net_work"` que é reutilizado para enfileirar chamadas de `cma_netevent_work_handler()` no `cma_wq`.
A falha abaixo [1] pode ocorrer se houver mais de uma chamada para `cma_netevent_callback()` em rápida sucessão, o que enfileira novamente `cma_netevent_work_handler()`s para o mesmo `rdma_cm_id`, sobrescrevendo quaisquer itens de trabalho anteriormente enfileirados que estavam programados para serem executados, ou seja, não há garantia de que o item de trabalho enfileirado possa ser executado entre duas chamadas sucessivas de `cma_netevent_callback()` e a segunda chamada de `INIT_WORK` sobrescreverá o primeiro item de trabalho (para o mesmo `rdma_cm_id`), apesar de adquirir `id_table_lock` durante o enfileiramento.
Além disso, a análise do drgn [2] indica que o item de trabalho provavelmente foi sobrescrito.
Corrija isso movendo o `INIT_WORK()` para `__rdma_create_id()`, para que não haja uma condição de corrida com qualquer `queue_work()` existente ou com sua thread de trabalho.
[1] Pilha de falha truncada:
============================================= 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] Análise de falha do drgn:
>>> 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:3459:3) (11) kthread (kernel/kthread.c:408:21) (12) ret_from_fork (arch/x86/entry/entry_64.S:120:1) (13) ret_from_fork_asm (arch/x86/entry/entry_64.S:120:1) >>> trace[8]["pwq"]
(struct pool_workqueue *)<absent>
Em process_one_work(), pwq é atribuído de: struct pool_workqueue *pwq = get_work_pwq(work);
e get_work_pwq() é: 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 é 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ']))
Object(prog, 'enum work_flags', value=4)
Mas work->data é 536870912 que é 0x20000000. Então, get_work_pwq() retorna NULL e nós falhamos em process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
If you want to get best quality of vulnerability data, you may have to visit VulDB.