<?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>Sun, 04 Oct 2026 12:49:14 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-12138</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-12138</link>
      <description>bdu:2025-12138</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-12138</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-37875</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-37875</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-2025-37875</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0463 — 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-2025-avi-0463</link>
      <description>certfr-2025-avi-0463</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0463</guid>
    </item>
    <item>
      <title>EUVD-2026-314296</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-314296</link>
      <description>EUVD-2026-314296</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-314296</guid>
    </item>
    <item>
      <title>fkie_cve-2025-37875</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-37875</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;igc: fix PTM cycle trigger logic&lt;/p&gt;
&lt;p&gt;Writing to clear the PTM status &amp;#39;valid&amp;#39; bit while the PTM cycle is
triggered results in unreliable PTM operation. To fix this, clear the
PTM &amp;#39;trigger&amp;#39; and status after each PTM transaction.&lt;/p&gt;
&lt;p&gt;The issue can be reproduced with the following:&lt;/p&gt;
&lt;p&gt;$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m&lt;/p&gt;
&lt;p&gt;Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to
quickly reproduce the issue.&lt;/p&gt;
&lt;p&gt;PHC2SYS exits with:&lt;/p&gt;
&lt;p&gt;&amp;#34;ioctl PTP_OFFSET_PRECISE: Connection timed out&amp;#34; when the PTM transaction
  fails&lt;/p&gt;
&lt;p&gt;This patch also fixes a hang in igc_probe() when loading the igc
driver in the kdump kernel on systems supporting PTM.&lt;/p&gt;
&lt;p&gt;The igc driver running in the base kernel enables PTM trigger in
igc_probe().  Therefore the driver is always in PTM trigger mode,
except in brief periods when manually triggering a PTM cycle.&lt;/p&gt;
&lt;p&gt;When a crash occurs, the NIC is reset while PTM trigger is enabled.
Due to a hardware problem, the NIC is subsequently in a bad busmaster
state and doesn&amp;#39;t handle register reads/writes.  When running
igc_probe() in the kdump kernel, the first register access to a NIC
register hangs driver probing and ultimately breaks kdump.&lt;/p&gt;
&lt;p&gt;With this patch, igc has PTM trigger disabled most of the time,
and the trigger is only enabled for very brief (10 - 100 us) periods
when manually triggering a PTM cycle.  Chances that a crash occurs
during a PTM trigger are not 0, but extremely reduced.&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;igc: fix PTM cycle trigger logic&lt;/p&gt;
&lt;p&gt;Writing to clear the PTM status &amp;#39;valid&amp;#39; bit while the PTM cycle is
triggered results in unreliable PTM operation. To fix this, clear the
PTM &amp;#39;trigger&amp;#39; and status after each PTM transaction.&lt;/p&gt;
&lt;p&gt;The issue can be reproduced with the following:&lt;/p&gt;
&lt;p&gt;$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m&lt;/p&gt;
&lt;p&gt;Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to
quickly reproduce the issue.&lt;/p&gt;
&lt;p&gt;PHC2SYS exits with:&lt;/p&gt;
&lt;p&gt;&amp;#34;ioctl PTP_OFFSET_PRECISE: Connection timed out&amp;#34; when the PTM transaction
  fails&lt;/p&gt;
&lt;p&gt;This patch also fixes a hang in igc_probe() when loading the igc
driver in the kdump kernel on systems supporting PTM.&lt;/p&gt;
&lt;p&gt;The igc driver running in the base kernel enables PTM trigger in
igc_probe().  Therefore the driver is always in PTM trigger mode,
except in brief periods when manually triggering a PTM cycle.&lt;/p&gt;
&lt;p&gt;When a crash occurs, the NIC is reset while PTM trigger is enabled.
Due to a hardware problem, the NIC is subsequently in a bad busmaster
state and doesn&amp;#39;t handle register reads/writes.  When running
igc_probe() in the kdump kernel, the first register access to a NIC
register hangs driver probing and ultimately breaks kdump.&lt;/p&gt;
&lt;p&gt;With this patch, igc has PTM trigger disabled most of the time,
and the trigger is only enabled for very brief (10 - 100 us) periods
when manually triggering a PTM cycle.  Chances that a crash occurs
during a PTM trigger are not 0, but extremely reduced.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-37875</guid>
    </item>
    <item>
      <title>GHSA-8rhv-v35f-jq29</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8rhv-v35f-jq29</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;igc: fix PTM cycle trigger logic&lt;/p&gt;
&lt;p&gt;Writing to clear the PTM status &amp;#39;valid&amp;#39; bit while the PTM cycle is
triggered results in unreliable PTM operation. To fix this, clear the
PTM &amp;#39;trigger&amp;#39; and status after each PTM transaction.&lt;/p&gt;
&lt;p&gt;The issue can be reproduced with the following:&lt;/p&gt;
&lt;p&gt;$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m&lt;/p&gt;
&lt;p&gt;Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to
quickly reproduce the issue.&lt;/p&gt;
&lt;p&gt;PHC2SYS exits with:&lt;/p&gt;
&lt;p&gt;&amp;#34;ioctl PTP_OFFSET_PRECISE: Connection timed out&amp;#34; when the PTM transaction
  fails&lt;/p&gt;
&lt;p&gt;This patch also fixes a hang in igc_probe() when loading the igc
driver in the kdump kernel on systems supporting PTM.&lt;/p&gt;
&lt;p&gt;The igc driver running in the base kernel enables PTM trigger in
igc_probe().  Therefore the driver is always in PTM trigger mode,
except in brief periods when manually triggering a PTM cycle.&lt;/p&gt;
&lt;p&gt;When a crash occurs, the NIC is reset while PTM trigger is enabled.
Due to a hardware problem, the NIC is subsequently in a bad busmaster
state and doesn&amp;#39;t handle register reads/writes.  When running
igc_probe() in the kdump kernel, the first register access to a NIC
register hangs driver probing and ultimately breaks kdump.&lt;/p&gt;
&lt;p&gt;With this patch, igc has PTM trigger disabled most of the time,
and the trigger is only enabled for very brief (10 - 100 us) periods
when manually triggering a PTM cycle.  Chances that a crash occurs
during a PTM trigger are not 0, but extremely reduced.&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;igc: fix PTM cycle trigger logic&lt;/p&gt;
&lt;p&gt;Writing to clear the PTM status &amp;#39;valid&amp;#39; bit while the PTM cycle is
triggered results in unreliable PTM operation. To fix this, clear the
PTM &amp;#39;trigger&amp;#39; and status after each PTM transaction.&lt;/p&gt;
&lt;p&gt;The issue can be reproduced with the following:&lt;/p&gt;
&lt;p&gt;$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m&lt;/p&gt;
&lt;p&gt;Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to
quickly reproduce the issue.&lt;/p&gt;
&lt;p&gt;PHC2SYS exits with:&lt;/p&gt;
&lt;p&gt;&amp;#34;ioctl PTP_OFFSET_PRECISE: Connection timed out&amp;#34; when the PTM transaction
  fails&lt;/p&gt;
&lt;p&gt;This patch also fixes a hang in igc_probe() when loading the igc
driver in the kdump kernel on systems supporting PTM.&lt;/p&gt;
&lt;p&gt;The igc driver running in the base kernel enables PTM trigger in
igc_probe().  Therefore the driver is always in PTM trigger mode,
except in brief periods when manually triggering a PTM cycle.&lt;/p&gt;
&lt;p&gt;When a crash occurs, the NIC is reset while PTM trigger is enabled.
Due to a hardware problem, the NIC is subsequently in a bad busmaster
state and doesn&amp;#39;t handle register reads/writes.  When running
igc_probe() in the kdump kernel, the first register access to a NIC
register hangs driver probing and ultimately breaks kdump.&lt;/p&gt;
&lt;p&gt;With this patch, igc has PTM trigger disabled most of the time,
and the trigger is only enabled for very brief (10 - 100 us) periods
when manually triggering a PTM cycle.  Chances that a crash occurs
during a PTM trigger are not 0, but extremely reduced.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8rhv-v35f-jq29</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-37875 — igc: fix PTM cycle trigger logic</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-37875</link>
      <description>msrc_CVE-2025-37875</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-37875</guid>
    </item>
    <item>
      <title>OESA-2025-2120 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2120</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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;gtp: Destroy device along with udp socket&amp;amp;apos;s netns dismantle.&lt;/p&gt;
&lt;p&gt;gtp_newlink() links the device to a list in dev_net(dev) instead of
src_net, where a udp tunnel socket is created.&lt;/p&gt;
&lt;p&gt;Even when src_net is removed, the device stays alive on dev_net(dev).
Then, removing src_net triggers the splat below. [0]&lt;/p&gt;
&lt;p&gt;In this example, gtp0 is created in ns2, and the udp socket is created
in ns1.&lt;/p&gt;
&lt;p&gt;ip netns add ns1
  ip netns add ns2
  ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn
  ip netns del ns1&lt;/p&gt;
&lt;p&gt;Let&amp;amp;apos;s link the device to the socket&amp;amp;apos;s netns instead.&lt;/p&gt;
&lt;p&gt;Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove
all gtp devices in the netns.&lt;/p&gt;
&lt;p&gt;[0]:
ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at
     sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)
     inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)
     __sock_create (net/socket.c:1558)
     udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)
     gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)
     gtp_create_sockets (drivers/net/gtp.c:1447)
     gtp_newlink (drivers/net/gtp.c:1507)
     rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)
     rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)
     netlink_rcv_skb (net/netlink/af_netlink.c:2542)
     netlink_unicast…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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;gtp: Destroy device along with udp socket&amp;amp;apos;s netns dismantle.&lt;/p&gt;
&lt;p&gt;gtp_newlink() links the device to a list in dev_net(dev) instead of
src_net, where a udp tunnel socket is created.&lt;/p&gt;
&lt;p&gt;Even when src_net is removed, the device stays alive on dev_net(dev).
Then, removing src_net triggers the splat below. [0]&lt;/p&gt;
&lt;p&gt;In this example, gtp0 is created in ns2, and the udp socket is created
in ns1.&lt;/p&gt;
&lt;p&gt;ip netns add ns1
  ip netns add ns2
  ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn
  ip netns del ns1&lt;/p&gt;
&lt;p&gt;Let&amp;amp;apos;s link the device to the socket&amp;amp;apos;s netns instead.&lt;/p&gt;
&lt;p&gt;Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove
all gtp devices in the netns.&lt;/p&gt;
&lt;p&gt;[0]:
ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at
     sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)
     inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)
     __sock_create (net/socket.c:1558)
     udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)
     gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)
     gtp_create_sockets (drivers/net/gtp.c:1447)
     gtp_newlink (drivers/net/gtp.c:1507)
     rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)
     rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)
     netlink_rcv_skb (net/netlink/af_netlink.c:2542)
     netlink_unicast…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2120</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:01964-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:01964-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:01964-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-37875</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37875</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 152 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: igc: fix PTM cycle trigger logic Writing to clear the PTM status &amp;#39;valid&amp;#39; bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM &amp;#39;trigger&amp;#39; and status after each PTM transaction. The issue can be reproduced with the following: $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue. PHC2SYS exits with: &amp;#34;ioctl PTP_OFFSET_PRECISE: Connection timed out&amp;#34; when the PTM transaction   fails This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM. The igc driver running in the base kernel enables PTM trigger in igc_probe().  Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle. When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn&amp;#39;t handle register reads/writes.  When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump. With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle.  Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.&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 152 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: igc: fix PTM cycle trigger logic Writing to clear the PTM status &amp;#39;valid&amp;#39; bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM &amp;#39;trigger&amp;#39; and status after each PTM transaction. The issue can be reproduced with the following: $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue. PHC2SYS exits with: &amp;#34;ioctl PTP_OFFSET_PRECISE: Connection timed out&amp;#34; when the PTM transaction   fails This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM. The igc driver running in the base kernel enables PTM trigger in igc_probe().  Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle. When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn&amp;#39;t handle register reads/writes.  When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump. With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle.  Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37875</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0991 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0991</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff und weitere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff und weitere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0991</guid>
    </item>
  </channel>
</rss>
