<?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 09:53:59 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12509</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12509</link>
      <description>bdu:2026-12509</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12509</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-31420</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31420</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-31420</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0697 — 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-2026-avi-0697</link>
      <description>certfr-2026-avi-0697</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0697</guid>
    </item>
    <item>
      <title>EUVD-2026-367479</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-367479</link>
      <description>EUVD-2026-367479</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-367479</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31420</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31420</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bridge: mrp: reject zero test interval to avoid OOM panic&lt;/p&gt;
&lt;p&gt;br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
interval value from netlink without validation. When interval is 0,
usecs_to_jiffies(0) yields 0, causing the delayed work
(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
itself with zero delay. This creates a tight loop on system_percpu_wq
that allocates and transmits MRP test frames at maximum rate, exhausting
all system memory and causing a kernel panic via OOM deadlock.&lt;/p&gt;
&lt;p&gt;The same zero-interval issue applies to br_mrp_start_in_test_parse()
for interconnect test frames.&lt;/p&gt;
&lt;p&gt;Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
netlink attribute parsing layer before the value ever reaches the
workqueue scheduling code. This is consistent with how other bridge
subsystems (br_fdb, br_mst) enforce range constraints on netlink
attributes.&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;bridge: mrp: reject zero test interval to avoid OOM panic&lt;/p&gt;
&lt;p&gt;br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
interval value from netlink without validation. When interval is 0,
usecs_to_jiffies(0) yields 0, causing the delayed work
(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
itself with zero delay. This creates a tight loop on system_percpu_wq
that allocates and transmits MRP test frames at maximum rate, exhausting
all system memory and causing a kernel panic via OOM deadlock.&lt;/p&gt;
&lt;p&gt;The same zero-interval issue applies to br_mrp_start_in_test_parse()
for interconnect test frames.&lt;/p&gt;
&lt;p&gt;Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
netlink attribute parsing layer before the value ever reaches the
workqueue scheduling code. This is consistent with how other bridge
subsystems (br_fdb, br_mst) enforce range constraints on netlink
attributes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31420</guid>
    </item>
    <item>
      <title>GHSA-644j-vc34-vf98</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-644j-vc34-vf98</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bridge: mrp: reject zero test interval to avoid OOM panic&lt;/p&gt;
&lt;p&gt;br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
interval value from netlink without validation. When interval is 0,
usecs_to_jiffies(0) yields 0, causing the delayed work
(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
itself with zero delay. This creates a tight loop on system_percpu_wq
that allocates and transmits MRP test frames at maximum rate, exhausting
all system memory and causing a kernel panic via OOM deadlock.&lt;/p&gt;
&lt;p&gt;The same zero-interval issue applies to br_mrp_start_in_test_parse()
for interconnect test frames.&lt;/p&gt;
&lt;p&gt;Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
netlink attribute parsing layer before the value ever reaches the
workqueue scheduling code. This is consistent with how other bridge
subsystems (br_fdb, br_mst) enforce range constraints on netlink
attributes.&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;bridge: mrp: reject zero test interval to avoid OOM panic&lt;/p&gt;
&lt;p&gt;br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
interval value from netlink without validation. When interval is 0,
usecs_to_jiffies(0) yields 0, causing the delayed work
(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
itself with zero delay. This creates a tight loop on system_percpu_wq
that allocates and transmits MRP test frames at maximum rate, exhausting
all system memory and causing a kernel panic via OOM deadlock.&lt;/p&gt;
&lt;p&gt;The same zero-interval issue applies to br_mrp_start_in_test_parse()
for interconnect test frames.&lt;/p&gt;
&lt;p&gt;Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
netlink attribute parsing layer before the value ever reaches the
workqueue scheduling code. This is consistent with how other bridge
subsystems (br_fdb, br_mst) enforce range constraints on netlink
attributes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-644j-vc34-vf98</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-31420 — bridge: mrp: reject zero test interval to avoid OOM panic</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31420</link>
      <description>msrc_CVE-2026-31420</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-31420</guid>
    </item>
    <item>
      <title>OESA-2026-2232 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2232</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP3: 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, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipv6: add NULL checks for idev in SRv6 paths&lt;/p&gt;
&lt;p&gt;__in6_dev_get() can return NULL when the device has no IPv6 configuration
(e.g. MTU &amp;amp;lt; IPV6_MIN_MTU or after NETDEV_UNREGISTER).&lt;/p&gt;
&lt;p&gt;Add NULL checks for idev returned by __in6_dev_get() in both
seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL
pointer dereferences.(CVE-2026-23442)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: conntrack: add missing netlink policy validations&lt;/p&gt;
&lt;p&gt;Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.&lt;/p&gt;
&lt;p&gt;These attributes are used by the kernel without any validation.
Extend the netlink policies accordingly.&lt;/p&gt;
&lt;p&gt;Quoting the reporter:
  nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE
  value directly to ct-&amp;amp;gt;proto.sctp.state without checking that it is…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP3: 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, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipv6: add NULL checks for idev in SRv6 paths&lt;/p&gt;
&lt;p&gt;__in6_dev_get() can return NULL when the device has no IPv6 configuration
(e.g. MTU &amp;amp;lt; IPV6_MIN_MTU or after NETDEV_UNREGISTER).&lt;/p&gt;
&lt;p&gt;Add NULL checks for idev returned by __in6_dev_get() in both
seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL
pointer dereferences.(CVE-2026-23442)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: conntrack: add missing netlink policy validations&lt;/p&gt;
&lt;p&gt;Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.&lt;/p&gt;
&lt;p&gt;These attributes are used by the kernel without any validation.
Extend the netlink policies accordingly.&lt;/p&gt;
&lt;p&gt;Quoting the reporter:
  nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE
  value directly to ct-&amp;amp;gt;proto.sctp.state without checking that it is…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2232</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20826-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-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:20826-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:21834-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:21834-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:21834-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31420</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31420</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 181 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.&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 181 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bridge: mrp: reject zero test interval to avoid OOM panic br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31420</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1088 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1088</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, darunter möglicherweise DoS-Angriffe, die Manipulation oder Offenlegung von Daten sowie die Umgehung von Sicherheitsmaßnahmen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, darunter möglicherweise DoS-Angriffe, die Manipulation oder Offenlegung von Daten sowie die Umgehung von Sicherheitsmaßnahmen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1088</guid>
    </item>
  </channel>
</rss>
