<?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 22:39:10 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-68432</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-68432</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-68432</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-356341</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-356341</link>
      <description>EUVD-2026-356341</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-356341</guid>
    </item>
    <item>
      <title>fkie_cve-2026-68432</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-68432</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vxlan: 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 vxlan-&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 vxlan-&amp;gt;net can rewrite a vxlan
device whose underlay lives in vxlan-&amp;gt;net.&lt;/p&gt;
&lt;p&gt;vxlan_changelink() validates and applies the new configuration against
vxlan-&amp;gt;net (vxlan_config_validate(vxlan-&amp;gt;net, ...)) and can reopen the
underlay socket in that netns, so the same reasoning as the tunnel
changelink series applies here.&lt;/p&gt;
&lt;p&gt;Gate vxlan_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;vxlan: 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 vxlan-&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 vxlan-&amp;gt;net can rewrite a vxlan
device whose underlay lives in vxlan-&amp;gt;net.&lt;/p&gt;
&lt;p&gt;vxlan_changelink() validates and applies the new configuration against
vxlan-&amp;gt;net (vxlan_config_validate(vxlan-&amp;gt;net, ...)) and can reopen the
underlay socket in that netns, so the same reasoning as the tunnel
changelink series applies here.&lt;/p&gt;
&lt;p&gt;Gate vxlan_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-68432</guid>
    </item>
    <item>
      <title>GHSA-mq37-5gx6-p5gp</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-mq37-5gx6-p5gp</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vxlan: 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 vxlan-&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 vxlan-&amp;gt;net can rewrite a vxlan
device whose underlay lives in vxlan-&amp;gt;net.&lt;/p&gt;
&lt;p&gt;vxlan_changelink() validates and applies the new configuration against
vxlan-&amp;gt;net (vxlan_config_validate(vxlan-&amp;gt;net, ...)) and can reopen the
underlay socket in that netns, so the same reasoning as the tunnel
changelink series applies here.&lt;/p&gt;
&lt;p&gt;Gate vxlan_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;vxlan: 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 vxlan-&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 vxlan-&amp;gt;net can rewrite a vxlan
device whose underlay lives in vxlan-&amp;gt;net.&lt;/p&gt;
&lt;p&gt;vxlan_changelink() validates and applies the new configuration against
vxlan-&amp;gt;net (vxlan_config_validate(vxlan-&amp;gt;net, ...)) and can reopen the
underlay socket in that netns, so the same reasoning as the tunnel
changelink series applies here.&lt;/p&gt;
&lt;p&gt;Gate vxlan_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-mq37-5gx6-p5gp</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-68432 — vxlan: require CAP_NET_ADMIN in the device netns for changelink</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-68432</link>
      <description>msrc_CVE-2026-68432</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-68432</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-68432</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68432</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: vxlan: 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 vxlan-&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 vxlan-&amp;gt;net can rewrite a vxlan device whose underlay lives in vxlan-&amp;gt;net. vxlan_changelink() validates and applies the new configuration against vxlan-&amp;gt;net (vxlan_config_validate(vxlan-&amp;gt;net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_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: vxlan: 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 vxlan-&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 vxlan-&amp;gt;net can rewrite a vxlan device whose underlay lives in vxlan-&amp;gt;net. vxlan_changelink() validates and applies the new configuration against vxlan-&amp;gt;net (vxlan_config_validate(vxlan-&amp;gt;net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_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-68432</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2799 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2799</link>
      <description>&lt;p&gt;Ein entfernter, anonymer 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 Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer 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 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-2799</guid>
    </item>
  </channel>
</rss>
