CVE-2026-90163 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
smb/server: call ksmbd_proc_cleanup() on module init failure
When a later initializer fails, the unwind chain releases resources created after procfs and then jumps directly to class_unregister(). Returning an error from module_init() leaves the proc tree and its per-CPU counters allocated.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified in the ksmbd server component represents a critical resource management flaw within the module initialization sequence, specifically concerning the handling of failure paths during dynamic loading. This issue stems from an incomplete cleanup procedure when one of the subsequent initializers fails after the proc filesystem structures have already been established. In complex kernel modules like ksmbd, which facilitate Server Message Block protocol operations, multiple subsystems must be initialized in a specific order to ensure proper dependency resolution and resource allocation. When this initialization chain encounters an error at any stage beyond the creation of the procfs entries, the existing unwind mechanism incorrectly assumes that all prior allocations are either irrelevant or already handled by higher-level cleanup routines. Consequently, it bypasses the necessary deallocation steps for the proc tree and its associated per-CPU counters, leading to a state where these kernel objects remain allocated despite the module failing to load successfully.
From a technical perspective, this flaw is categorized under CWE-401, which describes memory leaks that occur when resources are not properly released after they have been used or when an error condition prevents their deallocation. The specific mechanism involves the ksmbd_proc_cleanup function, which is designed to dismantle the procfs interface and release per-CPU data structures associated with it. However, due to a logic gap in the module init failure path, this cleanup routine is never invoked if an initializer fails after the proc tree has been created but before class_unregister() is called. This results in persistent kernel memory leaks that accumulate each time the module is attempted to be loaded and subsequently fails. Over time, particularly on systems where such modules are frequently reloaded or tested during development or troubleshooting phases, these leaked structures can contribute to increased memory pressure and potential instability within the kernel space.
The operational impact of this vulnerability extends beyond simple resource exhaustion. While a single instance may seem negligible, repeated occurrences can degrade system performance by consuming valuable kernel heap memory that could otherwise be allocated for active processes. More critically, in high-throughput environments where ksmbd is actively used to provide file sharing services over SMB protocols, the accumulation of these unreleased per-CPU counters and proc entries can lead to fragmentation issues or trigger out-of-memory conditions within restricted kernel contexts. Furthermore, such inconsistencies in resource lifecycle management often serve as precursors to more severe vulnerabilities, including use-after-free scenarios if subsequent code attempts to interact with partially initialized structures that were not fully torn down during the failed initialization attempt.
To mitigate this risk, developers must ensure that all allocated resources are properly released regardless of which stage of the initialization process fails. The primary remediation involves modifying the error handling logic in the module init function to explicitly call ksmbd_proc_cleanup() before returning an error code or jumping to subsequent cleanup steps like class_unregister(). This ensures a symmetric allocation and deallocation pattern, adhering to best practices for kernel programming where every successful allocation must have a corresponding release path. System administrators should apply available kernel updates that incorporate this fix promptly. Additionally, monitoring tools such as kmemleak can be employed during development or testing phases to detect similar resource management anomalies in other parts of the kernel stack, ensuring comprehensive coverage against memory leak vulnerabilities across all loaded modules.