<?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>Sat, 03 Oct 2026 23:37:43 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-68378</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-68378</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-2026-68378</guid>
    </item>
    <item>
      <title>EUVD-2026-353576</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-353576</link>
      <description>EUVD-2026-353576</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-353576</guid>
    </item>
    <item>
      <title>fkie_cve-2026-68378</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-68378</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()&lt;/p&gt;
&lt;p&gt;When a dpll_pin is shared across multiple dpll_device instances and
those devices are being unregistered (e.g. during driver module removal),
a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().&lt;/p&gt;
&lt;p&gt;This happens under the following conditions:
 - A pin is registered with two or more dpll devices (dpll_A, dpll_B)
 - The pin has ref_sync pairs with other pins
 - During unregistration of dpll_A&amp;#39;s pins, a ref_sync partner pin is
   unregistered first, removing it from dpll_A-&amp;gt;pin_refs
 - But since the partner pin is still registered with dpll_B, its
   dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT
   run and the partner stays in the pin&amp;#39;s ref_sync_pins xarray
 - When the pin itself is then unregistered from dpll_A, the delete
   notification calls dpll_msg_add_pin_ref_sync() which finds the
   partner in ref_sync_pins, passes dpll_pin_available() (partner is
   still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,
   partner) returns NULL because partner was already removed from
   dpll_A-&amp;gt;pin_refs
 - The NULL priv pointer is passed to the driver&amp;#39;s ref_sync_get
   callback, which dereferences it&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000034
 Oops: Oops: 0000 [#1] SMP NOPTI
 RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]
 Call Trace:
  dpll_msg_add_pin_ref_sync+0xb8…&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;dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()&lt;/p&gt;
&lt;p&gt;When a dpll_pin is shared across multiple dpll_device instances and
those devices are being unregistered (e.g. during driver module removal),
a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().&lt;/p&gt;
&lt;p&gt;This happens under the following conditions:
 - A pin is registered with two or more dpll devices (dpll_A, dpll_B)
 - The pin has ref_sync pairs with other pins
 - During unregistration of dpll_A&amp;#39;s pins, a ref_sync partner pin is
   unregistered first, removing it from dpll_A-&amp;gt;pin_refs
 - But since the partner pin is still registered with dpll_B, its
   dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT
   run and the partner stays in the pin&amp;#39;s ref_sync_pins xarray
 - When the pin itself is then unregistered from dpll_A, the delete
   notification calls dpll_msg_add_pin_ref_sync() which finds the
   partner in ref_sync_pins, passes dpll_pin_available() (partner is
   still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,
   partner) returns NULL because partner was already removed from
   dpll_A-&amp;gt;pin_refs
 - The NULL priv pointer is passed to the driver&amp;#39;s ref_sync_get
   callback, which dereferences it&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000034
 Oops: Oops: 0000 [#1] SMP NOPTI
 RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]
 Call Trace:
  dpll_msg_add_pin_ref_sync+0xb8…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-68378</guid>
    </item>
    <item>
      <title>GHSA-j7r8-gfhw-6w5q</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-j7r8-gfhw-6w5q</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()&lt;/p&gt;
&lt;p&gt;When a dpll_pin is shared across multiple dpll_device instances and
those devices are being unregistered (e.g. during driver module removal),
a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().&lt;/p&gt;
&lt;p&gt;This happens under the following conditions:
 - A pin is registered with two or more dpll devices (dpll_A, dpll_B)
 - The pin has ref_sync pairs with other pins
 - During unregistration of dpll_A&amp;#39;s pins, a ref_sync partner pin is
   unregistered first, removing it from dpll_A-&amp;gt;pin_refs
 - But since the partner pin is still registered with dpll_B, its
   dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT
   run and the partner stays in the pin&amp;#39;s ref_sync_pins xarray
 - When the pin itself is then unregistered from dpll_A, the delete
   notification calls dpll_msg_add_pin_ref_sync() which finds the
   partner in ref_sync_pins, passes dpll_pin_available() (partner is
   still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,
   partner) returns NULL because partner was already removed from
   dpll_A-&amp;gt;pin_refs
 - The NULL priv pointer is passed to the driver&amp;#39;s ref_sync_get
   callback, which dereferences it&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000034
 Oops: Oops: 0000 [#1] SMP NOPTI
 RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]
 Call Trace:
  dpll_msg_add_pin_ref_sync+0xb8…&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;dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()&lt;/p&gt;
&lt;p&gt;When a dpll_pin is shared across multiple dpll_device instances and
those devices are being unregistered (e.g. during driver module removal),
a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().&lt;/p&gt;
&lt;p&gt;This happens under the following conditions:
 - A pin is registered with two or more dpll devices (dpll_A, dpll_B)
 - The pin has ref_sync pairs with other pins
 - During unregistration of dpll_A&amp;#39;s pins, a ref_sync partner pin is
   unregistered first, removing it from dpll_A-&amp;gt;pin_refs
 - But since the partner pin is still registered with dpll_B, its
   dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT
   run and the partner stays in the pin&amp;#39;s ref_sync_pins xarray
 - When the pin itself is then unregistered from dpll_A, the delete
   notification calls dpll_msg_add_pin_ref_sync() which finds the
   partner in ref_sync_pins, passes dpll_pin_available() (partner is
   still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,
   partner) returns NULL because partner was already removed from
   dpll_A-&amp;gt;pin_refs
 - The NULL priv pointer is passed to the driver&amp;#39;s ref_sync_get
   callback, which dereferences it&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000034
 Oops: Oops: 0000 [#1] SMP NOPTI
 RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]
 Call Trace:
  dpll_msg_add_pin_ref_sync+0xb8…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-j7r8-gfhw-6w5q</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-68378</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68378</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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions:  - A pin is registered with two or more dpll devices (dpll_A, dpll_B)  - The pin has ref_sync pairs with other pins  - During unregistration of dpll_A&amp;#39;s pins, a ref_sync partner pin is    unregistered first, removing it from dpll_A-&amp;gt;pin_refs  - But since the partner pin is still registered with dpll_B, its    dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT    run and the partner stays in the pin&amp;#39;s ref_sync_pins xarray  - When the pin itself is then unregistered from dpll_A, the delete    notification calls dpll_msg_add_pin_ref_sync() which finds the    partner in ref_sync_pins, passes dpll_pin_available() (partner is    still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,    partner) returns NULL because partner was already removed from    dpll_A-&amp;gt;pin_refs  - The NULL priv pointer is passed to the driver&amp;#39;s ref_sync_get    callback, which dereferences it  BUG: kernel NULL pointer dereference, address: 0000000000000034  Oops: Oops: 0000 [#1] SMP NOPTI  RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]  Call Trace:   dpll_msg_add_pin_ref_sync+0xb8/0x2…&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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions:  - A pin is registered with two or more dpll devices (dpll_A, dpll_B)  - The pin has ref_sync pairs with other pins  - During unregistration of dpll_A&amp;#39;s pins, a ref_sync partner pin is    unregistered first, removing it from dpll_A-&amp;gt;pin_refs  - But since the partner pin is still registered with dpll_B, its    dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT    run and the partner stays in the pin&amp;#39;s ref_sync_pins xarray  - When the pin itself is then unregistered from dpll_A, the delete    notification calls dpll_msg_add_pin_ref_sync() which finds the    partner in ref_sync_pins, passes dpll_pin_available() (partner is    still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,    partner) returns NULL because partner was already removed from    dpll_A-&amp;gt;pin_refs  - The NULL priv pointer is passed to the driver&amp;#39;s ref_sync_get    callback, which dereferences it  BUG: kernel NULL pointer dereference, address: 0000000000000034  Oops: Oops: 0000 [#1] SMP NOPTI  RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]  Call Trace:   dpll_msg_add_pin_ref_sync+0xb8/0x2…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68378</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2730 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</guid>
    </item>
  </channel>
</rss>
