<?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>Fri, 02 Oct 2026 22:33:45 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-12822</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-12822</link>
      <description>bdu:2025-12822</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-12822</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53503</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-53503</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-53503</guid>
    </item>
    <item>
      <title>EUVD-2026-312097</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-312097</link>
      <description>EUVD-2026-312097</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-312097</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53503</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53503</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: allow ext4_get_group_info() to fail&lt;/p&gt;
&lt;p&gt;Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen.  However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number.  In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number.  Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.&lt;/p&gt;
&lt;p&gt;For a quality of implementation perspective, it&amp;#39;s best that even if
the system administrator does something that they shouldn&amp;#39;t, that it
will not trigger a BUG.  So instead of BUG&amp;#39;ing, ext4_get_group_info()
will call ext4_error and return NULL.  We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.&lt;/p&gt;
&lt;p&gt;Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it.  The results in a next reduction of the
compiled text size of ext4 by roughly 2k.&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;ext4: allow ext4_get_group_info() to fail&lt;/p&gt;
&lt;p&gt;Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen.  However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number.  In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number.  Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.&lt;/p&gt;
&lt;p&gt;For a quality of implementation perspective, it&amp;#39;s best that even if
the system administrator does something that they shouldn&amp;#39;t, that it
will not trigger a BUG.  So instead of BUG&amp;#39;ing, ext4_get_group_info()
will call ext4_error and return NULL.  We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.&lt;/p&gt;
&lt;p&gt;Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it.  The results in a next reduction of the
compiled text size of ext4 by roughly 2k.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-53503</guid>
    </item>
    <item>
      <title>GHSA-794g-3p8m-5jpc</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-794g-3p8m-5jpc</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: allow ext4_get_group_info() to fail&lt;/p&gt;
&lt;p&gt;Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen.  However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number.  In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number.  Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.&lt;/p&gt;
&lt;p&gt;For a quality of implementation perspective, it&amp;#39;s best that even if
the system administrator does something that they shouldn&amp;#39;t, that it
will not trigger a BUG.  So instead of BUG&amp;#39;ing, ext4_get_group_info()
will call ext4_error and return NULL.  We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.&lt;/p&gt;
&lt;p&gt;Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it.  The results in a next reduction of the
compiled text size of ext4 by roughly 2k.&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;ext4: allow ext4_get_group_info() to fail&lt;/p&gt;
&lt;p&gt;Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen.  However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number.  In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number.  Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.&lt;/p&gt;
&lt;p&gt;For a quality of implementation perspective, it&amp;#39;s best that even if
the system administrator does something that they shouldn&amp;#39;t, that it
will not trigger a BUG.  So instead of BUG&amp;#39;ing, ext4_get_group_info()
will call ext4_error and return NULL.  We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.&lt;/p&gt;
&lt;p&gt;Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it.  The results in a next reduction of the
compiled text size of ext4 by roughly 2k.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-794g-3p8m-5jpc</guid>
    </item>
    <item>
      <title>RHSA-2024:10771 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:10771</link>
      <description>&lt;p&gt;kernel: vt_ioctl: fix array_index_nospec in vt_setactivate kernel: pstore/ram: Fix crash when setting number of cpus to an odd number kernel: PM / devfreq: Synchronize devfreq_monitor_[start/stop] kernel: net/smc: avoid data corruption caused by decline kernel: scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool kernel: ext4: allow ext4_get_group_info() to fail kernel: ext4: correct grp validation in ext4_mb_good_group kernel: ext4: regenerate buddy after block freeing failed if under fc replay kernel: net/smc: fix illegal rmb_desc access in SMC-D connection dump kernel: fs/proc: do_task_stat: use sig-&amp;gt;stats_lock to gather the threads/children stats kernel: ext4: fix double-free of blocks due to wrong extents moved_len kernel: Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout kernel: s390/qeth: Fix kernel panic after setting hsuid kernel: drm/vmwgfx: Fix invalid reads in fence signaled events kernel: blk-cgroup: fix list corruption from reorder of WRITE -&amp;amp;gt;lqueued kernel: of: module: add buffer overflow check in of_modalias() kernel: net/mlx5: Discard command completions in internal error kernel: net: hns3: fix kernel crash problem in concurrent scenario kernel: cpufreq: amd-pstate: fix memory leak on CPU EPP exit kernel: tcp: avoid too many retransmit packets kernel: drm/amdgpu: change vm-&amp;amp;gt;task_info handling kernel: bpf: Fix overrunning reservations in ringbuf kernel: mm/filemap: skip to create PMD-sized page cache if needed kernel: firmware: cs_dsp…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: vt_ioctl: fix array_index_nospec in vt_setactivate kernel: pstore/ram: Fix crash when setting number of cpus to an odd number kernel: PM / devfreq: Synchronize devfreq_monitor_[start/stop] kernel: net/smc: avoid data corruption caused by decline kernel: scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool kernel: ext4: allow ext4_get_group_info() to fail kernel: ext4: correct grp validation in ext4_mb_good_group kernel: ext4: regenerate buddy after block freeing failed if under fc replay kernel: net/smc: fix illegal rmb_desc access in SMC-D connection dump kernel: fs/proc: do_task_stat: use sig-&amp;gt;stats_lock to gather the threads/children stats kernel: ext4: fix double-free of blocks due to wrong extents moved_len kernel: Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout kernel: s390/qeth: Fix kernel panic after setting hsuid kernel: drm/vmwgfx: Fix invalid reads in fence signaled events kernel: blk-cgroup: fix list corruption from reorder of WRITE -&amp;amp;gt;lqueued kernel: of: module: add buffer overflow check in of_modalias() kernel: net/mlx5: Discard command completions in internal error kernel: net: hns3: fix kernel crash problem in concurrent scenario kernel: cpufreq: amd-pstate: fix memory leak on CPU EPP exit kernel: tcp: avoid too many retransmit packets kernel: drm/amdgpu: change vm-&amp;amp;gt;task_info handling kernel: bpf: Fix overrunning reservations in ringbuf kernel: mm/filemap: skip to create PMD-sized page cache if needed kernel: firmware: cs_dsp…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:10771</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53503</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53503</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, 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 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ext4: allow ext4_get_group_info() to fail Previously, ext4_get_group_info() would treat an invalid group number as BUG(), since in theory it should never happen.  However, if a malicious attaker (or fuzzer) modifies the superblock via the block device while it is the file system is mounted, it is possible for s_first_data_block to get set to a very large number.  In that case, when calculating the block group of some block number (such as the starting block of a preallocation region), could result in an underflow and very large block group number.  Then the BUG_ON check in ext4_get_group_info() would fire, resutling in a denial of service attack that can be triggered by root or someone with write access to the block device. For a quality of implementation perspective, it&amp;#39;s best that even if the system administrator does something that they shouldn&amp;#39;t, that it will not trigger a BUG.  So instead of BUG&amp;#39;ing, ext4_get_group_info() will call ext4_error and return NULL.  We also add fallback code in all of the callers of ext4_get_group_info() that it might NULL. Also, since ext4_get_group_info() was already borderline to be an inline function, un-inline it.  The results in a next reduction of the compiled text size of ext4 by roughly 2k.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, 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 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ext4: allow ext4_get_group_info() to fail Previously, ext4_get_group_info() would treat an invalid group number as BUG(), since in theory it should never happen.  However, if a malicious attaker (or fuzzer) modifies the superblock via the block device while it is the file system is mounted, it is possible for s_first_data_block to get set to a very large number.  In that case, when calculating the block group of some block number (such as the starting block of a preallocation region), could result in an underflow and very large block group number.  Then the BUG_ON check in ext4_get_group_info() would fire, resutling in a denial of service attack that can be triggered by root or someone with write access to the block device. For a quality of implementation perspective, it&amp;#39;s best that even if the system administrator does something that they shouldn&amp;#39;t, that it will not trigger a BUG.  So instead of BUG&amp;#39;ing, ext4_get_group_info() will call ext4_error and return NULL.  We also add fallback code in all of the callers of ext4_get_group_info() that it might NULL. Also, since ext4_get_group_info() was already borderline to be an inline function, un-inline it.  The results in a next reduction of the compiled text size of ext4 by roughly 2k.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53503</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2187 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2187</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht nähere beschriebene Effekte zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht nähere beschriebene Effekte zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2187</guid>
    </item>
  </channel>
</rss>
