---
id: CVE-2021-46921
title: |-
  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_l…
summary: |-
  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_l…
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
cwe:
  - CWE-668
vendor: linux
product: linux_kernel
affected:
  - 'linux_kernel >= 4.15.0, < 4.19.189'
  - 'linux_kernel >= 4.20.0, < 5.4.115'
  - 'linux_kernel >= 5.5.0, < 5.10.33'
  - 'linux_kernel >= 5.11.0, < 5.11.17'
patched:
  - linux_kernel 5.11.17
published: '2024-02-27'
updated: '2026-08-04'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2021-46921'
references:
  - url: 'https://git.kernel.org/stable/c/5902f9453a313be8fe78cbd7e7ca9dba9319fc6e'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/82808cc026811fbc3ecf0c0b267a12a339eead56'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/82fa9ced35d88581cffa4a1c856fc41fca96d80a'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/d558fcdb17139728347bccc60a16af3e639649d2'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/5902f9453a313be8fe78cbd7e7ca9dba9319fc6e'
    label: af854a3a-2127-422b-91ae-364da2661108
  - url: 'https://git.kernel.org/stable/c/82808cc026811fbc3ecf0c0b267a12a339eead56'
    label: af854a3a-2127-422b-91ae-364da2661108
  - url: 'https://git.kernel.org/stable/c/82fa9ced35d88581cffa4a1c856fc41fca96d80a'
    label: af854a3a-2127-422b-91ae-364da2661108
  - url: 'https://git.kernel.org/stable/c/84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896'
    label: af854a3a-2127-422b-91ae-364da2661108
  - url: 'https://git.kernel.org/stable/c/d558fcdb17139728347bccc60a16af3e639649d2'
    label: af854a3a-2127-422b-91ae-364da2661108
tags:
  - nvd
epss: 0.00235
epssPercentile: 0.12955
ingestedAt: '2026-08-04T10:39:38.283Z'
---

## Overview

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

## Affected

- `linux_kernel >= 4.15.0, < 4.19.189`
- `linux_kernel >= 4.20.0, < 5.4.115`
- `linux_kernel >= 5.5.0, < 5.10.33`
- `linux_kernel >= 5.11.0, < 5.11.17`

## Remediation

Upgrade past the affected range:

- `linux_kernel 5.11.17`