CVE-2021-46921

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/qrwlock: Fix ordering in queued_write_lock_slowpath()<br /> <br /> While this code is executed with the wait_lock held, a reader can<br /> acquire the lock without holding wait_lock. The writer side loops<br /> checking the value with the atomic_cond_read_acquire(), but only truly<br /> acquires the lock when the compare-and-exchange is completed<br /> successfully which isn’t ordered. This exposes the window between the<br /> acquire and the cmpxchg to an A-B-A problem which allows reads<br /> following the lock acquisition to observe values speculatively before<br /> the write lock is truly acquired.<br /> <br /> We&amp;#39;ve seen a problem in epoll where the reader does a xchg while<br /> holding the read lock, but the writer can see a value change out from<br /> under it.<br /> <br /> Writer | Reader<br /> --------------------------------------------------------------------------------<br /> ep_scan_ready_list() |<br /> |- write_lock_irq() |<br /> |- queued_write_lock_slowpath() |<br /> |- atomic_cond_read_acquire() |<br /> | read_lock_irqsave(&amp;ep-&gt;lock, flags);<br /> --&gt; (observes value before unlock) | chain_epi_lockless()<br /> | | epi-&gt;next = xchg(&amp;ep-&gt;ovflist, epi);<br /> | | read_unlock_irqrestore(&amp;ep-&gt;lock, flags);<br /> | |<br /> | atomic_cmpxchg_relaxed() |<br /> |-- READ_ONCE(ep-&gt;ovflist); |<br /> <br /> A core can order the read of the ovflist ahead of the<br /> atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire<br /> semantics addresses this issue at which point the atomic_cond_read can<br /> be switched to use relaxed semantics.<br /> <br /> [peterz: use try_cmpxchg()]