CVE-2026-23356
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
Fraqueza
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
Produtos afetados
- linux linux_kernel
Referências
- https://git.kernel.org/stable/c/7752569fc78e89794ce28946529850282233f99d
- https://git.kernel.org/stable/c/933d161baa3794547adee621c0bf52cbf2c1b3cd
- https://git.kernel.org/stable/c/ab140365fb62c0bdab22b2f516aff563b2559e3b
- https://git.kernel.org/stable/c/cf01aa6288e1190f89865e765056e2a9d8190639
- https://git.kernel.org/stable/c/d1ef3aed4df2ef1fe46befd8f2da9a6ec5445508
- https://git.kernel.org/stable/c/e91d8d6565b7819d13dab21d4dbed5b45efba59b
Encontre a falha antes de um atacante.
Entre com o GitHub e rode sua primeira auditoria em menos de um minuto. O plano gratuito não exige cartão de crédito.