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()]
History

No history.

cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2025-05-04T07:00:23.829Z

Reserved: 2024-02-25T13:45:52.719Z

Link: CVE-2021-46921

cve-icon Vulnrichment

Updated: 2024-08-04T05:17:42.848Z

cve-icon NVD

Status : Modified

Published: 2024-02-27T10:15:06.990

Modified: 2024-11-21T06:34:56.260

Link: CVE-2021-46921

cve-icon Redhat

Severity : Low

Publid Date: 2024-02-27T00:00:00Z

Links: CVE-2021-46921 - Bugzilla

cve-icon OpenCVE Enrichment

No data.