Expired Pointer Dereference Affecting openshift/ose-rhel-coreos-9 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-RHEL7-OPENSHIFTOSERHELCOREOS9-19786465
- published14 Sept 2026
- disclosed11 Sept 2026
Introduced: 11 Sep 2026
NewCVE-2026-89738 (opens in a new tab)How to fix?
There is no fixed version for RHEL:7 openshift/ose-rhel-coreos-9.
NVD Description
Note: Versions mentioned in the description apply only to the upstream openshift/ose-rhel-coreos-9 package and not the openshift/ose-rhel-coreos-9 package as distributed by RHEL.
See How to fix? for RHEL:7 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed
In polled-VBUS mode (board.vbus_pin && board.vbus_polled), probe arms a self-restarting cycle: at91_vbus_timer() schedules vbus_timer_work, and at91_vbus_timer_work() calls at91_vbus_update() and re-arms the timer via mod_timer(). Both recover the same udc through container_of and dereference it on every iteration.
Neither teardown path cancels this cycle. udc is devm-allocated, so it is freed after at91udc_remove() returns, and is likewise freed when probe fails and devres runs. A timer callback or work item that is pending or running at either point dereferences the freed udc.
Add at91_udc_shutdown_vbus_timer() and call it from at91udc_remove() and from the usb_add_gadget_udc() failure path in probe; the remaining probe error paths fail before the timer is armed. timer_shutdown_sync() waits for a running callback and clears timer->function, which makes the work handler's mod_timer() a permanent no-op; cancel_work_sync() then drains any pending or running work whose re-arm attempt now does nothing. The timer must be shut down first, since cancelling the work alone would let the timer re-queue it. The guard mirrors probe: in IRQ mode the timer and work_struct are never initialized.
This does not require a fault; a normal driver unbind can interleave with an already queued work item.
This issue was found by an in-house static analysis tool.
References
- https://access.redhat.com/security/cve/CVE-2026-89738
- https://git.kernel.org/stable/c/51a311eb97e91ce1aed3005cb71ccb2e30f8cce8
- https://git.kernel.org/stable/c/557ef547d49ff5e6026a4d39bdd3113bd81d7688
- https://git.kernel.org/stable/c/a2a602cb1e28d76a5398cec3fa21b0110385f501
- https://git.kernel.org/stable/c/c27d13ce4bab80fbdf6523928071b6c24b37606c