CVE-2026-90219 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cxgb4: Free debugfs on registration failure
c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev.
Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel driver for Chelsio T6 RDMA adapters, specifically within the cxgb4 subsystem, contained a resource management flaw related to the lifecycle of debug filesystem entries. During the initialization phase, the function c4iw_alloc invokes setup_debugfs to create a per-device directory structure under dev->debugfs_root. This mechanism is intended for debugging and diagnostic purposes during development or troubleshooting phases. However, the cleanup logic was improperly distributed across two distinct functions: c4iw_remove and c4iw_dealloc. The removal of these debug filesystem entries via debugfs_remove_recursive was exclusively implemented in c4iw_remove, which serves as the standard teardown routine when a device is successfully registered and subsequently removed from the system.
The vulnerability arises during error handling paths within the RDMA device registration process. When the kernel attempts to register an RDMA device, it may encounter failures at various stages of initialization or configuration validation. In such scenarios, the execution flow diverts to an error handler path labeled err_dealloc_ctx, which directly invokes c4iw_dealloc to release allocated resources and free memory associated with the context structure. Because this specific code path bypasses the standard removal routine c4iw_remove, the corresponding debugfs directory entries are never deleted. This creates a scenario where the kernel frees the underlying device data structures while leaving behind dangling pointers or references within the virtual filesystem hierarchy maintained by the kernel's debugfs subsystem.
This oversight results in a resource leak that persists beyond the lifetime of the associated driver context. While typically classified as a memory or file descriptor leak, this specific instance involves the leakage of dentries and inode objects managed by the VFS layer for debug files. Over time, particularly on systems where devices are frequently added and removed during testing or dynamic configuration changes, these unreleased resources can accumulate. Although immediate exploitation leading to arbitrary code execution is unlikely due to the nature of debugfs entries being non-executable metadata structures, the accumulation of leaked kernel objects contributes to memory pressure and potential instability in long-running environments. Furthermore, accessing stale dentries could theoretically lead to use-after-free conditions if other subsystems attempt to interact with filesystem nodes that reference freed memory regions, although modern VFS protections often mitigate direct exploitation risks for this specific class of bug.
From a vulnerability classification perspective, this issue aligns with CWE-401, which describes a missing release of memory after effective allocation, and more specifically relates to improper resource cleanup during error handling paths. In the context of the MITRE ATT&CK framework, while not an attack technique itself, such flaws are often leveraged in post-exploitation scenarios for persistence or denial-of-service through resource exhaustion if an attacker can trigger repeated registration failures. The root cause is a logical flaw in the driver's state machine and error handling architecture, where cleanup responsibilities were not uniformly assigned to all exit paths that deallocate device contexts.
To mitigate this vulnerability, the patch moves the call to debugfs_remove_recursive into c4iw_dealloc. This ensures that regardless of whether the device registration succeeds or fails, any path that results in the freeing of the context structure will also properly dismantle its associated debug filesystem tree. Developers should audit similar drivers for consistent resource cleanup across all error paths and success paths. Best practices dictate that every allocation must have a corresponding deallocation on every possible exit branch from the function performing the allocation. Additionally, utilizing kernel debugging tools like kmemleak can help identify such leaks during development phases before they reach production environments. System administrators relying on stable RDMA configurations should ensure their kernels are updated to include this fix to maintain system integrity and prevent potential resource exhaustion issues over extended operational periods.