From: Takashi Iwai <tiwai@suse.de>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Takashi Sakamoto <o-takashi@sakamocchi.jp>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Mark Brown <broonie@kernel.org>,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] ALSA: control: prevent some integer overflow issues
Date: Thu, 12 Sep 2024 12:05:31 +0200 [thread overview]
Message-ID: <87v7z1yyok.wl-tiwai@suse.de> (raw)
In-Reply-To: <0f03d569-9804-4617-a806-f0e5c32399fb@stanley.mountain>
On Thu, 12 Sep 2024 10:51:14 +0200,
Dan Carpenter wrote:
>
> I believe the this bug affects 64bit systems as well, but analyzing this
> code is easier if we assume that we're on a 32bit system. The problem is
> in snd_ctl_elem_add() where we do:
>
> sound/core/control.c
> 1669 private_size = value_sizes[info->type] * info->count;
> 1670 alloc_size = compute_user_elem_size(private_size, count);
> ^^^^^
> count is info->owner. It's a non-zero u32 that comes from the user via
> snd_ctl_elem_add_user(). So the math in compute_user_elem_size() could
> have an integer overflow resulting in a smaller than expected size.
So this should also use the overflow macro, too, in addition to your
changes? Something like:
--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -1618,7 +1618,7 @@ static int snd_ctl_elem_add(struct snd_ctl_file *file,
struct snd_kcontrol *kctl;
unsigned int count;
unsigned int access;
- long private_size;
+ size_t private_size;
size_t alloc_size;
struct user_element *ue;
unsigned int offset;
@@ -1666,7 +1666,7 @@ static int snd_ctl_elem_add(struct snd_ctl_file *file,
/* user-space control doesn't allow zero-size data */
if (info->count < 1)
return -EINVAL;
- private_size = value_sizes[info->type] * info->count;
+ private_size = array_size(value_sizes[info->type], info->count);
alloc_size = compute_user_elem_size(private_size, count);
guard(rwsem_write)(&card->controls_rwsem);
thanks,
Takashi
>
> 1671
> 1672 guard(rwsem_write)(&card->controls_rwsem);
> 1673 if (check_user_elem_overflow(card, alloc_size))
>
> The math is check_user_elem_overflow() can also overflow. Additionally,
> large positive values are cast to negative and thus do not exceed
> max_user_ctl_alloc_size so they are treated as valid. It should be the
> opposite, where negative sizes are invalid.
>
> 1674 return -ENOMEM;
>
> Fixes: 2225e79b9b03 ("ALSA: core: reduce stack usage related to snd_ctl_new()")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
> sound/core/control.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/sound/core/control.c b/sound/core/control.c
> index 4f55f64c42e1..f36af27e68d5 100644
> --- a/sound/core/control.c
> +++ b/sound/core/control.c
> @@ -1397,9 +1397,9 @@ struct user_element {
> };
>
> // check whether the addition (in bytes) of user ctl element may overflow the limit.
> -static bool check_user_elem_overflow(struct snd_card *card, ssize_t add)
> +static bool check_user_elem_overflow(struct snd_card *card, size_t add)
> {
> - return (ssize_t)card->user_ctl_alloc_size + add > max_user_ctl_alloc_size;
> + return size_add(card->user_ctl_alloc_size, add) > max_user_ctl_alloc_size;
> }
>
> static int snd_ctl_elem_user_info(struct snd_kcontrol *kcontrol,
> @@ -1593,7 +1593,7 @@ static int snd_ctl_elem_init_enum_names(struct user_element *ue)
>
> static size_t compute_user_elem_size(size_t size, unsigned int count)
> {
> - return sizeof(struct user_element) + size * count;
> + return size_add(sizeof(struct user_element), size_mul(size, count));
> }
>
> static void snd_ctl_elem_user_free(struct snd_kcontrol *kcontrol)
> --
> 2.45.2
>
next prev parent reply other threads:[~2024-09-12 10:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 8:51 [PATCH] ALSA: control: prevent some integer overflow issues Dan Carpenter
2024-09-12 10:05 ` Takashi Iwai [this message]
2024-09-12 11:29 ` Dan Carpenter
2024-09-12 12:44 ` Dan Carpenter
2024-09-12 14:03 ` Takashi Iwai
2024-09-12 14:34 ` Dan Carpenter
2024-09-12 14:52 ` Dan Carpenter
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=87v7z1yyok.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=broonie@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=o-takashi@sakamocchi.jp \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox