gsd-2021-46921
Vulnerability from gsd
Modified
2024-02-26 06:03
Details
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()]
Aliases
{ "gsd": { "metadata": { "exploitCode": "unknown", "remediation": "unknown", "reportConfidence": "confirmed", "type": "vulnerability" }, "osvSchema": { "aliases": [ "CVE-2021-46921" ], "details": "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_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\u2019t 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\u0027ve 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(\u0026ep-\u003elock, flags);\n --\u003e (observes value before unlock) | chain_epi_lockless()\n | | epi-\u003enext = xchg(\u0026ep-\u003eovflist, epi);\n | | read_unlock_irqrestore(\u0026ep-\u003elock, flags);\n | |\n | atomic_cmpxchg_relaxed() |\n |-- READ_ONCE(ep-\u003eovflist); |\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()]", "id": "GSD-2021-46921", "modified": "2024-02-26T06:03:52.730535Z", "schema_version": "1.4.0" } }, "namespaces": { "cve.org": { "CVE_data_meta": { "ASSIGNER": "cve@kernel.org", "ID": "CVE-2021-46921", "STATE": "PUBLIC" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "Linux", "version": { "version_data": [ { "version_affected": "\u003c", "version_name": "b519b56e378e", "version_value": "5902f9453a31" }, { "version_value": "not down converted", "x_cve_json_5_version_data": { "defaultStatus": "affected", "versions": [ { "status": "affected", "version": "4.15" }, { "lessThan": "4.15", "status": "unaffected", "version": "0", "versionType": "custom" }, { "lessThanOrEqual": "4.19.*", "status": "unaffected", "version": "4.19.189", "versionType": "custom" }, { "lessThanOrEqual": "5.4.*", "status": "unaffected", "version": "5.4.115", "versionType": "custom" }, { "lessThanOrEqual": "5.10.*", "status": "unaffected", "version": "5.10.33", "versionType": "custom" }, { "lessThanOrEqual": "5.11.*", "status": "unaffected", "version": "5.11.17", "versionType": "custom" }, { "lessThanOrEqual": "*", "status": "unaffected", "version": "5.12", "versionType": "original_commit_for_fix" } ] } } ] } } ] }, "vendor_name": "Linux" } ] } }, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": { "description_data": [ { "lang": "eng", "value": "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_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\u2019t 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\u0027ve 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(\u0026ep-\u003elock, flags);\n --\u003e (observes value before unlock) | chain_epi_lockless()\n | | epi-\u003enext = xchg(\u0026ep-\u003eovflist, epi);\n | | read_unlock_irqrestore(\u0026ep-\u003elock, flags);\n | |\n | atomic_cmpxchg_relaxed() |\n |-- READ_ONCE(ep-\u003eovflist); |\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()]" } ] }, "generator": { "engine": "bippy-1e70cc10feda" }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "n/a" } ] } ] }, "references": { "reference_data": [ { "name": "https://git.kernel.org/stable/c/5902f9453a313be8fe78cbd7e7ca9dba9319fc6e", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/5902f9453a313be8fe78cbd7e7ca9dba9319fc6e" }, { "name": "https://git.kernel.org/stable/c/82808cc026811fbc3ecf0c0b267a12a339eead56", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/82808cc026811fbc3ecf0c0b267a12a339eead56" }, { "name": "https://git.kernel.org/stable/c/82fa9ced35d88581cffa4a1c856fc41fca96d80a", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/82fa9ced35d88581cffa4a1c856fc41fca96d80a" }, { "name": "https://git.kernel.org/stable/c/d558fcdb17139728347bccc60a16af3e639649d2", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/d558fcdb17139728347bccc60a16af3e639649d2" }, { "name": "https://git.kernel.org/stable/c/84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896" } ] } }, "nvd.nist.gov": { "cve": { "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "8EEE5714-B0F5-40FB-9A6E-4BF3F2A51B2E", "versionEndExcluding": "4.19.189", "versionStartIncluding": "4.15.0", "vulnerable": true }, { "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "CC57D065-3933-4083-BA07-817D4CBF8157", "versionEndExcluding": "5.4.115", "versionStartIncluding": "4.20.0", "vulnerable": true }, { "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "995EF7FE-8C8F-470B-8214-BC0C68B162C3", "versionEndExcluding": "5.10.33", "versionStartIncluding": "5.5.0", "vulnerable": true }, { "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "6C74925C-5E45-4C6F-9E47-653DC5ACBE9E", "versionEndExcluding": "5.11.17", "versionStartIncluding": "5.11.0", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "descriptions": [ { "lang": "en", "value": "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_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\u2019t 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\u0027ve 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(\u0026ep-\u003elock, flags);\n --\u003e (observes value before unlock) | chain_epi_lockless()\n | | epi-\u003enext = xchg(\u0026ep-\u003eovflist, epi);\n | | read_unlock_irqrestore(\u0026ep-\u003elock, flags);\n | |\n | atomic_cmpxchg_relaxed() |\n |-- READ_ONCE(ep-\u003eovflist); |\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()]" }, { "lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: lock/qrwlock: corrige el orden en queued_write_lock_slowpath() Mientras este c\u00f3digo se ejecuta con wait_lock retenido, un lector puede adquirir el bloqueo sin mantener wait_lock. El lado del escritor realiza un bucle para verificar el valor con atomic_cond_read_acquire(), pero solo adquiere realmente el bloqueo cuando la comparaci\u00f3n e intercambio se completa con \u00e9xito, lo cual no est\u00e1 ordenado. Esto expone la ventana entre la adquisici\u00f3n y el cmpxchg a un problema ABA que permite que las lecturas posteriores a la adquisici\u00f3n del bloqueo observen los valores de forma especulativa antes de que se adquiera realmente el bloqueo de escritura. Hemos visto un problema en epoll donde el lector realiza un xchg mientras mantiene el bloqueo de lectura, pero el escritor puede ver un cambio de valor debajo de \u00e9l. Escritor | Lector ------------------------------------------------- ------------------------------- ep_scan_ready_list() | |- write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | | read_lock_irqsave(\u0026amp;ep-\u0026gt;bloquear, banderas); --\u0026gt; (observa el valor antes de desbloquear) | cadena_epi_lockless() | | epi-\u0026gt;siguiente = xchg(\u0026amp;ep-\u0026gt;ovflist, epi); | | read_unlock_irqrestore(\u0026amp;ep-\u0026gt;bloquear, banderas); | | | atomic_cmpxchg_relaxed() | |-- READ_ONCE(ep-\u0026gt;ovflist); | Un n\u00facleo puede ordenar la lectura de ovflist antes de atomic_cmpxchg_relaxed(). Cambiar cmpxchg para usar la sem\u00e1ntica de adquisici\u00f3n soluciona este problema, momento en el que atomic_cond_read se puede cambiar para usar una sem\u00e1ntica relajada. [peterz: utilice try_cmpxchg()]" } ], "id": "CVE-2021-46921", "lastModified": "2024-04-10T13:39:36.027", "metrics": { "cvssMetricV31": [ { "cvssData": { "attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "NONE", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N", "version": "3.1" }, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary" } ] }, "published": "2024-02-27T10:15:06.990", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/5902f9453a313be8fe78cbd7e7ca9dba9319fc6e" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/82808cc026811fbc3ecf0c0b267a12a339eead56" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/82fa9ced35d88581cffa4a1c856fc41fca96d80a" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/d558fcdb17139728347bccc60a16af3e639649d2" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-668" } ], "source": "nvd@nist.gov", "type": "Primary" } ] } } } }
Loading...
Loading...
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.