CVE-2026-90068: ASoC: dapm: Fix off-by-one check on the second enum channel
In the Linux kernel, the following vulnerability has been resolved:
ASoC: dapm: Fix off-by-one check on the second enum channel
The sndsocdapmputenumdouble() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to sndsocenumitemtoval(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end.
The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used = there, and the sndsocputenumdouble() in soc-ops.c still does.
Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80xmuxvalues. The core catches that only under CONFIGSNDCTLINPUTVALIDATION, which defaults off.
Affected Software
Event History
Frequently Asked Questions
Which systems are realistically exposed to this out-of-bounds read?
The described affected case is the adav80x control, which combines a value table with two shifts and reports two values. The issue is reachable when the second enum-channel item is set equal to the enum item count; the example given is writing three, which reads past adav80x_mux_values.
Does the default kernel configuration detect the invalid value?
No. The core catches the condition only when CONFIG_SND_CTL_INPUT_VALIDATION is enabled, and that option defaults to off.
What input is required to trigger the issue?
An entity able to write the affected ALSA control must supply an out-of-range value for the second enum channel that is equal to e->items. That value then reaches snd_soc_enum_item_to_val(), which indexes the value table without its own bounds check.