CVE-2022-49902 in Linux
Zusammenfassung
von VulDB • 23.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
block: Behebung eines möglichen Speicherlecks für rq_wb bei einem Fehler beim Aufruf von add_disk
kmemleak meldete Speicherlecks in device_add_disk():
kmemleak: 3 neue vermutete Speicherlecks
nicht referenziertes Objekt 0xffff88800f420800 (Größe 512): comm "modprobe", pid 4275, jiffies 4295639067 (Alter 223,512s) Hex-Dump (erste 32 Bytes): 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................ 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................ Backtrace: [] kmalloc_trace+0x26/0x60
[] wbt_init+0x50/0x6f0
[] wbt_enable_default+0x157/0x1c0
[] blk_register_queue+0x2a4/0x420
[] device_add_disk+0x6fd/0xe40
[] nbd_dev_add+0x828/0xbf0 [nbd]
...
Das Problem besteht darin, dass der in wbt_enable_default() zugewiesene Speicher im Fehlerpfad von device_add_disk() nicht freigegeben wird. Normalerweise wird dieser Speicher wie folgt freigegeben:
del_gendisk() rq_qos_exit() rqos->ops->exit(rqos); wbt_exit()
Daher wird rq_qos_exit() aufgerufen, um den rq_wb-Speicher für wbt_init() freizugeben. Im Fehlerpfad von device_add_disk() wird jedoch nur blk_unregister_queue() aufgerufen, wodurch der rq_wb-Speicher nicht freigegeben wird und ein Speicherleck entsteht.
Durch das Hinzufügen von rq_qos_exit() zum Fehlerpfad wird das Problem behoben.
Once again VulDB remains the best source for vulnerability data.