Hello,
Thank you for your reply!
Best wishes, Tuo Li
On Mon, Jun 26, 2023 at 3:08 PM Takashi Iwai tiwai@suse.de wrote:
On Mon, 26 Jun 2023 05:42:29 +0200, Tuo Li wrote:
Hello,
Our static analysis tool finds a possible data race in ALSA in Linux
6.4.0.
In some functions, the field snd_card.total_pcm_alloc_bytes is accessed with holding the lock snd_card.memory_mutex. Here is an example:
do_free_pages() --> Line 57 mutex_lock(&card->memory_mutex); --> Line 61 (Lock
card->memory_mutex)
card->total_pcm_alloc_bytes -= dmab->bytes; --> Line 63(Access card->
total_pcm_alloc_bytes)
However, in the function do_alloc_pages():
if (max_alloc_per_card && card->total_pcm_alloc_bytes + size > max_alloc_per_card) --> Line 41
the variable card->total_pcm_alloc_bytes is accessed without holding the lock card->memory_mutex, and thus a data race can occur.
In my opinion, this data race may be harmful, because the value of card->total_pcm_alloc_bytes may be changed by another thread after the if check. Therefore, its value may be too large after Line 51 and can cause memory bugs such as buffer overflow:
card->total_pcm_alloc_bytes += dmab->bytes; --> Line 51
I am not quite sure whether this possible data race is real and how to fix it if it is real.
Any feedback would be appreciated, thanks!
Reported-by: BassCheck bass@buaa.edu.cn
It's a bit racy indeed, but the effect is almost negligible. The size check there is merely a sanity check, and allocating more bytes doesn't mean to conflict against anything practically.
That said, it's a better-to-be-addressed bug, but nothing too serious.
thanks,
Takashi