https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 12 Nov 2026 14:58:26 +0000 https://db.gcve.eu/vuln/cve-2026-99234 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tracing: Unregister field variable histograms when the command fails</p> <p>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-&gt;field_var_hists[].</p> <p>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:</p> <p># echo &#39;hist:keys=pid:ts0=common_timestamp.usecs&#39; &gt;&gt; \ events/sched/sched_waking/trigger # echo &#39;my_synth u64 lat; int a; int b&#39; &gt;&gt; synthetic_events # echo &#39;hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).my_synth($wakeup_lat,prio,nosuchfld)&#39;\ &gt;&gt; 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]</p> <p>The second histogram is the one created for &#39;prio&#39;. It is still active and still counting.</p> <p>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.…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tracing: Unregister field variable histograms when the command fails</p> <p>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-&gt;field_var_hists[].</p> <p>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:</p> <p># echo &#39;hist:keys=pid:ts0=common_timestamp.usecs&#39; &gt;&gt; \ events/sched/sched_waking/trigger # echo &#39;my_synth u64 lat; int a; int b&#39; &gt;&gt; synthetic_events # echo &#39;hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).my_synth($wakeup_lat,prio,nosuchfld)&#39;\ &gt;&gt; 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]</p> <p>The second histogram is the one created for &#39;prio&#39;. It is still active and still counting.</p> <p>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.…</p> https://db.gcve.eu/vuln/cve-2026-99234