External risk intelligence

Linux Kernel DRBD Out-of-Range Payload Size Corruption

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-72014

DRBD is a block-level replication protocol typically configured within private storage networks or dedicated back-end infrastructure between server nodes. While it uses network communication, it is rarely exposed to the public internet and is designed to operate within controlled, trusted data center environments.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in the Linux kernel's DRBD component could allow a malicious peer to corrupt kernel memory by sending specially crafted data replies. This could lead to a denial-of-service condition or potentially more severe system compromise if an attacker can overwrite critical memory structures. The issue is present in the default configuration and does not require specific data integrity algorithms to be enabled.

Malicious DRBD peer corrupts kernel memory.
Matters for nodes reading from peers.
Confirm relevance and exposure.

Attack Path

How an attacker could exploit the issue

An attacker can target a system running a vulnerable Linux kernel by sending specially crafted data replies over the DRBD network protocol. This malicious data can cause the kernel to write attacker-controlled bytes beyond the intended buffer, corrupting memory. A node reading data from its peer is particularly at risk, even with default security settings.

Requires network access to a DRBD peer.
Triggered by receiving a malicious data reply.
Results in arbitrary kernel memory corruption.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow a malicious DRBD peer to overwrite kernel memory on a receiving node. This may occur when a node reads data from its peer, and it is exposed even in the default configuration without special integrity algorithms.

Kernel memory corruption.
Malicious peer sends crafted data.
Uncontrolled overwrite of critical data.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability affects DRBD peers involved in data replication. Infrastructure or platform teams managing DRBD deployments are likely responsible for addressing this. The first practical step is to identify all DRBD peers, confirm their network accessibility and criticality, and then coordinate remediation with accountable owners based on observed risk.

Own the issue: Infrastructure/Platform teams.
Verify first: DRBD peer reachability and criticality.
Action: Plan and execute remediation.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Linux kernel DRBD component?

DRBD stands for Distributed Replicated Block Device. It functions as a RAID-1 over network, mirroring the contents of block devices like hard drives or partitions between servers. It is a fundamental component for high-availability clusters and disaster recovery, ensuring that if one server fails, another has an up-to-date copy of the data.

What does CVE-2026-72014 mean for system memory?

This vulnerability involves an integer handling error. When the kernel receives a reply from a DRBD peer, it may incorrectly calculate the payload size. This can lead to a negative size value, causing the system to attempt to write data into memory locations outside of the allocated buffer. This uncontrolled memory access is a form of buffer overflow, which can corrupt critical kernel structures, leading to system crashes or unstable behavior.

How is this DRBD memory corruption triggered?

An attacker needs to act as a malicious or compromised DRBD peer that sends a crafted 'P_DATA_REPLY' network packet to a target node. The bug triggers whenever the target node requests data from the peer. Crucially, this happens even in default configurations without specialized security settings enabled. It is not triggered by standard read-path processes that properly validate block sizes before memory allocation.

Do I need to worry if my DRBD setup is internal?

While Halo Surface Signal identifies the potential for external attack, DRBD is typically used within private, trusted infrastructure. You should assess your risk based on whether your DRBD network segments are accessible to unauthorized users or compromised internal nodes. If your DRBD traffic is isolated to a secure, backend management network, the practical risk is lower than if the interface is reachable by broader network segments.

How should I respond to this kernel vulnerability?

Your first step is to inventory all systems running DRBD to understand your footprint. Focus on identifying nodes configured to perform read operations from peers, as these are directly affected. Once mapped, coordinate with your infrastructure or platform teams to plan for patching the underlying Linux kernel. Monitor internal release channels for kernel updates from your distribution vendor, as these will contain the necessary code to reject out-of-range payload sizes.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.