CVE-2025-38708: drbd: add missing kref_get in handle_write_conflicts
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.
Security readout for executives and security teams
Plain-English summary
A Linux DRBD reference-counting flaw can cause use-after-free and kernel crashes when two primary nodes issue conflicting concurrent writes. The supplied severity is critical, but the kernel description says this path should rarely occur in correctly coordinated production clusters.
Executive priority
Prioritize prompt review of clustered Linux storage, especially two-primary DRBD deployments. Patch confirmed exposures through normal vendor maintenance channels. Emergency disruption is not justified solely by the score when reliable upper-layer write coordination exists, but uncoordinated two-primary systems warrant accelerated remediation.
Technical view
With DRBD two-primaries enabled, handle_write_conflicts omitted a kref_get while processing superseded writes. This can prematurely destroy a DRBD device, leaving code to access freed memory and potentially crashing the kernel. Linux stable commits resolve the missing reference acquisition.
Likely exposure
Exposure is limited to Linux systems using DRBD with two-primaries enabled where both nodes can submit conflicting writes to the same sector. Proper cluster filesystems and virtualization migration controls should prevent that condition. The supplied version data is insufficiently structured to determine exposure from a version number alone.
Exploitation context
The supplied record is not in CISA KEV, and no supplied source reports active exploitation. Triggering requires the unusual concurrent-write conflict path described by the kernel maintainers. Although CVSS is 9.8, real-world exploitability appears substantially constrained by DRBD configuration and upper-layer coordination.
Researcher notes
The defect is a missing reference increment producing premature drbd_destroy_device and use-after-free in conflict handling. The kernel narrative emphasizes crash symptoms and calls the path largely test-only in correctly operated environments. The sources do not establish practical code execution, data corruption outcomes, or active exploitation.
Mitigation direction
Apply the vendor kernel update containing the applicable Linux stable fix.
Inventory DRBD deployments and prioritize systems configured for two-primaries.
Until updated, prevent both nodes from writing concurrently to the same sectors.
Check distribution or appliance vendor guidance before changing clustered storage configurations.
Validation and detection
Confirm whether DRBD is installed, active, and configured with two-primaries.
Map each running kernel build to its vendor advisory or applicable stable fix.
Verify cluster locking or migration controls prevent concurrent writes across nodes.
Review kernel and DRBD logs for crashes or device-destruction symptoms.
Avoid intentionally triggering write conflicts on production storage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-38708 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
2ADP providers
14Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.