CVE-2021-46921

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lock/qrwlock: corrige el orden en queued_write_lock_slowpath() Mientras este código 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ón e intercambio se completa con éxito, lo cual no está ordenado. Esto expone la ventana entre la adquisición y el cmpxchg a un problema ABA que permite que las lecturas posteriores a la adquisición 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 él. Escritor | Lector ------------------------------------------------- ------------------------------- ep_scan_ready_list() | |- write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | | read_lock_irqsave(&ep->bloquear, banderas); --> (observa el valor antes de desbloquear) | cadena_epi_lockless() | | epi->siguiente = xchg(&ep->ovflist, epi); | | read_unlock_irqrestore(&ep->bloquear, banderas); | | | atomic_cmpxchg_relaxed() | |-- READ_ONCE(ep->ovflist); | Un núcleo puede ordenar la lectura de ovflist antes de atomic_cmpxchg_relaxed(). Cambiar cmpxchg para usar la semántica de adquisición soluciona este problema, momento en el que atomic_cond_read se puede cambiar para usar una semántica relajada. [peterz: utilice try_cmpxchg()]

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