<?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-16T08:51:16.275377+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/cve-2024-26627</id>
    <title>CVE-2024-26627 — scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler</title>
    <updated>2026-10-16T08:51:16.291684+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler</p>
<p>Inside scsi_eh_wakeup(), scsi_host_busy() is called &amp; checked with host
lock every time for deciding if error handler kthread needs to be waken up.</p>
<p>This can be too heavy in case of recovery, such as:</p>
<p>- N hardware queues</p>
<p>- queue depth is M for each hardware queue</p>
<p>- each scsi_host_busy() iterates over (N * M) tag/requests</p>
<p>If recovery is triggered in case that all requests are in-flight, each
scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called
for the last in-flight request, scsi_host_busy() has been run for (N * M -
1) times, and request has been iterated for (N*M - 1) * (N * M) times.</p>
<p>If both N and M are big enough, hard lockup can be triggered on acquiring
host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).</p>
<p>Fix the issue by calling scsi_host_busy() outside the host lock. We don't
need the host lock for getting busy count because host the lock never
covers that.</p>
<p>[mkp: Drop unnecessary 'busy' variables pointed out by Bart]</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2024-26627"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/usn-6688-1</id>
    <title>USN-6688-1 — linux-oem-6.1 vulnerabilities</title>
    <updated>2026-10-16T08:51:16.291766+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:22.04:LTS: linux-oem-6.1</p>
<p>Pratyush Yadav discovered that the Xen network backend implementation in
the Linux kernel did not properly handle zero length data request, leading
to a null pointer dereference vulnerability. An attacker in a guest VM
could possibly use this to cause a denial of service (host domain crash).
(CVE-2023-46838)</p>
<p>It was discovered that the Habana's AI Processors driver in the Linux
kernel did not properly initialize certain data structures before passing
them to user space. A local attacker could use this to expose sensitive
information (kernel memory). (CVE-2023-50431)</p>
<p>Murray McAllister discovered that the VMware Virtual GPU DRM driver in the
Linux kernel did not properly handle memory objects when storing surfaces,
leading to a use-after-free vulnerability. A local attacker in a guest VM
could use this to cause a denial of service (system crash) or possibly
execute arbitrary code. (CVE-2023-5633)</p>
<p>It was discovered that the CIFS network file system implementation in the
Linux kernel did not properly validate certain SMB messages, leading to an
out-of-bounds read vulnerability. An attacker could use this to cause a
denial of service (system crash) or possibly expose sensitive information.
(CVE-2023-6610)</p>
<p>It was discovered that the VirtIO subsystem in the Linux kernel did not
properly initialize memory in some situations. A local attacker could use
this to possibly expose sensitive information (kernel memory).
(CVE-2024-0340)</p>
<p>Lonial Con discovered that the netfilter subsystem…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/usn-6688-1"/>
  </entry>
</feed>
