From: Dan Carpenter <dan.carpenter@linaro.org>
To: Takashi Iwai <tiwai@suse.de>
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 14:29:58 +0300 [thread overview]
Message-ID: <20c99f50-948e-4076-ba28-9640c3cd982d@stanley.mountain> (raw)
In-Reply-To: <87v7z1yyok.wl-tiwai@suse.de>
On Thu, Sep 12, 2024 at 12:05:31PM +0200, Takashi Iwai wrote:
> 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);
>
I've reviewed this some more and those changes are harmless but unnecessary.
info->count is checked in snd_ctl_check_elem_info().
regards,
dan carpenter
next prev parent reply other threads:[~2024-09-12 12:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 8:51 Dan Carpenter
2024-09-12 10:05 ` Takashi Iwai
2024-09-12 11:29 ` Dan Carpenter [this message]
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=20c99f50-948e-4076-ba28-9640c3cd982d@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=broonie@kernel.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 \
--cc=tiwai@suse.de \
/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
all inboxes | Powered by JetHome®