CVE-2022-50506
published 2025-10-04CVE-2022-50506: In the Linux kernel, the following vulnerability has been resolved: drbd: only clone bio if we have a backing device Commit c347a787e34cb (drbd: set ->bi_bdev…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.13%
2.8th percentile
In the Linux kernel, the following vulnerability has been resolved:
drbd: only clone bio if we have a backing device
Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a
bio_set_dev call (which has since been removed) to "earlier", from
drbd_request_prepare to drbd_req_new.
The problem is that this accesses device->ldev->backing_bdev, which is
not NULL-checked at this point. When we don't have an ldev (i.e. when
the DRBD device is diskless), this leads to a null pointer deref.
So, only allocate the private_bio if we actually have a disk. This is
also a small optimization, since we don't clone the bio to only to
immediately free it again in the diskless case.
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.6-1 (bookworm) | linux 6.0.6-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= c347a787e34cba0e5a80a04082dacaf259105605 < 05580a3bbf3cec677cb00a85dfeb21d6a9b48eaf | 05580a3bbf3cec677cb00a85dfeb21d6a9b48eaf |
| linux | linux | >= c347a787e34cba0e5a80a04082dacaf259105605 < 6d42ddf7f27b6723549ee6d4c8b1b418b59bf6b5 | 6d42ddf7f27b6723549ee6d4c8b1b418b59bf6b5 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.0.6-1 | 6.0.6-1 |
| linux | linux_kernel | >= 0 < 6.0.6-1 | 6.0.6-1 |
| linux | linux_kernel | >= 0 < 6.0.6-1 | 6.0.6-1 |
| linux | linux_kernel | >= 5.18 < 6.0.6 | 6.0.6 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: drbd: only clone bio if we have a backing device
vendor_redhat·2025-10-04·CVSS 5.5
CVE-2022-50506 [MEDIUM] CWE-476 kernel: drbd: only clone bio if we have a backing device
kernel: drbd: only clone bio if we have a backing device
In the Linux kernel, the following vulnerability has been resolved:
drbd: only clone bio if we have a backing device
Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a
bio_set_dev call (which has since been removed) to "earlier", from
drbd_request_prepare to drbd_req_new.
The problem is that this accesses device->ldev->backing_bdev, which is
not NULL-checked at this point. When we don't have an ldev (i.e. when
the DRBD device is diskless), this leads to a null pointer deref.
So, only allocate the private_bio if we actually have a disk. This is
also a small optimization, since we don't clone the bio to only to
immediately free it again in the diskless case.
A NULL pointer dereference was found in the Linux kernel Dis
Debian
CVE-2022-50506: linux - In the Linux kernel, the following vulnerability has been resolved: drbd: only ...
vendor_debian·2022·CVSS 5.5
CVE-2022-50506 [MEDIUM] CVE-2022-50506: linux - In the Linux kernel, the following vulnerability has been resolved: drbd: only ...
In the Linux kernel, the following vulnerability has been resolved: drbd: only clone bio if we have a backing device Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a bio_set_dev call (which has since been removed) to "earlier", from drbd_request_prepare to drbd_req_new. The problem is that this accesses device->ldev->backing_bdev, which is not NULL-checked at this point. When we don't have an ldev (i.e. when the DRBD device is diskless), this leads to a null pointer deref. So, only allocate the private_bio if we actually have a disk. This is also a small optimization, since we don't clone the bio to only to immediately free it again in the diskless case.
Scope: local
bookworm: resolved (fixed in 6.0.6-1)
bullseye: resolved
forky: resolved (fixed in 6.0.6-1)
sid: resolved
GHSA
GHSA-2p73-743m-m4r5: In the Linux kernel, the following vulnerability has been resolved:
drbd: only clone bio if we have a backing device
Commit c347a787e34cb (drbd: set
ghsa_unreviewed·2025-10-04
CVE-2022-50506 [MEDIUM] CWE-476 GHSA-2p73-743m-m4r5: In the Linux kernel, the following vulnerability has been resolved:
drbd: only clone bio if we have a backing device
Commit c347a787e34cb (drbd: set
In the Linux kernel, the following vulnerability has been resolved:
drbd: only clone bio if we have a backing device
Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a
bio_set_dev call (which has since been removed) to "earlier", from
drbd_request_prepare to drbd_req_new.
The problem is that this accesses device->ldev->backing_bdev, which is
not NULL-checked at this point. When we don't have an ldev (i.e. when
the DRBD device is diskless), this leads to a null pointer deref.
So, only allocate the private_bio if we actually have a disk. This is
also a small optimization, since we don't clone the bio to only to
immediately free it again in the diskless case.
OSV
CVE-2022-50506: In the Linux kernel, the following vulnerability has been resolved: drbd: only clone bio if we have a backing device Commit c347a787e34cb (drbd: set -
osv·2025-10-04·CVSS 5.5
CVE-2022-50506 [MEDIUM] CVE-2022-50506: In the Linux kernel, the following vulnerability has been resolved: drbd: only clone bio if we have a backing device Commit c347a787e34cb (drbd: set -
In the Linux kernel, the following vulnerability has been resolved: drbd: only clone bio if we have a backing device Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a bio_set_dev call (which has since been removed) to "earlier", from drbd_request_prepare to drbd_req_new. The problem is that this accesses device->ldev->backing_bdev, which is not NULL-checked at this point. When we don't have an ldev (i.e. when the DRBD device is diskless), this leads to a null pointer deref. So, only allocate the private_bio if we actually have a disk. This is also a small optimization, since we don't clone the bio to only to immediately free it again in the diskless case.
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2025-10-04
Published