CVE-2026-46262 in Linux
Summary
by MITRE • 06/03/2026
In the Linux kernel, the following vulnerability has been resolved:
ASoC: fsl_xcvr: Revert fix missing lock in fsl_xcvr_mode_put()
This reverts commit f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()").
The original patch attempted to acquire the card->controls_rwsem lock in fsl_xcvr_mode_put(). However, this function is called from the upper ALSA core function snd_ctl_elem_write(), which already holds the write lock on controls_rwsem for the whole put operation. So there is no need to simply hold the lock for fsl_xcvr_activate_ctl() again.
Acquiring the read lock while holding the write lock in the same thread results in a deadlock and a hung task, as reported by Alexander Stein.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/03/2026
The vulnerability in question involves a critical deadlock condition within the Linux kernel's audio subsystem, specifically within the Freescale Xceiver driver component. This issue manifests in the ASoC (Audio Subsystem) framework where the fsl_xcvr_mode_put() function incorrectly attempts to acquire a read lock on the card->controls_rwsem semaphore while already holding a write lock from the upper ALSA core function snd_ctl_elem_write(). The original patch attempt to address a missing lock was fundamentally flawed because it failed to account for the existing locking hierarchy established by the ALSA subsystem itself. This particular function is invoked during control element operations within the ALSA core, which already maintains exclusive write access to the controls_rwsem for the duration of the put operation, making additional locking redundant and harmful.
The technical flaw stems from improper lock ordering and nesting within the kernel's synchronization mechanisms. When the fsl_xcvr_mode_put() function attempts to acquire a read lock while already holding a write lock in the same execution context, it creates a circular dependency that results in immediate deadlock conditions. This type of deadlock occurs because the read lock acquisition fails to complete due to the existing write lock held by the same thread, leading to a hung task that prevents further system operation. The vulnerability directly relates to CWE-362, which describes concurrent execution using shared resource access violations, and more specifically to improper locking patterns within kernel subsystems. The issue demonstrates a classic example of lock inversion where a thread attempting to acquire a lock it already holds creates an impossible state that results in system unresponsiveness.
The operational impact of this vulnerability extends beyond simple system hangs to potentially compromise the entire audio subsystem functionality within Linux systems. When the deadlock occurs, audio devices become unresponsive and may require system reboot to restore normal operation. This affects systems using Freescale-based audio hardware where the fsl_xcvr driver is utilized, potentially impacting embedded systems, automotive infotainment systems, and other devices that rely on specific audio hardware configurations. The vulnerability affects systems running kernel versions that include the problematic commit, making it a widespread concern across various hardware platforms that utilize Freescale audio controllers. The hung task condition prevents further control operations and can cause cascading failures in applications that depend on audio subsystem functionality.
The resolution to this vulnerability involves reverting the problematic patch that introduced the incorrect locking behavior, effectively restoring the original implementation that correctly avoided the double locking scenario. This approach follows established kernel development practices for addressing synchronization issues, where reverting to a working state is preferable to introducing complex fixes that may create additional problems. The fix aligns with ATT&CK framework technique T1490, which covers deletion of system information, as the vulnerability effectively creates a system hang condition that prevents normal operation. System administrators and kernel developers should ensure that affected systems are updated to kernel versions that contain this revert, particularly in production environments where audio subsystem stability is critical. The vulnerability highlights the importance of understanding the complete locking hierarchy in kernel subsystems and the need for careful review of synchronization mechanisms before applying patches that modify locking behavior in complex subsystems like ALSA audio drivers.