CVE-2022-50550 blk-iolatency: Fix memory leak on add_disk() failures
A memory leak in the Linux kernel's blk-iolatency module during disk initialization failures can lead to resource exhaustion and denial of service.
- Exploited in the wild
- Not known
- Login needed
- Any signed-in user
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2022-50550?
CVE-2022-50550 is a medium-severity memory corruption vulnerability in Linux kernel, published on 7 Oct 2025. It can only be exploited from the same machine or local network, with no action from the victim.
Official description
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.
Weakness: CWE-401
Which versions are affected by CVE-2022-50550?
It affects 1 product.
Products include Linux kernel.
How do I fix CVE-2022-50550?
Apply the vendor's patch.
Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.
Is CVE-2022-50550 being exploited?
There is no known exploitation of CVE-2022-50550 in the wild and no public exploit code.
Other vulnerabilities in Linux kernel
Sources
Also known as AZL-76628, DEBIAN-CVE-2022-50550, GHSA-rv3q-w2vv-wgf5, ROOT-OS-DEBIAN-11-CVE-2022-50550, ROOT-OS-UBUNTU-2204-CVE-2022-50550, UBUNTU-CVE-2022-50550.