CVE-2022-50550

blk-iolatency: Fix memory leak on add_disk() failures

State
Published
Severity
Not scored
Published
Oct 7, 2025
Updated
May 11, 2026
Reserved
Oct 7, 2025

Read the record on cve.org

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.

Scores

The record has no CVSS score.

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • d70675121546c35feaceebf7ed9caed8716640f3 to before 2a126e1db5553ce4498290df019866952f858954Affected
  • d70675121546c35feaceebf7ed9caed8716640f3 to before 215f9437dda09531bcb80605298a24219f01cec5Affected
  • d70675121546c35feaceebf7ed9caed8716640f3 to before 813e693023ba10da9e75067780f8378465bf27ccAffected
LinuxLinux
  • 4.19Affected
  • before 4.19Not affected
  • 6.0.17 through 6.0.*Not affected
  • 6.1.2 through 6.1.*Not affected
  • 6.2 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.