{"id":"CVE-2021-46921","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nlocking/qrwlock: Fix ordering in queued_write_lock_slowpath()\n\nWhile this code is executed with the wait_lock held, a reader can\nacquire the lock without holding wait_l…","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlocking/qrwlock: Fix ordering in queued_write_lock_slowpath()\n\nWhile this code is executed with the wait_lock held, a reader can\nacquire 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","slug":"CVE-2021-46921","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlocking/qrwlock: Fix ordering in queued_write_lock_slowpath()\n\nWhile this code is executed with the wait_lock held, a reader can\nacquire the lock without holding wait_lock.  The writer side loops\nchecking the value with the atomic_cond_read_acquire(), but only truly\nacquires the lock when the compare-and-exchange is completed\nsuccessfully which isn’t ordered. This exposes the window between the\nacquire and the cmpxchg to an A-B-A problem which allows reads\nfollowing the lock acquisition to observe values speculatively before\nthe write lock is truly acquired.\n\nWe've seen a problem in epoll where the reader does a xchg while\nholding the read lock, but the writer can see a value change out from\nunder it.\n\n  Writer                                | Reader\n  --------------------------------------------------------------------------------\n  ep_scan_ready_list()                  |\n  |- write_lock_irq()                   |\n      |- queued_write_lock_slowpath()   |\n\t|- atomic_cond_read_acquire()   |\n\t\t\t\t        | read_lock_irqsave(&ep->lock, flags);\n     --> (observes value before unlock) |  chain_epi_lockless()\n     |                                  |    epi->next = xchg(&ep->ovflist, epi);\n     |                                  | read_unlock_irqrestore(&ep->lock, flags);\n     |                                  |\n     |     atomic_cmpxchg_relaxed()     |\n     |-- READ_ONCE(ep->ovflist);        |\n\nA core can order the read of the ovflist ahead of the\natomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire\nsemantics addresses this issue at which point the atomic_cond_read can\nbe switched to use relaxed semantics.\n\n[peterz: use try_cmpxchg()]\n\n## Affected\n\n- `linux_kernel >= 4.15.0, < 4.19.189`\n- `linux_kernel >= 4.20.0, < 5.4.115`\n- `linux_kernel >= 5.5.0, < 5.10.33`\n- `linux_kernel >= 5.11.0, < 5.11.17`\n\n## Remediation\n\nUpgrade past the affected range:\n\n- `linux_kernel 5.11.17`","depth":"twilight","depthScore":43,"depthScoreParts":{"impact":42.9,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}