CVE-2022-50550
published 2025-10-07CVE-2022-50550: In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix memory leak on add_disk() failures When a gendisk is successfully…
PriorityP417medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.18%
8.2th percentile
In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: Fix memory leak on add_disk() failures
When a gendisk is successfully initialized but add_disk() fails such as when
a loop device has invalid number of minor device numbers specified,
blkcg_init_disk() is called during init and then blkcg_exit_disk() during
error handling. Unfortunately, iolatency gets initialized in the former but
doesn't get cleaned up in the latter.
This is because, in non-error cases, the cleanup is performed by
del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos
policies, iolatency being one of them, can only be activated once the disk
is fully registered and visible. That assumption is true for wbt and iocost,
but not so for iolatency as it gets initialized before add_disk() is called.
It is desirable to lazy-init rq_qos policies because they are optional
features and add to hot path overhead once initialized - each IO has to walk
all the registered rq_qos policies. So, we want to switch iolatency to lazy
init too. However, that's a bigger change. As a fix for the immediate
problem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk().
This is safe because duplicate calls to rq_qos_exit() become noop's.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.4-1 (bookworm) | linux 6.1.4-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= d70675121546c35feaceebf7ed9caed8716640f3 < 2a126e1db5553ce4498290df019866952f858954 | 2a126e1db5553ce4498290df019866952f858954 |
| linux | linux | >= d70675121546c35feaceebf7ed9caed8716640f3 < 215f9437dda09531bcb80605298a24219f01cec5 | 215f9437dda09531bcb80605298a24219f01cec5 |
| linux | linux | >= d70675121546c35feaceebf7ed9caed8716640f3 < 813e693023ba10da9e75067780f8378465bf27cc | 813e693023ba10da9e75067780f8378465bf27cc |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 4.19 < 6.0.17 | 6.0.17 |
| linux | linux_kernel | >= 6.1 < 6.1.2 | 6.1.2 |
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.
VulDB
Linux Kernel up to 6.0.16/6.1.1 add_disk memory leak (EUVD-2025-31985 / WID-SEC-2025-2229)
vuldb·2026-04-20·CVSS 5.5
CVE-2022-50550 [MEDIUM] Linux Kernel up to 6.0.16/6.1.1 add_disk memory leak (EUVD-2025-31985 / WID-SEC-2025-2229)
A vulnerability described as critical has been identified in Linux Kernel up to 6.0.16/6.1.1. Impacted is the function add_disk. The manipulation results in memory leak.
This vulnerability is identified as CVE-2022-50550. The attack can only be performed from the local network. There is not any exploit available.
Upgrading the affected component is recommended.
GHSA
GHSA-rv3q-w2vv-wgf5: In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: Fix memory leak on add_disk() failures
When a gendisk is successf
ghsa_unreviewed·2025-10-07
CVE-2022-50550 [MEDIUM] CWE-401 GHSA-rv3q-w2vv-wgf5: In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: Fix memory leak on add_disk() failures
When a gendisk is successf
In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: Fix memory leak on add_disk() failures
When a gendisk is successfully initialized but add_disk() fails such as when
a loop device has invalid number of minor device numbers specified,
blkcg_init_disk() is called during init and then blkcg_exit_disk() during
error handling. Unfortunately, iolatency gets initialized in the former but
doesn't get cleaned up in the latter.
This is because, in non-error cases, the cleanup is performed by
del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos
policies, iolatency being one of them, can only be activated once the disk
is fully registered and visible. That assumption is true for wbt and iocost,
but not so for iolatency as it gets initialized before
OSV
CVE-2022-50550: In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix memory leak on add_disk() failures When a gendisk is successful
osv·2025-10-07·CVSS 5.5
CVE-2022-50550 [MEDIUM] CVE-2022-50550: In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix memory leak on add_disk() failures When a gendisk is successful
In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix memory leak on add_disk() failures When a gendisk is successfully initialized but add_disk() fails such as when a loop device has invalid number of minor device numbers specified, blkcg_init_disk() is called during init and then blkcg_exit_disk() during error handling. Unfortunately, iolatency gets initialized in the former but doesn't get cleaned up in the latter. This is because, in non-error cases, the cleanup is performed by del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos policies, iolatency being one of them, can only be activated once the disk is fully registered and visible. That assumption is true for wbt and iocost, but not so for iolatency as it gets initialized before add
Red Hat
kernel: blk-iolatency: Fix memory leak on add_disk() failures
vendor_redhat·2025-10-07·CVSS 5.5
CVE-2022-50550 [MEDIUM] CWE-772 kernel: blk-iolatency: Fix memory leak on add_disk() failures
kernel: blk-iolatency: Fix memory leak on add_disk() failures
In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: Fix memory leak on add_disk() failures
When a gendisk is successfully initialized but add_disk() fails such as when
a loop device has invalid number of minor device numbers specified,
blkcg_init_disk() is called during init and then blkcg_exit_disk() during
error handling. Unfortunately, iolatency gets initialized in the former but
doesn't get cleaned up in the latter.
This is because, in non-error cases, the cleanup is performed by
del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos
policies, iolatency being one of them, can only be activated once the disk
is fully registered and visible. That assumption is true for wbt and ioc
Debian
CVE-2022-50550: linux - In the Linux kernel, the following vulnerability has been resolved: blk-iolaten...
vendor_debian·2022·CVSS 5.5
CVE-2022-50550 [MEDIUM] CVE-2022-50550: linux - In the Linux kernel, the following vulnerability has been resolved: blk-iolaten...
In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix memory leak on add_disk() failures When a gendisk is successfully initialized but add_disk() fails such as when a loop device has invalid number of minor device numbers specified, blkcg_init_disk() is called during init and then blkcg_exit_disk() during error handling. Unfortunately, iolatency gets initialized in the former but doesn't get cleaned up in the latter. This is because, in non-error cases, the cleanup is performed by del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos policies, iolatency being one of them, can only be activated once the disk is fully registered and visible. That assumption is true for wbt and iocost, but not so for iolatency as it gets initialized before add
No detection rules found.
No public exploits indexed.
2025-10-07
Published