CVE-2026-89508

In the Linux kernel, the following vulnerability has been resolved:

RDMA/ucma: Lock the handler in ucma set ib path()

ucma set ib path() calls ucma event handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference:

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 */

A concurrent ucma migrate id() reassigns ctx->file while the SET OPTION caller sleeps in mutex lock(), so the list add tail() lands on file B's event list while only file A's mutex is held, racing every other user of that list:

BUG: KASAN: slab-use-after-free in list add valid or report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc corr/486 Call Trace: list add valid or report+0x1aa/0x1c0 ucma event handler+0x1be/0xc00 ucma set ib path+0x45e/0x710 ucma set option+0x32e/0x590 ucma write+0x1f9/0x330 Allocated by task 505: ucma write cm event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma get event+0x5d5/0x7e0

The freed object is a ucma event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep.

This path needs a bound and address-resolved cm id, so it requires an RDMA device to be present.

Take the handler lock around the call.