CVE-2022-50545
MEDIUMDescription
In the Linux kernel, the following vulnerability has been resolved: r6040: Fix kmemleak in probe and remove There is a memory leaks reported by kmemleak: unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60 [<ffffffff827e20ee>] phy_device_create+0x4e/0x90 [<ffffffff827e6072>] get_phy_device+0xd2/0x220 [<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0 [<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0 [<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040] ... The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path // error handling path err_out_mdio_unregister: mdiobus_unregister(lp->mii_bus); err_out_mdio: mdiobus_free(lp->mii_bus); <- the reference count of the first phy_device is 1, it is not released and other phy_devices are released // similarly, the remove process also has the same problem The root cause is traced to the phy_device is not disconnected when removes one r6040 device in r6040_remove_one() or on error handling path after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet device is connected to the first PHY device of mii_bus, in order to notify the connected driver when the link status changes, which is the default behavior of the PHY infrastructure to handle everything. Therefore the phy_device should be disconnected when removes one r6040 device or on error handling path. Fix it by adding phy_disconnect() when removes one r6040 device or on error handling path after r6040_mii probed successfully.
How to fix
Remediation is compiled from vendor and distribution security advisories. Always confirm against the linked source for your exact version and platform.
CVSS v3 Vector
Exploitability
Impact
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Exploit Intelligence
Low risk: more likely to be exploited than 10% of all known CVEs.
References
Related Vulnerabilities
Other CWE-401 (Missing Release of Memory (Memory Leak)) vulnerabilities, ordered by exploit likelihood. View all
| CVE | Severity | CVSS | EPSS | Exploited | Fix |
|---|---|---|---|---|---|
| CVE-2020-13934 | High | 7.5 | 64% | - | Fix |
| CVE-2016-6304 | High | 7.5 | 63% | - | Fix |
| CVE-2019-12265 | Medium | 5.3 | 55% | - | Fix |
| CVE-2001-0136 | Medium | 5.0 | 45% | - | - |
| CVE-2016-4232 | High | 7.5 | 36% | - | - |
| CVE-2001-0543 | Medium | 5.0 | 21% | - | - |
Embed a live status badge for CVE-2022-50545
Markdown
[](https://tridentstack.com/cve/CVE-2022-50545)HTML
<a href="https://tridentstack.com/cve/CVE-2022-50545"><img src="https://tridentstack.com/cve/badge/CVE-2022-50545.svg" alt="CVE-2022-50545"></a>Find and fix vulnerabilities across your fleet
TridentStack Control continuously scans your Windows, macOS, and Linux fleet for known vulnerabilities, prioritizes them by severity and active exploitation, and patches them automatically.
Start freeThis product uses NVD data but is not endorsed or certified by the NVD. EPSS scores courtesy of FIRST.org (https://www.first.org/epss). Source: CISA KEV Catalog. Data as of 2026-02-26.