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 %un.

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.

Weakness

The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.

Affected Software

Extended Description

While assertion is good for catching logic errors and reducing the chances of reaching more serious vulnerability conditions, it can still lead to a denial of service. For example, if a server handles multiple simultaneous connections, and an assert() occurs in one single connection that causes all other connections to be dropped, this is a reachable assertion that leads to a denial of service.

Potential Mitigations

References

• 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
• https://git.kernel.org/stable/c/eef1390125b660b8b61f9f227a03bb9c5e6d36a5
• https://git.kernel.org/stable/c/f558e5404a72054b525dced1a0c66aa95a144153