GHSA-M9M2-QW72-CJ43
Vulnerability from github – Published: 2026-08-22 18:30 – Updated: 2026-08-25 06:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: FCP: fix OOB write in fcp_meter_ctl_get()
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
{
"affected": [],
"aliases": [
"CVE-2026-74640"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-22T16:16:37Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: FCP: fix OOB write in fcp_meter_ctl_get()\n\nfcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size\nby the driver\u0027s own limit of 255\n\n\tif (map.map_size \u003c 1 || map.map_size \u003e 255 ||\n\t map.meter_slots \u003c 1 || map.meter_slots \u003e 255)\n\t\treturn -EINVAL;\n\nand passes it to fcp_add_new_ctl() as the control\u0027s channel count, where\nit is stored as elem-\u003echannels.\n\nEvery control read writes into struct snd_ctl_elem_value, whose integer\narray is declared long value[128], so the limit is 128, not 255.\nfcp_meter_ctl_get() stores one 64-bit word per channel into that array\nwith no bound of its own:\n\n\tfor (i = 0; i \u003c elem-\u003echannels; i++) {\n\t\tint idx = private-\u003emeter_level_map[i];\n\t\tint value = idx \u003c 0 ? 0 : le32_to_cpu(resp[idx]);\n\n\t\tucontrol-\u003evalue.integer.value[i] = value;\n\t}\n\nsnd_ctl_elem_read_user() serves that object from\nmemdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of\nkmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so\nelement i is written at byte 72 + 8 * i and element 144 already lands\npast the allocation. At map_size 255 the last store ends at byte 2112,\n888 bytes past the object and 64 bytes into the adjacent slab object.\nThe stored words come from the device and meter_level_map[] selects\nwhich word lands in which slot, so extent and contents are both\ncontrolled.\n\nThe core does not catch this. snd_ctl_check_elem_info() is reached only\nfrom __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under\nCONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a\ncompile-time true. __snd_ctl_add_replace() validates kcontrol-\u003ecount and\nnever inspects elem-\u003echannels.\n\nInstalling an oversized map needs CAP_SYS_RAWIO, but the control outlives\nthe hwdep descriptor that created it, so the out-of-bounds stores are\nissued by any process able to read controls on /dev/snd/controlC0.\n\nKASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read:\n\n BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get\n Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185\n __asan_store8\n fcp_meter_ctl_get\n snd_ctl_elem_read\n snd_ctl_ioctl\n Allocated by task 185:\n memdup_user\n snd_ctl_ioctl\n The buggy address is located 0 bytes to the right of\n allocated 1224-byte region [ffff000017af0000, ffff000017af04c8)\n\nBound the map size by the ABI limit rather than by 255, and bound the\nstore loop at the sink so it cannot run past the value array whatever\nelem-\u003echannels holds.\n\nDiscovered by XBOW, triaged by Baul Lee \u003cbaul.lee@xbow.com\u003e",
"id": "GHSA-m9m2-qw72-cj43",
"modified": "2026-08-25T06:31:24Z",
"published": "2026-08-22T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74640"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/620f1e52a46f604635efd0fb78138afd6a513b5d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb30e35c36ed00f24fa39aded811f64230a913b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb61dc2ae59026f76db26e1909746908bc5b6f31"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.