From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E92B175A6B for ; Sat, 11 Apr 2026 19:28:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775935692; cv=none; b=gsMeN1/RN9XiwarthPMOtG0gdW6enlG6jD72PiiA+9MgRfryhqRoeOXyyiab+wP1tqy/ZFo7IIJqONqz8SXD309SSw3C0YBTu73p5oMVZrjm9TG2jPT08R9Whn2Uvsj8/iVM0RuHAcEKw4bdZw/yGRaebn3TCbDHUCGkNC+vHNE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775935692; c=relaxed/simple; bh=2sNIdWrd945IOGQtxtsSGClheuILfCTJ1X0VSYffb3Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ls2aVy0ypmsWT65Hn94S2ApjAKmqQPrK35VTgMPbDTY3BNyb0C6rCZ1BMSHsxTIKW9Ihb38kFYeqBfBYyzCHgdWjYoyMxAclK4Wlfl6wud2fHPWvQQYPMwYUm/HqeX+onfZ9hYdkwgRCM9Abtc0J8J/k+KKJ5lF+8jEO7Ry4qo0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b=OfD8PSMf; arc=none smtp.client-ip=209.85.160.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b="OfD8PSMf" Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-40f1ffba6a0so2367108fac.0 for ; Sat, 11 Apr 2026 12:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1775935689; x=1776540489; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=AyJL0kUnDxM6166F9pMjNO09u6R1nYa0DYiABdU9bA4=; b=OfD8PSMf+n1pf8O8cg9Kh/rmckbNCsJsvUXIwXeNuTYMSND320timfkaRKr1pBEX79 cyBF0GEeq6ZPp0hSQHV9legUtafhj77bJbm+2HTqOkW7FstqKtnftaprc+B+LSJH8NOv S88FC9fq7CwGaPTiy+vcGjnZfvDy7zZYkGhC2JvFpddwWbbhwLMLvPaBh7BiNUNAi4vr GeFerurGSYvi0FyfHzE+dBYxEPhh1u74ov/D42y1VmSlxDDIcToBc8HT/QBxd8c9niLw 4N2afyGQ+FeF6dwE+WWtbWJTn2osJ7Td/GtSrtUl+N0u6lIGF+4oL7unASXbQzQWZ4DQ cgZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775935689; x=1776540489; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AyJL0kUnDxM6166F9pMjNO09u6R1nYa0DYiABdU9bA4=; b=HozhiKTp62t2zOPcu+oolROQqD0QaBr8Yx2I5FPVxD0Ms+zMRwxLE2wf0BUO3Du2wY ZPuk1XgWYfSi6Z7G5wr26KLINVjKqRBVcFmYk2UznTZOapdTYOny8go1T7w/LJdnD6r7 eshfTPcaE4B+xxgCNzlv48L/jCC9w3pzm6J3ZSkdEYA86WPvv7EZ3ZD2Cfb3qHEY/zSV qTrddjbHE7rVPGr3J+suJlu6crxtgUD8pMeGAUzq50//fwfGT4UlKH9xgH03Bw40487/ 12nqLkcdELadP+VGTK4JVx3xc0etqFOFt/UGKFKvv3tn8YGXJSdbK/l9ERRm9SjcicX2 OOMA== X-Forwarded-Encrypted: i=1; AJvYcCX4a1lFVzTy/J5bUd6QR5ylYOHdQfQvG5XFDnJRaKKsh7IA0WIiyklLf2jguV0M8J9nQPpgAlT0IvbT9Vs=@vger.kernel.org X-Gm-Message-State: AOJu0YwqlrRZx7pzkdYlP2hgCz35MgPzSoEFpjWOa400WxQpNOSp6+Oj JyLG1GLdssUxmMyx2/u/brUtBnXM8X3MvY/Hq6Vn039yueIe6a1/ycr/KjfRnxVMxcM= X-Gm-Gg: AeBDievDHYv1D0aiDgiA2ErXQqqqqIwZ2QdlECv/royi77YDu7Vzc05T+VXPuJdId8F wwTYmRc/niT24IEhPnf4E02xU+3hJq44pAuoxr6r+/2ejd09epURfCiu3R4NLIciXcbsKRpyl+z aPVoha1XuFInhE1hXaJmWbB6si9Qzh65bK/PVk0WtRD8oSAv/HpJlqANpDKFtmH0BwDx0B3GtlB 32Gd/R7fPV6LkcJ57yZP7wcoUB4BV/w5uAUMQArrwGatfTG1Z6GfVPIomm2nXLVAYOCA+PZejhe WH8CIxcanIibpiGK50AL7WtCw2tJ1G0V+qor1KysQmmm2revUqKNOceWG9QZz6GYG1X/cPKNUVQ RFWhDWomFNBOO6Bmv22fMID0gVDvXZCx/KSopf9QXRs/Gt02De6VRQhFHrQ/mv42P2dwD6VlJG/ HxecL4OvB5ivDS5zot+SlvFEQLN/C+GuAfdDxXD4fbap4DHQrw8R1cQnozxowa9/PFxNVlsevbd mhQKj4rN0wr X-Received: by 2002:a05:6870:d06:b0:422:f606:1420 with SMTP id 586e51a60fabf-423e113c410mr4250749fac.34.1775935689020; Sat, 11 Apr 2026 12:28:09 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:500:d2e5:c81c:5b23:fe55? ([2600:8803:e7e4:500:d2e5:c81c:5b23:fe55]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-423dd420bd2sm4761399fac.6.2026.04.11.12.28.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Apr 2026 12:28:08 -0700 (PDT) Message-ID: Date: Sat, 11 Apr 2026 14:28:07 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] iio: imu: bmi323: Fix potential out-of-bounds access of bmi323_hw[] To: gerben@altlinux.org, jagathjog1996@gmail.com Cc: jic23@kernel.org, nuno.sa@analog.com, andy@kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org References: <20260327103202.459143-1-gerben@altlinux.org> Content-Language: en-US From: David Lechner In-Reply-To: <20260327103202.459143-1-gerben@altlinux.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/27/26 5:32 AM, gerben@altlinux.org wrote: > From: Denis Rastyogin > > The bmi323_channels[] array defines a channel with chan->type = > IIO_TEMP and enables the IIO_CHAN_INFO_SCALE mask. As a result, > bmi323_write_raw() may be called for this channel. However, > bmi323_iio_to_sensor() returns -EINVAL for IIO_TEMP, and if this > value is not validated, it can lead to an out-of-bounds access > when used as an array index. > > A similar case is properly handled in bmi323_read_raw() and does > not result in an error. > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > Fixes: 8a636db3aa57 ("iio: imu: Add driver for BMI323 IMU") > Signed-off-by: Denis Rastyogin > --- > drivers/iio/imu/bmi323/bmi323_core.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/iio/imu/bmi323/bmi323_core.c b/drivers/iio/imu/bmi323/bmi323_core.c > index 6bcb9a436581..64ead4f667e0 100644 > --- a/drivers/iio/imu/bmi323/bmi323_core.c > +++ b/drivers/iio/imu/bmi323/bmi323_core.c > @@ -1713,6 +1713,8 @@ static int bmi323_write_raw(struct iio_dev *indio_dev, > iio_device_release_direct(indio_dev); > return ret; > case IIO_CHAN_INFO_SCALE: > + if (chan->type == IIO_TEMP) > + return -EINVAL; > if (!iio_device_claim_direct(indio_dev)) > return -EBUSY; > ret = bmi323_set_scale(data, bmi323_iio_to_sensor(chan->type), This is OK, but why not check and propagate the error return? case IIO_CHAN_INFO_SCALE: ret = bmi323_iio_to_sensor(chan->type); if (ret < 0) return ret; if (!iio_device_claim_direct(indio_dev)) return -EBUSY; ret = bmi323_set_scale(data, ret, val, val2); ... And even if we shouldn't hit the error in other case statements, it seems like it would be good practice to still check for error there too.