<?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-02T11:41:35.632241+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/bdu:2026-09717</id>
    <title>bdu:2026-09717</title>
    <updated>2026-10-02T11:41:36.018204+00:00</updated>
    <content>bdu:2026-09717</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2026-09717"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2026-31533</id>
    <title>BELL-CVE-2026-31533</title>
    <updated>2026-10-02T11:41:36.018280+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-31533"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0526</id>
    <title>certfr-2026-avi-0526 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Elles permettent à un attaquant de provoqu…</title>
    <updated>2026-10-02T11:41:36.018316+00:00</updated>
    <content>certfr-2026-avi-0526</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-0526"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-364758</id>
    <title>EUVD-2026-364758</title>
    <updated>2026-10-02T11:41:36.018335+00:00</updated>
    <content>EUVD-2026-364758</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-364758"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31533</id>
    <title>fkie_cve-2026-31533</title>
    <updated>2026-10-02T11:41:36.018347+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>net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption</p>
<p>The -EBUSY handling in tls_do_encryption(), introduced by commit
859054147318 ("net: tls: handle backlogging of crypto requests"), has
a use-after-free due to double cleanup of encrypt_pending and the
scatterlist entry.</p>
<p>When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to
the cryptd backlog and the async callback tls_encrypt_done() will be
invoked upon completion. That callback unconditionally restores the
scatterlist entry (sge-&gt;offset, sge-&gt;length) and decrements
ctx-&gt;encrypt_pending. However, if tls_encrypt_async_wait() returns an
error, the synchronous error path in tls_do_encryption() performs the
same cleanup again, double-decrementing encrypt_pending and
double-restoring the scatterlist.</p>
<p>The double-decrement corrupts the encrypt_pending sentinel (initialized
to 1), making tls_encrypt_async_wait() permanently skip the wait for
pending async callbacks. A subsequent sendmsg can then free the
tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still
pending, resulting in a use-after-free when the callback fires on the
freed record.</p>
<p>Fix this by skipping the synchronous cleanup when the -EBUSY async
wait returns an error, since the callback has already handled
encrypt_pending and sge restoration.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-31533"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-r7wv-m72q-8qj8</id>
    <title>GHSA-r7wv-m72q-8qj8</title>
    <updated>2026-10-02T11:41:36.018387+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>net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption</p>
<p>The -EBUSY handling in tls_do_encryption(), introduced by commit
859054147318 ("net: tls: handle backlogging of crypto requests"), has
a use-after-free due to double cleanup of encrypt_pending and the
scatterlist entry.</p>
<p>When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to
the cryptd backlog and the async callback tls_encrypt_done() will be
invoked upon completion. That callback unconditionally restores the
scatterlist entry (sge-&gt;offset, sge-&gt;length) and decrements
ctx-&gt;encrypt_pending. However, if tls_encrypt_async_wait() returns an
error, the synchronous error path in tls_do_encryption() performs the
same cleanup again, double-decrementing encrypt_pending and
double-restoring the scatterlist.</p>
<p>The double-decrement corrupts the encrypt_pending sentinel (initialized
to 1), making tls_encrypt_async_wait() permanently skip the wait for
pending async callbacks. A subsequent sendmsg can then free the
tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still
pending, resulting in a use-after-free when the callback fires on the
freed record.</p>
<p>Fix this by skipping the synchronous cleanup when the -EBUSY async
wait returns an error, since the callback has already handled
encrypt_pending and sge restoration.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-r7wv-m72q-8qj8"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/icsa-26-209-04</id>
    <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
    <updated>2026-10-02T11:41:36.018414+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>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).</p>
<p>Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/icsa-26-209-04"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31533</id>
    <title>msrc_CVE-2026-31533 — net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption</title>
    <updated>2026-10-02T11:41:36.018639+00:00</updated>
    <content>msrc_CVE-2026-31533</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2026-31533"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2026-2581</id>
    <title>OESA-2026-2581 — kernel security update</title>
    <updated>2026-10-02T11:41:36.018657+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>net: mvpp2: Prevent parser TCAM memory corruption</p>
<p>Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM
information, from concurrent modifications.</p>
<p>Both the TCAM and SRAM tables are indirectly accessed by configuring
an index register that selects the row to read or write to. This means
that operations must be atomic in order to, e.g., avoid spreading
writes across multiple rows. Since the shadow SRAM array is used to
find free rows in the hardware table, it must also be protected in
order to avoid TOCTOU errors where multiple cores allocate the same
row.</p>
<p>This issue was detected in a situation where `mvpp2_set_rx_mode()` ran
concurrently on two CPUs. In this particular case the
MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the
classifier unit to drop all incoming unicast - indicated by the
`rx_classifier_drops` counter.(CVE-2025-22060)</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>mptcp: fix NULL pointer in can_accept_new_subflow</p>
<p>When testing valkey benchmark tool with MPTCP, the kernel panics in
&amp;apos;mptcp_can_accept_new_subflow&amp;apos; because subflow_req-&amp;gt;msk is NULL.</p>
<p>Call trace:</p>
<p>mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)
  subflow_syn_recv_sock (./net/mptcp/subflow.c:854)
  tcp_check_req (./net/ipv4/tcp_minisocks.c:863)
  tcp_v4_rcv (./net/…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2026-2581"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-1</id>
    <title>openSUSE-SU-2026:20826-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T11:41:36.019082+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ssa-019113</id>
    <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>
    <updated>2026-10-02T11:41:36.019230+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>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).</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ssa-019113"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:2111-1</id>
    <title>SUSE-SU-2026:2111-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T11:41:36.019471+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2026:2111-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31533</id>
    <title>UBUNTU-CVE-2026-31533</title>
    <updated>2026-10-02T11:41:36.019521+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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 197 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge-&gt;offset, sge-&gt;length) and decrements ctx-&gt;encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31533"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1265</id>
    <title>WID-SEC-W-2026-1265 — Linux Kernel: Schwachstelle ermöglicht nicht spezifizierten Angriff</title>
    <updated>2026-10-02T11:41:36.019754+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein lokaler Angreifer kann eine Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, einschließlich der Ausführung von beliebigem Code, der Manipulation von Speicherinhalten oder der Verursachung eines Denial-of-Service-Zustands.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1265"/>
  </entry>
</feed>
