<?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 17:15:29 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-01636</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-01636</link>
      <description>bdu:2026-01636</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-01636</guid>
    </item>
    <item>
      <title>EUVD-2026-310989</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-310989</link>
      <description>EUVD-2026-310989</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-310989</guid>
    </item>
    <item>
      <title>fkie_cve-2022-50063</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-50063</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: felix: suppress non-changes to the tagging protocol&lt;/p&gt;
&lt;p&gt;The way in which dsa_tree_change_tag_proto() works is that when
dsa_tree_notify() fails, it doesn&amp;#39;t know whether the operation failed
mid way in a multi-switch tree, or it failed for a single-switch tree.
So even though drivers need to fail cleanly in
ds-&amp;gt;ops-&amp;gt;change_tag_protocol(), DSA will still call dsa_tree_notify()
again, to restore the old tag protocol for potential switches in the
tree where the change did succeeed (before failing for others).&lt;/p&gt;
&lt;p&gt;This means for the felix driver that if we report an error in
felix_change_tag_protocol(), we&amp;#39;ll get another call where proto_ops ==
old_proto_ops. If we proceed to act upon that, we may do unexpected
things. For example, we will call dsa_tag_8021q_register() twice in a
row, without any dsa_tag_8021q_unregister() in between. Then we will
actually call dsa_tag_8021q_unregister() via old_proto_ops-&amp;gt;teardown,
which (if it manages to run at all, after walking through corrupted data
structures) will leave the ports inoperational anyway.&lt;/p&gt;
&lt;p&gt;The bug can be readily reproduced if we force an error while in
tag_8021q mode; this crashes the kernel.&lt;/p&gt;
&lt;p&gt;echo ocelot-8021q &amp;gt; /sys/class/net/eno2/dsa/tagging
echo edsa &amp;gt; /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014
Call trace:
 vcap_entry_get+0x24/0x124
 ocelot_vcap_filter_del+0x…&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;net: dsa: felix: suppress non-changes to the tagging protocol&lt;/p&gt;
&lt;p&gt;The way in which dsa_tree_change_tag_proto() works is that when
dsa_tree_notify() fails, it doesn&amp;#39;t know whether the operation failed
mid way in a multi-switch tree, or it failed for a single-switch tree.
So even though drivers need to fail cleanly in
ds-&amp;gt;ops-&amp;gt;change_tag_protocol(), DSA will still call dsa_tree_notify()
again, to restore the old tag protocol for potential switches in the
tree where the change did succeeed (before failing for others).&lt;/p&gt;
&lt;p&gt;This means for the felix driver that if we report an error in
felix_change_tag_protocol(), we&amp;#39;ll get another call where proto_ops ==
old_proto_ops. If we proceed to act upon that, we may do unexpected
things. For example, we will call dsa_tag_8021q_register() twice in a
row, without any dsa_tag_8021q_unregister() in between. Then we will
actually call dsa_tag_8021q_unregister() via old_proto_ops-&amp;gt;teardown,
which (if it manages to run at all, after walking through corrupted data
structures) will leave the ports inoperational anyway.&lt;/p&gt;
&lt;p&gt;The bug can be readily reproduced if we force an error while in
tag_8021q mode; this crashes the kernel.&lt;/p&gt;
&lt;p&gt;echo ocelot-8021q &amp;gt; /sys/class/net/eno2/dsa/tagging
echo edsa &amp;gt; /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014
Call trace:
 vcap_entry_get+0x24/0x124
 ocelot_vcap_filter_del+0x…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-50063</guid>
    </item>
    <item>
      <title>GHSA-vhwp-83w8-m7pm</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-vhwp-83w8-m7pm</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: felix: suppress non-changes to the tagging protocol&lt;/p&gt;
&lt;p&gt;The way in which dsa_tree_change_tag_proto() works is that when
dsa_tree_notify() fails, it doesn&amp;#39;t know whether the operation failed
mid way in a multi-switch tree, or it failed for a single-switch tree.
So even though drivers need to fail cleanly in
ds-&amp;gt;ops-&amp;gt;change_tag_protocol(), DSA will still call dsa_tree_notify()
again, to restore the old tag protocol for potential switches in the
tree where the change did succeeed (before failing for others).&lt;/p&gt;
&lt;p&gt;This means for the felix driver that if we report an error in
felix_change_tag_protocol(), we&amp;#39;ll get another call where proto_ops ==
old_proto_ops. If we proceed to act upon that, we may do unexpected
things. For example, we will call dsa_tag_8021q_register() twice in a
row, without any dsa_tag_8021q_unregister() in between. Then we will
actually call dsa_tag_8021q_unregister() via old_proto_ops-&amp;gt;teardown,
which (if it manages to run at all, after walking through corrupted data
structures) will leave the ports inoperational anyway.&lt;/p&gt;
&lt;p&gt;The bug can be readily reproduced if we force an error while in
tag_8021q mode; this crashes the kernel.&lt;/p&gt;
&lt;p&gt;echo ocelot-8021q &amp;gt; /sys/class/net/eno2/dsa/tagging
echo edsa &amp;gt; /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014
Call trace:
 vcap_entry_get+0x24/0x124
 ocelot_vcap_filter_del+0x…&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;net: dsa: felix: suppress non-changes to the tagging protocol&lt;/p&gt;
&lt;p&gt;The way in which dsa_tree_change_tag_proto() works is that when
dsa_tree_notify() fails, it doesn&amp;#39;t know whether the operation failed
mid way in a multi-switch tree, or it failed for a single-switch tree.
So even though drivers need to fail cleanly in
ds-&amp;gt;ops-&amp;gt;change_tag_protocol(), DSA will still call dsa_tree_notify()
again, to restore the old tag protocol for potential switches in the
tree where the change did succeeed (before failing for others).&lt;/p&gt;
&lt;p&gt;This means for the felix driver that if we report an error in
felix_change_tag_protocol(), we&amp;#39;ll get another call where proto_ops ==
old_proto_ops. If we proceed to act upon that, we may do unexpected
things. For example, we will call dsa_tag_8021q_register() twice in a
row, without any dsa_tag_8021q_unregister() in between. Then we will
actually call dsa_tag_8021q_unregister() via old_proto_ops-&amp;gt;teardown,
which (if it manages to run at all, after walking through corrupted data
structures) will leave the ports inoperational anyway.&lt;/p&gt;
&lt;p&gt;The bug can be readily reproduced if we force an error while in
tag_8021q mode; this crashes the kernel.&lt;/p&gt;
&lt;p&gt;echo ocelot-8021q &amp;gt; /sys/class/net/eno2/dsa/tagging
echo edsa &amp;gt; /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014
Call trace:
 vcap_entry_get+0x24/0x124
 ocelot_vcap_filter_del+0x…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-vhwp-83w8-m7pm</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-50063</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50063</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 71 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: suppress non-changes to the tagging protocol The way in which dsa_tree_change_tag_proto() works is that when dsa_tree_notify() fails, it doesn&amp;#39;t know whether the operation failed mid way in a multi-switch tree, or it failed for a single-switch tree. So even though drivers need to fail cleanly in ds-&amp;gt;ops-&amp;gt;change_tag_protocol(), DSA will still call dsa_tree_notify() again, to restore the old tag protocol for potential switches in the tree where the change did succeeed (before failing for others). This means for the felix driver that if we report an error in felix_change_tag_protocol(), we&amp;#39;ll get another call where proto_ops == old_proto_ops. If we proceed to act upon that, we may do unexpected things. For example, we will call dsa_tag_8021q_register() twice in a row, without any dsa_tag_8021q_unregister() in between. Then we will actually call dsa_tag_8021q_unregister() via old_proto_ops-&amp;gt;teardown, which (if it manages to run at all, after walking through corrupted data structures) will leave the ports inoperational anyway. The bug can be readily reproduced if we force an error while in tag_8021q mode; this crashes the kernel. echo ocelot-8021q &amp;gt; /sys/class/net/eno2/dsa/tagging echo edsa &amp;gt; /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014 Call trace:  vcap_entry_get+0x24/0x124  ocelot_vcap_filter_del+0x198/0x…&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 71 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: suppress non-changes to the tagging protocol The way in which dsa_tree_change_tag_proto() works is that when dsa_tree_notify() fails, it doesn&amp;#39;t know whether the operation failed mid way in a multi-switch tree, or it failed for a single-switch tree. So even though drivers need to fail cleanly in ds-&amp;gt;ops-&amp;gt;change_tag_protocol(), DSA will still call dsa_tree_notify() again, to restore the old tag protocol for potential switches in the tree where the change did succeeed (before failing for others). This means for the felix driver that if we report an error in felix_change_tag_protocol(), we&amp;#39;ll get another call where proto_ops == old_proto_ops. If we proceed to act upon that, we may do unexpected things. For example, we will call dsa_tag_8021q_register() twice in a row, without any dsa_tag_8021q_unregister() in between. Then we will actually call dsa_tag_8021q_unregister() via old_proto_ops-&amp;gt;teardown, which (if it manages to run at all, after walking through corrupted data structures) will leave the ports inoperational anyway. The bug can be readily reproduced if we force an error while in tag_8021q mode; this crashes the kernel. echo ocelot-8021q &amp;gt; /sys/class/net/eno2/dsa/tagging echo edsa &amp;gt; /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014 Call trace:  vcap_entry_get+0x24/0x124  ocelot_vcap_filter_del+0x198/0x…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50063</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1350 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350</guid>
    </item>
  </channel>
</rss>
