Time-of-check Time-of-use (TOCTOU) Affecting openshift/ose-rhel-coreos-8 package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL9-OPENSHIFTOSERHELCOREOS8-19784613
- published14 Sept 2026
- disclosed11 Sept 2026
Introduced: 11 Sep 2026
NewCVE-2026-89508 (opens in a new tab)How to fix?
There is no fixed version for RHEL:9 openshift/ose-rhel-coreos-8.
NVD Description
Note: Versions mentioned in the description apply only to the upstream openshift/ose-rhel-coreos-8 package and not the openshift/ose-rhel-coreos-8 package as distributed by RHEL.
See How to fix? for RHEL:9 relevant fixed versions and status.
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.
References
- https://access.redhat.com/security/cve/CVE-2026-89508
- https://git.kernel.org/stable/c/28ac2dd416482d1c763c4af5d61af465b387fb50
- https://git.kernel.org/stable/c/43a7d8ae9f645dc00235cfa4bf57673c20b769f8
- https://git.kernel.org/stable/c/764586f8f6180084c5a7d622120f526acc6ce0c9
- https://git.kernel.org/stable/c/ecbe7d36dc2de07e5dfbb4a8ff5b315ab43de820
- https://git.kernel.org/stable/c/3dd07b369371a2f29e1c3caf1ade85bb92b4c551
- https://git.kernel.org/stable/c/71dc206f2e2a645dac78879768762451aa1799f7
- https://git.kernel.org/stable/c/a7f8d26e653ee43b0b572984b8ec544d3b3b6f3c
- https://git.kernel.org/stable/c/b2da0d488a1c72956ebb0a57015ee8ee6a2f7748