Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2501421pxb; Sun, 16 Jan 2022 22:55:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJyoLsbkRQQ3LK+eIiVX2pKTb6+WK2eekscyEgE0F8qehVC1Ol/YCeFgjHq+HoNn2UALRIEQ X-Received: by 2002:a63:84c8:: with SMTP id k191mr10573041pgd.562.1642402557626; Sun, 16 Jan 2022 22:55:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642402557; cv=none; d=google.com; s=arc-20160816; b=JqHxT07g5FKPIlqV2NGcAUMClx5hy9o/xoEzb9lsfwAtgUSDzWUkDXnBYh6ASKuRIO mqeuNyNpW613nPiMoL53TC5lyOVMf3bGY4SN+VkA7DNxeOBs2C1sAGnWeaWv5Ko3llE6 2BVHe1e1taLtytMMFx/Ud6f36fc/okwXSfN6V4rMJkTAekmwuxDY0yVdKJkRHkgPE8Dy T6Ji7Pdsvmj4QChvwIwTwoyIdsd2lMQKVPin3GU5lweLaJyr+RYGKLwUEHtRrB5Z6+Cx C8OVjhznAo/2vUHXdfxzV1tz1z0GuZCMM0Miry/WXlaGztALXT/3dacffj/dLyoOWaU5 CkNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=UQba+2bn5zMXCY2A1mHnMuNYmdKHJPf7AoC0KDbt0pU=; b=PnaZ2atRw/r+P7n9atwwxBE5uvOvcXvKE0sMXrRFaN68l7s0fnxDREA6L0Kcvy4iuE Y9oEVtVsf63eWfwaoFd28vFcnu7hPdfquKGD1Ba0Pk5F5szf6vTvNjBMKIMdmuf3uP32 ujwB+T4l+usV5FYtKQQZV/cHwQthRU7X6yw2bOvTn4MRAdMoo4xaOviGUlmM/NTls9g9 KVJbJ+C5rz796yC5OcJ93UUeeBuZH19BcPZVdKlnuHqkUFlOih1Gn5t39pFMyfY821NK 4nSElmqLombH2vfnt1u08TBkAZ7H7isKKMIQk+Fv4cUDCQzF2fQdXFHk3eO3nmrqP/KW pIAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dO1X1bqI; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mi3si18856725pjb.115.2022.01.16.22.55.45; Sun, 16 Jan 2022 22:55:57 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dO1X1bqI; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234980AbiAPLwY (ORCPT + 99 others); Sun, 16 Jan 2022 06:52:24 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:45128 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232933AbiAPLwX (ORCPT ); Sun, 16 Jan 2022 06:52:23 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2B5C8B80978; Sun, 16 Jan 2022 11:52:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBDF3C36AE7; Sun, 16 Jan 2022 11:52:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642333940; bh=Nn5UlheFW3tQqA1zQjKnG0yVDgckawJTxXhXNb922+w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dO1X1bqItNZ+Swz4EtWfTIvkT02D1BqOWTiVxq4XpfymW2m89Q8BJipQBzwdVDcjg +UAYBO2I5FBYlRTCiWsVcccOpfHHanDJtluv7W7ocm5X8mj3cB0f/x7D/6WT+RttUB /9t976qnKrEkm+EBa1t+iy2cVjsOFCWWZR3iqfQ5mbUVb+k6SJ59QdqiMxC+XMVBDJ G+rKqIzivpfV8hjahhHBIJTGkAfMU6SdA6jrhoQls7pFOs33tsK5I8kAh6DWBNA9PK 3zMfHAylOnXQUYhqz2KlAEOomgVtgsIXdyASR0wOBJ17sA6IalfO5WocBLZJmLutnM X9Ty5Yw3eMwzg== Date: Sun, 16 Jan 2022 11:58:21 +0000 From: Jonathan Cameron To: Oleksij Rempel Cc: devicetree@vger.kernel.org, Lars-Peter Clausen , linux-iio@vger.kernel.org, Robin van der Gracht , linux-kernel@vger.kernel.org, Pengutronix Kernel Team , David Jander Subject: Re: [PATCH v1 1/1] iio: adc: tsc2046: fix memory corruption by preventing array overflow Message-ID: <20220116115821.1d58b437@jic23-huawei> In-Reply-To: <20220115181659.0c759ec5@jic23-huawei> References: <20220107081401.2816357-1-o.rempel@pengutronix.de> <20220109152557.74f06d2d@jic23-huawei> <20220110071945.GB3326@pengutronix.de> <20220115181659.0c759ec5@jic23-huawei> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 15 Jan 2022 18:16:59 +0000 Jonathan Cameron wrote: > On Mon, 10 Jan 2022 08:19:45 +0100 > Oleksij Rempel wrote: > > > Hi Jonathan, > > > > On Sun, Jan 09, 2022 at 03:25:57PM +0000, Jonathan Cameron wrote: > > > On Fri, 7 Jan 2022 09:14:01 +0100 > > > Oleksij Rempel wrote: > > > > > > > On one side we have indio_dev->num_channels includes all physical channels + > > > > timestamp channel. On other side we have an array allocated only for > > > > physical channels. So, fix memory corruption by ARRAY_SIZE() instead of > > > > num_channels variable. > > > > > > > > Fixes: 9374e8f5a38d ("iio: adc: add ADC driver for the TI TSC2046 controller") > > > > Signed-off-by: Oleksij Rempel > > > Hi Olesij, > > > > > > Have you managed to make this occur, or is it inspection only? > > > > Yes, this bug has eaten my rx_one and tx_one pointers on probe. I wonted > > to use this buffers for read_raw and noticed that they do not exist. > > I got hung up on the first case and failed to notice the second one was > entirely different :( > > > > > > I 'think' (it's been a while since I looked at the particular code) that the timestamp > > > bit in active_scan_mask will never actually be set because we handle that as a > > > separate flag. > > > > I didn't tested if active_scan_mask will trigger this issue as well, but > > It it looked safer to me, to avoid this issue in both places. Even if on > > of it is only theoretical. > > It certainly does no harm to not check a bit that is never set, so I'm fine with > the change - just don't want to have lots of 'fixes' for this in other drivers > adding noise and pointless backports. This one is fine because we need the > other part of the patch anyway. > > Jonathan On that note, applied to the fixes-togreg branch of iio.git and marked for stable with a minor addition to the patch description to make sure we don't get the first case cargo picked up by anyone who doesn't read this thread as something to 'fix' everywhere else. Thanks, Jonathan > > > > > > > So it is indeed an efficiency improvement to not check that bit but I don't think > > > it's a bug to do so. More than possible I'm missing something though! > > > > > > This one had me quite worried when I first read it because this is a very common > > > pattern to see in IIO drivers. > > > > I was thinking about this as well, because big part of this code was > > inspired by other drivers. But i didn't reviewed other places so far. > > > > Regards, > > Oleksij >