CVE-2022-49926
—In the Linux kernel, the following vulnerability has been resolved: net: dsa: Fix possible memory leaks in dsa_loop_init() kmemleak reported memory leaks in dsa_loop_init(): kmemleak: 12 new suspected memory leaks unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [ ] kmalloc_trace+0x26/0x60 [ ] phy_device_create+0x5d/0x970 [ ] get_phy_device+0xf3/0x2b0 [ ] __fixed_phy_register.part.0+0x92/0x4e0 [ ] fixed_phy_register+0x84/0xb0 [ ] dsa_loop_init+0xa9/0x116 [dsa_loop] ... There are two reasons for memleak in dsa_loop_init(). First, fixed_phy_register() create and register phy_device: fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove() But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked. Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs. Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.
- Vendors
- linux
- Products
- linux kernel
- Weakness
- CWE-401
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.