<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 05 Oct 2026 10:46:29 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-03308</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-03308</link>
      <description>bdu:2026-03308</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-03308</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-39821</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-39821</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-39821</guid>
    </item>
    <item>
      <title>EUVD-2026-347219</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347219</link>
      <description>EUVD-2026-347219</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347219</guid>
    </item>
    <item>
      <title>fkie_cve-2025-39821</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-39821</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;perf: Avoid undefined behavior from stopping/starting inactive events&lt;/p&gt;
&lt;p&gt;Calling pmu-&amp;gt;start()/stop() on perf events in PERF_EVENT_STATE_OFF can
leave event-&amp;gt;hw.idx at -1. When PMU drivers later attempt to use this
negative index as a shift exponent in bitwise operations, it leads to UBSAN
shift-out-of-bounds reports.&lt;/p&gt;
&lt;p&gt;The issue is a logical flaw in how event groups handle throttling when some
members are intentionally disabled. Based on the analysis and the
reproducer provided by Mark Rutland (this issue on both arm64 and x86-64).&lt;/p&gt;
&lt;p&gt;The scenario unfolds as follows:&lt;/p&gt;
&lt;p&gt;1. A group leader event is configured with a very aggressive sampling
    period (e.g., sample_period = 1). This causes frequent interrupts and
    triggers the throttling mechanism.
 2. A child event in the same group is created in a disabled state
    (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.
    Since it hasn&amp;#39;t been scheduled onto the PMU, its event-&amp;gt;hw.idx remains
    initialized at -1.
 3. When throttling occurs, perf_event_throttle_group() and later
    perf_event_unthrottle_group() iterate through all siblings, including
    the disabled child event.
 4. perf_event_throttle()/unthrottle() are called on this inactive child
    event, which then call event-&amp;gt;pmu-&amp;gt;start()/stop().
 5. The PMU driver receives the event with hw.idx == -1 and attempts to
    use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),
    le…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;perf: Avoid undefined behavior from stopping/starting inactive events&lt;/p&gt;
&lt;p&gt;Calling pmu-&amp;gt;start()/stop() on perf events in PERF_EVENT_STATE_OFF can
leave event-&amp;gt;hw.idx at -1. When PMU drivers later attempt to use this
negative index as a shift exponent in bitwise operations, it leads to UBSAN
shift-out-of-bounds reports.&lt;/p&gt;
&lt;p&gt;The issue is a logical flaw in how event groups handle throttling when some
members are intentionally disabled. Based on the analysis and the
reproducer provided by Mark Rutland (this issue on both arm64 and x86-64).&lt;/p&gt;
&lt;p&gt;The scenario unfolds as follows:&lt;/p&gt;
&lt;p&gt;1. A group leader event is configured with a very aggressive sampling
    period (e.g., sample_period = 1). This causes frequent interrupts and
    triggers the throttling mechanism.
 2. A child event in the same group is created in a disabled state
    (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.
    Since it hasn&amp;#39;t been scheduled onto the PMU, its event-&amp;gt;hw.idx remains
    initialized at -1.
 3. When throttling occurs, perf_event_throttle_group() and later
    perf_event_unthrottle_group() iterate through all siblings, including
    the disabled child event.
 4. perf_event_throttle()/unthrottle() are called on this inactive child
    event, which then call event-&amp;gt;pmu-&amp;gt;start()/stop().
 5. The PMU driver receives the event with hw.idx == -1 and attempts to
    use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),
    le…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-39821</guid>
    </item>
    <item>
      <title>GHSA-cqwc-52gw-4x53</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-cqwc-52gw-4x53</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;perf: Avoid undefined behavior from stopping/starting inactive events&lt;/p&gt;
&lt;p&gt;Calling pmu-&amp;gt;start()/stop() on perf events in PERF_EVENT_STATE_OFF can
leave event-&amp;gt;hw.idx at -1. When PMU drivers later attempt to use this
negative index as a shift exponent in bitwise operations, it leads to UBSAN
shift-out-of-bounds reports.&lt;/p&gt;
&lt;p&gt;The issue is a logical flaw in how event groups handle throttling when some
members are intentionally disabled. Based on the analysis and the
reproducer provided by Mark Rutland (this issue on both arm64 and x86-64).&lt;/p&gt;
&lt;p&gt;The scenario unfolds as follows:&lt;/p&gt;
&lt;p&gt;1. A group leader event is configured with a very aggressive sampling
    period (e.g., sample_period = 1). This causes frequent interrupts and
    triggers the throttling mechanism.
 2. A child event in the same group is created in a disabled state
    (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.
    Since it hasn&amp;#39;t been scheduled onto the PMU, its event-&amp;gt;hw.idx remains
    initialized at -1.
 3. When throttling occurs, perf_event_throttle_group() and later
    perf_event_unthrottle_group() iterate through all siblings, including
    the disabled child event.
 4. perf_event_throttle()/unthrottle() are called on this inactive child
    event, which then call event-&amp;gt;pmu-&amp;gt;start()/stop().
 5. The PMU driver receives the event with hw.idx == -1 and attempts to
    use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),
    le…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;perf: Avoid undefined behavior from stopping/starting inactive events&lt;/p&gt;
&lt;p&gt;Calling pmu-&amp;gt;start()/stop() on perf events in PERF_EVENT_STATE_OFF can
leave event-&amp;gt;hw.idx at -1. When PMU drivers later attempt to use this
negative index as a shift exponent in bitwise operations, it leads to UBSAN
shift-out-of-bounds reports.&lt;/p&gt;
&lt;p&gt;The issue is a logical flaw in how event groups handle throttling when some
members are intentionally disabled. Based on the analysis and the
reproducer provided by Mark Rutland (this issue on both arm64 and x86-64).&lt;/p&gt;
&lt;p&gt;The scenario unfolds as follows:&lt;/p&gt;
&lt;p&gt;1. A group leader event is configured with a very aggressive sampling
    period (e.g., sample_period = 1). This causes frequent interrupts and
    triggers the throttling mechanism.
 2. A child event in the same group is created in a disabled state
    (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.
    Since it hasn&amp;#39;t been scheduled onto the PMU, its event-&amp;gt;hw.idx remains
    initialized at -1.
 3. When throttling occurs, perf_event_throttle_group() and later
    perf_event_unthrottle_group() iterate through all siblings, including
    the disabled child event.
 4. perf_event_throttle()/unthrottle() are called on this inactive child
    event, which then call event-&amp;gt;pmu-&amp;gt;start()/stop().
 5. The PMU driver receives the event with hw.idx == -1 and attempts to
    use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),
    le…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-cqwc-52gw-4x53</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-39821</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39821</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 79 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: perf: Avoid undefined behavior from stopping/starting inactive events Calling pmu-&amp;gt;start()/stop() on perf events in PERF_EVENT_STATE_OFF can leave event-&amp;gt;hw.idx at -1. When PMU drivers later attempt to use this negative index as a shift exponent in bitwise operations, it leads to UBSAN shift-out-of-bounds reports. The issue is a logical flaw in how event groups handle throttling when some members are intentionally disabled. Based on the analysis and the reproducer provided by Mark Rutland (this issue on both arm64 and x86-64). The scenario unfolds as follows:  1. A group leader event is configured with a very aggressive sampling     period (e.g., sample_period = 1). This causes frequent interrupts and     triggers the throttling mechanism.  2. A child event in the same group is created in a disabled state     (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.     Since it hasn&amp;#39;t been scheduled onto the PMU, its event-&amp;gt;hw.idx remains     initialized at -1.  3. When throttling occurs, perf_event_throttle_group() and later     perf_event_unthrottle_group() iterate through all siblings, including     the disabled child event.  4. perf_event_throttle()/unthrottle() are called on this inactive child     event, which then call event-&amp;gt;pmu-&amp;gt;start()/stop().  5. The PMU driver receives the event with hw.idx == -1 and attempts to     use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),     leading…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 79 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: perf: Avoid undefined behavior from stopping/starting inactive events Calling pmu-&amp;gt;start()/stop() on perf events in PERF_EVENT_STATE_OFF can leave event-&amp;gt;hw.idx at -1. When PMU drivers later attempt to use this negative index as a shift exponent in bitwise operations, it leads to UBSAN shift-out-of-bounds reports. The issue is a logical flaw in how event groups handle throttling when some members are intentionally disabled. Based on the analysis and the reproducer provided by Mark Rutland (this issue on both arm64 and x86-64). The scenario unfolds as follows:  1. A group leader event is configured with a very aggressive sampling     period (e.g., sample_period = 1). This causes frequent interrupts and     triggers the throttling mechanism.  2. A child event in the same group is created in a disabled state     (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.     Since it hasn&amp;#39;t been scheduled onto the PMU, its event-&amp;gt;hw.idx remains     initialized at -1.  3. When throttling occurs, perf_event_throttle_group() and later     perf_event_unthrottle_group() iterate through all siblings, including     the disabled child event.  4. perf_event_throttle()/unthrottle() are called on this inactive child     event, which then call event-&amp;gt;pmu-&amp;gt;start()/stop().  5. The PMU driver receives the event with hw.idx == -1 and attempts to     use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),     leading…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39821</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2077 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2077</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2077</guid>
    </item>
  </channel>
</rss>
