<?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-03T06:11:06.557154+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:2025-14584</id>
    <title>bdu:2025-14584</title>
    <updated>2026-10-03T06:11:06.575785+00:00</updated>
    <content>bdu:2025-14584</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-14584"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2023-52609</id>
    <title>BELL-CVE-2023-52609</title>
    <updated>2026-10-03T06:11:06.575826+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-2023-52609"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0301</id>
    <title>certfr-2024-avi-0301 — De multiples vulnérabilités ont été découvertes dans &lt;span
class="textit"&gt;le noyau Linux d'Ubuntu&lt;/span&gt;. Certaines d'e…</title>
    <updated>2026-10-03T06:11:06.575857+00:00</updated>
    <content>certfr-2024-avi-0301</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2024-avi-0301"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-311580</id>
    <title>EUVD-2026-311580</title>
    <updated>2026-10-03T06:11:06.575874+00:00</updated>
    <content>EUVD-2026-311580</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-311580"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2023-52609</id>
    <title>fkie_cve-2023-52609</title>
    <updated>2026-10-03T06:11:06.575885+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>binder: fix race between mmput() and do_exit()</p>
<p>Task A calls binder_update_page_range() to allocate and insert pages on
a remote address space from Task B. For this, Task A pins the remote mm
via mmget_not_zero() first. This can race with Task B do_exit() and the
final mmput() refcount decrement will come from Task A.</p>
<p>Task A            | Task B
  ------------------+------------------
  mmget_not_zero()  |
                    |  do_exit()
                    |    exit_mm()
                    |      mmput()
  mmput()           |
    exit_mmap()     |
      remove_vma()  |
        fput()      |</p>
<p>In this case, the work of ____fput() from Task B is queued up in Task A
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
work gets executed. However, Task A instead sleep, waiting for a reply
from Task B that never comes (it's dead).</p>
<p>This means the binder_deferred_release() is blocked until an unrelated
binder event forces Task A to go back to userspace. All the associated
death notifications will also be delayed until then.</p>
<p>In order to fix this use mmput_async() that will schedule the work in
the corresponding mm-&gt;async_put_work WQ instead of Task A.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2023-52609"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-5h3h-5652-8xp5</id>
    <title>GHSA-5h3h-5652-8xp5</title>
    <updated>2026-10-03T06:11:06.575923+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>binder: fix race between mmput() and do_exit()</p>
<p>Task A calls binder_update_page_range() to allocate and insert pages on
a remote address space from Task B. For this, Task A pins the remote mm
via mmget_not_zero() first. This can race with Task B do_exit() and the
final mmput() refcount decrement will come from Task A.</p>
<p>Task A            | Task B
  ------------------+------------------
  mmget_not_zero()  |
                    |  do_exit()
                    |    exit_mm()
                    |      mmput()
  mmput()           |
    exit_mmap()     |
      remove_vma()  |
        fput()      |</p>
<p>In this case, the work of ____fput() from Task B is queued up in Task A
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
work gets executed. However, Task A instead sleep, waiting for a reply
from Task B that never comes (it's dead).</p>
<p>This means the binder_deferred_release() is blocked until an unrelated
binder event forces Task A to go back to userspace. All the associated
death notifications will also be delayed until then.</p>
<p>In order to fix this use mmput_async() that will schedule the work in
the corresponding mm-&gt;async_put_work WQ instead of Task A.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-5h3h-5652-8xp5"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/gsd-2023-52609</id>
    <title>gsd-2023-52609</title>
    <updated>2026-10-03T06:11:06.575949+00:00</updated>
    <content>gsd-2023-52609</content>
    <link href="https://cve.radiocsirt.org/vuln/gsd-2023-52609"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2024-1566</id>
    <title>OESA-2024-1566 — kernel security update</title>
    <updated>2026-10-03T06:11:06.575959+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: kernel</p>
<p>The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Fix scsi_mode_sense() buffer length handling

Several problems exist with scsi_mode_sense() buffer length handling:

 1) The allocation length field of the MODE SENSE(10) command is 16-bits,
    occupying bytes 7 and 8 of the CDB. With this command, access to mode
    pages larger than 255 bytes is thus possible. However, the CDB
    allocation length field is set by assigning len to byte 8 only, thus
    truncating buffer length larger than 255.

 2) If scsi_mode_sense() is called with len smaller than 8 with
    sdev-&amp;gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
    is increased to 8 and 4 respectively, and the buffer is zero filled
    with these increased values, thus corrupting the memory following the
    buffer.

Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.

Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&amp;gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.

While at it, also fix the folowing:

 *…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2024-1566"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52609</id>
    <title>UBUNTU-CVE-2023-52609</title>
    <updated>2026-10-03T06:11:06.576074+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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 159 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: binder: fix race between mmput() and do_exit() Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A.   Task A            | Task B   ------------------+------------------   mmget_not_zero()  |                     |  do_exit()                     |    exit_mm()                     |      mmput()   mmput()           |     exit_mmap()     |       remove_vma()  |         fput()      | In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead). This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then. In order to fix this use mmput_async() that will schedule the work in the corresponding mm-&gt;async_put_work WQ instead of Task A.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52609"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0654</id>
    <title>WID-SEC-W-2024-0654 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service und unspezifische Angriffe</title>
    <updated>2026-10-03T06:11:06.576277+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0654"/>
  </entry>
</feed>
