CVE-2026-90119 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup
snd_ice1712_probe() performs multiple initialization steps after snd_card_new(), but directly returns on failures from later steps without releasing the ALSA card, causing resource leaks when probing fails.
Use snd_devm_card_new() together with scope-based cleanup via __free(snd_card_unref), and clear the card pointer after successful registration to keep it alive.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel's Advanced Linux Sound Architecture (ALSA) subsystem, specifically within the ice1712 sound driver, represents a classic resource management flaw known as a resource leak or memory leak during error handling paths. This issue arises from improper cleanup procedures when the initialization sequence of an audio card fails partway through its setup process. The snd_ice1712_probe function is responsible for initializing hardware components and registering the sound card with the ALSA core. During this multi-step initialization, if a subsequent step encounters an error after the initial allocation via snd_card_new(), the original implementation would return immediately without invoking the necessary deallocation routines for the previously allocated snd_card structure. This oversight results in the kernel retaining references to memory that is no longer accessible or usable by the system, leading to gradual resource exhaustion over time as devices are probed and fail repeatedly.
From a technical perspective, this flaw aligns with CWE-401, which describes missing release of memory after effective usage, and more specifically relates to improper cleanup on error paths within driver code. The root cause lies in the manual management of the card's lifecycle without leveraging modern kernel mechanisms for automatic resource disposal. By directly returning upon failure rather than jumping to a common exit label that handles all necessary cleanups, the driver leaves orphaned objects in memory. This not only wastes system resources but can also lead to stability issues if the leak is severe enough to deplete available kernel memory pools, potentially causing other subsystems or applications to fail due to lack of memory availability.
The operational impact of this vulnerability extends beyond simple resource waste. In environments where hardware probing occurs frequently, such as during hot-plug events or system startup with multiple audio devices, the cumulative effect of these leaks can degrade system performance and reliability. Over extended periods, especially in server or embedded systems that remain online for long durations without rebooting, the accumulation of unreleased snd_card structures contributes to memory fragmentation and increased pressure on the kernel's memory allocator. While a single instance might seem negligible, repeated occurrences across multiple probes can lead to significant degradation in system stability and responsiveness, affecting both local users and remote services dependent on audio functionality.
To mitigate this vulnerability, the fix implements scope-based resource management using snd_devm_card_new() combined with automatic cleanup via __free(snd_card_unref). This approach leverages the kernel's device-managed API framework, which ensures that resources allocated during a probe are automatically released when the device is detached or if an error occurs during initialization. By integrating these mechanisms, the driver guarantees that every allocation has a corresponding deallocation path regardless of how the function exits. Additionally, clearing the card pointer after successful registration prevents accidental double-free scenarios and maintains clear ownership semantics within the kernel's object model. This pattern not only resolves the immediate leak but also improves code maintainability by reducing manual cleanup logic and minimizing the risk of future errors in similar initialization sequences across other drivers.
This remediation strategy reflects broader industry best practices for secure coding in operating system kernels, emphasizing defensive programming techniques that prioritize automatic resource management over manual tracking. It aligns with ATT&CK tactics related to persistence through resource exhaustion if exploited maliciously, although this specific case is primarily a stability and reliability concern rather than an exploitable attack vector for privilege escalation or data exfiltration. Nevertheless, addressing such flaws strengthens the overall security posture of the kernel by reducing its attack surface and improving resilience against denial-of-service conditions caused by internal software defects.