CVE-2026-93185

What the bug is

rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

sound/soc/codecs/rt700-sdw.c

What this is

REALTEK AUDIO CODECSMAINTAINERS section matched on sound/soc/codecs/rt* · Maintained

Kernel module

snd_soc_rt700

Check it on the machine

grep -wE 'CONFIG_SND|CONFIG_SND_SOC|CONFIG_SND_SOC_RT700' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w snd_soc_rt700

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

• bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, ppc64el/powerpc64le
• trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
• forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
• bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k

M

a module where it is built at all; some flavours do not build it

Build switches

CONFIG_SND, CONFIG_SND_SOC, CONFIG_SND_SOC_RT700

Reads as

all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-09-17 (31 days ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.21%, higher than 9.9% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

sound/soc

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
5.12	5.15.221	f1e21b7b977f
5.12	6.1.188	b81c2131dbb6
5.12	6.6.157	1bb23c9d6831
5.12	6.12.110	45fcf435ffcc
5.12	6.18.52	1e8fddab6cbe
5.12	7.2.6	a47f087877bb
5.12	7.3	612ccf42acd1

Debian advisories