CVE-2026-23356

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Mar 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in Linux storage replication code can let local programs cause crashes or allow data writes to happen at the wrong time during backups.

Exploitation: Local Privilege
Attacker needs: Low Privilege
Complexity: Low
Impact: Denial Of Service
Component: OS kernel
Class: Race Condition
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

Race condition in drbd_al_begin_io_nonblock allows lc_get_cumulative to fail after the al_lock check due to concurrent lc_try_lock, causing the code to proceed without activity log references, violating resync vs application IO mutual exclusion and triggering BUG_ON(refcnt == 0) in lc_put.

Why it matters to the business

In DRBD-based storage replication environments, this flaw can lead to kernel crashes, incomplete resyncs, or data inconsistency during active synchronization, impacting availability of replicated volumes and requiring unplanned downtime for recovery.

How an attack unfolds

A local attacker with low privileges triggers timing-dependent concurrent access to the activity log lock from resync and IO paths, causing the nonblock begin function to return without error while holding no references; subsequent completion then hits the refcount assertion or allows overlapping resync and application writes.

How to fix it

Update to a Linux kernel containing the upstream fix for drbd_al_begin_io_nonblock that returns an error on failure and handles e->refcnt == 0 without crashing; rebuild and reboot affected nodes, then verify DRBD resync behavior under load.

How to confirm the fix worked

Confirm the kernel source contains the updated drbd_al_begin_io_nonblock logic that checks refcnt and returns error codes on lock failure; test by exercising concurrent resync and IO workloads and verifying absence of BUG_ON or LOGIC BUG messages in dmesg.

Typical attack path

Obtain local unprivileged access on a system using DRBD
Induce concurrent resync and application IO workloads that race on al_lock and lc_try_lock
Force drbd_al_begin_io_nonblock to take the failure path without returning an error
Trigger al_complete_io or request completion to hit BUG_ON or allow non-exclusive access

How to detect it

Search kernel logs and dmesg for "LOGIC BUG for enr" or "al_complete_io called on inactive extent" strings on systems running DRBD; correlate with resync activity timestamps and application IO bursts.

What your security team should do

Prioritize patching DRBD-enabled kernels within the next maintenance window given the 215-day publication window
Monitor dmesg and kernel logs for "LOGIC BUG" or "al_complete_io called on inactive extent" messages
Limit local user access on storage nodes until patched kernels are deployed

The record

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.

Affected packages

Ecosystem	Package	Introduced	Fixed