<?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 20:16:00 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-68122</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-68122</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-68122</guid>
    </item>
    <item>
      <title>EUVD-2026-353478</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-353478</link>
      <description>EUVD-2026-353478</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-353478</guid>
    </item>
    <item>
      <title>fkie_cve-2026-68122</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-68122</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ovpn: fix peer refcount leak in TCP error paths&lt;/p&gt;
&lt;p&gt;When either the TCP RX or TX error path calls ovpn_peer_hold() followed
by schedule_work(&amp;amp;peer-&amp;gt;tcp.defer_del_work), and the work item is already
pending from the other path, schedule_work() returns false and the work
runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put()
exactly once, the extra reference taken by the losing path is never
dropped, leaking the peer object.&lt;/p&gt;
&lt;p&gt;The race window:&lt;/p&gt;
&lt;p&gt;CPU0 (strparser/RX error):       CPU1 (tcp_tx_work/TX error):
  ovpn_peer_hold()   &amp;lt;- refcnt+1   ovpn_peer_hold()   &amp;lt;- refcnt+2
  schedule_work()    &amp;lt;- queued      schedule_work()    &amp;lt;- NO-OP
                                    (work already pending)
  ovpn_tcp_peer_del_work runs:
    ovpn_peer_del()
    ovpn_peer_put()  &amp;lt;- refcnt+1
                                   &amp;lt;- peer never freed&lt;/p&gt;
&lt;p&gt;Fix by checking the return value of schedule_work() in both paths and
calling ovpn_peer_put() to drop the extra reference if the work was
already pending. ovpn_peer_hold() is kept unconditional in the TX path
as it cannot fail at that point.&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;ovpn: fix peer refcount leak in TCP error paths&lt;/p&gt;
&lt;p&gt;When either the TCP RX or TX error path calls ovpn_peer_hold() followed
by schedule_work(&amp;amp;peer-&amp;gt;tcp.defer_del_work), and the work item is already
pending from the other path, schedule_work() returns false and the work
runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put()
exactly once, the extra reference taken by the losing path is never
dropped, leaking the peer object.&lt;/p&gt;
&lt;p&gt;The race window:&lt;/p&gt;
&lt;p&gt;CPU0 (strparser/RX error):       CPU1 (tcp_tx_work/TX error):
  ovpn_peer_hold()   &amp;lt;- refcnt+1   ovpn_peer_hold()   &amp;lt;- refcnt+2
  schedule_work()    &amp;lt;- queued      schedule_work()    &amp;lt;- NO-OP
                                    (work already pending)
  ovpn_tcp_peer_del_work runs:
    ovpn_peer_del()
    ovpn_peer_put()  &amp;lt;- refcnt+1
                                   &amp;lt;- peer never freed&lt;/p&gt;
&lt;p&gt;Fix by checking the return value of schedule_work() in both paths and
calling ovpn_peer_put() to drop the extra reference if the work was
already pending. ovpn_peer_hold() is kept unconditional in the TX path
as it cannot fail at that point.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-68122</guid>
    </item>
    <item>
      <title>GHSA-76xv-8vj7-3x63</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-76xv-8vj7-3x63</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ovpn: fix peer refcount leak in TCP error paths&lt;/p&gt;
&lt;p&gt;When either the TCP RX or TX error path calls ovpn_peer_hold() followed
by schedule_work(&amp;amp;peer-&amp;gt;tcp.defer_del_work), and the work item is already
pending from the other path, schedule_work() returns false and the work
runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put()
exactly once, the extra reference taken by the losing path is never
dropped, leaking the peer object.&lt;/p&gt;
&lt;p&gt;The race window:&lt;/p&gt;
&lt;p&gt;CPU0 (strparser/RX error):       CPU1 (tcp_tx_work/TX error):
  ovpn_peer_hold()   &amp;lt;- refcnt+1   ovpn_peer_hold()   &amp;lt;- refcnt+2
  schedule_work()    &amp;lt;- queued      schedule_work()    &amp;lt;- NO-OP
                                    (work already pending)
  ovpn_tcp_peer_del_work runs:
    ovpn_peer_del()
    ovpn_peer_put()  &amp;lt;- refcnt+1
                                   &amp;lt;- peer never freed&lt;/p&gt;
&lt;p&gt;Fix by checking the return value of schedule_work() in both paths and
calling ovpn_peer_put() to drop the extra reference if the work was
already pending. ovpn_peer_hold() is kept unconditional in the TX path
as it cannot fail at that point.&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;ovpn: fix peer refcount leak in TCP error paths&lt;/p&gt;
&lt;p&gt;When either the TCP RX or TX error path calls ovpn_peer_hold() followed
by schedule_work(&amp;amp;peer-&amp;gt;tcp.defer_del_work), and the work item is already
pending from the other path, schedule_work() returns false and the work
runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put()
exactly once, the extra reference taken by the losing path is never
dropped, leaking the peer object.&lt;/p&gt;
&lt;p&gt;The race window:&lt;/p&gt;
&lt;p&gt;CPU0 (strparser/RX error):       CPU1 (tcp_tx_work/TX error):
  ovpn_peer_hold()   &amp;lt;- refcnt+1   ovpn_peer_hold()   &amp;lt;- refcnt+2
  schedule_work()    &amp;lt;- queued      schedule_work()    &amp;lt;- NO-OP
                                    (work already pending)
  ovpn_tcp_peer_del_work runs:
    ovpn_peer_del()
    ovpn_peer_put()  &amp;lt;- refcnt+1
                                   &amp;lt;- peer never freed&lt;/p&gt;
&lt;p&gt;Fix by checking the return value of schedule_work() in both paths and
calling ovpn_peer_put() to drop the extra reference if the work was
already pending. ovpn_peer_hold() is kept unconditional in the TX path
as it cannot fail at that point.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-76xv-8vj7-3x63</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-68122</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68122</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: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&amp;amp;peer-&amp;gt;tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window:   CPU0 (strparser/RX error):       CPU1 (tcp_tx_work/TX error):   ovpn_peer_hold()   &amp;lt;- refcnt+1   ovpn_peer_hold()   &amp;lt;- refcnt+2   schedule_work()    &amp;lt;- queued      schedule_work()    &amp;lt;- NO-OP                                     (work already pending)   ovpn_tcp_peer_del_work runs:     ovpn_peer_del()     ovpn_peer_put()  &amp;lt;- refcnt+1                                    &amp;lt;- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.&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: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&amp;amp;peer-&amp;gt;tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window:   CPU0 (strparser/RX error):       CPU1 (tcp_tx_work/TX error):   ovpn_peer_hold()   &amp;lt;- refcnt+1   ovpn_peer_hold()   &amp;lt;- refcnt+2   schedule_work()    &amp;lt;- queued      schedule_work()    &amp;lt;- NO-OP                                     (work already pending)   ovpn_tcp_peer_del_work runs:     ovpn_peer_del()     ovpn_peer_put()  &amp;lt;- refcnt+1                                    &amp;lt;- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68122</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>
