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.
668700b40a7c8727bbd2b3fd4fd22e0ce3f1aeb6 builds before 0336bfe9c237476bd7c45605a36ca79c2bca62e5; 668700b40a7c8727bbd2b3fd4fd22e0ce3f1aeb6 builds before 810cd546a29bfac90ed1328ea01d693d4bd11cb1; 668700b40a7c8727bbd2b3fd4fd22e0ce3f1aeb6 builds before 84ef8dd3238330d1795745ece83b19f0295751bf; 668700b40a7c8727bbd2b3fd4fd22e0ce3f1aeb6 builds before 57418de35420cedab035aa1da8a26c0499b7f575; 668700b40a7c8727bbd2b3fd4fd22e0ce3f1aeb6 builds before 9f53b2433ad248cd3342cc345f56f5c7904bd8c4; 668700b40a7c8727bbd2b3fd4fd22e0ce3f1aeb6 builds before 7d483ad300fc0a06f69b019dda8f74970714baf8; 668700b40a7c8727bbd2b3fd4fd22e0ce3f1aeb6 builds before 46e3763dcae0ffcf8fcfaff4fc10a90a92ffdd89; 668700b40a7c8727bbd2b3fd4fd22e0ce3f1aeb6 builds before 3a896498f6f577e57bf26aaa93b48c22b6d20c20; and 1 more ranges
from 4.5 before 5.4.297; from 5.5 before 5.10.241; from 5.11 before 5.15.190; from 5.16 before 6.1.149; from 6.2 before 6.6.103; from 6.7 before 6.12.43; from 6.13 before 6.15.11; from 6.16 before 6.16.2
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.
