<?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://cve.radiocsirt.org</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>Mon, 05 Oct 2026 13:48:48 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-46921 — locking/qrwlock: Fix ordering in queued_write_lock_slowpath()</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2021-46921</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;locking/qrwlock: Fix ordering in queued_write_lock_slowpath()&lt;/p&gt;
&lt;p&gt;While this code is executed with the wait_lock held, a reader can
acquire the lock without holding wait_lock.  The writer side loops
checking the value with the atomic_cond_read_acquire(), but only truly
acquires the lock when the compare-and-exchange is completed
successfully which isn’t ordered. This exposes the window between the
acquire and the cmpxchg to an A-B-A problem which allows reads
following the lock acquisition to observe values speculatively before
the write lock is truly acquired.&lt;/p&gt;
&lt;p&gt;We&amp;#39;ve seen a problem in epoll where the reader does a xchg while
holding the read lock, but the writer can see a value change out from
under it.&lt;/p&gt;
&lt;p&gt;Writer                                | Reader
  --------------------------------------------------------------------------------
  ep_scan_ready_list()                  |
  |- write_lock_irq()                   |
      |- queued_write_lock_slowpath()   |
	|- atomic_cond_read_acquire()   |
				        | read_lock_irqsave(&amp;amp;ep-&amp;gt;lock, flags);
     --&amp;gt; (observes value before unlock) |  chain_epi_lockless()
     |                                  |    epi-&amp;gt;next = xchg(&amp;amp;ep-&amp;gt;ovflist, epi);
     |                                  | read_unlock_irqrestore(&amp;amp;ep-&amp;gt;lock, flags);
     |                                  |
     |     atomic_cmpxchg_relaxed()     |
     |-- READ_ONCE(ep-&amp;gt;ovflist);        |&lt;/p&gt;
&lt;p&gt;A core can order…&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;locking/qrwlock: Fix ordering in queued_write_lock_slowpath()&lt;/p&gt;
&lt;p&gt;While this code is executed with the wait_lock held, a reader can
acquire the lock without holding wait_lock.  The writer side loops
checking the value with the atomic_cond_read_acquire(), but only truly
acquires the lock when the compare-and-exchange is completed
successfully which isn’t ordered. This exposes the window between the
acquire and the cmpxchg to an A-B-A problem which allows reads
following the lock acquisition to observe values speculatively before
the write lock is truly acquired.&lt;/p&gt;
&lt;p&gt;We&amp;#39;ve seen a problem in epoll where the reader does a xchg while
holding the read lock, but the writer can see a value change out from
under it.&lt;/p&gt;
&lt;p&gt;Writer                                | Reader
  --------------------------------------------------------------------------------
  ep_scan_ready_list()                  |
  |- write_lock_irq()                   |
      |- queued_write_lock_slowpath()   |
	|- atomic_cond_read_acquire()   |
				        | read_lock_irqsave(&amp;amp;ep-&amp;gt;lock, flags);
     --&amp;gt; (observes value before unlock) |  chain_epi_lockless()
     |                                  |    epi-&amp;gt;next = xchg(&amp;amp;ep-&amp;gt;ovflist, epi);
     |                                  | read_unlock_irqrestore(&amp;amp;ep-&amp;gt;lock, flags);
     |                                  |
     |     atomic_cmpxchg_relaxed()     |
     |-- READ_ONCE(ep-&amp;gt;ovflist);        |&lt;/p&gt;
&lt;p&gt;A core can order…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2021-46921</guid>
    </item>
  </channel>
</rss>
