Incomplete Cleanup 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-22284060
- published8 Nov 2026
- disclosed2 Nov 2026
Introduced: 2 Nov 2026
NewCVE-2026-99234 (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:
tracing: Unregister field variable histograms when the command fails
An action that names a field on another event needs that field as a variable, so create_field_var_hist() registers a second hist trigger on that event to provide it, and records it in target_hist_data->field_var_hists[].
If a later part of the same command fails, create_actions() returns an error and event_hist_trigger_parse() jumps to out_free. The write fails with -EINVAL and sched_switch gets no trigger, but:
echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> \
events/sched/sched_waking/trigger
echo 'my_synth u64 lat; int a; int b' >> synthetic_events
echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\
onmatch(sched.sched_waking).my_synth($wakeup_lat,prio,nosuchfld)'\
>> events/sched/sched_switch/trigger
cat events/sched/sched_waking/trigger
hist:keys=pid:vals=hitcount:ts0=common_timestamp.usecs:sort=hitcount:size=2048:clock=global [active] hist:keys=pid:vals=hitcount:synthetic_prio=prio:sort=hitcount:size=2048 [active]
The second histogram is the one created for 'prio'. It is still active and still counting.
out_free reaches destroy_field_var_hists(), which frees the field_var_hists[] entries, but never unregister_field_var_hists(), which is what removes the triggers and runs only from event_hist_trigger_free(). The entry is freed and the trigger is left with nothing tracking it.
Unregister the field variable histograms in out_free as well, and record each one as soon as its trigger is registered rather than after the lookup that follows it, so no exit can leave a registered trigger untracked. The entry then belongs to field_var_hists[] and is released by destroy_field_var_hists(), so freeing it on that exit would be a double free.
References
- https://access.redhat.com/security/cve/CVE-2026-99234
- https://git.kernel.org/stable/c/431959fc76456cbba539279fe8967aa9391e6f23
- https://git.kernel.org/stable/c/5afb9317e2eeb1c7021a82995ce244fda5a4bd4f
- https://git.kernel.org/stable/c/8482ec5b65f606d5bbcec518e0afc69ad65ca414
- https://git.kernel.org/stable/c/a3d7ffd2409700748a495b645948fef48199206e
- https://git.kernel.org/stable/c/aae0ccd7326eef78dcdefffef3d1253e6f0615ca
- https://git.kernel.org/stable/c/d0090baf02dd08f6e909f36f0ad54a4e80f5e79b
- https://git.kernel.org/stable/c/dba0f492703956801149cc70b39d2650a37995c3
- https://git.kernel.org/stable/c/f21351d1c4cdcc6a68f03636a407c2af1a5e1e10
- https://git.kernel.org/stable/c/91c14d6c13096091c56304120aaa26e479130b8b