Re: [PATCH] ASoC: soc-core: reset rtd->num_components after allocation

[Kees Cook <kees@kernel.org>]

On Wed, Nov 11, 2026 at 11:28:52AM +0100, Emanuele Ghidoli wrote:
> 
> 
> On 11/11/26 06:59, Kees Cook wrote:
> > 
> > 
> > On November 10, 2026 9:50:08 PM PST, Kees Cook <kees@kernel.org> wrote:
> > 
> > For example, what keeps snd_soc_rtd_add_component() from overflowing
> > that array? If you want to protect the array, add another member,
> > say max_component, and use that for the counter, which gets set at
> > allocation time and protects the array from indexing beyond the actual
> > allocation size.
> 
> Hello Kees,
> 
> Mark has already applied the fix to for-7.4 (d00ba321499c). I agree that
> your proposal is far better, but the applied patch was meant as the
> minimal change to fix the regression.

Yes, totally correct. :) I was just looking at it from a root-cause
perspective. Each time we hit issues with counted_by I try to understand
what the problem was, since the goal is to make it "easy to use". :P

> On your question about what keeps snd_soc_rtd_add_component() from
> overflowing the array: nothing, and it already seems possible today.
> 
> From an LLM-assisted review of the code: the platform loop in
> snd_soc_add_pcm_runtime() adds every component that matches the platform
> dai_link_component, while components[] has one entry per
> platform. On mt8173, for example, the AFE registers three components on the
> same device and the front-end links use it as platform, so four components go
> into three entries. The extra store has gone unnoticed in the slab slack, but
> with max_components as the counter UBSAN_BOUNDS would report it.
> 
> I can't work on a follow-up. If someone picks it up, components[] probably
> needs to be sized by the matching components before the counter is switched to
> max_components.

Yeah, I think we need some better documentation about best practices for
counted_by, as there is clearly 2 very distinct cases it's getting
applied to, and the "usage count" case is the most fragile.

-- 
Kees Cook