<?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>Fri, 02 Oct 2026 20:32:01 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-68142</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-68142</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-68142</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1069 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069</link>
      <description>certfr-2026-avi-1069</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069</guid>
    </item>
    <item>
      <title>EUVD-2026-356013</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-356013</link>
      <description>EUVD-2026-356013</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-356013</guid>
    </item>
    <item>
      <title>fkie_cve-2026-68142</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-68142</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;geneve: require CAP_NET_ADMIN in the device netns for changelink&lt;/p&gt;
&lt;p&gt;A tunnel changelink() operates on at most two netns, dev_net(dev) and
the sticky underlay netns geneve-&amp;gt;net. They differ once the device is
created in or moved to a netns other than the one the request runs in.
The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),
so a caller privileged there but not in geneve-&amp;gt;net can rewrite a geneve
device whose underlay lives in geneve-&amp;gt;net.&lt;/p&gt;
&lt;p&gt;geneve_changelink() applies the new configuration against geneve-&amp;gt;net:
geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair
reopen the underlay sockets in that netns (geneve_sock_add() uses
geneve-&amp;gt;net), so the same reasoning as the tunnel changelink series
applies here.&lt;/p&gt;
&lt;p&gt;Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of
the op before any attribute is parsed, matching ipgre_changelink() and
the rest of the &amp;#34;require CAP_NET_ADMIN in the device netns for
changelink&amp;#34; series.&lt;/p&gt;
&lt;p&gt;Found by 0sec automated security-research tooling (https://0sec.ai).&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;geneve: require CAP_NET_ADMIN in the device netns for changelink&lt;/p&gt;
&lt;p&gt;A tunnel changelink() operates on at most two netns, dev_net(dev) and
the sticky underlay netns geneve-&amp;gt;net. They differ once the device is
created in or moved to a netns other than the one the request runs in.
The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),
so a caller privileged there but not in geneve-&amp;gt;net can rewrite a geneve
device whose underlay lives in geneve-&amp;gt;net.&lt;/p&gt;
&lt;p&gt;geneve_changelink() applies the new configuration against geneve-&amp;gt;net:
geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair
reopen the underlay sockets in that netns (geneve_sock_add() uses
geneve-&amp;gt;net), so the same reasoning as the tunnel changelink series
applies here.&lt;/p&gt;
&lt;p&gt;Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of
the op before any attribute is parsed, matching ipgre_changelink() and
the rest of the &amp;#34;require CAP_NET_ADMIN in the device netns for
changelink&amp;#34; series.&lt;/p&gt;
&lt;p&gt;Found by 0sec automated security-research tooling (https://0sec.ai).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-68142</guid>
    </item>
    <item>
      <title>GHSA-2rrg-cg9g-pgvw</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-2rrg-cg9g-pgvw</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;geneve: require CAP_NET_ADMIN in the device netns for changelink&lt;/p&gt;
&lt;p&gt;A tunnel changelink() operates on at most two netns, dev_net(dev) and
the sticky underlay netns geneve-&amp;gt;net. They differ once the device is
created in or moved to a netns other than the one the request runs in.
The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),
so a caller privileged there but not in geneve-&amp;gt;net can rewrite a geneve
device whose underlay lives in geneve-&amp;gt;net.&lt;/p&gt;
&lt;p&gt;geneve_changelink() applies the new configuration against geneve-&amp;gt;net:
geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair
reopen the underlay sockets in that netns (geneve_sock_add() uses
geneve-&amp;gt;net), so the same reasoning as the tunnel changelink series
applies here.&lt;/p&gt;
&lt;p&gt;Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of
the op before any attribute is parsed, matching ipgre_changelink() and
the rest of the &amp;#34;require CAP_NET_ADMIN in the device netns for
changelink&amp;#34; series.&lt;/p&gt;
&lt;p&gt;Found by 0sec automated security-research tooling (https://0sec.ai).&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;geneve: require CAP_NET_ADMIN in the device netns for changelink&lt;/p&gt;
&lt;p&gt;A tunnel changelink() operates on at most two netns, dev_net(dev) and
the sticky underlay netns geneve-&amp;gt;net. They differ once the device is
created in or moved to a netns other than the one the request runs in.
The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),
so a caller privileged there but not in geneve-&amp;gt;net can rewrite a geneve
device whose underlay lives in geneve-&amp;gt;net.&lt;/p&gt;
&lt;p&gt;geneve_changelink() applies the new configuration against geneve-&amp;gt;net:
geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair
reopen the underlay sockets in that netns (geneve_sock_add() uses
geneve-&amp;gt;net), so the same reasoning as the tunnel changelink series
applies here.&lt;/p&gt;
&lt;p&gt;Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of
the op before any attribute is parsed, matching ipgre_changelink() and
the rest of the &amp;#34;require CAP_NET_ADMIN in the device netns for
changelink&amp;#34; series.&lt;/p&gt;
&lt;p&gt;Found by 0sec automated security-research tooling (https://0sec.ai).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-2rrg-cg9g-pgvw</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-68142 — geneve: require CAP_NET_ADMIN in the device netns for changelink</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-68142</link>
      <description>msrc_CVE-2026-68142</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-68142</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-68142</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68142</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve-&amp;gt;net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve-&amp;gt;net can rewrite a geneve device whose underlay lives in geneve-&amp;gt;net. geneve_changelink() applies the new configuration against geneve-&amp;gt;net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve-&amp;gt;net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the &amp;#34;require CAP_NET_ADMIN in the device netns for changelink&amp;#34; series. Found by 0sec automated security-research tooling (https://0sec.ai).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve-&amp;gt;net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve-&amp;gt;net can rewrite a geneve device whose underlay lives in geneve-&amp;gt;net. geneve_changelink() applies the new configuration against geneve-&amp;gt;net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve-&amp;gt;net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the &amp;#34;require CAP_NET_ADMIN in the device netns for changelink&amp;#34; series. Found by 0sec automated security-research tooling (https://0sec.ai).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68142</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>
