CVE-2025-71272: Linux Kernel Resource Leak Vulnerability

CVE-2025-71272 Overview

CVE-2025-71272 is a resource leak vulnerability in the Linux kernel's Media Oriented Systems Transport (MOST) core driver. The flaw resides in the most_register_interface() function within the MOST subsystem. When the function fails early — before the device is registered — it returns an error code immediately without releasing the memory allocated for the interface.

The issue has been resolved in upstream Linux kernel commits by initializing the device early via device_initialize() and calling put_device() on all error paths. The fix also switches from device_register() to device_add() to handle the split initialization correctly.

Critical Impact
Repeated invocation of the failing code path can exhaust kernel memory, leading to degraded system stability or denial of service on systems using MOST interface drivers.

Affected Products

Linux kernel (mainline) — MOST core subsystem (drivers/most/core.c)
Linux kernel stable branches prior to the patched commits
Distributions shipping unpatched kernels with the MOST driver enabled

Discovery Timeline

2026-05-06 - CVE-2025-71272 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2025-71272

Vulnerability Analysis

The vulnerability is a memory leak [CWE-401] in the MOST core driver. The most_register_interface() function allocates memory for an interface structure and initializes a device representation. When subsequent setup steps fail before the device is registered, the function returns an error code directly. The previously allocated memory is never freed.

The MOST subsystem provides a transport layer for streaming audio, video, and packet data over MOST networks, commonly used in automotive infotainment systems. The driver's interface registration path performs multiple operations that can fail, including string formatting, attribute group creation, and device addition. Each failure point that occurs before successful registration leaks the interface allocation.

Repeated triggering of the failure conditions — for example, through driver reload cycles or device hotplug scenarios — gradually depletes kernel memory. The leak occurs in kernel address space and cannot be reclaimed without rebooting the system.

Root Cause

The root cause is improper resource management across error branches. The original code used device_register(), which combines device_initialize() and device_add() into a single call. This design left no clean way to release device resources if failures occurred between allocation and registration. Error paths preceding device_register() returned without invoking the appropriate release callback (release_mdev() or dim2_release()), leaving allocated structures orphaned.

Attack Vector

Triggering the leak requires interaction with the MOST driver registration logic. A local attacker or malicious driver caller capable of repeatedly invoking the failing code path could amplify the leak into resource exhaustion. The vulnerability does not provide code execution or privilege escalation primitives; the practical impact is limited to availability degradation on affected systems.

The vulnerability is described in prose only — no public proof-of-concept exploit is available. Refer to the upstream kernel commits for the precise diff and code-level remediation details.

Detection Methods for CVE-2025-71272

Indicators of Compromise

Gradual increase in kernel slab memory consumption visible via /proc/slabinfo or slabtop on systems using MOST drivers.
Repeated kernel log entries from the most subsystem indicating registration failures without corresponding cleanup messages.
Long-running automotive or embedded systems exhibiting memory pressure that correlates with MOST driver activity.

Detection Strategies

Audit installed kernel versions against the patched commit hashes (1f4c9d8a1021, 2f483f3817fb, a49028a796d7, af0b99b2214a) to identify unpatched systems.
Monitor kernel memory growth trends on hosts where the most_core module is loaded.
Use kernel memory leak detection facilities such as kmemleak during testing of MOST-enabled kernels.

Monitoring Recommendations

Collect kernel ring buffer logs (dmesg) and forward them to a centralized logging or SIEM platform for trend analysis.
Track loaded kernel modules across the fleet to inventory systems exposed to the MOST driver.
Alert on unexpected kernel module load or unload events involving most_core, most_cdev, or most_dim2.

How to Mitigate CVE-2025-71272

Immediate Actions Required

Update affected systems to a Linux kernel version containing the upstream fix from the referenced stable commits.
If the MOST subsystem is not required, unload the most_core module and blacklist it to remove the attack surface.
Inventory embedded and automotive Linux deployments where MOST drivers are commonly enabled and prioritize patching.

Patch Information

The fix is available in the following upstream Linux kernel commits: 1f4c9d8a1021, 2f483f3817fb, a49028a796d7, and af0b99b2214a. The patches modify most_register_interface() to call device_initialize() early and to invoke put_device() on every error path, ensuring release_mdev() or dim2_release() runs and frees the allocated interface.

Workarounds

Disable the MOST driver in kernel configuration (CONFIG_MOST=n) when rebuilding kernels for systems that do not use MOST hardware.
Restrict access to driver loading and hotplug interfaces using standard Linux capability and namespace controls.
Schedule periodic reboots on long-running systems where patching is delayed to reclaim leaked kernel memory.

bash

# Verify whether the MOST core module is loaded
lsmod | grep -i most

# Unload MOST modules if not required
sudo modprobe -r most_cdev most_dim2 most_core

# Blacklist the module to prevent automatic loading
echo 'blacklist most_core' | sudo tee /etc/modprobe.d/blacklist-most.conf