ghsa-262g-44pp-38c2
Vulnerability from github
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: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] 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.
{
"affected": [],
"aliases": [
"CVE-2022-49926"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:18Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: Fix possible memory leaks in dsa_loop_init()\n\nkmemleak reported memory leaks in dsa_loop_init():\n\nkmemleak: 12 new suspected memory leaks\n\nunreferenced object 0xffff8880138ce000 (size 2048):\n comm \"modprobe\", pid 390, jiffies 4295040478 (age 238.976s)\n backtrace:\n [\u003c000000006a94f1d5\u003e] kmalloc_trace+0x26/0x60\n [\u003c00000000a9c44622\u003e] phy_device_create+0x5d/0x970\n [\u003c00000000d0ee2afc\u003e] get_phy_device+0xf3/0x2b0\n [\u003c00000000dca0c71f\u003e] __fixed_phy_register.part.0+0x92/0x4e0\n [\u003c000000008a834798\u003e] fixed_phy_register+0x84/0xb0\n [\u003c0000000055223fcb\u003e] dsa_loop_init+0xa9/0x116 [dsa_loop]\n ...\n\nThere are two reasons for memleak in dsa_loop_init().\n\nFirst, fixed_phy_register() create and register phy_device:\n\nfixed_phy_register()\n get_phy_device()\n phy_device_create() # freed by phy_device_free()\n phy_device_register() # freed by phy_device_remove()\n\nBut fixed_phy_unregister() only calls phy_device_remove().\nSo the memory allocated in phy_device_create() is leaked.\n\nSecond, when mdio_driver_register() fail in dsa_loop_init(),\nit just returns and there is no cleanup for phydevs.\n\nFix the problems by catching the error of mdio_driver_register()\nin dsa_loop_init(), then calling both fixed_phy_unregister() and\nphy_device_free() to release phydevs.\nAlso add a function for phydevs cleanup to avoid duplacate.",
"id": "GHSA-262g-44pp-38c2",
"modified": "2025-05-01T15:31:53Z",
"published": "2025-05-01T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49926"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c"
}
],
"schema_version": "1.4.0",
"severity": []
}
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.