All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tuo Li <islituo@gmail.com>
To: perex@perex.cz, tiwai@suse.com
Cc: alsa-devel@alsa-project.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	baijiaju1990@outlook.com
Subject: [BUG] ALSA: core: pcm_memory: a possible data race in do_alloc_pages()
Date: Mon, 26 Jun 2023 11:42:29 +0800	[thread overview]
Message-ID: <CADm8Tek6t0WedK+3Y6rbE5YEt19tML8BUL45N2ji4ZAz1KcN_A@mail.gmail.com> (raw)

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>

Best wishes,
Tuo Li

             reply	other threads:[~2023-06-26 11:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26  3:42 Tuo Li [this message]
2023-06-26  7:08 ` [BUG] ALSA: core: pcm_memory: a possible data race in do_alloc_pages() Takashi Iwai
2023-06-26  7:31   ` Tuo Li
2023-06-26  7:33     ` Takashi Iwai
2023-06-26  7:52       ` Tuo Li
2023-06-26  7:56       ` Jaroslav Kysela
2023-06-26 11:02         ` Takashi Iwai
2023-06-26 11:09           ` Jaroslav Kysela
2023-06-26 11:13             ` Takashi Iwai
2023-06-26 13:15               ` Takashi Iwai
2023-06-26 13:32                 ` Jaroslav Kysela
2023-06-26 13:37                   ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADm8Tek6t0WedK+3Y6rbE5YEt19tML8BUL45N2ji4ZAz1KcN_A@mail.gmail.com \
    --to=islituo@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=baijiaju1990@outlook.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.