alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Clemens Ladisch <clemens@ladisch.de>,
	Takashi Iwai <tiwai@suse.com>
Subject: Re: [PATCH/RFC 2/2] ALSA: firewire-tascam: Fix integer overflow in midi_port_work()
Date: Tue, 12 Jan 2021 14:55:35 +0100	[thread overview]
Message-ID: <CAMuHMdWo6uSBYr=uBWVPBfELfs6g5ZdnLdADakBj5ze9wkq9BQ@mail.gmail.com> (raw)
In-Reply-To: <20210112134259.GA44140@workstation>

Hi Sakamoto-san,

On Tue, Jan 12, 2021 at 2:43 PM Takashi Sakamoto
<o-takashi@sakamocchi.jp> wrote:
> On Mon, Jan 11, 2021 at 02:02:51PM +0100, Geert Uytterhoeven wrote:
> > As snd_fw_async_midi_port.consume_bytes is unsigned int, and
> > NSEC_PER_SEC is 1000000000L, the second multiplication in
> >
> >     port->consume_bytes * 8 * NSEC_PER_SEC / 31250
> >
> > always overflows on 32-bit platforms, truncating the result.  Fix this
> > by precalculating "NSEC_PER_SEC / 31250", which is an integer constant.
> >
> > Note that this assumes port->consume_bytes <= 16777.
> >
> > Fixes: 531f471834227d03 ("ALSA: firewire-lib/firewire-tascam: localize async midi port")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > Compile-tested only.
> >
> > I don't know the maximum transfer length of MIDI, but given it's an old
> > standard, I guess it's rather small.  If it is larger than 16777, the
> > constant "8" should be replaced by "8ULL", to force 64-bit arithmetic.
> > ---
> >  sound/firewire/tascam/tascam-transaction.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Indeed. The calculation brings integer overflow of 32 bit storage. Thanks
> for your care and proposal of the patch. I agree with the intension of
> patch, however I have a nitpicking that the consume_bytes member is
> defined as 'int', not 'unsigned int' in your commit comment.

Thanks, you're right.
Note that port->consume_bytes being signed halves the limit to
8388 bytes, which is of course still met.

> The member has value returned from the call of 'fill_message()'[1] for the
> length of byte messages in buffer to process, or for error code. The
> error code is checked immediately. The range of value is equal to
> or less than 3 when reaching the calculation, thus it should be less than
> 16777.
>
> Regardless of the type of 'int' or 'unsigned int', this patch can fix
> the issued problem. Feel free to add my tag when you post second version
> with comment fix.
>
> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2021-01-12 13:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 13:02 [PATCH/RFC 0/2] ALSA: firewire: Fix integer overflows on 32-bit Geert Uytterhoeven
2021-01-11 13:02 ` [PATCH/RFC 1/2] ALSA: fireface: Fix integer overflow in transmit_midi_msg() Geert Uytterhoeven
2021-01-12 13:53   ` Takashi Sakamoto
2021-01-12 13:58   ` Takashi Iwai
2021-01-11 13:02 ` [PATCH/RFC 2/2] ALSA: firewire-tascam: Fix integer overflow in midi_port_work() Geert Uytterhoeven
2021-01-12 13:42   ` Takashi Sakamoto
2021-01-12 13:55     ` Geert Uytterhoeven [this message]
2021-01-12 13:58   ` Takashi Iwai

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='CAMuHMdWo6uSBYr=uBWVPBfELfs6g5ZdnLdADakBj5ze9wkq9BQ@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=o-takashi@sakamocchi.jp \
    --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;
as well as URLs for NNTP newsgroup(s).