<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T17:20:15.162150+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2026-74624</id>
    <title>BELL-CVE-2026-74624</title>
    <updated>2026-10-03T17:20:15.193513+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2026-74624"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1090</id>
    <title>certfr-2026-avi-1090 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
    <updated>2026-10-03T17:20:15.193574+00:00</updated>
    <content>certfr-2026-avi-1090</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-1090"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-358522</id>
    <title>EUVD-2026-358522</title>
    <updated>2026-10-03T17:20:15.193632+00:00</updated>
    <content>EUVD-2026-358522</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-358522"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74624</id>
    <title>fkie_cve-2026-74624</title>
    <updated>2026-10-03T17:20:15.193644+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>netfilter: nf_conntrack: defer invalid log until after unlock</p>
<p>TCP and SCTP conntrack paths can emit invalid-packet logs while ct-&gt;lock
is still held.</p>
<p>When invalid logging is routed to nfnetlink_log and conntrack export is
enabled, the log path can re-enter conntrack netlink glue and dump the
same conntrack again. Protocol attribute dumping may take ct-&gt;lock, so
logging while holding that lock can deadlock.</p>
<p>Defer the TCP invalid logs by storing only the minimal log context while
ct-&gt;lock is held and emitting the log after unlocking. Also make the TCP
timeout-lowering invalid path return whether a log is needed, then emit
that log after unlocking.</p>
<p>Do the same for the SCTP invalid state-transition log that can be reached
while ct-&gt;lock is held.</p>
<p>Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers
that log invalid conntracks while holding ct-&gt;lock are caught outside TCP
and SCTP as well.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-74624"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-3q82-j896-jqw7</id>
    <title>GHSA-3q82-j896-jqw7</title>
    <updated>2026-10-03T17:20:15.193679+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>netfilter: nf_conntrack: defer invalid log until after unlock</p>
<p>TCP and SCTP conntrack paths can emit invalid-packet logs while ct-&gt;lock
is still held.</p>
<p>When invalid logging is routed to nfnetlink_log and conntrack export is
enabled, the log path can re-enter conntrack netlink glue and dump the
same conntrack again. Protocol attribute dumping may take ct-&gt;lock, so
logging while holding that lock can deadlock.</p>
<p>Defer the TCP invalid logs by storing only the minimal log context while
ct-&gt;lock is held and emitting the log after unlocking. Also make the TCP
timeout-lowering invalid path return whether a log is needed, then emit
that log after unlocking.</p>
<p>Do the same for the SCTP invalid state-transition log that can be reached
while ct-&gt;lock is held.</p>
<p>Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers
that log invalid conntracks while holding ct-&gt;lock are caught outside TCP
and SCTP as well.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-3q82-j896-jqw7"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2026-74624</id>
    <title>msrc_CVE-2026-74624 — netfilter: nf_conntrack: defer invalid log until after unlock</title>
    <updated>2026-10-03T17:20:15.193704+00:00</updated>
    <content>msrc_CVE-2026-74624</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2026-74624"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2026-3707</id>
    <title>OESA-2026-3707 — kernel security update</title>
    <updated>2026-10-03T17:20:15.193720+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:24.03-LTS-SP1: kernel</p>
<p>The Linux Kernel, the operating system core itself.

Security Fix(es):</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>seg6: separate dst_cache for input and output paths in seg6 lwtunnel</p>
<p>The seg6 lwtunnel uses a single dst_cache per encap route, shared
between seg6_input_core() and seg6_output_core(). These two paths
can perform the post-encap SID lookup in different routing contexts
(e.g., ip rules matching on the ingress interface, or VRF table
separation). Whichever path runs first populates the cache, and the
other reuses it blindly, bypassing its own lookup.</p>
<p>Fix this by splitting the cache into cache_input and cache_output,
so each path maintains its own cached dst independently.(CVE-2026-31668)</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE</p>
<p>The current implementation incorrectly handles memory regions (MRs) with
page sizes different from the system PAGE_SIZE. The core issue is that
rxe_set_page() is called with mr-&amp;gt;page_size step increments, but the
page_list stores individual struct page pointers, each representing
PAGE_SIZE of memory.</p>
<p>ib_sg_to_page() has ensured that when i&amp;gt;=1 either
a) SG[i-1].dma_end and SG[i].dma_addr are contiguous
or
b) SG[i-1].dma_end and SG[i].dma_addr are mr-&amp;gt;page_size aligned.</p>
<p>This leads to incorrect iova-to-va conversion in scenarios:</p>
<p>1) page_size &amp;lt; PAGE_SIZE (e.g., MR: 4K, system: 64K):
   ibmr-&amp;gt;iova = 0x1…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2026-3707"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74624</id>
    <title>UBUNTU-CVE-2026-74624</title>
    <updated>2026-10-03T17:20:15.194239+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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 154 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: defer invalid log until after unlock TCP and SCTP conntrack paths can emit invalid-packet logs while ct-&gt;lock is still held. When invalid logging is routed to nfnetlink_log and conntrack export is enabled, the log path can re-enter conntrack netlink glue and dump the same conntrack again. Protocol attribute dumping may take ct-&gt;lock, so logging while holding that lock can deadlock. Defer the TCP invalid logs by storing only the minimal log context while ct-&gt;lock is held and emitting the log after unlocking. Also make the TCP timeout-lowering invalid path return whether a log is needed, then emit that log after unlocking. Do the same for the SCTP invalid state-transition log that can be reached while ct-&gt;lock is held. Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers that log invalid conntracks while holding ct-&gt;lock are caught outside TCP and SCTP as well.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74624"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</id>
    <title>WID-SEC-W-2026-2970 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
    <updated>2026-10-03T17:20:15.194444+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970"/>
  </entry>
</feed>
