<?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 14:09:59 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-04187</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-04187</link>
      <description>bdu:2025-04187</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-04187</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-38621</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-38621</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-2024-38621</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0527 — 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-2024-avi-0527</link>
      <description>certfr-2024-avi-0527</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0527</guid>
    </item>
    <item>
      <title>EUVD-2026-312896</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-312896</link>
      <description>EUVD-2026-312896</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-312896</guid>
    </item>
    <item>
      <title>fkie_cve-2024-38621</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-38621</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: stk1160: fix bounds checking in stk1160_copy_video()&lt;/p&gt;
&lt;p&gt;The subtract in this condition is reversed.  The -&amp;gt;length is the length
of the buffer.  The -&amp;gt;bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it&amp;#39;s unsigned then the result
is a very high positive value.  That means the overflow check is never
true.&lt;/p&gt;
&lt;p&gt;Additionally, the -&amp;gt;bytesused doesn&amp;#39;t actually work for this purpose
because we&amp;#39;re not writing to &amp;#34;buf-&amp;gt;mem + buf-&amp;gt;bytesused&amp;#34;.  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.&lt;/p&gt;
&lt;p&gt;To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf-&amp;gt;length bytes.&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;media: stk1160: fix bounds checking in stk1160_copy_video()&lt;/p&gt;
&lt;p&gt;The subtract in this condition is reversed.  The -&amp;gt;length is the length
of the buffer.  The -&amp;gt;bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it&amp;#39;s unsigned then the result
is a very high positive value.  That means the overflow check is never
true.&lt;/p&gt;
&lt;p&gt;Additionally, the -&amp;gt;bytesused doesn&amp;#39;t actually work for this purpose
because we&amp;#39;re not writing to &amp;#34;buf-&amp;gt;mem + buf-&amp;gt;bytesused&amp;#34;.  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.&lt;/p&gt;
&lt;p&gt;To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf-&amp;gt;length bytes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-38621</guid>
    </item>
    <item>
      <title>GHSA-q3h4-pxwf-237f</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-q3h4-pxwf-237f</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: stk1160: fix bounds checking in stk1160_copy_video()&lt;/p&gt;
&lt;p&gt;The subtract in this condition is reversed.  The -&amp;gt;length is the length
of the buffer.  The -&amp;gt;bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it&amp;#39;s unsigned then the result
is a very high positive value.  That means the overflow check is never
true.&lt;/p&gt;
&lt;p&gt;Additionally, the -&amp;gt;bytesused doesn&amp;#39;t actually work for this purpose
because we&amp;#39;re not writing to &amp;#34;buf-&amp;gt;mem + buf-&amp;gt;bytesused&amp;#34;.  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.&lt;/p&gt;
&lt;p&gt;To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf-&amp;gt;length bytes.&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;media: stk1160: fix bounds checking in stk1160_copy_video()&lt;/p&gt;
&lt;p&gt;The subtract in this condition is reversed.  The -&amp;gt;length is the length
of the buffer.  The -&amp;gt;bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it&amp;#39;s unsigned then the result
is a very high positive value.  That means the overflow check is never
true.&lt;/p&gt;
&lt;p&gt;Additionally, the -&amp;gt;bytesused doesn&amp;#39;t actually work for this purpose
because we&amp;#39;re not writing to &amp;#34;buf-&amp;gt;mem + buf-&amp;gt;bytesused&amp;#34;.  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.&lt;/p&gt;
&lt;p&gt;To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf-&amp;gt;length bytes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-q3h4-pxwf-237f</guid>
    </item>
    <item>
      <title>ICSA-23-348-10 — Siemens SIMATIC S7-1500</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-23-348-10</link>
      <description>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-23-348-10</guid>
    </item>
    <item>
      <title>OESA-2024-1793 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1793</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;
net: ethernet: fix potential use-after-free in ec_bhf_remove&#13;
&#13;
static void ec_bhf_remove(struct pci_dev *dev)
{
...
	struct ec_bhf_priv *priv = netdev_priv(net_dev);&#13;
&#13;
	unregister_netdev(net_dev);
	free_netdev(net_dev);&#13;
&#13;
	pci_iounmap(dev, priv-&amp;amp;gt;dma_io);
	pci_iounmap(dev, priv-&amp;amp;gt;io);
...
}&#13;
&#13;
priv is netdev private data, but it is used
after free_netdev(). It can cause use-after-free when accessing priv
pointer. So, fix it by moving free_netdev() after pci_iounmap()
calls.(CVE-2021-47235)&#13;
&#13;
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47285)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
mac80211: track only QoS data frames for admission control&#13;
&#13;
For admission control, obviously all of that only works for
QoS data frames, otherwise we cannot even access the QoS
field in the header.&#13;
&#13;
Syzbot reported (see below) an uninitialized value here due
to a status of a non-QoS nullfunc packet, which isn&amp;amp;apos;t even
long enough to contain the QoS header.&#13;
&#13;
Fix this to only do anything for QoS data packets.(CVE-2021-47602)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe&#13;
&#13;
Running tests with a debug kernel shows that bnx2fc_recv_frame() is
modifying the per_cpu lport stats cou…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: 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;
net: ethernet: fix potential use-after-free in ec_bhf_remove&#13;
&#13;
static void ec_bhf_remove(struct pci_dev *dev)
{
...
	struct ec_bhf_priv *priv = netdev_priv(net_dev);&#13;
&#13;
	unregister_netdev(net_dev);
	free_netdev(net_dev);&#13;
&#13;
	pci_iounmap(dev, priv-&amp;amp;gt;dma_io);
	pci_iounmap(dev, priv-&amp;amp;gt;io);
...
}&#13;
&#13;
priv is netdev private data, but it is used
after free_netdev(). It can cause use-after-free when accessing priv
pointer. So, fix it by moving free_netdev() after pci_iounmap()
calls.(CVE-2021-47235)&#13;
&#13;
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47285)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
mac80211: track only QoS data frames for admission control&#13;
&#13;
For admission control, obviously all of that only works for
QoS data frames, otherwise we cannot even access the QoS
field in the header.&#13;
&#13;
Syzbot reported (see below) an uninitialized value here due
to a status of a non-QoS nullfunc packet, which isn&amp;amp;apos;t even
long enough to contain the QoS header.&#13;
&#13;
Fix this to only do anything for QoS data packets.(CVE-2021-47602)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe&#13;
&#13;
Running tests with a debug kernel shows that bnx2fc_recv_frame() is
modifying the per_cpu lport stats cou…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1793</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2360-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2360-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:2360-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-38621</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-38621</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 184 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: stk1160: fix bounds checking in stk1160_copy_video() The subtract in this condition is reversed.  The -&amp;gt;length is the length of the buffer.  The -&amp;gt;bytesused is how many bytes we have copied thus far.  When the condition is reversed that means the result of the subtraction is always negative but since it&amp;#39;s unsigned then the result is a very high positive value.  That means the overflow check is never true. Additionally, the -&amp;gt;bytesused doesn&amp;#39;t actually work for this purpose because we&amp;#39;re not writing to &amp;#34;buf-&amp;gt;mem + buf-&amp;gt;bytesused&amp;#34;.  Instead, the math to calculate the destination where we are writing is a bit involved.  You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line. To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return.  Otherwise, write up to buf-&amp;gt;length bytes.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 184 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: stk1160: fix bounds checking in stk1160_copy_video() The subtract in this condition is reversed.  The -&amp;gt;length is the length of the buffer.  The -&amp;gt;bytesused is how many bytes we have copied thus far.  When the condition is reversed that means the result of the subtraction is always negative but since it&amp;#39;s unsigned then the result is a very high positive value.  That means the overflow check is never true. Additionally, the -&amp;gt;bytesused doesn&amp;#39;t actually work for this purpose because we&amp;#39;re not writing to &amp;#34;buf-&amp;gt;mem + buf-&amp;gt;bytesused&amp;#34;.  Instead, the math to calculate the destination where we are writing is a bit involved.  You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line. To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return.  Otherwise, write up to buf-&amp;gt;length bytes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-38621</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1431 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1431</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service 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 Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1431</guid>
    </item>
  </channel>
</rss>
