CVE-2026-89437 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: int1092: Fix potential memory leak in sar_probe()
The memory allocated for device_mode_info in parse_package() called by sar_get_data() is not freed in some of the error paths in sar_probe(). Fix that by converting to use device managed allocations.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/12/2026
The Linux kernel vulnerability identified within the platform/x86 subsystem, specifically affecting the int1092 driver module, centers on a resource management flaw during the initialization phase of hardware probing operations. The core issue resides in the sar_probe function, which is responsible for initializing and setting up the device context when the system detects compatible hardware. During this process, the code invokes sar_get_data to retrieve necessary configuration information from firmware or ACPI tables. This retrieval operation relies on an internal helper function named parse_package, which dynamically allocates memory for a structure known as device_mode_info. While the primary execution path correctly handles cleanup upon successful completion, several error handling paths within sar_probe fail to release this allocated memory before returning an error code to the kernel core.
This oversight constitutes a classic resource leak vulnerability where dynamic memory is acquired but not returned to the system pool under specific failure conditions. In the context of Linux kernel development, such leaks are particularly concerning because they occur in probe functions that may be triggered multiple times during device hot-plug events or driver reloads. Each time an error condition arises within sar_get_data or its subsequent processing steps, a new block of memory is allocated for device_mode_info but remains orphaned due to the missing free call. Over time, particularly on systems with frequent hardware state changes or automated testing environments that trigger repeated probe attempts, these unreleased allocations accumulate in kernel space.
The operational impact of this vulnerability manifests primarily as increased kernel memory consumption without corresponding utility. As the leak persists across multiple initialization failures, it contributes to a gradual degradation of available system resources. In severe cases involving high-frequency error conditions or long-running systems with intermittent hardware issues, this can lead to significant pressure on the kernel slab allocator. While immediate catastrophic failure such as an out-of-memory kill is unlikely for a single driver instance due to the relatively small size of typical ACPI package data structures, the cumulative effect across multiple devices and repeated errors can contribute to overall system instability or reduced performance margins. Furthermore, persistent memory leaks in core subsystems like platform/x86 complicate debugging efforts and obscure other potential issues by masking true resource usage patterns through artificial inflation of allocated memory metrics.
From a standards perspective, this flaw aligns with CWE-401, which describes the missing release of memory after effective allocation. The vulnerability represents an improper cleanup mechanism where error handling paths do not mirror the acquisition logic in terms of resource deallocation. In the context of attack vectors and defensive security frameworks such as MITRE ATT&CK, while this specific leak is primarily a reliability issue rather than a direct exploitation vector for privilege escalation or remote code execution, it falls under broader categories related to system availability impacts. Adversaries with local access could potentially leverage resource exhaustion techniques to degrade service quality on affected systems, although the practical exploitability depends heavily on the frequency of triggerable error conditions and the volume of data involved in each leak instance.
The resolution implemented by converting the allocation strategy to use device managed allocations addresses the root cause by leveraging the kernel's built-in devm_ family of functions. Device-managed resources are automatically released when the associated device is detached or when its driver unbinds, eliminating the need for explicit free calls in every possible error path within the probe function. This approach not only fixes the immediate leak but also improves code robustness by ensuring that resource lifecycle management is tied to the device's existence rather than manual bookkeeping logic. By adopting this pattern, developers reduce the cognitive load required to maintain correct cleanup sequences and minimize the risk of future regressions where new error paths might inadvertently omit necessary deallocation steps.
Mitigation strategies for organizations running affected kernel versions involve applying the upstream patch that introduces these devm_ allocations. For systems unable to immediately update their kernels, monitoring tools such as kmemleak or slabtop can be employed to detect abnormal growth in specific memory caches associated with ACPI parsing structures. Administrators should also review logs for repeated probe failures related to int1092 devices, as frequent errors indicate active exploitation of the leak condition. Long-term remediation requires enforcing static analysis tools and code reviews that specifically check for symmetry between allocation and deallocation calls in driver probe functions, ensuring that error paths are treated with equal rigor regarding resource cleanup as success paths.