CVE-2026-72058 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
net: ixp4xx_hss: fix duplicate HDLC netdev allocation
ixp4xx_hss_probe() allocates two HDLC netdevs. The first one is stored in ndev, initialized, and registered with register_hdlc_device(). The second one is stored in port->netdev and later used by the remove path for unregister_hdlc_device() and free_netdev().
This means that the registered netdev is not the same object that is unregistered and freed on remove. It also leaks the first allocation if the second alloc_hdlcdev() call fails, and the first allocation is not checked before ndev is used.
Older code allocated the HDLC netdev only once and stored the same object in both the local variable and port->netdev. The buggy conversion split this into two alloc_hdlcdev() calls. A later rename changed the local variable name to ndev, but the underlying mismatch remained.
Fix this by allocating the HDLC netdev only once and assigning the same object to port->netdev.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides in the ixp4xx_hss network driver within the Linux kernel, specifically addressing a critical issue in HDLC (High-Level Data Link Control) netdev allocation management. This flaw demonstrates a classic double allocation pattern that creates fundamental inconsistencies in device handling and resource management. The problem manifests when the ixp4xx_hss_probe() function executes its initialization routine, where it performs two separate allocations for HDLC netdev objects instead of maintaining a single consistent reference throughout the driver lifecycle.
The technical implementation error stems from a flawed conversion process that split what was originally a single allocation into two distinct calls to alloc_hdlcdev(). The first allocation creates an HDLC netdev object stored in the local variable ndev, which is then initialized and registered with the kernel's HDLC subsystem using register_hdlc_device(). However, the second allocation occurs later in the function and stores the resulting netdev object in port->netdev, which serves as the reference point for cleanup operations during driver removal. This fundamental mismatch between allocation points creates a scenario where different memory objects are registered and subsequently unregistered, leading to undefined behavior and potential system instability.
The operational impact of this vulnerability extends beyond simple resource management issues, creating conditions that could lead to memory corruption and system crashes. When the second alloc_hdlcdev() call fails during driver initialization, the first allocated netdev object becomes orphaned and leaked from the system's memory management framework. This represents a classic memory leak pattern that can accumulate over time and degrade system performance. Additionally, the lack of proper error checking before using ndev means that the system may attempt to operate with an improperly initialized or corrupted network device reference, potentially leading to kernel panics or data corruption during driver operations.
The root cause analysis reveals this issue as a conversion artifact from legacy code where a single allocation pattern was replaced with a flawed two-allocation approach. The original implementation correctly maintained a single netdev object reference stored in both local variables and the port structure, ensuring consistency throughout the device lifecycle. However, the refactoring process introduced a mismatch where the local variable ndev and port->netdev contain different memory addresses pointing to separate netdev objects. This pattern directly violates fundamental kernel development principles for resource management and demonstrates a failure to properly maintain object identity during driver initialization sequences.
Security implications of this vulnerability align with CWE-457, which addresses use of uninitialized variables, and CWE-415, concerning double free errors. The inconsistency between allocated and deallocated objects creates potential attack vectors where malicious actors could exploit the memory management irregularities to execute arbitrary code or cause denial of service conditions. From an ATT&CK framework perspective, this vulnerability maps to T1068 which covers "Exploitation for Privilege Escalation" through kernel-level vulnerabilities, and T1499 which addresses "Endpoint Denial of Service" via resource exhaustion and memory corruption attacks. The fix implemented by allocating the HDLC netdev object only once and assigning the same reference to both port->netdev and maintaining proper initialization sequences resolves these issues by ensuring consistent object identity throughout the driver's operational lifecycle.
Mitigation strategies should focus on implementing comprehensive error checking mechanisms during driver initialization, particularly verifying allocation success before proceeding with registration operations. System administrators should ensure that kernel updates incorporating this fix are deployed promptly, as the vulnerability exists in the core networking subsystem and could be exploited by attackers with local access or through compromised network devices. Additionally, monitoring for memory leak patterns and unexpected device registration failures can help detect potential exploitation attempts. The fix demonstrates proper kernel development practices by maintaining single object references throughout driver operations, eliminating the possibility of inconsistent device state management that could lead to security breaches or system instability.