Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp3530603pxb; Tue, 12 Jan 2021 17:45:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJwg596uIe0v3b/sM+1opnW0Kw6ctxxgJU1SwgQlQFCo8jxXKL0NeubPULE71h2tb322QuJN X-Received: by 2002:a17:906:a181:: with SMTP id s1mr1164084ejy.60.1610502310356; Tue, 12 Jan 2021 17:45:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610502310; cv=none; d=google.com; s=arc-20160816; b=AbiVc1sVNDRVLnunmxUSupDMB0vANKIIsb6KEcWxTP7eUFk0Ojgv64Bmwi6QO6b+UB yFd68ltBQHPVpqdK7nOjd4SxLfPjix1sDiVKxmDqEZ58UOdCmc2zIaROFsi2GKSYg/Nv RcHB+dHECXcluMgMRoFfAs0J6XZziCKXNzt7+hClpNiwR0ClbQf19VrxMSfoKkpODDEp 2Av8JtL4ROF8dn9LzciyNUBC0bZjBDjvrg9jL9ZlZlJ+AZ8mMaqtZsrO6bC2j4epi47y 18U93u4IuslvMczhgLxNt6BlTlFczhccLvR8Zo9hgebLcU1JawREToqU9XHDGnEZQUet BKWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date; bh=Bdne+M8/VewpHsYPXxOD3Fep02ejBEsVhBS6QzVMaFY=; b=o+94fZmZWUq3qnG1ajm9JS2ghfMlYnfSgQ3yNwWEip4zbKP2lz27AduA28WvdsdOci wDXmy1uf3xj3VV9bACO6xPwfid8FZDcaXRHkoBzMcSwLJEuI1VmtF6132hAvy6ykIq2y 1gXDYj+gj4ccB9B3mkGE536+BV8mY+AyHbdD9tut89e23YcpIc2BkAthreSI/ofCo5F5 enwl5tEG3RltgXMCDBAOj/sKQZLHc2TjK3CdOybWWunNkmVWZRT1gLls9GH39mnniupS +QTJAh0Gc0i4F8YYwUK4elBFaNWi5N0q4LJ0YgxzO68AQsB6SLz9n1KcZ7cPG31r2zrv Bkcw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dd5si202976ejb.464.2021.01.12.17.44.47; Tue, 12 Jan 2021 17:45:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387983AbhALN7R (ORCPT + 99 others); Tue, 12 Jan 2021 08:59:17 -0500 Received: from mx2.suse.de ([195.135.220.15]:60068 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729714AbhALN7Q (ORCPT ); Tue, 12 Jan 2021 08:59:16 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 98CDDAC24; Tue, 12 Jan 2021 13:58:35 +0000 (UTC) Date: Tue, 12 Jan 2021 14:58:35 +0100 Message-ID: From: Takashi Iwai To: Geert Uytterhoeven Cc: Clemens Ladisch , Takashi Sakamoto , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH/RFC 1/2] ALSA: fireface: Fix integer overflow in transmit_midi_msg() In-Reply-To: <20210111130251.361335-2-geert+renesas@glider.be> References: <20210111130251.361335-1-geert+renesas@glider.be> <20210111130251.361335-2-geert+renesas@glider.be> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 11 Jan 2021 14:02:50 +0100, Geert Uytterhoeven wrote: > > As snd_ff.rx_bytes[] is unsigned int, and NSEC_PER_SEC is 1000000000L, > the second multiplication in > > ff->rx_bytes[port] * 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 ff->rx_bytes[port] <= 16777. > > Fixes: 19174295788de77d ("ALSA: fireface: add transaction support") > Signed-off-by: Geert Uytterhoeven > --- > 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. Applied now. Thanks. Takashi