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.
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.
Metrics
Affected Vendors & Products
No data.
No data.
OpenCVE Enrichment is a feature of OpenCVE that uses AI to automatically link vendors and products to CVEs. Learn more on GitHub.
| Vendors | Products |
|---|---|
|
Linux
Subscribe
|
Linux Kernel
Subscribe
|
Advisories
| Source | ID | Title |
|---|---|---|
 Debian DLA |
DLA-4327-1 | linux security update |
| Debian DLA |
DLA-4328-1 | linux-6.1 security update |
 Debian DSA |
DSA-6009-1 | linux security update |
 EUVD |
EUVD-2025-26761 | 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. |
 Ubuntu USN |
USN-7909-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7909-2 | Linux kernel (Real-time) vulnerabilities |
| Ubuntu USN |
USN-7909-3 | Linux kernel (FIPS) vulnerabilities |
| Ubuntu USN |
USN-7910-1 | Linux kernel (Azure FIPS) vulnerabilities |
| Ubuntu USN |
USN-7909-4 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7910-2 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-7909-5 | Linux kernel (Raspberry Pi) vulnerabilities |
| Ubuntu USN |
USN-7933-1 | Linux kernel (KVM) vulnerabilities |
| Ubuntu USN |
USN-7938-1 | Linux kernel (Azure) vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Mon, 03 Nov 2025 18:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Fri, 05 Sep 2025 14:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Linux
Linux linux Kernel |
|
| Vendors & Products |
Linux
Linux linux Kernel |
Fri, 05 Sep 2025 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Thu, 04 Sep 2025 15:45:00 +0000
| Type | Values Removed | Values 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. | |
| Title | drbd: add missing kref_get in handle_write_conflicts | |
| References |
|
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-11-03T17:41:39.261Z
Reserved: 2025-04-16T04:51:24.033Z
Link: CVE-2025-38708
Vulnrichment
No data.
NVD
Status : Awaiting Analysis
Published: 2025-09-04T16:15:39.847
Modified: 2025-11-03T18:16:36.653
Link: CVE-2025-38708
Redhat
OpenCVE Enrichment
Updated: 2025-09-05T14:02:32Z
Weaknesses
No weakness.