CVE-2026-53128: Linux Kernel DRBD RCU Lock Imbalance Denial of Service

Technical summary

The vulnerability exists in the DRBD kernel module's administrative device enumeration function. RCU is a Linux kernel synchronization mechanism that allows readers to access data structures without holding locks, with write-side updates deferred until all existing RCU critical sections complete. The drbd_adm_dump_devices() function violates RCU semantics by calling rcu_read_unlock() without first acquiring the RCU read-side lock via rcu_read_lock(). This creates an unbalanced lock-unlock pair that can cause the kernel's RCU state tracking to become corrupted, potentially triggering warnings, panics, or unpredictable kernel behavior. The fix involves ensuring rcu_read_lock() is invoked before any corresponding rcu_read_unlock() call within the function's execution path.

Business impact

This vulnerability primarily affects system availability rather than confidentiality or integrity. Exploitation can result in kernel crashes or hangs, disrupting services that depend on DRBD for block device replication—commonly used in high-availability storage and database clusters. Organizations relying on DRBD for failover or replication may experience unexpected downtime if the vulnerable code path is triggered during administrative operations. The impact is localized to systems actively using DRBD and will typically require a reboot to recover from a kernel panic.

Affected systems

Linux systems with the DRBD kernel module compiled and in use. DRBD is primarily deployed in enterprise storage, clustering, and high-availability database environments. The vulnerability affects the kernel subsystem rather than user-space utilities, so it impacts any Linux distribution that includes DRBD support (including mainline kernel builds, enterprise distributions, and custom kernels). The vulnerability requires local access to trigger, as it involves an administrative device dump operation.

Exploitability

Exploitation requires local access to the affected system and the ability to invoke the drbd_adm_dump_devices() function, typically through administrative interfaces or ioctl calls. No remote exploitation path exists. The attack surface is limited to local users with permissions to interact with DRBD administrative interfaces. Triggering the vulnerability does not require special privileges beyond those needed to query DRBD device status, making it accessible to any local user with DRBD monitoring or management capabilities. However, the actual impact (kernel instability) may require repeated or sustained triggering to manifest as a denial of service.

Remediation

Apply a kernel patch that restores proper RCU lock balancing in drbd_adm_dump_devices(). This requires updating to a patched kernel version from your distribution or the upstream Linux project. Verify the specific patched kernel version against your vendor's advisory, as version numbers vary across distributions. For systems where immediate patching is not feasible, restrict local access to DRBD administrative interfaces and monitor kernel logs for RCU-related warnings that may indicate exploitation attempts.

Patch guidance

Obtain and apply the kernel update from your Linux distribution's security advisory or the upstream Linux kernel project. The fix is a surgical addition of rcu_read_lock() in the drbd_adm_dump_devices() function to balance the existing rcu_read_unlock() call. Most distributions will backport this fix to supported stable kernel branches. Verify the patched kernel version against your vendor's advisory before applying. After patching, validate that DRBD administrative operations (device enumeration, status queries) function normally and monitor for any related warnings in kernel logs.

Detection guidance

Monitor kernel logs (via dmesg, journalctl, or syslog) for RCU-related warnings such as 'RCU detected stall' or 'RCU read-side critical section' imbalance messages. These warnings typically precede a crash or hang when the vulnerability is triggered. Correlate kernel warnings with invocations of DRBD administrative commands or monitoring tools that call the affected function. On systems using DRBD, audit which local users have permissions to query device status and monitor their activity for repeated calls to DRBD administrative interfaces. Kernel integrity monitoring or SELinux/AppArmor policies can restrict access to sensitive DRBD administrative operations.

Why prioritize this

Although the CVSS score is moderate (5.5), prioritize patching systems where DRBD is actively deployed for mission-critical storage or database replication. The local-only attack vector reduces immediate risk in well-controlled environments, but the availability impact can be severe for dependent applications. Prioritize systems in high-availability clusters or failover configurations where a kernel panic triggers unplanned failovers. Systems without active DRBD use can be deprioritized, but kernel patching cadence should include this fix to prevent future risk if DRBD is enabled.

Risk score, explained

The CVSS 3.1 score of 5.5 reflects a medium-severity vulnerability with local attack vector, low complexity, and no requirement for user interaction. The scoring emphasizes the high impact to availability (denial of service via kernel crash) balanced against the requirement for local access and no impact to confidentiality or integrity. The score appropriately captures the threat to system uptime without overstating the broader organizational risk for systems not using DRBD or those with restricted local access policies.

Frequently asked questions