Look up another CVE · open CVE-2026-74640 in the interactive tracker
CVE-2026-74640
ALSA: FCP: fix OOB write in fcp_meter_ctl_get()
Published 2026-08-22 (2 months ago) by the Linux kernel CNA. Subsystem sound/usb. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-74640 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size by the driver's own limit of 255 if (map.map_size < 1 || map.map_size > 255 || map.meter_slots < 1 || map.meter_slots > 255) return -EINVAL; and passes it to fcp_add_new_ctl() as the control's channel count, where it is stored as elem->channels. Every control read writes into struct snd_ctl_elem_value, whose integer array is declared long value[128], so the limit is 128, not 255. fcp_meter_ctl_get() stores one 64-bit word per channel into that array with no bound of its own: for (i = 0; i < elem->channels; i++) { int idx = private->meter_level_map[i]; int value = idx < 0 ? 0 : le32_to_cpu(resp[idx]); ucontrol->value.integer.value[i] = value; } snd_ctl_elem_read_user() serves that object from memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so element i is written at byte 72 + 8 * i and element 144 already lands past the allocation. At map_size 255 the last store ends at byte 2112, 888 bytes past the object and 64 bytes into the adjacent slab object. The stored words come from the device and meter_level_map[] selects which word lands in which slot, so extent and contents are both controlled. The core does not catch this. snd_ctl_check_elem_info() is reached only from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a compile-time true. __snd_ctl_add_replace() validates kcontrol->count and never inspects elem->channels. Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives the hwdep descriptor that created it, so the out-of-bounds stores are issued by any process able to read controls on /dev/snd/controlC0. KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read: BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185 __asan_store8 fcp_meter_ctl_get snd_ctl_elem_read snd_ctl_ioctl Allocated by task 185: memdup_user snd_ctl_ioctl The buggy address is located 0 bytes to the right of allocated 1224-byte region [ffff000017af0000, ffff000017af04c8) Bound the map size by the ABI limit rather than by 255, and bound the store loop at the sink so it cannot run past the value array whatever elem->channels holds. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
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/usb/fcp.c
- What this is
- FOCUSRITE CONTROL PROTOCOL/SCARLETT2 MIXER DRIVERS (Scarlett Gen 2+, Clarett, and Vocaster)MAINTAINERS section matched on sound/usb/fcp.c · linux-sound@vger.kernel.org · Maintained
- Kernel module
- snd_usb_audio
Check it on the machine
grep -wE 'CONFIG_SND|CONFIG_SND_USB_AUDIO' /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_usb_audioPrints 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. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_SND, CONFIG_SND_USB_AUDIO
- 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-08-22 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- sound/usb
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.14 | 6.18.45 | bb30e35c36ed |
| 6.14 | 7.1.9 | bb61dc2ae590 |
| 6.14 | 7.2 | 620f1e52a46f |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Exploitation is triggered by a local process issuing SNDRV_CTL_IOCTL_ELEM_READ on /dev/snd/controlC0, which reaches fcp_meter_ctl_get() via snd_ctl_elem_read_user(); there is no network, Bluetooth, or remote packet path to this code.
- AC:LAttack complexity, low
- After a Level Meter map with map_size above 128 is configured, each control read deterministically performs up to 888 bytes of out-of-bounds 64-bit stores past the kmalloc-2048 buffer; no races or attacker-uncontrollable timing are required.
- PR:LPrivileges required, low
- KASAN reproduced the slab OOB write from an unprivileged control read; snd_ctl_open has no capability check and the Level Meter control persists after hwdep close, so any local user with /dev/snd/controlC0 access can trigger it after normal fcp-server setup.
- UI:NUser interaction, none
- The attacker directly opens /dev/snd/controlC0 and issues the elem-read ioctl themselves; no separate victim action such as opening a file or mounting a filesystem is required.
- S:UScope, unchanged
- Impact is kernel heap corruption and local privilege escalation within the host kernel; it does not cross VM, container, or IOMMU security boundaries.
- C:HConfidentiality impact, high
- Out-of-bounds writes corrupt up to 888 bytes beyond snd_ctl_elem_value into adjacent slab objects; attacker-influenced meter_level_map selects written values, enabling heap grooming and potential arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- Unbounded 64-bit stores past the 128-element value array corrupt adjacent kmalloc-2048 slab data with partially attacker-controlled contents, providing a heap corruption primitive suitable for kernel code or data overwrite.
- A:HAvailability impact, high
- KASAN reported slab-out-of-bounds writes during an unprivileged control read; corrupting adjacent slab objects can cause kernel oops, panic, or hang, confirming high availability impact.