CVE-2021-46921

In the Linux kernel, the following vulnerability has been resolved:
locking/qrwlock: Fix ordering in queued_write_lock_slowpath() 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. We’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. Writer | Reader

ep_scan_ready_list() | |- write_lock_irq() | |-
queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | |
read_lock_irqsave(&ep->lock, flags); –> (observes value before unlock) |
chain_epi_lockless() | | epi->next = xchg(&ep->ovflist, epi); | |
read_unlock_irqrestore(&ep->lock, flags); | | | atomic_cmpxchg_relaxed() |
|-- READ_ONCE(ep->ovflist); | A core can order the read of the ovflist
ahead of the atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire
semantics addresses this issue at which point the atomic_cond_read can be
switched to use relaxed semantics. [peterz: use try_cmpxchg()]