ASoC: SOF: ipc4-topology: Fix shift-out-of-bounds for aggregated ALH capture
Impact
In the Linux kernel, the following vulnerability has been resolved:
Source excerpt · LinuxAffected packages
Affected products
Vendor version evidence. Product records are separate from automatic dependency matching.
Linux · Linux
Other versions: unaffected
| Version / range | Source status |
|---|---|
| 0390a102cc18cb7456d6c1f15ac51f1af90fcf9c to before cad63a7798d6a6cac1fc68732595f0a3278ff6f0 | affected |
| 0390a102cc18cb7456d6c1f15ac51f1af90fcf9c to before 5e1322787c5e424a570e87c8c2c25e37552cbe3b | affected |
| 0390a102cc18cb7456d6c1f15ac51f1af90fcf9c to before 746de48c3a250f0c264105dcbfcdf0c5001e970b | affected |
Linux · Linux
Other versions: affected
| Version / range | Source status |
|---|---|
| 6.3 | affected |
| 0 to before 6.3 | unaffected |
| 6.18.59 through 6.18.* (inclusive) | unaffected |
| 7.2.13 through 7.2.* (inclusive) | unaffected |
| 7.3 through * (inclusive) | unaffected |
Original source description
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc4-topology: Fix shift-out-of-bounds for aggregated ALH capture
When ch_count is smaller than blob->alh_cfg.device_count (e.g. a mono capture stream, such as a SmartMic, aggregated across multiple SDW links), step = ch_count / blob->alh_cfg.device_count truncates to 0. The subsequent GENMASK(step - 1, 0) then underflows step - 1 (u32) to UINT_MAX, causing GENMASK()'s internal shift to use an out-of-bounds exponent:
UBSAN: shift-out-of-bounds in sound/soc/sof/ipc4-topology.c:2363:13 shift exponent 18446744069414584384 is too large for 64-bit type 'long unsigned int'
Treat ch_count < device_count the same way as the existing "channels equal to output reference channels" case: apply the same ch_mask to every aggregated device instead of trying to split channels that can't be evenly divided.