CVE-2026-93122: usb: gadget: uac: validate rate list length before storing
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: uac: validate rate list length before storing
UAC1 and UAC2 configfs rate-list attributes parse a comma-separated list of sampling rates and store each parsed value in fixed-size arrays. The arrays have UACMAXRATES entries, but the store paths do not check that the input contains at most that many tokens before writing through opts->name##s[i++].
Writing more than ten rates therefore writes past the end of the psrates[] or csrates[] array in struct fuac1opts or struct fuac2opts.
With CONFIGUBSANBOUNDS enabled, writing an 11-entry rate list to the UAC1 psrate attribute reports:
UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/fuac1.c:1669:1 index 10 is out of range for type 'int [10]' ubsanhandleoutofbounds.cold fuac1optspsratestore configfswriteiter vfswrite ksyswrite dosyscall64
The same reproducer against the UAC2 psrate attribute reports:
UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/fuac2.c:2087:1 index 10 is out of range for type 'int [10]' ubsanhandleoutofbounds.cold fuac2optspsratestore configfswriteiter vfswrite ksyswrite dosyscall64
Reject additional tokens once UACMAXRATES entries have been parsed. Also keep the original kstrdup() pointer for kfree(), because strsep() advances the parsing cursor. Freeing the advanced cursor leaks the original buffer on successful parses and can free an interior pointer on some error paths.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify/patch the kernel so that UAC1 and UAC2 configfs rate-list attributes (including UAC1 p_srate and UAC2 p_srate) validate the comma-separated token count and stop parsing/reject additional tokens once UAC_MAX_RATES entries have been parsed, preventing array-index-out-of-bounds writes into fixed-size arrays.
Linux kernel USB gadget UAC1/UAC2 configfs rate-list parsing (f_uac1.c, f_uac2.c) UAC1/UAC2 p_srate rate-list token count validation = Reject additional tokens once UAC_MAX_RATES entries have been parsed - Operational
Ensure rate-list parsing uses fixed-size arrays only up to UAC_MAX_RATES tokens; validate behavior with inputs exceeding the maximum (e.g., an 11-entry list when 10 is the maximum) to confirm the parser rejects them rather than writing past the end.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the USB gadget UAC1 or UAC2 configfs functionality are exposed when someone can write sampling-rate list attributes. The affected storage arrays are the playback and capture rate lists, p_srates[] and c_srates[].
What is required to trigger the out-of-bounds write?
An attacker or local user must be able to write a comma-separated sampling-rate list with more than ten entries to a relevant UAC1 or UAC2 configfs rate-list attribute. The eleventh value writes beyond the fixed-size ten-entry array.
What can be done if the resolved change cannot be applied immediately?
Restrict write access to the relevant configfs UAC attributes and ensure rate lists contain no more than ten comma-separated values. Do not allow untrusted users or automation to supply these attribute values without enforcing that limit.
How can this be detected on an affected system?
With CONFIG_UBSAN_BOUNDS enabled, writing an 11-entry list to the UAC1 or UAC2 p_srate attribute produces an array-index-out-of-bounds UBSAN report identifying index 10 for an int[10] array. Existing configuration should also be checked for rate-list values containing more than ten entries.