<?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://db.gcve.eu</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>Thu, 05 Nov 2026 21:01:34 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-99230 — io_uring/cmd: don't leave list poison in -&gt;hash_node</title>
      <link>https://db.gcve.eu/vuln/cve-2026-99230</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;io_uring/cmd: don&amp;#39;t leave list poison in -&amp;gt;hash_node&lt;/p&gt;
&lt;p&gt;io_uring_cmd_del_cancelable() uses hlist_del() to take a command off
-&amp;gt;cancelable_uring_cmd, which leaves LIST_POISON1/2 behind in
-&amp;gt;hash_node. Requests are recycled through the request cache without
being reinitialised, and not every user of -&amp;gt;hash_node sets it up before
it is used:&lt;/p&gt;
&lt;p&gt;If a vectored futex wait is woken while futex_wait_multiple_setup() is
still queueing the futexes, io_futexv_wait() doesn&amp;#39;t add the request to
-&amp;gt;futex_list, and leaves the completion to the task_work queued by the
wake up. io_futexv_complete() ends in __io_futex_complete(), whose
hlist_del_init() is fine for a request that is unhashed, which is how all
other users of the node leave it. If the request was a cancelable
uring_cmd in its previous life, e.g. a ublk FETCH_REQ, it writes through
LIST_POISON2:&lt;/p&gt;
&lt;p&gt;Oops: general protection fault, probably for non-canonical address
  KASAN: maybe wild-memory-access in range [0xdead000000000120-...]
  RIP: 0010:io_futexv_complete+0x219/0x420
  Call Trace:
   tctx_task_work_run+0x804/0x950
   tctx_task_work+0x71/0xa0
   task_work_run+0x118/0x200&lt;/p&gt;
&lt;p&gt;Leave the node unhashed.&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;io_uring/cmd: don&amp;#39;t leave list poison in -&amp;gt;hash_node&lt;/p&gt;
&lt;p&gt;io_uring_cmd_del_cancelable() uses hlist_del() to take a command off
-&amp;gt;cancelable_uring_cmd, which leaves LIST_POISON1/2 behind in
-&amp;gt;hash_node. Requests are recycled through the request cache without
being reinitialised, and not every user of -&amp;gt;hash_node sets it up before
it is used:&lt;/p&gt;
&lt;p&gt;If a vectored futex wait is woken while futex_wait_multiple_setup() is
still queueing the futexes, io_futexv_wait() doesn&amp;#39;t add the request to
-&amp;gt;futex_list, and leaves the completion to the task_work queued by the
wake up. io_futexv_complete() ends in __io_futex_complete(), whose
hlist_del_init() is fine for a request that is unhashed, which is how all
other users of the node leave it. If the request was a cancelable
uring_cmd in its previous life, e.g. a ublk FETCH_REQ, it writes through
LIST_POISON2:&lt;/p&gt;
&lt;p&gt;Oops: general protection fault, probably for non-canonical address
  KASAN: maybe wild-memory-access in range [0xdead000000000120-...]
  RIP: 0010:io_futexv_complete+0x219/0x420
  Call Trace:
   tctx_task_work_run+0x804/0x950
   tctx_task_work+0x71/0xa0
   task_work_run+0x118/0x200&lt;/p&gt;
&lt;p&gt;Leave the node unhashed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-99230</guid>
    </item>
  </channel>
</rss>
