CVE-2022-49808 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: don't leak tagger-owned storage on switch driver unbind
In the initial commit dc452a471dba ("net: dsa: introduce tagger-owned storage for private and shared data"), we had a call to tag_ops->disconnect(dst) issued from dsa_tree_free(), which is called at tree teardown time.
There were problems with connecting to a switch tree as a whole, so this got reworked to connecting to individual switches within the tree. In this process, tag_ops->disconnect(ds) was made to be called only from switch.c (cross-chip notifiers emitted as a result of dynamic tag proto changes), but the normal driver teardown code path wasn't replaced with anything.
Solve this problem by adding a function that does the opposite of dsa_switch_setup_tag_protocol(), which is called from the equivalent spot in dsa_switch_teardown(). The positioning here also ensures that we won't have any use-after-free in tagging protocol (*rcv) ops, since the teardown sequence is as follows:
dsa_tree_teardown -> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler -> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many() -> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/07/2025
The vulnerability described in CVE-2022-49808 represents a memory management issue within the Linux kernel's Distributed Switch Architecture (DSA) subsystem that occurs during switch driver unbinding operations. This flaw specifically affects the handling of tagger-owned storage, which is used to maintain private and shared data structures associated with different tagging protocols in DSA switch configurations. The issue stems from an incomplete implementation of the teardown sequence for DSA switch drivers, where the cleanup of resources allocated during the initialization phase was not properly executed when drivers are unbound from switch devices.
The technical root cause of this vulnerability lies in the improper handling of memory cleanup during the DSA switch driver teardown process. Initially, the kernel implemented a mechanism where tag_ops->disconnect() was called from dsa_tree_free() during tree teardown operations. However, as the DSA subsystem evolved to support connecting to individual switches within a tree rather than entire switch trees, the disconnect mechanism was restructured. While the dynamic tag protocol change handling was updated to call tag_ops->disconnect() from switch.c, the standard driver teardown code path was left incomplete, resulting in memory leaks of tagger-owned storage that had been allocated during the setup phase.
This memory leak represents a classic use-after-free vulnerability pattern that can lead to various security implications and system instability. When DSA switch drivers are unbound from the system, the tagger-owned storage that was allocated during the dsa_switch_setup_tag_protocol() function call is not properly freed during the dsa_switch_teardown() sequence. The vulnerability manifests as a resource leak that can accumulate over time, potentially leading to denial of service conditions or memory exhaustion scenarios that could affect network functionality and system stability.
The fix implemented addresses this issue by introducing a complementary function to dsa_switch_setup_tag_protocol() that performs the reverse operation during teardown. This new function is called from the appropriate location within the dsa_switch_teardown() function, ensuring that all tagger-owned storage is properly freed before the switch driver unbinding process completes. The solution follows a carefully orchestrated teardown sequence that prevents use-after-free conditions by ensuring proper ordering of operations, including the unsetting of master pointers, unregistering of network devices with synchronization, and finally the freeing of tagger-owned storage.
This vulnerability aligns with CWE-415 and CWE-416 categories related to double free and use-after-free conditions in memory management, while also demonstrating characteristics consistent with ATT&CK technique T1499.004 related to network denial of service. The fix ensures proper resource management by maintaining the principle of balanced allocation and deallocation, which is fundamental to secure kernel programming practices. The implementation follows established kernel memory management patterns and ensures that all resources allocated during the switch setup phase are properly cleaned up during the teardown phase, preventing the accumulation of leaked memory that could impact system performance or availability.