CVE-2022-49926 in Linux
Summary
by MITRE • 05/01/2025
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability CVE-2022-49926 represents a memory leak issue within the Linux kernel's Distributed Switch Architecture (DSA) subsystem, specifically in the dsa_loop_init() function. This flaw manifests as unreferenced memory allocations that persist in kernel memory, creating potential system instability and resource exhaustion over time. The issue was identified through kmemleak analysis which detected 12 new suspected memory leaks, with one particular allocation of 2048 bytes remaining unreferenced for over 238 seconds, indicating a sustained memory consumption problem that could impact system performance and reliability.
The technical root cause of this vulnerability stems from two distinct memory management failures within the DSA loop initialization process. The first issue occurs when fixed_phy_register() creates and registers phy_device structures through a chain of function calls including phy_device_create() and phy_device_register(). While phy_device_register() is properly cleaned up by phy_device_remove(), the fixed_phy_unregister() function only invokes phy_device_remove() without properly releasing the memory allocated during phy_device_create(), resulting in a memory leak. The second problem arises when mdio_driver_register() fails within dsa_loop_init(), as the function returns without performing proper cleanup of previously allocated phy_device structures, leaving them in an unreferenced state.
This vulnerability directly relates to CWE-401: Improper Release of Memory Before Removing Last Reference, which describes memory leaks occurring when memory is allocated but not properly freed before the reference count reaches zero. The operational impact of this memory leak can be significant in systems running extensive DSA configurations, particularly in network switching environments where multiple DSA loops are initialized. Over time, repeated initialization of DSA loops without proper cleanup can lead to progressive memory consumption, potentially causing system slowdowns, memory exhaustion, or even system crashes under memory pressure conditions.
The fix implemented addresses both memory management issues by adding proper error handling to catch failures in mdio_driver_register() within dsa_loop_init(). When an error occurs, the function now properly calls both fixed_phy_unregister() and phy_device_free() to ensure complete cleanup of phy_device structures. Additionally, a dedicated cleanup function was introduced to prevent duplicate cleanup operations, thereby eliminating the redundant memory management calls that could have occurred in previous implementations. This remediation aligns with ATT&CK technique T1484.001: "Privilege Escalation: Group Policy Modification" through proper resource management, ensuring that kernel memory is properly managed throughout the device initialization lifecycle and preventing potential exploitation through memory exhaustion attacks that could be leveraged by malicious actors with kernel access privileges.