CVE-2026-46262

What it actually does

This is a local denial-of-service flaw in the Linux kernel ASoC Freescale/NXP XCVR audio driver. The vulnerable code path attempts to take an ALSA control read/write semaphore while the ALSA core already holds the same lock for a control write operation. Because the same thread tries to reacquire an incompatible lock, the task can deadlock and remain hung. On affected systems using the fsl_xcvr driver, a local user with access to the relevant ALSA control interface can trigger a kernel hung-task condition, degrading or stopping audio functionality and potentially affecting overall system availability depending on workload and watchdog configuration.

Why it matters to the business

Successful exploitation can cause affected Linux systems to hang or become partially unavailable, requiring service restart, device reboot, or operational intervention. The risk is highest for embedded, edge, appliance, industrial, or multimedia systems based on Freescale/NXP SoCs where the affected audio driver is enabled and local users or processes can access ALSA controls. This is not known to be remotely exploitable, is not listed in CISA KEV, has no known ransomware association, and currently has very low EPSS, so remediation should be prioritized based on exposure of local shell/application users and the operational importance of affected devices.

How an attack unfolds

An attacker first needs local access to an affected Linux system and sufficient permission to interact with ALSA mixer/control devices associated with the fsl_xcvr ASoC driver. The attacker then performs an ALSA control write that reaches snd_ctl_elem_write() and ultimately invokes fsl_xcvr_mode_put(). In the vulnerable kernel, the driver attempts to acquire controls_rwsem even though the ALSA core already holds the write lock for the control update. This causes a self-deadlock: the thread waits indefinitely on a lock it cannot obtain. The kernel may report a hung task, the invoking process may become stuck in uninterruptible sleep, and depending on system policy and watchdog behavior, the host may require a reboot to recover.

How to fix it

Update affected Linux kernels to a vendor-supported build that includes the upstream revert/fix for the ASoC fsl_xcvr locking regression. Because no exact fixed package versions were provided, track the relevant Linux distribution, device vendor, or board support package advisory and apply the first kernel update that references this CVE or the ASoC fsl_xcvr deadlock fix. Where immediate patching is not possible, reduce exposure by disabling or unloading the fsl_xcvr driver if not required, disabling affected audio functionality, limiting membership in groups that can access sound devices, tightening permissions on /dev/snd/controlC*, and preventing untrusted local code from interacting with ALSA controls. For embedded fleets, include the fix in the next firmware or kernel image and stage reboot windows where required.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build by checking the installed kernel package changelog, distribution security advisory, or source tree for the revert of commit f51424872760 or equivalent fsl_xcvr_mode_put() locking fix. Verify whether the affected driver is present or loaded using kernel configuration, module listings, and device tree/platform inventory. Validate that local users without a business need cannot write to ALSA control devices. After patching, exercise normal ALSA control writes for the XCVR device and confirm they complete without hung-task warnings, blocked processes, or lockdep reports. Monitor kernel logs after reboot and during audio-control testing for absence of fsl_xcvr_mode_put(), controls_rwsem, snd_ctl_elem_write(), and hung-task messages.

Typical attack path

1. Gain local execution on a Linux system running an affected kernel with the ASoC fsl_xcvr driver enabled or loaded.
2. Confirm access to ALSA control interfaces, commonly through /dev/snd/controlC* or mixer/control utilities.
3. Issue a write to the affected XCVR mode/control element handled by fsl_xcvr_mode_put().
4. Trigger recursive locking on card->controls_rwsem during the ALSA control write path.
5. Cause the calling task to deadlock and appear as a hung task in kernel logs.
6. Use the resulting hang to disrupt local service availability, audio processing, or device operation.

How to detect it

To determine whether this was already triggered, review kernel logs, persistent journal entries, crash dumps, watchdog reset records, and endpoint telemetry for hung tasks or deadlocks in the ALSA control-write path. Relevant log sources include dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel facility logs, pstore/ramoops after unexpected reboots, kdump/vmcore artifacts, and embedded device watchdog/reset logs. Look for tasks stuck in uninterruptible sleep after ALSA control writes, stack traces containing fsl_xcvr_mode_put(), fsl_xcvr_activate_ctl(), snd_ctl_elem_write(), down_read(), down_write(), or controls_rwsem, and repeated access to /dev/snd/controlC* immediately before the hang. If auditd, eBPF, or EDR telemetry is available, correlate writes or ioctl activity against ALSA control devices with subsequent kernel hung-task reports. There are no known public exploit artifacts or named threat actors associated with this issue, so detection should focus on behavioral evidence of local triggering rather than network indicators.

• fsl_xcvr_mode_put
• fsl_xcvr_activate_ctl
• snd_ctl_elem_write
• controls_rwsem
• INFO: task
• blocked for more than 120 seconds
• hung_task_timeout_secs
• Call Trace:
• /dev/snd/controlC
• D state
• down_read
• down_write
• ASoC: fsl_xcvr
• f51424872760

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and board support packages that use Freescale/NXP ASoC XCVR audio hardware or load the fsl_xcvr driver.
• Prioritize patching systems where untrusted local users, containers, applications, kiosks, or field-service accounts can access ALSA controls.
• Apply vendor kernel or firmware updates that include the ASoC fsl_xcvr deadlock fix; no exact fixed versions were provided, so rely on vendor advisories and package changelogs.
• If patching is delayed, restrict access to /dev/snd/controlC* devices and remove unnecessary users from audio-related groups.
• Disable or unload the fsl_xcvr driver on systems that do not require this audio functionality.
• Add monitoring for kernel hung-task messages and stack traces involving fsl_xcvr_mode_put(), snd_ctl_elem_write(), controls_rwsem, or fsl_xcvr_activate_ctl().
• Treat repeated hung-task events involving this driver as potential abuse or as a stability incident requiring forensic review and kernel update.
• Because the issue is local-only, not KEV-listed, and has very low EPSS, rank it below internet-facing remote-code-execution issues but above routine defects on devices where availability is safety-critical or operationally critical.