CVE-2026-23356

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()<br /> <br /> Even though we check that we "should" be able to do lc_get_cumulative()<br /> while holding the device-&gt;al_lock spinlock, it may still fail,<br /> if some other code path decided to do lc_try_lock() with bad timing.<br /> <br /> If that happened, we logged "LOGIC BUG for enr=...",<br /> but still did not return an error.<br /> <br /> The rest of the code now assumed that this request has references<br /> for the relevant activity log extents.<br /> <br /> The implcations are that during an active resync, mutual exclusivity of<br /> resync versus application IO is not guaranteed. And a potential crash<br /> at this point may not realizs that these extents could have been target<br /> of in-flight IO and would need to be resynced just in case.<br /> <br /> Also, once the request completes, it will give up activity log references it<br /> does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().<br /> <br /> Fix:<br /> <br /> Do not crash the kernel for a condition that is harmless during normal<br /> operation: also catch "e-&gt;refcnt == 0", not only "e == NULL"<br /> when being noisy about "al_complete_io() called on inactive extent %u\n".<br /> <br /> And do not try to be smart and "guess" whether something will work, then<br /> be surprised when it does not.<br /> Deal with the fact that it may or may not work. If it does not, remember a<br /> possible "partially in activity log" state (only possible for requests that<br /> cross extent boundaries), and return an error code from<br /> drbd_al_begin_io_nonblock().<br /> <br /> A latter call for the same request will then resume from where we left off.