<?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 15:32:09 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-15957</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-15957</link>
      <description>bdu:2025-15957</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-15957</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-49998</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-49998</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-2024-49998</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0088 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0088</link>
      <description>certfr-2025-avi-0088</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0088</guid>
    </item>
    <item>
      <title>EUVD-2026-364455</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-364455</link>
      <description>EUVD-2026-364455</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-364455</guid>
    </item>
    <item>
      <title>fkie_cve-2024-49998</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-49998</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: improve shutdown sequence&lt;/p&gt;
&lt;p&gt;Alexander Sverdlin presents 2 problems during shutdown with the
lan9303 driver. One is specific to lan9303 and the other just happens
to reproduce there.&lt;/p&gt;
&lt;p&gt;The first problem is that lan9303 is unique among DSA drivers in that it
calls dev_get_drvdata() at &amp;#34;arbitrary runtime&amp;#34; (not probe, not shutdown,
not remove):&lt;/p&gt;
&lt;p&gt;phy_state_machine()
-&amp;gt; ...
   -&amp;gt; dsa_user_phy_read()
      -&amp;gt; ds-&amp;gt;ops-&amp;gt;phy_read()
         -&amp;gt; lan9303_phy_read()
            -&amp;gt; chip-&amp;gt;ops-&amp;gt;phy_read()
               -&amp;gt; lan9303_mdio_phy_read()
                  -&amp;gt; dev_get_drvdata()&lt;/p&gt;
&lt;p&gt;But we never stop the phy_state_machine(), so it may continue to run
after dsa_switch_shutdown(). Our common pattern in all DSA drivers is
to set drvdata to NULL to suppress the remove() method that may come
afterwards. But in this case it will result in an NPD.&lt;/p&gt;
&lt;p&gt;The second problem is that the way in which we set
dp-&amp;gt;conduit-&amp;gt;dsa_ptr = NULL; is concurrent with receive packet
processing. dsa_switch_rcv() checks once whether dev-&amp;gt;dsa_ptr is NULL,
but afterwards, rather than continuing to use that non-NULL value,
dev-&amp;gt;dsa_ptr is dereferenced again and again without NULL checks:
dsa_conduit_find_user() and many other places. In between dereferences,
there is no locking to ensure that what was valid once continues to be
valid.&lt;/p&gt;
&lt;p&gt;Both problems have the common aspect that closing the conduit interface
solves them.&lt;/p&gt;
&lt;p&gt;In the first case, dev_clos…&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: improve shutdown sequence&lt;/p&gt;
&lt;p&gt;Alexander Sverdlin presents 2 problems during shutdown with the
lan9303 driver. One is specific to lan9303 and the other just happens
to reproduce there.&lt;/p&gt;
&lt;p&gt;The first problem is that lan9303 is unique among DSA drivers in that it
calls dev_get_drvdata() at &amp;#34;arbitrary runtime&amp;#34; (not probe, not shutdown,
not remove):&lt;/p&gt;
&lt;p&gt;phy_state_machine()
-&amp;gt; ...
   -&amp;gt; dsa_user_phy_read()
      -&amp;gt; ds-&amp;gt;ops-&amp;gt;phy_read()
         -&amp;gt; lan9303_phy_read()
            -&amp;gt; chip-&amp;gt;ops-&amp;gt;phy_read()
               -&amp;gt; lan9303_mdio_phy_read()
                  -&amp;gt; dev_get_drvdata()&lt;/p&gt;
&lt;p&gt;But we never stop the phy_state_machine(), so it may continue to run
after dsa_switch_shutdown(). Our common pattern in all DSA drivers is
to set drvdata to NULL to suppress the remove() method that may come
afterwards. But in this case it will result in an NPD.&lt;/p&gt;
&lt;p&gt;The second problem is that the way in which we set
dp-&amp;gt;conduit-&amp;gt;dsa_ptr = NULL; is concurrent with receive packet
processing. dsa_switch_rcv() checks once whether dev-&amp;gt;dsa_ptr is NULL,
but afterwards, rather than continuing to use that non-NULL value,
dev-&amp;gt;dsa_ptr is dereferenced again and again without NULL checks:
dsa_conduit_find_user() and many other places. In between dereferences,
there is no locking to ensure that what was valid once continues to be
valid.&lt;/p&gt;
&lt;p&gt;Both problems have the common aspect that closing the conduit interface
solves them.&lt;/p&gt;
&lt;p&gt;In the first case, dev_clos…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-49998</guid>
    </item>
    <item>
      <title>GHSA-3xm8-389p-x4rm</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3xm8-389p-x4rm</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: improve shutdown sequence&lt;/p&gt;
&lt;p&gt;Alexander Sverdlin presents 2 problems during shutdown with the
lan9303 driver. One is specific to lan9303 and the other just happens
to reproduce there.&lt;/p&gt;
&lt;p&gt;The first problem is that lan9303 is unique among DSA drivers in that it
calls dev_get_drvdata() at &amp;#34;arbitrary runtime&amp;#34; (not probe, not shutdown,
not remove):&lt;/p&gt;
&lt;p&gt;phy_state_machine()
-&amp;gt; ...
   -&amp;gt; dsa_user_phy_read()
      -&amp;gt; ds-&amp;gt;ops-&amp;gt;phy_read()
         -&amp;gt; lan9303_phy_read()
            -&amp;gt; chip-&amp;gt;ops-&amp;gt;phy_read()
               -&amp;gt; lan9303_mdio_phy_read()
                  -&amp;gt; dev_get_drvdata()&lt;/p&gt;
&lt;p&gt;But we never stop the phy_state_machine(), so it may continue to run
after dsa_switch_shutdown(). Our common pattern in all DSA drivers is
to set drvdata to NULL to suppress the remove() method that may come
afterwards. But in this case it will result in an NPD.&lt;/p&gt;
&lt;p&gt;The second problem is that the way in which we set
dp-&amp;gt;conduit-&amp;gt;dsa_ptr = NULL; is concurrent with receive packet
processing. dsa_switch_rcv() checks once whether dev-&amp;gt;dsa_ptr is NULL,
but afterwards, rather than continuing to use that non-NULL value,
dev-&amp;gt;dsa_ptr is dereferenced again and again without NULL checks:
dsa_conduit_find_user() and many other places. In between dereferences,
there is no locking to ensure that what was valid once continues to be
valid.&lt;/p&gt;
&lt;p&gt;Both problems have the common aspect that closing the conduit interface
solves them.&lt;/p&gt;
&lt;p&gt;In the first case, dev_clos…&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: improve shutdown sequence&lt;/p&gt;
&lt;p&gt;Alexander Sverdlin presents 2 problems during shutdown with the
lan9303 driver. One is specific to lan9303 and the other just happens
to reproduce there.&lt;/p&gt;
&lt;p&gt;The first problem is that lan9303 is unique among DSA drivers in that it
calls dev_get_drvdata() at &amp;#34;arbitrary runtime&amp;#34; (not probe, not shutdown,
not remove):&lt;/p&gt;
&lt;p&gt;phy_state_machine()
-&amp;gt; ...
   -&amp;gt; dsa_user_phy_read()
      -&amp;gt; ds-&amp;gt;ops-&amp;gt;phy_read()
         -&amp;gt; lan9303_phy_read()
            -&amp;gt; chip-&amp;gt;ops-&amp;gt;phy_read()
               -&amp;gt; lan9303_mdio_phy_read()
                  -&amp;gt; dev_get_drvdata()&lt;/p&gt;
&lt;p&gt;But we never stop the phy_state_machine(), so it may continue to run
after dsa_switch_shutdown(). Our common pattern in all DSA drivers is
to set drvdata to NULL to suppress the remove() method that may come
afterwards. But in this case it will result in an NPD.&lt;/p&gt;
&lt;p&gt;The second problem is that the way in which we set
dp-&amp;gt;conduit-&amp;gt;dsa_ptr = NULL; is concurrent with receive packet
processing. dsa_switch_rcv() checks once whether dev-&amp;gt;dsa_ptr is NULL,
but afterwards, rather than continuing to use that non-NULL value,
dev-&amp;gt;dsa_ptr is dereferenced again and again without NULL checks:
dsa_conduit_find_user() and many other places. In between dereferences,
there is no locking to ensure that what was valid once continues to be
valid.&lt;/p&gt;
&lt;p&gt;Both problems have the common aspect that closing the conduit interface
solves them.&lt;/p&gt;
&lt;p&gt;In the first case, dev_clos…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-3xm8-389p-x4rm</guid>
    </item>
    <item>
      <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-26-209-04</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-26-209-04</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-49998 — net: dsa: improve shutdown sequence</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-49998</link>
      <description>msrc_CVE-2024-49998</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-49998</guid>
    </item>
    <item>
      <title>OESA-2025-1093 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1093</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: fix potencial out-of-bounds when buffer offset is invalid&lt;/p&gt;
&lt;p&gt;I found potencial out-of-bounds when buffer offset fields of a few requests
is invalid. This patch set the minimum value of buffer offset field to
-&amp;amp;gt;Buffer offset to validate buffer length.(CVE-2024-26952)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()&lt;/p&gt;
&lt;p&gt;If -&amp;amp;gt;NameOffset of smb2_create_req is smaller than Buffer offset of
smb2_create_req, slab-out-of-bounds read can happen from smb2_open.
This patch set the minimum value of the name offset to the buffer offset
to validate name length of smb2_create_req().(CVE-2024-26954)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: improve shutdown sequence&lt;/p&gt;
&lt;p&gt;Alexander Sverdlin presents 2 problems during shutdown with the
lan9303 driver. One is specific to lan9303 and the other just happens
to reproduce there.&lt;/p&gt;
&lt;p&gt;The first problem is that lan9303 is unique among DSA drivers in that it
calls dev_get_drvdata() at &amp;amp;quot;arbitrary runtime&amp;amp;quot; (not probe, not shutdown,
not remove):&lt;/p&gt;
&lt;p&gt;phy_state_machine()
-&amp;amp;gt; ...
   -&amp;amp;gt; dsa_user_phy_read()
      -&amp;amp;gt; ds-&amp;amp;gt;ops-&amp;amp;gt;phy_read()
         -&amp;amp;gt; lan9303_phy_read()
            -&amp;amp;gt; chip-&amp;amp;gt;ops-&amp;amp;gt;phy_read()
               -&amp;amp;gt; lan9303_mdio_phy_read()
                  -&amp;amp;gt;…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: fix potencial out-of-bounds when buffer offset is invalid&lt;/p&gt;
&lt;p&gt;I found potencial out-of-bounds when buffer offset fields of a few requests
is invalid. This patch set the minimum value of buffer offset field to
-&amp;amp;gt;Buffer offset to validate buffer length.(CVE-2024-26952)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()&lt;/p&gt;
&lt;p&gt;If -&amp;amp;gt;NameOffset of smb2_create_req is smaller than Buffer offset of
smb2_create_req, slab-out-of-bounds read can happen from smb2_open.
This patch set the minimum value of the name offset to the buffer offset
to validate name length of smb2_create_req().(CVE-2024-26954)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: improve shutdown sequence&lt;/p&gt;
&lt;p&gt;Alexander Sverdlin presents 2 problems during shutdown with the
lan9303 driver. One is specific to lan9303 and the other just happens
to reproduce there.&lt;/p&gt;
&lt;p&gt;The first problem is that lan9303 is unique among DSA drivers in that it
calls dev_get_drvdata() at &amp;amp;quot;arbitrary runtime&amp;amp;quot; (not probe, not shutdown,
not remove):&lt;/p&gt;
&lt;p&gt;phy_state_machine()
-&amp;amp;gt; ...
   -&amp;amp;gt; dsa_user_phy_read()
      -&amp;amp;gt; ds-&amp;amp;gt;ops-&amp;amp;gt;phy_read()
         -&amp;amp;gt; lan9303_phy_read()
            -&amp;amp;gt; chip-&amp;amp;gt;ops-&amp;amp;gt;phy_read()
               -&amp;amp;gt; lan9303_mdio_phy_read()
                  -&amp;amp;gt;…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1093</guid>
    </item>
    <item>
      <title>openSUSE-SU-2024:14500-1 — kernel-devel-6.11.8-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</link>
      <description>&lt;p&gt;kernel-devel-6.11.8-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-6.11.8-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</guid>
    </item>
    <item>
      <title>SSA-019113 — SSA-019113: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-019113</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-019113</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:0289-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:0289-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-2025:0289-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-49998</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49998</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 133 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at &amp;#34;arbitrary runtime&amp;#34; (not probe, not shutdown, not remove): phy_state_machine() -&amp;gt; ...    -&amp;gt; dsa_user_phy_read()       -&amp;gt; ds-&amp;gt;ops-&amp;gt;phy_read()          -&amp;gt; lan9303_phy_read()             -&amp;gt; chip-&amp;gt;ops-&amp;gt;phy_read()                -&amp;gt; lan9303_mdio_phy_read()                   -&amp;gt; dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp-&amp;gt;conduit-&amp;gt;dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev-&amp;gt;dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev-&amp;gt;dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(condui…&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 133 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at &amp;#34;arbitrary runtime&amp;#34; (not probe, not shutdown, not remove): phy_state_machine() -&amp;gt; ...    -&amp;gt; dsa_user_phy_read()       -&amp;gt; ds-&amp;gt;ops-&amp;gt;phy_read()          -&amp;gt; lan9303_phy_read()             -&amp;gt; chip-&amp;gt;ops-&amp;gt;phy_read()                -&amp;gt; lan9303_mdio_phy_read()                   -&amp;gt; dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp-&amp;gt;conduit-&amp;gt;dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev-&amp;gt;dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev-&amp;gt;dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(condui…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49998</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-3251 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251</guid>
    </item>
  </channel>
</rss>
