In the Linux kernel, the following vulnerability has been resolved:
ALSA: FCP: fix OOB write in fcpmeterctlget()
fcpioctlsetmetermap() bounds the user-supplied Level Meter map size by the driver's own limit of 255
if (map.mapsize < 1 || map.mapsize > 255 || map.meterslots < 1 || map.meterslots > 255) return -EINVAL;
and passes it to fcpaddnewctl() as the control's channel count, where it is stored as elem->channels.
Every control read writes into struct sndctlelemvalue, whose integer array is declared long value[128], so the limit is 128, not 255. fcpmeterctlget() 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->meterlevelmap[i]; int value = idx < 0 ? 0 : le32tocpu(resp[idx]);
ucontrol->value.integer.value[i] = value; }
sndctlelemreaduser() serves that object from memdupuser(control, sizeof(control)), 1224 bytes on LP64 out of kmalloc-2048. offsetof(struct sndctlelemvalue, value) is 72, so element i is written at byte 72 + 8 i and element 144 already lands past the allocation. At mapsize 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 meterlevelmap[] selects which word lands in which slot, so extent and contents are both controlled.
The core does not catch this. sndctlcheckeleminfo() is reached only from sndctleleminfo(), which sndctlelemread() calls under CONFIGSNDCTLDEBUG; without that option sndctlskipvalidation() is a compile-time true. sndctladdreplace() validates kcontrol->count and never inspects elem->channels.
Installing an oversized map needs CAPSYSRAWIO, 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 fcpmeterctlget Write of size 8 at addr ffff000017af04c8 by task fcptrigger/185 asanstore8 fcpmeterctlget sndctlelemread sndctlioctl Allocated by task 185: memdupuser sndctlioctl 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>