In the Linux kernel, the following vulnerability has been resolved:

drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()

Even though we check that we "should" be able to do lc_get_cumulative()
while holding the device->al_lock spinlock, it may still fail,
if some other code path decided to do lc_try_lock() with bad timing.

If that happened, we logged "LOGIC BUG for enr=...",
but still did not return an error.

The rest of the code now assumed that this request has references
for the relevant activity log extents.

The implcations are that during an active resync, mutual exclusivity of
resync versus application IO is not guaranteed. And a potential crash
at this point may not realizs that these extents could have been target
of in-flight IO and would need to be resynced just in case.

Also, once the request completes, it will give up activity log references it
does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().

Fix:

Do not crash the kernel for a condition that is harmless during normal
operation: also catch "e->refcnt == 0", not only "e == NULL"
when being noisy about "al_complete_io() called on inactive extent %u\n".

And do not try to be smart and "guess" whether something will work, then
be surprised when it does not.
Deal with the fact that it may or may not work. If it does not, remember a
possible "partially in activity log" state (only possible for requests that
cross extent boundaries), and return an error code from
drbd_al_begin_io_nonblock().

A latter call for the same request will then resume from where we left off.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:

drbd: corrige el 'LOGIC BUG' en drbd_al_begin_io_nonblock()

Aunque verificamos que "deberíamos" poder hacer lc_get_cumulative() mientras mantenemos el spinlock device->al_lock, aún puede fallar, si alguna otra ruta de código decidió hacer lc_try_lock() con una sincronización deficiente.

Si eso sucedía, registrábamos 'LOGIC BUG for enr=...', pero aún así no devolvíamos un error.

El resto del código ahora asumía que esta solicitud tiene referencias para las extensiones de registro de actividad relevantes.

Las implicaciones son que durante una resincronización activa, la exclusividad mutua de la resincronización frente a la E/S de la aplicación no está garantizada. Y un posible fallo en este punto podría no darse cuenta de que estas extensiones podrían haber sido objetivo de E/S en curso y necesitarían ser resincronizadas por si acaso.

Además, una vez que la solicitud se completa, liberará referencias del registro de actividad que ni siquiera posee, lo que activará un BUG_ON(refcnt == 0) en lc_put().

Solución:

No bloquear el kernel por una condición inofensiva durante el funcionamiento normal: también capturar 'e->refcnt == 0', no solo 'e == NULL' al ser ruidoso sobre 'al_complete_io() called on inactive extent %u\n'.

Y no intentar ser inteligente y "adivinar" si algo funcionará, para luego sorprenderse cuando no lo haga.
Afrontar el hecho de que puede o no funcionar. Si no funciona, recordar un posible estado de 'parcialmente en el registro de actividad' (solo posible para solicitudes que cruzan límites de extensión), y devolver un código de error desde drbd_al_begin_io_nonblock().

Una llamada posterior para la misma solicitud se reanudará desde donde lo dejamos.