Expired Pointer Dereference 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-RHEL8-OPENSHIFTOSERHELCOREOS8-19785961
- published14 Sept 2026
- disclosed11 Sept 2026
Introduced: 11 Sep 2026
NewCVE-2026-89465 (opens in a new tab)How to fix?
There is no fixed version for RHEL:8 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:8 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
power: supply: rt9455: quiesce delayed work before teardown
The threaded IRQ handler can queue pwr_rdy_work, max_charging_time_work and batt_presence_work. pwr_rdy_work and batt_presence_work can also queue max_charging_time_work, while batt_presence_work can requeue itself.
rt9455_remove() cancels max_charging_time_work before batt_presence_work. The latter can therefore queue max_charging_time_work after it has already been cancelled:
rt9455_remove() workqueue cancel pwr_rdy_work cancel max_charging_time_work batt_presence_work queues max_charging_time_work cancel batt_presence_work return devres frees rt9455_info max_charging_time_work dereferences rt9455_info
The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls. If rt9455_hw_init() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued. A pending callback can then access rt9455_info after it has been freed.
Register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() right after devm_power_supply_register(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455_info is released, so the delayed works are drained in both rt9455_remove() and the probe error path. Cancel pwr_rdy_work and batt_presence_work before max_charging_time_work because both can queue the latter.
This issue was found by an in-house static analysis tool.
References
- https://access.redhat.com/security/cve/CVE-2026-89465
- https://git.kernel.org/stable/c/1b9978433c61a9b46e48832a1ebceee1cf5c9eb4
- https://git.kernel.org/stable/c/3e7a1ebc32fad5a558254a478efd401c17a24381
- https://git.kernel.org/stable/c/7323e562f6961e4b7bce3225cde4ecbc78260deb
- https://git.kernel.org/stable/c/df67c7a2fff8414aa766b8cd5ffe11ec1ca27d02
- https://git.kernel.org/stable/c/442c60c08ec23ac45da0a58877cab05e0a58f4ea