GHSA-262G-44PP-38C2
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-05-07 15:31In 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": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:18Z",
"severity": "MODERATE"
},
"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-07T15:31:28Z",
"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": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.