CVE-2026-43257

What it actually does

This is a local denial-of-service flaw in the Linux kernel cx88 media/ALSA driver. In the snd_cx88_hw_params() error path, DMA resources allocated by cx88_alsa_dma_map() were not released before returning. A local user with the ability to interact with the affected cx88 audio/video capture device can repeatedly trigger the failing path and cause DMA/IOMMU or related kernel resource leakage. Over time this can degrade system stability, exhaust resources, or cause a kernel-level availability impact. The flaw does not provide confidentiality or integrity impact and is not remotely exploitable under the published CVSS vector.

Why it matters to the business

Systems using affected Linux kernels with cx88-based media capture hardware or the cx88 ALSA driver enabled may be susceptible to local crashes, hangs, or service interruption. The main operational risk is loss of availability for affected hosts, especially where these systems support media capture, monitoring, broadcast, embedded, kiosk, or appliance workloads. Exploitation requires local privileges and specific driver exposure, and EPSS is very low with no known CISA KEV listing, so broad internet-scale exploitation is unlikely; however, untrusted local users or multi-user systems should still prioritize patching.

How an attack unfolds

An attacker first needs local access to a Linux system where the affected kernel and cx88 ALSA/media driver are present and accessible. The attacker then interacts with the cx88 audio device interface in a way that invokes snd_cx88_hw_params() and intentionally drives it into the error path after DMA mapping has occurred. Because the vulnerable error handling omits the matching unmap operation, each failed attempt can leave kernel-managed DMA resources allocated. By repeating the operation, the attacker can progressively consume resources until the kernel, driver, audio subsystem, or broader host becomes unstable or unavailable. There is no indication from the provided data that this vulnerability enables remote code execution, privilege escalation, data theft, or ransomware activity.

How to fix it

Update the Linux kernel to a vendor-supported version that includes the upstream fix adding cx88_alsa_dma_unmap() in the snd_cx88_hw_params() error path. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, or kernel maintainer. If immediate patching is not possible, reduce exposure by unloading or blacklisting the cx88/cx88-alsa driver where it is not required, restricting local access to media/audio device nodes, limiting untrusted shell access, and monitoring systems where cx88 hardware is in use. Reboot into the patched kernel after installation; merely installing a kernel package is insufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed kernel package, is a vendor-fixed build. Check the active kernel with uname -r and compare it against the distribution or vendor advisory for this issue. Confirm whether the cx88-related modules are loaded using lsmod or modinfo and validate that unnecessary modules are disabled or blacklisted. Where source or debug symbols are available, confirm the patched code path calls cx88_alsa_dma_unmap() after cx88_alsa_dma_map() fails later in snd_cx88_hw_params(). Operationally, validate that repeated open/configuration failures against the cx88 ALSA interface no longer cause growing DMA/IOMMU resource consumption, kernel warnings, device lockups, or host instability.

Typical attack path

1. Gain local access to a Linux host with an affected kernel version.
2. Confirm that cx88 media/ALSA driver support is present and the relevant device node is accessible.
3. Open or configure the cx88 ALSA capture/playback interface from user space.
4. Trigger snd_cx88_hw_params() in a way that reaches the vulnerable error path after DMA mapping succeeds.
5. Repeat the failing operation to leak DMA/IOMMU or related kernel resources.
6. Cause degraded performance, device failure, kernel instability, or a denial of service.

How to detect it

To determine whether this was already exploited, focus on local activity and kernel-level resource symptoms rather than network indicators. Review kernel logs, system journal entries, audit logs, and endpoint telemetry for repeated access to cx88-related media or ALSA devices followed by DMA/IOMMU allocation failures, kernel warnings, device resets, out-of-memory behavior, or host hangs. Useful log sources include journalctl -k, /var/log/kern.log, /var/log/messages, auditd records for access to /dev/snd/*, /dev/video*, and /dev/media*, and EDR process telemetry showing local tools repeatedly opening or configuring ALSA/media devices. Correlate suspicious activity with local user sessions, scripts, fuzzing tools, media utilities, or unusual repeated invocations of audio/video configuration commands. There are no known threat actors, ransomware campaigns, public exploit signatures, or network indicators in the provided data.

What your security team should do

• Inventory Linux systems that run media capture workloads or have cx88/cx88-alsa kernel modules available.
• Prioritize patching systems where untrusted or semi-trusted local users can access audio/media device nodes.
• Upgrade to the vendor-fixed kernel and reboot into the patched kernel.
• If cx88 hardware is not required, blacklist or unload the cx88-related modules to remove the vulnerable attack surface.
• Restrict permissions on relevant /dev media, video, and sound devices to trusted users and service accounts only.
• Review kernel and audit logs for repeated cx88, ALSA, DMA, IOMMU, or out-of-memory errors that could indicate attempted resource exhaustion.
• Because this is not KEV-listed, has very low EPSS, and has no known exploit maturity in the provided data, treat it as a targeted local availability risk rather than a broad remote exploitation emergency.