[Problem] A data race in snd_ctl_elem_add()

[Takashi Iwai]

On Thu, 15 Apr 2021 03:47:14 +0200,
Gong, Sishuai wrote:
> 
> Hi,
> 
> We found a data race in sound/core/control.c in linux-5.12-rc3 and we are able to reproduce it under x86. 
> In general, we found when 2 kernel threads are both running snd_ctl_elem_add(),
> one may read a stale value of card->user_ctl_count, as shown below.
> 
> Currently, we haven’t found any explicit errors due to this data race, but it looks the reader threads 
> may operate in an inconsistent  state, where card->user_ctl_count + 1 is actually bigger 
> than MAX_USER_CONTROLS, so we want to point it out.
>  
> Thread 1					Thread 2
> //snd_ctl_elem_add()		//snd_ctl_elem_add()
> 						if (card->user_ctl_count + 1 > MAX_USER_CONTROLS)
> 							return -ENOMEM;
> 						
> card->user_ctl_count++;
> unlock:
> up_write(&card->controls_rwsem);
> return err;

Thanks for the report.  Indeed this is a race at read.

OTOH, it's not much serious since this check is only for a sort of
soft-limit to avoid the memory exhaustion.  If any, we can add the
same card->user_ctl_count check just before __snd_ctl_add_replace()
call, but maybe not worth for extra work.

To be noted, the relevant code was already changed significantly for
5.13 (currently in for-next branch), hence the fix I mentioned in the
above won't be applicable.  And, I noticed that a similar problem is
seen there, even worse -- a race may happen at the write side in this
case, which needs a fix.  Will take a deeper look later.


thanks,

Takashi