CVE-2026-80900

What it actually does

The Linux kernel ASoC SDCA UMP handler used a size check that could succeed when a message offset already exceeded the destination buffer length. Later processing can therefore access memory outside the intended kernel buffer, producing out-of-bounds read or write, kernel memory corruption, or an oops/panic.

Why it matters to the business

Linux hosts that use SoundWire Device Class Audio hardware can suffer unexpected kernel crashes, audio outages, or loss of the user-to-kernel isolation boundary if memory is corrupted. The issue is not in CISA KEV, is not tied to ransomware, and has no known exploit maturity, so urgency is driven by kernel memory-safety risk on SDCA-equipped systems rather than mass exploitation. Systems without this audio stack are not meaningfully exposed.

How an attack unfolds

An attacker who can reach the SDCA UMP path—typically a local user with access to the relevant ALSA or SoundWire interface, or a malicious SoundWire audio peripheral—supplies a UMP message whose offset is larger than the receive buffer. The defective comparison accepts the message, and the kernel then operates past the buffer. The usual result is a host crash; with additional control over adjacent kernel memory, the same defect could be abused toward privilege escalation. No named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Install a Linux kernel that contains the upstream change titled "ASoC: SDCA: Make UMP message size check more robust," which rejects offsets that exceed the buffer length, then reboot onto that kernel. Exact distribution package versions were not supplied with this record; confirm the commit or an equivalent backport in the vendor advisory or kernel changelog. Until a patched kernel is running, restrict which accounts can open ALSA and SoundWire device nodes and unload unused SDCA-related modules. There is no userspace-only workaround.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory includes the ASoC SDCA UMP size-check refactor. After installing the vendor kernel package, reboot and verify the new kernel version. Inventory whether SDCA or SoundWire audio is present (SDCA-related modules loaded, SoundWire devices in sysfs, ALSA cards bound to ASoC SDCA). After the reboot, confirm the audio path still enumerates expected devices and that kernel logs show no new sound-subsystem oops.

Typical attack path

1. Obtain local access on a Linux host with ASoC SDCA or SoundWire audio support, or present a malicious SoundWire audio device.
2. Reach the kernel SDCA UMP message handling path through the ASoC driver.
3. Submit a UMP message whose offset exceeds the allocated buffer so the incorrect size check accepts it.
4. Cause out-of-bounds kernel memory access during message processing.
5. Produce a denial of service via kernel oops or panic, or attempt to turn resulting memory corruption into elevated privileges.

How to detect it

No public exploit activity or named campaign is documented. To see whether the defect was triggered, search kernel logs and crash dumps for oops or panic records whose call traces mention ASoC SDCA or UMP handling. Sources include dmesg, the systemd journal kernel facility, pstore/ramoops, kdump/vmcore, and vendor crash reporting. Correlate any match with processes that had ALSA or SoundWire device nodes open and with recent SoundWire peripheral attachment. Lack of an SDCA-related oops does not prove the host was unexposed, only that a crashing trigger was not recorded.

• kernel BUG at sound/soc/sdca
• Call Trace:.*sdca
• Oops:.*sdca
• Unable to handle kernel paging request
• ASoC: SDCA

What your security team should do

• Inventory Linux hosts that load ASoC SDCA or SoundWire audio modules and patch those first.
• Deploy the vendor kernel that includes the SDCA UMP size-check fix and reboot.
• Until patched, restrict unprivileged access to ALSA and SoundWire device nodes and unload unused SDCA modules.
• Monitor kernel logs and crash dumps for oops or panic stacks in the ASoC SDCA path.
• Treat this as a standard kernel memory-safety update, not a KEV emergency, but do not defer it on SDCA-equipped systems.