[PATCH 1/2] ALSA: seq: oss: Fix data-race for max_midi_devs access

[PATCH 1/2] ALSA: seq: oss: Fix data-race for max_midi_devs access

[Takashi Iwai]

ALSA OSS sequencer refers to a global variable max_midi_devs at
creating a new port, storing it to its own field.  Meanwhile this
variable may be changed by other sequencer events at
snd_seq_oss_midi_check_exit_port() in parallel, which may cause a data
race.

OTOH, this data race itself is almost harmless, as the access to the
MIDI device is done via get_mdev() and it's protected with a refcount,
hence its presence is guaranteed.

Though, it's sill better to address the data-race from the code sanity
POV, and this patch adds the proper spinlock for the protection.

Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAEHB2493pZRXs863w58QWnUTtv3HHfg85aYhLn5HJHCwxqtHQg@mail.gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/core/seq/oss/seq_oss_midi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/core/seq/oss/seq_oss_midi.c b/sound/core/seq/oss/seq_oss_midi.c
index 1e3bf086f867..07efb38f58ac 100644
--- a/sound/core/seq/oss/seq_oss_midi.c
+++ b/sound/core/seq/oss/seq_oss_midi.c
@@ -270,7 +270,9 @@ snd_seq_oss_midi_clear_all(void)
 void
 snd_seq_oss_midi_setup(struct seq_oss_devinfo *dp)
 {
+	spin_lock_irq(&register_lock);
 	dp->max_mididev = max_midi_devs;
+	spin_unlock_irq(&register_lock);
 }
 
 /*
-- 
2.35.3

[PATCH 2/2] ALSA: seq: Fix data-race at module auto-loading

[Takashi Iwai]

It's been reported that there is a possible data-race accessing to the
global card_requested[] array at ALSA sequencer core, which is used
for determining whether to call request_module() for the card or not.
This data race itself is almost harmless, as it might end up with one
extra request_module() call for the already loaded module at most.
But it's still better to fix.

This patch addresses the possible data race of card_requested[] and
client_requested[] arrays by replacing them with bitmask.
It's an atomic operation and can work without locks.

Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAEHB24_ay6YzARpA1zgCsE7=H9CSJJzux618E=Ka4h0YdKn=qA@mail.gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/core/seq/seq_clientmgr.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index 2e9d695d336c..052a690b5e11 100644
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -121,13 +121,13 @@ struct snd_seq_client *snd_seq_client_use_ptr(int clientid)
 	spin_unlock_irqrestore(&clients_lock, flags);
 #ifdef CONFIG_MODULES
 	if (!in_interrupt()) {
-		static char client_requested[SNDRV_SEQ_GLOBAL_CLIENTS];
-		static char card_requested[SNDRV_CARDS];
+		static DECLARE_BITMAP(client_requested, SNDRV_SEQ_GLOBAL_CLIENTS);
+		static DECLARE_BITMAP(card_requested, SNDRV_CARDS);
+
 		if (clientid < SNDRV_SEQ_GLOBAL_CLIENTS) {
 			int idx;
 			
-			if (!client_requested[clientid]) {
-				client_requested[clientid] = 1;
+			if (!test_and_set_bit(clientid, client_requested)) {
 				for (idx = 0; idx < 15; idx++) {
 					if (seq_client_load[idx] < 0)
 						break;
@@ -142,10 +142,8 @@ struct snd_seq_client *snd_seq_client_use_ptr(int clientid)
 			int card = (clientid - SNDRV_SEQ_GLOBAL_CLIENTS) /
 				SNDRV_SEQ_CLIENTS_PER_CARD;
 			if (card < snd_ecards_limit) {
-				if (! card_requested[card]) {
-					card_requested[card] = 1;
+				if (!test_and_set_bit(card_requested, card))
 					snd_request_card(card);
-				}
 				snd_seq_device_load_drivers();
 			}
 		}
-- 
2.35.3

Re: [PATCH 2/2] ALSA: seq: Fix data-race at module auto-loading

[Gabriel Ryan]

We have tested this patch and confirm it eliminates the race we initially
reported.

Best,

Gabe

On Tue, Aug 23, 2022 at 3:27 AM Takashi Iwai <tiwai@suse.de> wrote:

> It's been reported that there is a possible data-race accessing to the
> global card_requested[] array at ALSA sequencer core, which is used
> for determining whether to call request_module() for the card or not.
> This data race itself is almost harmless, as it might end up with one
> extra request_module() call for the already loaded module at most.
> But it's still better to fix.
>
> This patch addresses the possible data race of card_requested[] and
> client_requested[] arrays by replacing them with bitmask.
> It's an atomic operation and can work without locks.
>
> Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
> Cc: <stable@vger.kernel.org>
> Link:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_r_CAEHB24-5Fay6YzARpA1zgCsE7-3DH9CSJJzux618E-3DKa4h0YdKn-3DqA-40mail.gmail.com&d=DwIDAg&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=EyAJYRJu01oaAhhVVY3o8zKgZvacDAXd_PNRtaqACCo&m=oPAvNa2pfJuUIAiwbiE1IJgoQhWb8AB7IBdJqWslhhuZ-LwBrrgAnFUthdapQska&s=K26ukWoQce9A8OzoQEGfRXynlOouHQ79dnAnD7xriNw&e=
>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>  sound/core/seq/seq_clientmgr.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/sound/core/seq/seq_clientmgr.c
> b/sound/core/seq/seq_clientmgr.c
> index 2e9d695d336c..052a690b5e11 100644
> --- a/sound/core/seq/seq_clientmgr.c
> +++ b/sound/core/seq/seq_clientmgr.c
> @@ -121,13 +121,13 @@ struct snd_seq_client *snd_seq_client_use_ptr(int
> clientid)
>         spin_unlock_irqrestore(&clients_lock, flags);
>  #ifdef CONFIG_MODULES
>         if (!in_interrupt()) {
> -               static char client_requested[SNDRV_SEQ_GLOBAL_CLIENTS];
> -               static char card_requested[SNDRV_CARDS];
> +               static DECLARE_BITMAP(client_requested,
> SNDRV_SEQ_GLOBAL_CLIENTS);
> +               static DECLARE_BITMAP(card_requested, SNDRV_CARDS);
> +
>                 if (clientid < SNDRV_SEQ_GLOBAL_CLIENTS) {
>                         int idx;
>
> -                       if (!client_requested[clientid]) {
> -                               client_requested[clientid] = 1;
> +                       if (!test_and_set_bit(clientid, client_requested))
> {
>                                 for (idx = 0; idx < 15; idx++) {
>                                         if (seq_client_load[idx] < 0)
>                                                 break;
> @@ -142,10 +142,8 @@ struct snd_seq_client *snd_seq_client_use_ptr(int
> clientid)
>                         int card = (clientid - SNDRV_SEQ_GLOBAL_CLIENTS) /
>                                 SNDRV_SEQ_CLIENTS_PER_CARD;
>                         if (card < snd_ecards_limit) {
> -                               if (! card_requested[card]) {
> -                                       card_requested[card] = 1;
> +                               if (!test_and_set_bit(card_requested,
> card))
>                                         snd_request_card(card);
> -                               }
>                                 snd_seq_device_load_drivers();
>                         }
>                 }
> --
> 2.35.3
>
>

Re: [PATCH 1/2] ALSA: seq: oss: Fix data-race for max_midi_devs access

[Gabriel Ryan]

We have tested this patch and confirm it eliminates the race we observed on
max_mididev.

Best,

Gabe

On Tue, Aug 23, 2022 at 3:27 AM Takashi Iwai <tiwai@suse.de> wrote:

> ALSA OSS sequencer refers to a global variable max_midi_devs at
> creating a new port, storing it to its own field.  Meanwhile this
> variable may be changed by other sequencer events at
> snd_seq_oss_midi_check_exit_port() in parallel, which may cause a data
> race.
>
> OTOH, this data race itself is almost harmless, as the access to the
> MIDI device is done via get_mdev() and it's protected with a refcount,
> hence its presence is guaranteed.
>
> Though, it's sill better to address the data-race from the code sanity
> POV, and this patch adds the proper spinlock for the protection.
>
> Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
> Cc: <stable@vger.kernel.org>
> Link:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_r_CAEHB2493pZRXs863w58QWnUTtv3HHfg85aYhLn5HJHCwxqtHQg-40mail.gmail.com&d=DwIDAg&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=EyAJYRJu01oaAhhVVY3o8zKgZvacDAXd_PNRtaqACCo&m=CxIkVQqIvngOHaCRT98C_jGfJo6SNC38iwxKsCn-3yU1vAYynFqC_nB4PAgPegMm&s=B8XPQtfIHmyV0Z-NAEtd5FG1Indh15kFF_yJWOMLnz4&e=
>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>  sound/core/seq/oss/seq_oss_midi.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/sound/core/seq/oss/seq_oss_midi.c
> b/sound/core/seq/oss/seq_oss_midi.c
> index 1e3bf086f867..07efb38f58ac 100644
> --- a/sound/core/seq/oss/seq_oss_midi.c
> +++ b/sound/core/seq/oss/seq_oss_midi.c
> @@ -270,7 +270,9 @@ snd_seq_oss_midi_clear_all(void)
>  void
>  snd_seq_oss_midi_setup(struct seq_oss_devinfo *dp)
>  {
> +       spin_lock_irq(&register_lock);
>         dp->max_mididev = max_midi_devs;
> +       spin_unlock_irq(&register_lock);
>  }
>
>  /*
> --
> 2.35.3
>
>

Re: [PATCH 2/2] ALSA: seq: Fix data-race at module auto-loading

[Takashi Iwai]

On Tue, 23 Aug 2022 09:27:17 +0200,
Takashi Iwai wrote:
> 
> It's been reported that there is a possible data-race accessing to the
> global card_requested[] array at ALSA sequencer core, which is used
> for determining whether to call request_module() for the card or not.
> This data race itself is almost harmless, as it might end up with one
> extra request_module() call for the already loaded module at most.
> But it's still better to fix.
> 
> This patch addresses the possible data race of card_requested[] and
> client_requested[] arrays by replacing them with bitmask.
> It's an atomic operation and can work without locks.
> 
> Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
> Cc: <stable@vger.kernel.org>
> Link: https://lore.kernel.org/r/CAEHB24_ay6YzARpA1zgCsE7=H9CSJJzux618E=Ka4h0YdKn=qA@mail.gmail.com
> Signed-off-by: Takashi Iwai <tiwai@suse.de>

Gah, there was an obvious type in the patch.
The correct version is below, and I merged it now.


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH v2] ALSA: seq: Fix data-race at module auto-loading

It's been reported that there is a possible data-race accessing to the
global card_requested[] array at ALSA sequencer core, which is used
for determining whether to call request_module() for the card or not.
This data race itself is almost harmless, as it might end up with one
extra request_module() call for the already loaded module at most.
But it's still better to fix.

This patch addresses the possible data race of card_requested[] and
client_requested[] arrays by replacing them with bitmask.
It's an atomic operation and can work without locks.

Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAEHB24_ay6YzARpA1zgCsE7=H9CSJJzux618E=Ka4h0YdKn=qA@mail.gmail.com
Link: https://lore.kernel.org/r/20220823072717.1706-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
v1->v2: fix compile error

 sound/core/seq/seq_clientmgr.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index 2e9d695d336c..2d707afa1ef1 100644
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -121,13 +121,13 @@ struct snd_seq_client *snd_seq_client_use_ptr(int clientid)
 	spin_unlock_irqrestore(&clients_lock, flags);
 #ifdef CONFIG_MODULES
 	if (!in_interrupt()) {
-		static char client_requested[SNDRV_SEQ_GLOBAL_CLIENTS];
-		static char card_requested[SNDRV_CARDS];
+		static DECLARE_BITMAP(client_requested, SNDRV_SEQ_GLOBAL_CLIENTS);
+		static DECLARE_BITMAP(card_requested, SNDRV_CARDS);
+
 		if (clientid < SNDRV_SEQ_GLOBAL_CLIENTS) {
 			int idx;
 			
-			if (!client_requested[clientid]) {
-				client_requested[clientid] = 1;
+			if (!test_and_set_bit(clientid, client_requested)) {
 				for (idx = 0; idx < 15; idx++) {
 					if (seq_client_load[idx] < 0)
 						break;
@@ -142,10 +142,8 @@ struct snd_seq_client *snd_seq_client_use_ptr(int clientid)
 			int card = (clientid - SNDRV_SEQ_GLOBAL_CLIENTS) /
 				SNDRV_SEQ_CLIENTS_PER_CARD;
 			if (card < snd_ecards_limit) {
-				if (! card_requested[card]) {
-					card_requested[card] = 1;
+				if (!test_and_set_bit(card, card_requested))
 					snd_request_card(card);
-				}
 				snd_seq_device_load_drivers();
 			}
 		}
-- 
2.35.3

Re: [PATCH 2/2] ALSA: seq: Fix data-race at module auto-loading

[Gabriel Ryan]

Apologies, I just realized the previous patch raised incompatible
integer conversion warnings on that line during compilation. In the
future I'll keep a closer eye out for relevant warnings when testing.

This patch still eliminates the race we initially reported.

Best,

Gabe

On Wed, Aug 24, 2022 at 2:03 AM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Tue, 23 Aug 2022 09:27:17 +0200,
> Takashi Iwai wrote:
> >
> > It's been reported that there is a possible data-race accessing to the
> > global card_requested[] array at ALSA sequencer core, which is used
> > for determining whether to call request_module() for the card or not.
> > This data race itself is almost harmless, as it might end up with one
> > extra request_module() call for the already loaded module at most.
> > But it's still better to fix.
> >
> > This patch addresses the possible data race of card_requested[] and
> > client_requested[] arrays by replacing them with bitmask.
> > It's an atomic operation and can work without locks.
> >
> > Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
> > Cc: <stable@vger.kernel.org>
> > Link: https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_r_CAEHB24-5Fay6YzARpA1zgCsE7-3DH9CSJJzux618E-3DKa4h0YdKn-3DqA-40mail.gmail.com&d=DwIBAg&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=EyAJYRJu01oaAhhVVY3o8zKgZvacDAXd_PNRtaqACCo&m=5zfWpItqvL3lHhUMgi-DyAe7DauvBjWwe5UaP0CquJh8c8-phq2TFeGOm0TUvrBw&s=lnBmR8icRLp1uw0Gei6AgrBAaoROKuS3p0LfDWHyyD4&e=
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
>
> Gah, there was an obvious type in the patch.
> The correct version is below, and I merged it now.
>
>
> thanks,
>
> Takashi
>
> -- 8< --
> From: Takashi Iwai <tiwai@suse.de>
> Subject: [PATCH v2] ALSA: seq: Fix data-race at module auto-loading
>
> It's been reported that there is a possible data-race accessing to the
> global card_requested[] array at ALSA sequencer core, which is used
> for determining whether to call request_module() for the card or not.
> This data race itself is almost harmless, as it might end up with one
> extra request_module() call for the already loaded module at most.
> But it's still better to fix.
>
> This patch addresses the possible data race of card_requested[] and
> client_requested[] arrays by replacing them with bitmask.
> It's an atomic operation and can work without locks.
>
> Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
> Cc: <stable@vger.kernel.org>
> Link: https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_r_CAEHB24-5Fay6YzARpA1zgCsE7-3DH9CSJJzux618E-3DKa4h0YdKn-3DqA-40mail.gmail.com&d=DwIBAg&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=EyAJYRJu01oaAhhVVY3o8zKgZvacDAXd_PNRtaqACCo&m=5zfWpItqvL3lHhUMgi-DyAe7DauvBjWwe5UaP0CquJh8c8-phq2TFeGOm0TUvrBw&s=lnBmR8icRLp1uw0Gei6AgrBAaoROKuS3p0LfDWHyyD4&e=
> Link: https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_r_20220823072717.1706-2D2-2Dtiwai-40suse.de&d=DwIBAg&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=EyAJYRJu01oaAhhVVY3o8zKgZvacDAXd_PNRtaqACCo&m=5zfWpItqvL3lHhUMgi-DyAe7DauvBjWwe5UaP0CquJh8c8-phq2TFeGOm0TUvrBw&s=Fye5MLoxP4koy4AoFB2JfMaHXzfH8QflMxB0mZrmXOs&e=
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> v1->v2: fix compile error
>
>  sound/core/seq/seq_clientmgr.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
> index 2e9d695d336c..2d707afa1ef1 100644
> --- a/sound/core/seq/seq_clientmgr.c
> +++ b/sound/core/seq/seq_clientmgr.c
> @@ -121,13 +121,13 @@ struct snd_seq_client *snd_seq_client_use_ptr(int clientid)
>         spin_unlock_irqrestore(&clients_lock, flags);
>  #ifdef CONFIG_MODULES
>         if (!in_interrupt()) {
> -               static char client_requested[SNDRV_SEQ_GLOBAL_CLIENTS];
> -               static char card_requested[SNDRV_CARDS];
> +               static DECLARE_BITMAP(client_requested, SNDRV_SEQ_GLOBAL_CLIENTS);
> +               static DECLARE_BITMAP(card_requested, SNDRV_CARDS);
> +
>                 if (clientid < SNDRV_SEQ_GLOBAL_CLIENTS) {
>                         int idx;
>
> -                       if (!client_requested[clientid]) {
> -                               client_requested[clientid] = 1;
> +                       if (!test_and_set_bit(clientid, client_requested)) {
>                                 for (idx = 0; idx < 15; idx++) {
>                                         if (seq_client_load[idx] < 0)
>                                                 break;
> @@ -142,10 +142,8 @@ struct snd_seq_client *snd_seq_client_use_ptr(int clientid)
>                         int card = (clientid - SNDRV_SEQ_GLOBAL_CLIENTS) /
>                                 SNDRV_SEQ_CLIENTS_PER_CARD;
>                         if (card < snd_ecards_limit) {
> -                               if (! card_requested[card]) {
> -                                       card_requested[card] = 1;
> +                               if (!test_and_set_bit(card, card_requested))
>                                         snd_request_card(card);
> -                               }
>                                 snd_seq_device_load_drivers();
>                         }
>                 }
> --
> 2.35.3
>


-- 
Gabriel Ryan
PhD Candidate at Columbia University