[PATCH v2 0/6] ALSA: some driver fixes for control input validations

[PATCH v2 0/6] ALSA: some driver fixes for control input validations

[Takashi Iwai]

Hi,

this is a revised patch set as a follow up of the thread about the
errors reported by kselftest mixer-test.  It changes HD-audio and
vmaster control behavior to return -EINVAL for invalid input values.

There is a change in kselftest itself to skip the verification after
write tests for volatile controls, too.  It's for the channel map
controls that can't hold the stable values.

v1->v2:
* Skip only verification after write in kselftest
* Add sanity check to HDMI chmap write, too


Takashi

===

Takashi Iwai (6):
  ALSA: vmaster: Return error for invalid input values
  ALSA: hda: Return -EINVAL for invalid volume/switch inputs
  ALSA: control: Apply sanity check of input values for user elements
  kselftest/alsa: mixer-test: Skip write verification for volatile
    controls
  ALSA: chmap: Mark Channel Map controls as volatile
  ALSA: hda: Add input value sanity checks to HDMI channel map controls

 sound/core/control.c                      |  3 ++-
 sound/core/pcm_lib.c                      |  1 +
 sound/core/vmaster.c                      |  8 ++++++++
 sound/hda/hdmi_chmap.c                    | 18 ++++++++++++++++++
 sound/pci/hda/hda_codec.c                 | 23 ++++++++++++++++++-----
 tools/testing/selftests/alsa/mixer-test.c |  4 ++++
 6 files changed, 51 insertions(+), 6 deletions(-)

-- 
2.43.0

[PATCH v2 1/6] ALSA: vmaster: Return error for invalid input values

[Takashi Iwai]

So far the vmaster code has been tolerant about the input values and
accepts any values by correcting internally.  But now our own selftest
starts complaining about this behavior, so let's be picky and change
the behavior to return -EINVAL for invalid input values instead.

Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/core/vmaster.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/sound/core/vmaster.c b/sound/core/vmaster.c
index 04a57f7be6ea..c657659b236c 100644
--- a/sound/core/vmaster.c
+++ b/sound/core/vmaster.c
@@ -198,6 +198,12 @@ static int follower_put(struct snd_kcontrol *kcontrol,
 	err = follower_init(follower);
 	if (err < 0)
 		return err;
+	for (ch = 0; ch < follower->info.count; ch++) {
+		if (ucontrol->value.integer.value[ch] < follower->info.min_val ||
+		    ucontrol->value.integer.value[ch] > follower->info.max_val)
+			return -EINVAL;
+	}
+
 	for (ch = 0; ch < follower->info.count; ch++) {
 		if (follower->vals[ch] != ucontrol->value.integer.value[ch]) {
 			changed = 1;
@@ -365,6 +371,8 @@ static int master_put(struct snd_kcontrol *kcontrol,
 	new_val = ucontrol->value.integer.value[0];
 	if (new_val == old_val)
 		return 0;
+	if (new_val < master->info.min_val || new_val > master->info.max_val)
+		return -EINVAL;
 
 	err = sync_followers(master, old_val, new_val);
 	if (err < 0)
-- 
2.43.0

[PATCH v2 2/6] ALSA: hda: Return -EINVAL for invalid volume/switch inputs

[Takashi Iwai]

So far the HD-audio driver has been tolerant about the input values
and accepts any values by correcting the amp volume and switch values
internally.  But now our own selftest starts complaining about this
behavior, so let's be picky and change the behavior to return -EINVAL
for invalid input values instead.

Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/hda_codec.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 325e8f0b99a8..3dd1bda0c5c6 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1496,7 +1496,7 @@ update_amp_value(struct hda_codec *codec, hda_nid_t nid,
 	/* ofs = 0: raw max value */
 	maxval = get_amp_max_value(codec, nid, dir, 0);
 	if (val > maxval)
-		val = maxval;
+		return -EINVAL;
 	return snd_hda_codec_amp_update(codec, nid, ch, dir, idx,
 					HDA_AMP_VOLMASK, val);
 }
@@ -1547,13 +1547,21 @@ int snd_hda_mixer_amp_volume_put(struct snd_kcontrol *kcontrol,
 	unsigned int ofs = get_amp_offset(kcontrol);
 	long *valp = ucontrol->value.integer.value;
 	int change = 0;
+	int err;
 
 	if (chs & 1) {
-		change = update_amp_value(codec, nid, 0, dir, idx, ofs, *valp);
+		err = update_amp_value(codec, nid, 0, dir, idx, ofs, *valp);
+		if (err < 0)
+			return err;
+		change |= err;
 		valp++;
 	}
-	if (chs & 2)
-		change |= update_amp_value(codec, nid, 1, dir, idx, ofs, *valp);
+	if (chs & 2) {
+		err = update_amp_value(codec, nid, 1, dir, idx, ofs, *valp);
+		if (err < 0)
+			return err;
+		change |= err;
+	}
 	return change;
 }
 EXPORT_SYMBOL_GPL(snd_hda_mixer_amp_volume_put);
@@ -2149,15 +2157,20 @@ int snd_hda_mixer_amp_switch_put(struct snd_kcontrol *kcontrol,
 	int change = 0;
 
 	if (chs & 1) {
+		if (*valp < 0 || *valp > 1)
+			return -EINVAL;
 		change = snd_hda_codec_amp_update(codec, nid, 0, dir, idx,
 						  HDA_AMP_MUTE,
 						  *valp ? 0 : HDA_AMP_MUTE);
 		valp++;
 	}
-	if (chs & 2)
+	if (chs & 2) {
+		if (*valp < 0 || *valp > 1)
+			return -EINVAL;
 		change |= snd_hda_codec_amp_update(codec, nid, 1, dir, idx,
 						   HDA_AMP_MUTE,
 						   *valp ? 0 : HDA_AMP_MUTE);
+	}
 	hda_call_check_power_status(codec, nid);
 	return change;
 }
-- 
2.43.0

[PATCH v2 3/6] ALSA: control: Apply sanity check of input values for user elements

[Takashi Iwai]

Although we have already a mechanism for sanity checks of input values
for control writes, it's not applied unless the kconfig
CONFIG_SND_CTL_INPUT_VALIDATION is set due to the performance reason.
Nevertheless, it still makes sense to apply the check for user
elements despite of its cost, as that's the only way to filter out the
invalid values; the user controls are handled solely in ALSA core
code, and there is no corresponding driver, after all.

This patch enables the input value validation for user control
elements no matter whether CONFIG_SND_CTL_INPUT_VALIDATION is set or
not.  The kselftest will be happier with this change, as the incorrect
values will be bailed out now with errors.

For other normal controls, the check is applied still only when
CONFIG_SND_CTL_INPUT_VALIDATION is set.

Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/core/control.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/core/control.c b/sound/core/control.c
index fb0c60044f7b..50890983d7e2 100644
--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -1317,7 +1317,8 @@ static int snd_ctl_elem_write(struct snd_card *card, struct snd_ctl_file *file,
 	snd_ctl_build_ioff(&control->id, kctl, index_offset);
 	result = snd_power_ref_and_wait(card);
 	/* validate input values */
-	if (IS_ENABLED(CONFIG_SND_CTL_INPUT_VALIDATION) && !result) {
+	if ((IS_ENABLED(CONFIG_SND_CTL_INPUT_VALIDATION) ||
+	     (vd->access & SNDRV_CTL_ELEM_ACCESS_USER)) && !result) {
 		struct snd_ctl_elem_info info;
 
 		memset(&info, 0, sizeof(info));
-- 
2.43.0

Re: [PATCH v2 3/6] ALSA: control: Apply sanity check of input values for user elements

[Takashi Sakamoto]

Hi,

On Fri, Jun 14, 2024 at 05:37:12PM +0200, Takashi Iwai wrote:
> Although we have already a mechanism for sanity checks of input values
> for control writes, it's not applied unless the kconfig
> CONFIG_SND_CTL_INPUT_VALIDATION is set due to the performance reason.
> Nevertheless, it still makes sense to apply the check for user
> elements despite of its cost, as that's the only way to filter out the
> invalid values; the user controls are handled solely in ALSA core
> code, and there is no corresponding driver, after all.
> 
> This patch enables the input value validation for user control
> elements no matter whether CONFIG_SND_CTL_INPUT_VALIDATION is set or
> not.  The kselftest will be happier with this change, as the incorrect
> values will be bailed out now with errors.
> 
> For other normal controls, the check is applied still only when
> CONFIG_SND_CTL_INPUT_VALIDATION is set.
> 
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
> Reviewed-by: Jaroslav Kysela <perex@perex.cz>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>  sound/core/control.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/core/control.c b/sound/core/control.c
> index fb0c60044f7b..50890983d7e2 100644
> --- a/sound/core/control.c
> +++ b/sound/core/control.c
> @@ -1317,7 +1317,8 @@ static int snd_ctl_elem_write(struct snd_card *card, struct snd_ctl_file *file,
>  	snd_ctl_build_ioff(&control->id, kctl, index_offset);
>  	result = snd_power_ref_and_wait(card);
>  	/* validate input values */
> -	if (IS_ENABLED(CONFIG_SND_CTL_INPUT_VALIDATION) && !result) {
> +	if ((IS_ENABLED(CONFIG_SND_CTL_INPUT_VALIDATION) ||
> +	     (vd->access & SNDRV_CTL_ELEM_ACCESS_USER)) && !result) {
>  		struct snd_ctl_elem_info info;
>  
>  		memset(&info, 0, sizeof(info));

In my opinion, the validation in 'snd_ctl_elem_user_put()' is preferable
instead. In the function, it is free to access to 'struct
user_element.info' for the validation.

In the commit coment, I can see "that's the only way to filter out the
invalid values", however it not so good idea, since the ALSA control core
function loses transparency against control elements somehow.
Furthermore, I can see "there is no corresponding driver", however it is
suspicious somehow. It would be smart to charge the validation
implementation for user-defined control element set if forcing it.


Regards

Takashi Sakamoto

Re: [PATCH v2 3/6] ALSA: control: Apply sanity check of input values for user elements

[Takashi Iwai]

On Sat, 15 Jun 2024 07:13:29 +0200,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> On Fri, Jun 14, 2024 at 05:37:12PM +0200, Takashi Iwai wrote:
> > Although we have already a mechanism for sanity checks of input values
> > for control writes, it's not applied unless the kconfig
> > CONFIG_SND_CTL_INPUT_VALIDATION is set due to the performance reason.
> > Nevertheless, it still makes sense to apply the check for user
> > elements despite of its cost, as that's the only way to filter out the
> > invalid values; the user controls are handled solely in ALSA core
> > code, and there is no corresponding driver, after all.
> > 
> > This patch enables the input value validation for user control
> > elements no matter whether CONFIG_SND_CTL_INPUT_VALIDATION is set or
> > not.  The kselftest will be happier with this change, as the incorrect
> > values will be bailed out now with errors.
> > 
> > For other normal controls, the check is applied still only when
> > CONFIG_SND_CTL_INPUT_VALIDATION is set.
> > 
> > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
> > Reviewed-by: Jaroslav Kysela <perex@perex.cz>
> > Reviewed-by: Mark Brown <broonie@kernel.org>
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > ---
> >  sound/core/control.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/sound/core/control.c b/sound/core/control.c
> > index fb0c60044f7b..50890983d7e2 100644
> > --- a/sound/core/control.c
> > +++ b/sound/core/control.c
> > @@ -1317,7 +1317,8 @@ static int snd_ctl_elem_write(struct snd_card *card, struct snd_ctl_file *file,
> >  	snd_ctl_build_ioff(&control->id, kctl, index_offset);
> >  	result = snd_power_ref_and_wait(card);
> >  	/* validate input values */
> > -	if (IS_ENABLED(CONFIG_SND_CTL_INPUT_VALIDATION) && !result) {
> > +	if ((IS_ENABLED(CONFIG_SND_CTL_INPUT_VALIDATION) ||
> > +	     (vd->access & SNDRV_CTL_ELEM_ACCESS_USER)) && !result) {
> >  		struct snd_ctl_elem_info info;
> >  
> >  		memset(&info, 0, sizeof(info));
> 
> In my opinion, the validation in 'snd_ctl_elem_user_put()' is preferable
> instead. In the function, it is free to access to 'struct
> user_element.info' for the validation.

Yeah, more optimization would be possible and we can do it later.
My patch achieves the purpose in the smallest change.

> In the commit coment, I can see "that's the only way to filter out the
> invalid values", however it not so good idea, since the ALSA control core
> function loses transparency against control elements somehow.

Transparency?  The sanity check of input values is done in each driver
side, hence some overhead is more or less always present, depending on
the implementation.

> Furthermore, I can see "there is no corresponding driver", however it is
> suspicious somehow. It would be smart to charge the validation
> implementation for user-defined control element set if forcing it.

The context there implies that, in the case of user elements, all
handled in sound/core/control.c, and there is no other dedicated
driver code handling the control put for those controls, hence
sound/core/control.c is the only place where we can address the
issue.


thanks,

Takashi

Re: [PATCH v2 3/6] ALSA: control: Apply sanity check of input values for user elements

[Takashi Sakamoto]

On Sat, Jun 15, 2024 at 09:28:50AM +0200, Takashi Iwai wrote:
> > In the commit coment, I can see "that's the only way to filter out the
> > invalid values", however it not so good idea, since the ALSA control core
> > function loses transparency against control elements somehow.
> 
> Transparency?  The sanity check of input values is done in each driver
> side, hence some overhead is more or less always present, depending on
> the implementation.
>
> > Furthermore, I can see "there is no corresponding driver", however it is
> > suspicious somehow. It would be smart to charge the validation
> > implementation for user-defined control element set if forcing it.
> 
> The context there implies that, in the case of user elements, all
> handled in sound/core/control.c, and there is no other dedicated
> driver code handling the control put for those controls, hence
> sound/core/control.c is the only place where we can address the
> issue.

If you can force the validation to _all_ of the existing drivers by any
kind of mechanism, it would be. Actually, not. We can have such driver
which handles the write request without such validation, and control core
allows it. The kernel configuration is to ease the detection of such
drivers (and applications) in application runtime. Therefore the
transparency would be lost by the patch.

Assuming that two control element exist in a sound card, which has the
same information and TLV response, except for the flag of
SNDRV_CTL_ELEM_ACCESS_USER. For the same value data, one operation with
SNDRV_CTL_IOCTL_ELEM_WRITE is successful, and another operation with
SNDRV_CTL_ELEM_ACCESS_USER is failed. When encountering this issue,
the programmer of the application suspect the bug pertaining to the latter
control, then the programmer find the latter has
SNDRV_CTL_ELEM_ACCESS_USER. Then the programmer would judge that 'I got
it, it is a bug of user-defined control element set' even if the program
includes the bug for min/max/step computation and the underlying sound
driver includes the bug not to validate value data.

The patch loses transparency in the above step. Without the patch, both
operations finish with the equivalent result.


Nevertheless, I think the validation is itself preferable. In my opinion,
the validation before/after the call of 'snd_kcontrol_put_t' would result
in the different argument. The 'validate-before-call' is the argument of
control core function, while 'validate-after-call is the argument of
implementation of user-defined element set. The patch should belong to the
latter to extend current implementation of user-defined element set.
Thus I suggest to put the validation into the put callback function,
regardless of the optimization to which you address.


Regards

Takashi Sakamoto

Re: [PATCH v2 3/6] ALSA: control: Apply sanity check of input values for user elements

[Takashi Iwai]

On Sat, 15 Jun 2024 10:02:35 +0200,
Takashi Sakamoto wrote:
> 
> On Sat, Jun 15, 2024 at 09:28:50AM +0200, Takashi Iwai wrote:
> > > In the commit coment, I can see "that's the only way to filter out the
> > > invalid values", however it not so good idea, since the ALSA control core
> > > function loses transparency against control elements somehow.
> > 
> > Transparency?  The sanity check of input values is done in each driver
> > side, hence some overhead is more or less always present, depending on
> > the implementation.
> >
> > > Furthermore, I can see "there is no corresponding driver", however it is
> > > suspicious somehow. It would be smart to charge the validation
> > > implementation for user-defined control element set if forcing it.
> > 
> > The context there implies that, in the case of user elements, all
> > handled in sound/core/control.c, and there is no other dedicated
> > driver code handling the control put for those controls, hence
> > sound/core/control.c is the only place where we can address the
> > issue.
> 
> If you can force the validation to _all_ of the existing drivers by any
> kind of mechanism, it would be. Actually, not. We can have such driver
> which handles the write request without such validation, and control core
> allows it. The kernel configuration is to ease the detection of such
> drivers (and applications) in application runtime. Therefore the
> transparency would be lost by the patch.

In principle, the validation should be done for *every* kcontrol.  The
lack of the validation was ignored so far with a naive assumption that
the driver treats properly nevertheless.  But since we're checking it
more strictly in kselftest, the problem became more obvious, and this
is a corresponding fix for user control element part.  HD-audio driver
had another issues and they are fixed in other patches of this
series.

> Assuming that two control element exist in a sound card, which has the
> same information and TLV response, except for the flag of
> SNDRV_CTL_ELEM_ACCESS_USER. For the same value data, one operation with
> SNDRV_CTL_IOCTL_ELEM_WRITE is successful, and another operation with
> SNDRV_CTL_ELEM_ACCESS_USER is failed. When encountering this issue,
> the programmer of the application suspect the bug pertaining to the latter
> control, then the programmer find the latter has
> SNDRV_CTL_ELEM_ACCESS_USER. Then the programmer would judge that 'I got
> it, it is a bug of user-defined control element set' even if the program
> includes the bug for min/max/step computation and the underlying sound
> driver includes the bug not to validate value data.

No, it's a wrong understanding, other way round: the driver must
validate the values by itself.

> The patch loses transparency in the above step. Without the patch, both
> operations finish with the equivalent result.
> 
> Nevertheless, I think the validation is itself preferable.

The validation is not "preferable" but rather "mandatory".

> In my opinion,
> the validation before/after the call of 'snd_kcontrol_put_t' would result
> in the different argument. The 'validate-before-call' is the argument of
> control core function, while 'validate-after-call is the argument of
> implementation of user-defined element set. The patch should belong to the
> latter to extend current implementation of user-defined element set.
> Thus I suggest to put the validation into the put callback function,
> regardless of the optimization to which you address.

I don't get the argument, sorry.
If you have a better point, please submit an incremental patch.


thanks,

Takashi

Re: [PATCH v2 3/6] ALSA: control: Apply sanity check of input values for user elements

[Takashi Iwai]

On Sat, 15 Jun 2024 10:30:10 +0200,
Takashi Iwai wrote:
> 
> On Sat, 15 Jun 2024 10:02:35 +0200,
> Takashi Sakamoto wrote:
> > 
> > On Sat, Jun 15, 2024 at 09:28:50AM +0200, Takashi Iwai wrote:
> > > > In the commit coment, I can see "that's the only way to filter out the
> > > > invalid values", however it not so good idea, since the ALSA control core
> > > > function loses transparency against control elements somehow.
> > > 
> > > Transparency?  The sanity check of input values is done in each driver
> > > side, hence some overhead is more or less always present, depending on
> > > the implementation.
> > >
> > > > Furthermore, I can see "there is no corresponding driver", however it is
> > > > suspicious somehow. It would be smart to charge the validation
> > > > implementation for user-defined control element set if forcing it.
> > > 
> > > The context there implies that, in the case of user elements, all
> > > handled in sound/core/control.c, and there is no other dedicated
> > > driver code handling the control put for those controls, hence
> > > sound/core/control.c is the only place where we can address the
> > > issue.
> > 
> > If you can force the validation to _all_ of the existing drivers by any
> > kind of mechanism, it would be. Actually, not. We can have such driver
> > which handles the write request without such validation, and control core
> > allows it. The kernel configuration is to ease the detection of such
> > drivers (and applications) in application runtime. Therefore the
> > transparency would be lost by the patch.
> 
> In principle, the validation should be done for *every* kcontrol.  The
> lack of the validation was ignored so far with a naive assumption that
> the driver treats properly nevertheless.  But since we're checking it
> more strictly in kselftest, the problem became more obvious, and this
> is a corresponding fix for user control element part.  HD-audio driver
> had another issues and they are fixed in other patches of this
> series.
> 
> > Assuming that two control element exist in a sound card, which has the
> > same information and TLV response, except for the flag of
> > SNDRV_CTL_ELEM_ACCESS_USER. For the same value data, one operation with
> > SNDRV_CTL_IOCTL_ELEM_WRITE is successful, and another operation with
> > SNDRV_CTL_ELEM_ACCESS_USER is failed. When encountering this issue,
> > the programmer of the application suspect the bug pertaining to the latter
> > control, then the programmer find the latter has
> > SNDRV_CTL_ELEM_ACCESS_USER. Then the programmer would judge that 'I got
> > it, it is a bug of user-defined control element set' even if the program
> > includes the bug for min/max/step computation and the underlying sound
> > driver includes the bug not to validate value data.
> 
> No, it's a wrong understanding, other way round: the driver must
> validate the values by itself.
> 
> > The patch loses transparency in the above step. Without the patch, both
> > operations finish with the equivalent result.
> > 
> > Nevertheless, I think the validation is itself preferable.
> 
> The validation is not "preferable" but rather "mandatory".
> 
> > In my opinion,
> > the validation before/after the call of 'snd_kcontrol_put_t' would result
> > in the different argument. The 'validate-before-call' is the argument of
> > control core function, while 'validate-after-call is the argument of
> > implementation of user-defined element set. The patch should belong to the
> > latter to extend current implementation of user-defined element set.
> > Thus I suggest to put the validation into the put callback function,
> > regardless of the optimization to which you address.
> 
> I don't get the argument, sorry.
> If you have a better point, please submit an incremental patch.

Or did you meant something like below?


Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH v3] ALSA: control: Apply sanity check of input values for user elements

Although we have already a mechanism for sanity checks of input values
for control writes, it's not applied unless the kconfig
CONFIG_SND_CTL_INPUT_VALIDATION is set due to the performance reason.
Nevertheless, it still makes sense to apply the same check for user
elements despite of its cost, as that's the only way to filter out the
invalid values; the user controls are handled solely in ALSA core
code, and there is no corresponding driver, after all.

This patch adds the same input value validation for user control
elements at its put callback.  The kselftest will be happier with this
change, as the incorrect values will be bailed out now with errors.

For other normal controls, the check is applied still only when
CONFIG_SND_CTL_INPUT_VALIDATION is set.

Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/core/control.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sound/core/control.c b/sound/core/control.c
index fb0c60044f7b..1dd2337e2930 100644
--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -1480,12 +1480,16 @@ static int snd_ctl_elem_user_get(struct snd_kcontrol *kcontrol,
 static int snd_ctl_elem_user_put(struct snd_kcontrol *kcontrol,
 				 struct snd_ctl_elem_value *ucontrol)
 {
-	int change;
+	int err, change;
 	struct user_element *ue = kcontrol->private_data;
 	unsigned int size = ue->elem_data_size;
 	char *dst = ue->elem_data +
 			snd_ctl_get_ioff(kcontrol, &ucontrol->id) * size;
 
+	err = sanity_check_input_values(ue->card, ucontrol, &ue->info, false);
+	if (err < 0)
+		return err;
+
 	change = memcmp(&ucontrol->value, dst, size) != 0;
 	if (change)
 		memcpy(dst, &ucontrol->value, size);
-- 
2.43.0

Re: [PATCH v2 3/6] ALSA: control: Apply sanity check of input values for user elements

[Takashi Sakamoto]

On Sat, Jun 15, 2024 at 01:37:09PM +0200, Takashi Iwai wrote:
> From: Takashi Iwai <tiwai@suse.de>
> Subject: [PATCH v3] ALSA: control: Apply sanity check of input values for user elements
> 
> Although we have already a mechanism for sanity checks of input values
> for control writes, it's not applied unless the kconfig
> CONFIG_SND_CTL_INPUT_VALIDATION is set due to the performance reason.
> Nevertheless, it still makes sense to apply the same check for user
> elements despite of its cost, as that's the only way to filter out the
> invalid values; the user controls are handled solely in ALSA core
> code, and there is no corresponding driver, after all.
> 
> This patch adds the same input value validation for user control
> elements at its put callback.  The kselftest will be happier with this
> change, as the incorrect values will be bailed out now with errors.
> 
> For other normal controls, the check is applied still only when
> CONFIG_SND_CTL_INPUT_VALIDATION is set.
> 
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
> Reviewed-by: Jaroslav Kysela <perex@perex.cz>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>  sound/core/control.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>


Thanks

Takashi Sakamoto

[PATCH v2 4/6] kselftest/alsa: mixer-test: Skip write verification for volatile controls

[Takashi Iwai]

The control elements with volatile flag don't guarantee that the
written values are actually saved for the next reads, hence we can't
verify the written values reliably.  Skip the verification after write
tests for those volatile controls for avoiding confusion.

Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 tools/testing/selftests/alsa/mixer-test.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/testing/selftests/alsa/mixer-test.c b/tools/testing/selftests/alsa/mixer-test.c
index 1c04e5f638a0..c98167818319 100644
--- a/tools/testing/selftests/alsa/mixer-test.c
+++ b/tools/testing/selftests/alsa/mixer-test.c
@@ -616,6 +616,10 @@ static int write_and_verify(struct ctl_data *ctl,
 	if (!snd_ctl_elem_info_is_readable(ctl->info))
 		return err;
 
+	/* Skip the verification for volatile controls, too */
+	if (snd_ctl_elem_info_is_volatile(ctl->info))
+		return err;
+
 	snd_ctl_elem_value_set_id(read_val, ctl->id);
 
 	err = snd_ctl_elem_read(ctl->card->handle, read_val);
-- 
2.43.0

Re: [PATCH v2 4/6] kselftest/alsa: mixer-test: Skip write verification for volatile controls

[Jaroslav Kysela]

On 14. 06. 24 17:37, Takashi Iwai wrote:
> The control elements with volatile flag don't guarantee that the
> written values are actually saved for the next reads, hence we can't
> verify the written values reliably.  Skip the verification after write
> tests for those volatile controls for avoiding confusion.
> 
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
> Signed-off-by: Takashi Iwai <tiwai@suse.de>

Reviewed-by: Jaroslav Kysela <perex@perex.cz>

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: [PATCH v2 4/6] kselftest/alsa: mixer-test: Skip write verification for volatile controls

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Fri, Jun 14, 2024 at 05:37:13PM +0200, Takashi Iwai wrote:

> @@ -616,6 +616,10 @@ static int write_and_verify(struct ctl_data *ctl,
>  	if (!snd_ctl_elem_info_is_readable(ctl->info))
>  		return err;
>  
> +	/* Skip the verification for volatile controls, too */
> +	if (snd_ctl_elem_info_is_volatile(ctl->info))
> +		return err;
> +

I think we should do the checks in test_ctl_get_value() still - a read
and then ctl_value_is_valid() on whatever we read.  It doesn't need to
match the value we wrote but it should still be valid for the control.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 4/6] kselftest/alsa: mixer-test: Skip write verification for volatile controls

[Takashi Iwai]

On Fri, 14 Jun 2024 17:57:37 +0200,
Mark Brown wrote:
> 
> On Fri, Jun 14, 2024 at 05:37:13PM +0200, Takashi Iwai wrote:
> 
> > @@ -616,6 +616,10 @@ static int write_and_verify(struct ctl_data *ctl,
> >  	if (!snd_ctl_elem_info_is_readable(ctl->info))
> >  		return err;
> >  
> > +	/* Skip the verification for volatile controls, too */
> > +	if (snd_ctl_elem_info_is_volatile(ctl->info))
> > +		return err;
> > +
> 
> I think we should do the checks in test_ctl_get_value() still - a read
> and then ctl_value_is_valid() on whatever we read.  It doesn't need to
> match the value we wrote but it should still be valid for the control.

So something like below?


Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH v3] kselftest/alsa: mixer-test: Allow value mismatch for volatile controls

The control elements with volatile flag don't guarantee that the
written values are actually saved for the next reads, hence we can't
verify the written values reliably.  Return as success for volatile
controls even if the value verification after writes fails, in order
to avoid false-positive.

Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 tools/testing/selftests/alsa/mixer-test.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/testing/selftests/alsa/mixer-test.c b/tools/testing/selftests/alsa/mixer-test.c
index 1c04e5f638a0..62b77737f0de 100644
--- a/tools/testing/selftests/alsa/mixer-test.c
+++ b/tools/testing/selftests/alsa/mixer-test.c
@@ -668,6 +668,10 @@ static int write_and_verify(struct ctl_data *ctl,
 		ksft_print_msg("%s read and written values differ\n",
 			       ctl->name);
 
+	/* Allow difference for volatile controls */
+	if (snd_ctl_elem_info_is_volatile(ctl->info))
+		return 0;
+
 	return -1;
 }
 
-- 
2.43.0

Re: [PATCH v2 4/6] kselftest/alsa: mixer-test: Skip write verification for volatile controls

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On Fri, Jun 14, 2024 at 06:08:12PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> +++ b/tools/testing/selftests/alsa/mixer-test.c
> @@ -668,6 +668,10 @@ static int write_and_verify(struct ctl_data *ctl,
>  		ksft_print_msg("%s read and written values differ\n",
>  			       ctl->name);
>  
> +	/* Allow difference for volatile controls */
> +	if (snd_ctl_elem_info_is_volatile(ctl->info))
> +		return 0;
> +
>  	return -1;
>  }

That'll still print the warnings about the values differing and won't
check the values are in range...  I'll send a patch.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v2 5/6] ALSA: chmap: Mark Channel Map controls as volatile

[Takashi Iwai]

The values returned from Playback Channel Map and Capture Channel Map
controls may vary dynamically depending on the corresponding PCM
stream.  Mark those as volatile to indicate the values are unstable
and not suitable for testing.

Note that we may change the driver to return -EINVAL, but this would
bring other side effects, such as "alsactl restore" would start
receiving unexpected errors.  So we still keep returning 0 for those
invalid inputs.

Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/core/pcm_lib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 6f73b3c2c205..071c67cbc479 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -2556,6 +2556,7 @@ int snd_pcm_add_chmap_ctls(struct snd_pcm *pcm, int stream,
 	struct snd_kcontrol_new knew = {
 		.iface = SNDRV_CTL_ELEM_IFACE_PCM,
 		.access = SNDRV_CTL_ELEM_ACCESS_READ |
+			SNDRV_CTL_ELEM_ACCESS_VOLATILE |
 			SNDRV_CTL_ELEM_ACCESS_TLV_READ |
 			SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK,
 		.info = pcm_chmap_ctl_info,
-- 
2.43.0

[PATCH v2 6/6] ALSA: hda: Add input value sanity checks to HDMI channel map controls

[Takashi Iwai]

Add a simple sanity check to HD-audio HDMI Channel Map controls.
Although the value might not be accepted for the actual connection, we
can filter out some bogus values beforehand, and that should be enough
for making kselftest happier.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/hda/hdmi_chmap.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/sound/hda/hdmi_chmap.c b/sound/hda/hdmi_chmap.c
index 5d8e1d944b0a..7b276047f85a 100644
--- a/sound/hda/hdmi_chmap.c
+++ b/sound/hda/hdmi_chmap.c
@@ -753,6 +753,20 @@ static int hdmi_chmap_ctl_get(struct snd_kcontrol *kcontrol,
 	return 0;
 }
 
+/* a simple sanity check for input values to chmap kcontrol */
+static int chmap_value_check(struct hdac_chmap *hchmap,
+			     const struct snd_ctl_elem_value *ucontrol)
+{
+	int i;
+
+	for (i = 0; i < hchmap->channels_max; i++) {
+		if (ucontrol->value.integer.value[i] < 0 ||
+		    ucontrol->value.integer.value[i] > SNDRV_CHMAP_LAST)
+			return -EINVAL;
+	}
+	return 0;
+}
+
 static int hdmi_chmap_ctl_put(struct snd_kcontrol *kcontrol,
 			      struct snd_ctl_elem_value *ucontrol)
 {
@@ -764,6 +778,10 @@ static int hdmi_chmap_ctl_put(struct snd_kcontrol *kcontrol,
 	unsigned char chmap[8], per_pin_chmap[8];
 	int i, err, ca, prepared = 0;
 
+	err = chmap_value_check(hchmap, ucontrol);
+	if (err < 0)
+		return err;
+
 	/* No monitor is connected in dyn_pcm_assign.
 	 * It's invalid to setup the chmap
 	 */
-- 
2.43.0

Re: [PATCH v2 6/6] ALSA: hda: Add input value sanity checks to HDMI channel map controls

[Jaroslav Kysela]

On 14. 06. 24 17:37, Takashi Iwai wrote:
> Add a simple sanity check to HD-audio HDMI Channel Map controls.
> Although the value might not be accepted for the actual connection, we
> can filter out some bogus values beforehand, and that should be enough
> for making kselftest happier.
> 
> Signed-off-by: Takashi Iwai <tiwai@suse.de>

Reviewed-by: Jaroslav Kysela <perex@perex.cz>

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.