CVE-2025-38708
drbd: add missing kref_get in handle_write_conflicts
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.
INFO
Published Date :
Sept. 4, 2025, 4:15 p.m.
Last Modified :
Sept. 5, 2025, 5:47 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Solution
- Update the Linux kernel.
- Reboot the system.
- Verify the patch installation.
- Monitor system stability.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2025-38708.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2025-38708 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2025-38708
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2025-38708 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2025-38708 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Sep. 04, 2025
Action Type Old Value New Value Added 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. Added Reference https://git.kernel.org/stable/c/00c9c9628b49e368d140cfa61d7df9b8922ec2a8 Added Reference https://git.kernel.org/stable/c/0336bfe9c237476bd7c45605a36ca79c2bca62e5 Added Reference https://git.kernel.org/stable/c/3a896498f6f577e57bf26aaa93b48c22b6d20c20 Added Reference https://git.kernel.org/stable/c/46e3763dcae0ffcf8fcfaff4fc10a90a92ffdd89 Added Reference https://git.kernel.org/stable/c/57418de35420cedab035aa1da8a26c0499b7f575 Added Reference https://git.kernel.org/stable/c/7d483ad300fc0a06f69b019dda8f74970714baf8 Added Reference https://git.kernel.org/stable/c/810cd546a29bfac90ed1328ea01d693d4bd11cb1 Added Reference https://git.kernel.org/stable/c/84ef8dd3238330d1795745ece83b19f0295751bf Added Reference https://git.kernel.org/stable/c/9f53b2433ad248cd3342cc345f56f5c7904bd8c4