From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1430043AB2 for ; Wed, 15 Nov 2023 20:45:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="cCMtTMAm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5BE9C433C9; Wed, 15 Nov 2023 20:45:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1700081130; bh=VmaoimEdUq77hxAEhBTykEfbd1v/IuUJiO/V8nnVMEo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cCMtTMAmDoLf6/AAXYAWVOfULvrzLR9lHn/LYd5X5qMF/WJ3STgDL674ww8gcBjUW GzBdo6V7KSr2C2dqAn8YIKDel3lclsBrTj8al74QJuQ0RWuvVJHLffn9L4Vo9mgGBa JeOEhumvee37Qqp3fKqCLyWTZwiutRwwi5VGOFO4= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Chenyuan Mi , Jonathan Cameron , Sasha Levin Subject: [PATCH 4.19 57/88] tools: iio: iio_generic_buffer: Fix some integer type and calculation Date: Wed, 15 Nov 2023 15:36:09 -0500 Message-ID: <20231115191429.570835411@linuxfoundation.org> X-Mailer: git-send-email 2.42.1 In-Reply-To: <20231115191426.221330369@linuxfoundation.org> References: <20231115191426.221330369@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 4.19-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chenyuan Mi [ Upstream commit 49d736313d0975ddeb156f4f59801da833f78b30 ] In function size_from_channelarray(), the return value 'bytes' is defined as int type. However, the calcution of 'bytes' in this function is designed to use the unsigned int type. So it is necessary to change 'bytes' type to unsigned int to avoid integer overflow. The size_from_channelarray() is called in main() function, its return value is directly multipled by 'buf_len' and then used as the malloc() parameter. The 'buf_len' is completely controllable by user, thus a multiplication overflow may occur here. This could allocate an unexpected small area. Signed-off-by: Chenyuan Mi Link: https://lore.kernel.org/r/20230725092407.62545-1-michenyuan@huawei.com Signed-off-by: Jonathan Cameron Stable-dep-of: 2d3dff577dd0 ("tools: iio: iio_generic_buffer ensure alignment") Signed-off-by: Sasha Levin --- tools/iio/iio_generic_buffer.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c index 9a5af0f6592dc..8360605f01db8 100644 --- a/tools/iio/iio_generic_buffer.c +++ b/tools/iio/iio_generic_buffer.c @@ -53,9 +53,9 @@ enum autochan { * Has the side effect of filling the channels[i].location values used * in processing the buffer output. **/ -static int size_from_channelarray(struct iio_channel_info *channels, int num_channels) +static unsigned int size_from_channelarray(struct iio_channel_info *channels, int num_channels) { - int bytes = 0; + unsigned int bytes = 0; int i = 0; while (i < num_channels) { @@ -346,7 +346,7 @@ int main(int argc, char **argv) ssize_t read_size; int dev_num = -1, trig_num = -1; char *buffer_access = NULL; - int scan_size; + unsigned int scan_size; int noevents = 0; int notrigger = 0; char *dummy; @@ -616,7 +616,16 @@ int main(int argc, char **argv) } scan_size = size_from_channelarray(channels, num_channels); - data = malloc(scan_size * buf_len); + + size_t total_buf_len = scan_size * buf_len; + + if (scan_size > 0 && total_buf_len / scan_size != buf_len) { + ret = -EFAULT; + perror("Integer overflow happened when calculate scan_size * buf_len"); + goto error; + } + + data = malloc(total_buf_len); if (!data) { ret = -ENOMEM; goto error; -- 2.42.0