VYPR
High severity7.8NVD Advisory· Published Sep 4, 2025· Updated May 12, 2026

CVE-2025-38708

CVE-2025-38708

Description

In the Linux kernel, the following vulnerability has been resolved:

drbd: add missing kref_get in handle_write_conflicts

With two-primaries enabled, DRBD tries to detect "concurrent" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed.

In handling "superseeded" writes, we forgot a kref_get, resulting in a premature drbd_destroy_device and use after free, and further to kernel crashes with symptoms.

Relevance: No one should use DRBD as a random data generator, and apparently all users of "two-primaries" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node.

Which means that other than for "test cases", this code path is never taken in real life.

FYI, in DRBD 9, things are handled differently nowadays. We still detect "write conflicts", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Missing kref_get in DRBD's handle_write_conflicts causes use-after-free in the Linux kernel when two-primaries mode triggers superseeded write handling.

Vulnerability

In the Linux kernel's DRBD (Distributed Replicated Block Device) implementation, the handle_write_conflicts function contains a missing kref_get call when processing "superseeded" writes[1][2]. DRBD, with the two-primaries setting enabled, attempts to detect and handle concurrent writes to the same sector from two nodes to ensure data consistency. The missing reference count increment leads to a premature drbd_destroy_device, resulting in a use-after-free condition that manifests as kernel crashes[3][4].

Exploitation

Exploitation requires the DRBD module to be loaded and configured in two-primaries mode. The vulnerable code path is only exercised when a write conflict is detected and a prior write is superseded[1]. According to the upstream commit message and vendor advisories, this scenario is rarely encountered in real-world deployments because upper layers—such as cluster file systems with distributed lock managers or live-migration setups—prevent concurrent writes to the same sector[1][2]. The vulnerability is therefore primarily a concern for test environments or misconfigured systems.

Impact

An attacker who can trigger the specific write conflict condition can cause a use-after-free, leading to a kernel crash (denial of service). The advisory notes that the affected code path is infrequently hit in production, limiting the practical impact[1][2]. No evidence of active exploitation is provided in the sources.

Mitigation

The fix is to add the missing kref_get call, which has been applied in upstream Linux kernel stable commits[3][4]. Users should update their kernel to a version containing these commits. Siemens security advisories list several industrial products (e.g., SIMATIC S7-1500 family, SIMATIC CN 4100) as affected if they incorporate vulnerable kernel versions[1][2]. The advisory recommends following the remediation steps provided by Siemens for those products. No workaround is described besides applying the patch or avoiding the two-primaries configuration with untrusted input.

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2

Patches

0

No patches discovered yet.

Vulnerability mechanics

AI mechanics synthesis has not run for this CVE yet.

References

13

News mentions

1