<?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 14:22:04 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-04391</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-04391</link>
      <description>bdu:2025-04391</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-04391</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0420 — 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-2024-avi-0420</link>
      <description>certfr-2024-avi-0420</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0420</guid>
    </item>
    <item>
      <title>EUVD-2026-344396</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344396</link>
      <description>EUVD-2026-344396</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344396</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47131</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47131</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/tls: Fix use-after-free after the TLS device goes down and up&lt;/p&gt;
&lt;p&gt;When a netdev with active TLS offload goes down, tls_device_down is
called to stop the offload and tear down the TLS context. However, the
socket stays alive, and it still points to the TLS context, which is now
deallocated. If a netdev goes up, while the connection is still active,
and the data flow resumes after a number of TCP retransmissions, it will
lead to a use-after-free of the TLS context.&lt;/p&gt;
&lt;p&gt;This commit addresses this bug by keeping the context alive until its
normal destruction, and implements the necessary fallbacks, so that the
connection can resume in software (non-offloaded) kTLS mode.&lt;/p&gt;
&lt;p&gt;On the TX side tls_sw_fallback is used to encrypt all packets. The RX
side already has all the necessary fallbacks, because receiving
non-decrypted packets is supported. The thing needed on the RX side is
to block resync requests, which are normally produced after receiving
non-decrypted packets.&lt;/p&gt;
&lt;p&gt;The necessary synchronization is implemented for a graceful teardown:
first the fallbacks are deployed, then the driver resources are released
(it used to be possible to have a tls_dev_resync after tls_dev_del).&lt;/p&gt;
&lt;p&gt;A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback
mode. It&amp;#39;s used to skip the RX resync logic completely, as it becomes
useless, and some objects may be released (for example, resync_async,
which is allocated and freed by…&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/tls: Fix use-after-free after the TLS device goes down and up&lt;/p&gt;
&lt;p&gt;When a netdev with active TLS offload goes down, tls_device_down is
called to stop the offload and tear down the TLS context. However, the
socket stays alive, and it still points to the TLS context, which is now
deallocated. If a netdev goes up, while the connection is still active,
and the data flow resumes after a number of TCP retransmissions, it will
lead to a use-after-free of the TLS context.&lt;/p&gt;
&lt;p&gt;This commit addresses this bug by keeping the context alive until its
normal destruction, and implements the necessary fallbacks, so that the
connection can resume in software (non-offloaded) kTLS mode.&lt;/p&gt;
&lt;p&gt;On the TX side tls_sw_fallback is used to encrypt all packets. The RX
side already has all the necessary fallbacks, because receiving
non-decrypted packets is supported. The thing needed on the RX side is
to block resync requests, which are normally produced after receiving
non-decrypted packets.&lt;/p&gt;
&lt;p&gt;The necessary synchronization is implemented for a graceful teardown:
first the fallbacks are deployed, then the driver resources are released
(it used to be possible to have a tls_dev_resync after tls_dev_del).&lt;/p&gt;
&lt;p&gt;A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback
mode. It&amp;#39;s used to skip the RX resync logic completely, as it becomes
useless, and some objects may be released (for example, resync_async,
which is allocated and freed by…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-47131</guid>
    </item>
    <item>
      <title>GHSA-xrvj-3vx6-wwh7</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-xrvj-3vx6-wwh7</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/tls: Fix use-after-free after the TLS device goes down and up&lt;/p&gt;
&lt;p&gt;When a netdev with active TLS offload goes down, tls_device_down is
called to stop the offload and tear down the TLS context. However, the
socket stays alive, and it still points to the TLS context, which is now
deallocated. If a netdev goes up, while the connection is still active,
and the data flow resumes after a number of TCP retransmissions, it will
lead to a use-after-free of the TLS context.&lt;/p&gt;
&lt;p&gt;This commit addresses this bug by keeping the context alive until its
normal destruction, and implements the necessary fallbacks, so that the
connection can resume in software (non-offloaded) kTLS mode.&lt;/p&gt;
&lt;p&gt;On the TX side tls_sw_fallback is used to encrypt all packets. The RX
side already has all the necessary fallbacks, because receiving
non-decrypted packets is supported. The thing needed on the RX side is
to block resync requests, which are normally produced after receiving
non-decrypted packets.&lt;/p&gt;
&lt;p&gt;The necessary synchronization is implemented for a graceful teardown:
first the fallbacks are deployed, then the driver resources are released
(it used to be possible to have a tls_dev_resync after tls_dev_del).&lt;/p&gt;
&lt;p&gt;A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback
mode. It&amp;#39;s used to skip the RX resync logic completely, as it becomes
useless, and some objects may be released (for example, resync_async,
which is allocated and freed by…&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/tls: Fix use-after-free after the TLS device goes down and up&lt;/p&gt;
&lt;p&gt;When a netdev with active TLS offload goes down, tls_device_down is
called to stop the offload and tear down the TLS context. However, the
socket stays alive, and it still points to the TLS context, which is now
deallocated. If a netdev goes up, while the connection is still active,
and the data flow resumes after a number of TCP retransmissions, it will
lead to a use-after-free of the TLS context.&lt;/p&gt;
&lt;p&gt;This commit addresses this bug by keeping the context alive until its
normal destruction, and implements the necessary fallbacks, so that the
connection can resume in software (non-offloaded) kTLS mode.&lt;/p&gt;
&lt;p&gt;On the TX side tls_sw_fallback is used to encrypt all packets. The RX
side already has all the necessary fallbacks, because receiving
non-decrypted packets is supported. The thing needed on the RX side is
to block resync requests, which are normally produced after receiving
non-decrypted packets.&lt;/p&gt;
&lt;p&gt;The necessary synchronization is implemented for a graceful teardown:
first the fallbacks are deployed, then the driver resources are released
(it used to be possible to have a tls_dev_resync after tls_dev_del).&lt;/p&gt;
&lt;p&gt;A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback
mode. It&amp;#39;s used to skip the RX resync logic completely, as it becomes
useless, and some objects may be released (for example, resync_async,
which is allocated and freed by…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-xrvj-3vx6-wwh7</guid>
    </item>
    <item>
      <title>gsd-2021-47131</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-47131</link>
      <description>gsd-2021-47131</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-47131</guid>
    </item>
    <item>
      <title>OESA-2024-1483 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1483</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
i2c: img-scb: fix reference leak when pm_runtime_get_sync fails&#13;
&#13;
The PM reference count is not expected to be incremented on
return in functions img_i2c_xfer and img_i2c_init.&#13;
&#13;
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.&#13;
&#13;
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.(CVE-2020-36783)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
kyber: fix out of bounds access when preempted&#13;
&#13;
__blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and
passes the hctx to -&amp;amp;gt;bio_merge(). kyber_bio_merge() then gets the ctx
for the current CPU again and uses that to get the corresponding Kyber
context in the passed hctx. However, the thread may be preempted between
the two calls to blk_mq_get_ctx(), and the ctx returned the second time
may no longer correspond to the passed hctx. This &amp;amp;quot;works&amp;amp;quot; accidentally
most of the time, but it can cause us to read garbage if the second ctx
came from an hctx with more ctx&amp;amp;apos;s than the first one (i.e., if
ctx-&amp;amp;gt;index_hw[hctx-&amp;amp;gt;type] &amp;amp;gt; hctx-&amp;amp;gt;nr_ctx).&#13;
&#13;
This manifested as this UBSAN array index out of bounds error reported
by Jakub:&#13;
&#13;
UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9
index 1…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
i2c: img-scb: fix reference leak when pm_runtime_get_sync fails&#13;
&#13;
The PM reference count is not expected to be incremented on
return in functions img_i2c_xfer and img_i2c_init.&#13;
&#13;
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.&#13;
&#13;
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.(CVE-2020-36783)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
kyber: fix out of bounds access when preempted&#13;
&#13;
__blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and
passes the hctx to -&amp;amp;gt;bio_merge(). kyber_bio_merge() then gets the ctx
for the current CPU again and uses that to get the corresponding Kyber
context in the passed hctx. However, the thread may be preempted between
the two calls to blk_mq_get_ctx(), and the ctx returned the second time
may no longer correspond to the passed hctx. This &amp;amp;quot;works&amp;amp;quot; accidentally
most of the time, but it can cause us to read garbage if the second ctx
came from an hctx with more ctx&amp;amp;apos;s than the first one (i.e., if
ctx-&amp;amp;gt;index_hw[hctx-&amp;amp;gt;type] &amp;amp;gt; hctx-&amp;amp;gt;nr_ctx).&#13;
&#13;
This manifested as this UBSAN array index out of bounds error reported
by Jakub:&#13;
&#13;
UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9
index 1…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1483</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:1642-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:1642-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-2024:1642-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2021-47131</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47131</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: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 84 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net/tls: Fix use-after-free after the TLS device goes down and up When a netdev with active TLS offload goes down, tls_device_down is called to stop the offload and tear down the TLS context. However, the socket stays alive, and it still points to the TLS context, which is now deallocated. If a netdev goes up, while the connection is still active, and the data flow resumes after a number of TCP retransmissions, it will lead to a use-after-free of the TLS context. This commit addresses this bug by keeping the context alive until its normal destruction, and implements the necessary fallbacks, so that the connection can resume in software (non-offloaded) kTLS mode. On the TX side tls_sw_fallback is used to encrypt all packets. The RX side already has all the necessary fallbacks, because receiving non-decrypted packets is supported. The thing needed on the RX side is to block resync requests, which are normally produced after receiving non-decrypted packets. The necessary synchronization is implemented for a graceful teardown: first the fallbacks are deployed, then the driver resources are released (it used to be possible to have a tls_dev_resync after tls_dev_del). A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback mode. It&amp;#39;s used to skip the RX resync logic completely, as it becomes useless, and some objects may be released (for example, resync_async, which is allocated and freed by the dr…&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: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 84 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net/tls: Fix use-after-free after the TLS device goes down and up When a netdev with active TLS offload goes down, tls_device_down is called to stop the offload and tear down the TLS context. However, the socket stays alive, and it still points to the TLS context, which is now deallocated. If a netdev goes up, while the connection is still active, and the data flow resumes after a number of TCP retransmissions, it will lead to a use-after-free of the TLS context. This commit addresses this bug by keeping the context alive until its normal destruction, and implements the necessary fallbacks, so that the connection can resume in software (non-offloaded) kTLS mode. On the TX side tls_sw_fallback is used to encrypt all packets. The RX side already has all the necessary fallbacks, because receiving non-decrypted packets is supported. The thing needed on the RX side is to block resync requests, which are normally produced after receiving non-decrypted packets. The necessary synchronization is implemented for a graceful teardown: first the fallbacks are deployed, then the driver resources are released (it used to be possible to have a tls_dev_resync after tls_dev_del). A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback mode. It&amp;#39;s used to skip the RX resync logic completely, as it becomes useless, and some objects may be released (for example, resync_async, which is allocated and freed by the dr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47131</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0652 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0652</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0652</guid>
    </item>
  </channel>
</rss>
