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) {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