CVE-2026-43135

What it actually does

This is a local Linux kernel driver flaw in the cx23885 media/ALSA path. During snd_cx23885_hw_params(), an error path fails to unmap DMA resources previously acquired by cx23885_alsa_dma_map(). A local user with access to the affected device interface may be able to repeatedly trigger the faulty error path, causing resource leakage and eventual kernel or device instability. The expected impact is denial of service through degraded availability, hangs, crashes, or inability to use the affected media hardware; confidentiality and integrity impact are not indicated by the available description.

Why it matters to the business

Systems using affected Linux kernels with cx23885-based media capture hardware may experience local service disruption or host instability if an unprivileged or low-privileged user can access the device. The risk is most relevant to workstations, media-processing systems, appliance-like Linux deployments, and shared systems where local users or containers can interact with video/audio capture devices. EPSS is very low, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, the issue can still affect availability on exposed local systems.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel and using the cx23885 driver for compatible media hardware. The attacker then interacts with the relevant ALSA/media device interface and forces snd_cx23885_hw_params() into an error condition after DMA mapping has occurred. Because the vulnerable error path omits the corresponding DMA unmap operation, resources are not released correctly. By repeatedly invoking the failing path, the attacker can exhaust or destabilize kernel/device resources, potentially causing audio/video device failure, kernel warnings, system hangs, or a crash. This is not a remote code execution issue and does not provide a direct path to data theft or privilege escalation based on the provided information.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the upstream fix adding cx23885_alsa_dma_unmap() to the snd_cx23885_hw_params() error path. Because no exact fixed package versions were provided, use the latest stable kernel or the latest distribution security kernel for the affected release stream. If immediate patching is not possible, mitigate by disabling or unloading the cx23885 driver where the hardware is not required, restricting local access to media/audio device nodes, and preventing untrusted users or containers from accessing /dev/video*, /dev/media*, /dev/snd/*, or passed-through capture hardware. On systems where cx23885 hardware is not used, blacklist the module as a risk-reduction measure.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release containing the fix for the cx23885 ALSA DMA unmap error path. Validate that the active kernel is the patched version after reboot, not only that the package is installed. Check whether the cx23885 module is loaded with lsmod or equivalent tooling, and verify whether cx23885 hardware is present. If mitigation rather than patching was applied, confirm the module is unloaded or blacklisted and that untrusted users cannot access relevant media and ALSA device nodes. Review kernel logs after validation testing for absence of cx23885-related DMA, ALSA, WARN, Oops, hung task, or device reset messages.

Typical attack path

1. Gain local access to a Linux system with the affected kernel and cx23885-compatible media hardware present.
2. Confirm that the cx23885 media/ALSA driver is loaded and that the attacker can access the relevant device nodes.
3. Invoke audio/media hardware parameter setup through ALSA or media APIs in a way that reaches snd_cx23885_hw_params().
4. Trigger an error condition after cx23885_alsa_dma_map() succeeds.
5. Repeat the operation so the missing cx23885_alsa_dma_unmap() call leaks or leaves DMA-related resources allocated.
6. Cause degradation of the affected device, kernel instability, system hang, or denial of service.

How to detect it

Look for evidence of attempted or successful denial of service in kernel and system logs rather than traditional remote compromise artifacts. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, audit logs for device-node access, and EDR telemetry showing local processes repeatedly opening or configuring media/audio devices. Search for repeated cx23885 driver messages, ALSA hardware-parameter failures, DMA mapping or unmapping errors, kernel WARN/Oops traces, hung task reports, soft lockups, device resets, or unexplained reloading of media drivers. Correlate these events with local user sessions, container workloads with device passthrough, or processes repeatedly accessing /dev/video*, /dev/media*, and /dev/snd/* shortly before instability. There are no public named threat actors, KEV activity, ransomware linkage, or known exploit signatures provided for this issue, so detection should focus on abnormal local interaction with the affected driver and resulting kernel instability.

• cx23885
• snd_cx23885_hw_params
• cx23885_alsa_dma_map
• cx23885_alsa_dma_unmap
• /dev/video
• /dev/media
• /dev/snd/
• kernel: Oops
• kernel: WARNING
• kernel: BUG:
• kernel: hung task
• kernel: soft lockup
• ALSA
• DMA mapping
• DMA-API

What your security team should do

• Inventory Linux systems for loaded cx23885 drivers and compatible media capture hardware; prioritize systems with local multi-user access, kiosk/workstation use, or container/device passthrough.
• Patch affected Linux kernels to the latest vendor-supported fixed release and reboot to activate the updated kernel.
• Where cx23885 hardware is unnecessary, unload and blacklist the cx23885 module to remove exposure.
• Restrict permissions on media and sound device nodes so only trusted users or services can access the affected hardware.
• Review container, virtualization, and sandbox configurations to ensure untrusted workloads are not granted access to /dev/video*, /dev/media*, or /dev/snd/* devices.
• Monitor kernel logs for cx23885, ALSA, DMA mapping, kernel Oops, WARN, hung task, or repeated device-reset messages that may indicate attempted triggering or resulting instability.
• Treat this as a moderate-priority availability issue: EPSS is low and no known exploitation is reported, but local DoS may be operationally significant on media-processing or shared systems.