<?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>Wed, 30 Sep 2026 22:35:56 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-47552 — blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2021-47552</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;blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()&lt;/p&gt;
&lt;p&gt;For avoiding to slow down queue destroy, we don&amp;#39;t call
blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to
cancel dispatch work in blk_release_queue().&lt;/p&gt;
&lt;p&gt;However, this way has caused kernel oops[1], reported by Changhui. The log
shows that scsi_device can be freed before running blk_release_queue(),
which is expected too since scsi_device is released after the scsi disk
is closed and the scsi_device is removed.&lt;/p&gt;
&lt;p&gt;Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue()
and disk_release():&lt;/p&gt;
&lt;p&gt;1) when disk_release() is run, the disk has been closed, and any sync
dispatch activities have been done, so canceling dispatch work is enough to
quiesce filesystem I/O dispatch activity.&lt;/p&gt;
&lt;p&gt;2) in blk_cleanup_queue(), we only focus on passthrough request, and
passthrough request is always explicitly allocated &amp;amp; freed by
its caller, so once queue is frozen, all sync dispatch activity
for passthrough request has been done, then it is enough to just cancel
dispatch work for avoiding any dispatch activity.&lt;/p&gt;
&lt;p&gt;[1] kernel panic log
[12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300
[12622.777186] #PF: supervisor read access in kernel mode
[12622.782918] #PF: error_code(0x0000) - not-present page
[12622.788649] PGD 0 P4D 0
[12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI
[12622.796138] CPU:…&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;blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()&lt;/p&gt;
&lt;p&gt;For avoiding to slow down queue destroy, we don&amp;#39;t call
blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to
cancel dispatch work in blk_release_queue().&lt;/p&gt;
&lt;p&gt;However, this way has caused kernel oops[1], reported by Changhui. The log
shows that scsi_device can be freed before running blk_release_queue(),
which is expected too since scsi_device is released after the scsi disk
is closed and the scsi_device is removed.&lt;/p&gt;
&lt;p&gt;Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue()
and disk_release():&lt;/p&gt;
&lt;p&gt;1) when disk_release() is run, the disk has been closed, and any sync
dispatch activities have been done, so canceling dispatch work is enough to
quiesce filesystem I/O dispatch activity.&lt;/p&gt;
&lt;p&gt;2) in blk_cleanup_queue(), we only focus on passthrough request, and
passthrough request is always explicitly allocated &amp;amp; freed by
its caller, so once queue is frozen, all sync dispatch activity
for passthrough request has been done, then it is enough to just cancel
dispatch work for avoiding any dispatch activity.&lt;/p&gt;
&lt;p&gt;[1] kernel panic log
[12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300
[12622.777186] #PF: supervisor read access in kernel mode
[12622.782918] #PF: error_code(0x0000) - not-present page
[12622.788649] PGD 0 P4D 0
[12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI
[12622.796138] CPU:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2021-47552</guid>
    </item>
  </channel>
</rss>
