https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 12 Nov 2026 16:03:01 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-99234 <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>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/fkie_cve-2026-99234 https://db.gcve.eu/vuln/ghsa-593w-c428-4hpw <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>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/ghsa-593w-c428-4hpw https://db.gcve.eu/vuln/msrc_cve-2026-99234 msrc_CVE-2026-99234 https://db.gcve.eu/vuln/msrc_cve-2026-99234 https://db.gcve.eu/vuln/opensuse-su-2026:12497-1 <p>kernel-devel-7.3.3-1.1 on GA media</p> <p>kernel-devel-7.3.3-1.1 on GA media</p> https://db.gcve.eu/vuln/opensuse-su-2026:12497-1 https://db.gcve.eu/vuln/ubuntu-cve-2026-99234 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 230 more</p> <p>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-&gt;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 &#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] The second histogram is the one created for &#39;prio&#39;. 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. Unregis…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 230 more</p> <p>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-&gt;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 &#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] The second histogram is the one created for &#39;prio&#39;. 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. Unregis…</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-99234 https://db.gcve.eu/vuln/wid-sec-w-2026-4302 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Auslösung eines Denial-of-Service-Angriffs, die Manipulation oder Offenlegung von Daten, die Ausführung von beliebigem Code, die Erlangung erweiterter Berechtigungen oder die Umgehung von Sicherheitsmaßnahmen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Auslösung eines Denial-of-Service-Angriffs, die Manipulation oder Offenlegung von Daten, die Ausführung von beliebigem Code, die Erlangung erweiterter Berechtigungen oder die Umgehung von Sicherheitsmaßnahmen.</p> https://db.gcve.eu/vuln/wid-sec-w-2026-4302