Look up another CVE · open CVE-2026-89507 in the interactive tracker
CVE-2026-89507
RDMA/ucma: Lock the handler in ucma_write_cm_event()
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/infiniband. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89507 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
ctx->file may only be changed under the handler lock and the xa_lock, which is what stops uevents being queued for a ctx while ucma_migrate_id() moves it to another file. The CM core takes that lock before invoking ucma_event_handler(), but the write() paths that queue uevents themselves do not. ucma_write_cm_event() re-reads ctx->file for each of its four dereferences, so ucma_migrate_id() can swap it mid-sequence: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */ mutex_unlock(&ctx->file->mut); /* file B */ wake_up_interruptible(&ctx->file->poll_wait); /* file B */ The window is the mutex_lock() itself: the writer sleeps in it while the migration reassigns ctx->file. The list_add_tail() then runs on file B's event_list holding only file A's mutex: list_add corruption. prev->next should be next (ffff888101320f30), but was ffff88814a08c418. (prev=ffff88814a075c18). kernel BUG at lib/list_debug.c:32! Call Trace: ucma_write_cm_event+0x36e/0x5e0 and file A's mut is left held forever, wedging its next writer in D state. The uevent is also stranded on a list ucma_cleanup_ctx_events() will not walk, so it outlives its context. /dev/infiniband/rdma_cm is 0666 and no RDMA device is involved, so an unprivileged user reaches all of this. Take the handler lock, as ucma_cleanup_mc_events() does; ctx->cm_id is pinned by the ucma_get_ctx() reference.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/infiniband/core/ucma.c
- What this is
- INFINIBAND SUBSYSTEMMAINTAINERS section matched on drivers/infiniband/ · linux-rdma@vger.kernel.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/infiniband
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.18 | 6.18.50 | 4f8bb11dd2ff |
| 6.18 | 7.2.4 | 0be1955040a2 |
| 6.18 | 7.3 | f4cc21c6a8e9 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Reached by write() on the local misc device /dev/infiniband/rdma_cm (ucma_write → WRITE_CM_EVENT racing MIGRATE_ID). Remote RDMA CM packet handling already takes the handler lock in ucma_event_handler(), so this bug is not a network-packet path.
- AC:LAttack complexity, low
- The attacker fully controls both sides of the race: one thread issues WRITE_CM_EVENT while another issues MIGRATE_ID on the same ctx, and can hold file A's mutex from a third thread so the writer sleeps in mutex_lock() across ctx->file reassignment.
- PR:LPrivileges required, low
- ucma registers /dev/infiniband/rdma_cm with mode 0666 and the command path (create_id, write_cm_event, migrate_id) has no capability checks. No RDMA hardware is required (ucma_get_ctx, not ucma_get_ctx_dev), so any unprivileged local user can open the device and trigger the bug.
- UI:NUser interaction, none
- Exploitation uses only the attacker's own open/write syscalls against rdma_cm; no other user or administrator action is required.
- S:UScope, unchanged
- This is in-kernel list corruption and use-after-free within the host kernel's security authority. It can escalate privileges on the host but does not cross a VM, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- The unlocked list_add can strand a uevent on another file's list so it outlives its ucma_context, and concurrent GET_EVENT can free a ucma_event still being linked (UAF). Per UAF guidance that enables attacker-controlled reuse and arbitrary kernel reads.
- I:HIntegrity impact, high
- list_add_tail on file B's event_list while holding only file A's mutex, plus mutex_unlock of an unheld mutex, corrupts kernel lists; combined with UAF of ctx/uevent this yields heap-sprayable write and list-unlink primitives for control-flow hijacking.
- A:HAvailability impact, high
- The race was reproduced as kernel BUG at lib/list_debug.c:32 in ucma_write_cm_event, and file A's mutex is left held forever wedging later writers in D-state. UAFs also oops, so availability impact is high even without full exploitation.