<?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://vulnerability.circl.lu</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>Tue, 29 Sep 2026 05:28:37 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-72282 — KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-72282</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers&lt;/p&gt;
&lt;p&gt;kvm_io_bus_get_dev() returns a device that is only matched by the
address, and nothing else. This can cause a lifetime issue if
the matched device is not the expected type, as by the time
the caller can introspect the object, it might be gone (the srcu
lock having been dropped).&lt;/p&gt;
&lt;p&gt;Given that there is only a single user of this helper, the simplest
option is to move the locking responsibility to the caller, which
can keep the srcu lock held for as long as it wants.&lt;/p&gt;
&lt;p&gt;Note that this aligns with other kvm_io_bus*() helpers, which
already require the srcu lock to be held by the callers.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers&lt;/p&gt;
&lt;p&gt;kvm_io_bus_get_dev() returns a device that is only matched by the
address, and nothing else. This can cause a lifetime issue if
the matched device is not the expected type, as by the time
the caller can introspect the object, it might be gone (the srcu
lock having been dropped).&lt;/p&gt;
&lt;p&gt;Given that there is only a single user of this helper, the simplest
option is to move the locking responsibility to the caller, which
can keep the srcu lock held for as long as it wants.&lt;/p&gt;
&lt;p&gt;Note that this aligns with other kvm_io_bus*() helpers, which
already require the srcu lock to be held by the callers.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-72282</guid>
    </item>
  </channel>
</rss>
