CVE-2026-53065

What it actually does

This is a Linux kernel resource-leak flaw in the STMicroelectronics STi ASoC audio driver path. During player initialization, regmap_field objects were allocated without being freed when the driver or device was removed. If the affected driver can be repeatedly initialized and removed, kernel-managed resources may accumulate over time, potentially leading to memory/resource exhaustion and denial of service. The upstream fix changes the allocation to device-managed regmap field allocation so the resources are released automatically with the device lifecycle.

Why it matters to the business

The practical risk is service instability on systems using the affected STi audio driver, especially embedded or appliance-style Linux systems where driver bind/unbind, hotplug, or module lifecycle operations are possible. Successful exploitation would most likely cause degraded performance, failed driver initialization, or a system-level denial of service rather than data theft or privilege escalation. The vulnerability is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, so urgency is lower than actively exploited kernel issues, but affected systems should still receive routine kernel updates.

How an attack unfolds

An attacker would need a way to trigger repeated lifecycle events for the affected STi ASoC driver, such as causing the driver to initialize and then be removed, unbound, or reloaded. Each cycle can leave regmap_field allocations behind because the vulnerable code does not free them on driver removal. Over many cycles, unreleased kernel resources may accumulate until memory pressure or resource exhaustion causes driver failures, degraded system behavior, or a denial of service. Exploitation is most plausible for a local attacker with sufficient permissions to manipulate kernel modules, platform driver binding, or device lifecycle state, or through another management interface that indirectly performs those actions.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the STi ASoC driver resource leak. Where vendor kernels are used, install the distribution, appliance, or SoC vendor kernel package containing the backported change to use device-managed regmap_field allocation for the affected driver. If immediate patching is not possible, reduce exposure by disabling unused STi ASoC audio support, preventing untrusted users or services from loading/unloading kernel modules, restricting access to sysfs driver bind/unbind interfaces, and avoiding automated workflows that repeatedly remove or reinitialize the affected audio device. Because no affected product or fixed package versions were provided, use the relevant Linux distribution or device vendor advisory to identify the exact fixed kernel release.

How to confirm the fix worked

Confirm the running kernel has the vendor fix or contains the upstream change that replaces unmanaged regmap_field_alloc usage in the STi ASoC player initialization path with devm_regmap_field_alloc. Validate package status using the operating system's kernel package manager and vendor security advisory metadata. On source-based or embedded builds, inspect the STi ASoC driver source and confirm device-managed allocation is used for the regmap_field objects. After patching, test normal audio-driver initialization and removal/rebind workflows where applicable, and monitor that repeated lifecycle operations do not cause increasing unreclaimed kernel memory, failed allocations, or driver instability.

Typical attack path

1. Identify a Linux system running a kernel build that includes the vulnerable STi ASoC audio driver code.
2. Gain local administrative, device-management, or equivalent capability to trigger driver removal/rebind, module reload, or device lifecycle events.
3. Repeatedly initialize and remove or unbind the affected STi audio driver/device.
4. Cause regmap_field allocations to leak during each lifecycle cycle.
5. Continue triggering the leak until kernel resources are exhausted or the audio driver/system becomes unstable.
6. Leverage the resulting instability as a denial-of-service condition.

How to detect it

Look for evidence that the affected STi ASoC driver or platform device was repeatedly loaded, removed, bound, or unbound, followed by memory pressure, allocation failures, audio-driver failures, or system instability. Useful sources include kernel logs, system journal logs, audit logs for writes to sysfs driver bind/unbind files, shell history or EDR telemetry showing module-management commands, and monitoring data for rising unreclaimable kernel memory. Since this flaw is a resource leak rather than a code-execution vulnerability, there may be no unique exploit artifact; detection should focus on suspicious repetition of driver lifecycle operations and correlated denial-of-service symptoms. Also review privileged process activity involving modprobe, rmmod, insmod, driverctl, tee, or shell redirection into /sys/bus/platform/drivers/*/bind and /sys/bus/platform/drivers/*/unbind.

• sti-uniperif
• sti_uniperif_player
• ASoC: sti
• /sys/bus/platform/drivers
• /bind
• /unbind
• modprobe
• rmmod
• insmod
• driverctl
• Out of memory
• page allocation failure
• oom-killer
• regmap_field

What your security team should do

• Inventory Linux systems and embedded devices that use STMicroelectronics STi SoC audio drivers or custom kernels including the STi ASoC driver stack.
• Prioritize routine kernel updates for affected systems, especially devices where local users, management agents, containers with elevated privileges, or automation can manipulate kernel modules or sysfs driver binding.
• Restrict privileged operations that can load, unload, bind, or unbind kernel drivers to trusted administrative workflows only.
• Disable the affected audio driver or remove it from custom kernel builds if STi audio functionality is not required.
• Monitor for repeated driver bind/unbind, module reload, or kernel memory-pressure events on systems using the affected driver.
• Because this issue is not in KEV, is not known to be ransomware-used, and has very low EPSS, handle it through standard patch cycles unless the affected driver is exposed to untrusted local control.