Message ID | 20240301190425.120605-1-m.lobanov@rosalinux.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-88994-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:fa17:b0:10a:f01:a869 with SMTP id ju23csp94013dyc; Fri, 1 Mar 2024 11:06:32 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWhbakCBjPrVDPxj0fWAEUMeK/MHslGBEJxYux69SZhzPnf1gtks/Ip0bZwO3PPteOS9othxadWkXvBTe+V89yeRrOeIw== X-Google-Smtp-Source: AGHT+IEtiInO77jLM6DGfoFTCHUm3EBNx6BWG7zhO3WHo2KfmouHIL6/dkcvB/igsQMFHl/ngdHr X-Received: by 2002:a05:6512:2208:b0:512:9c37:97fc with SMTP id h8-20020a056512220800b005129c3797fcmr2199004lfu.57.1709319991794; Fri, 01 Mar 2024 11:06:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709319991; cv=pass; d=google.com; s=arc-20160816; b=mcE9Wj1FrEyJDH5Bsq57t7llXCRme2NQ7+hzGokVi+MeXygSMpeZyRol5yK2sP3Uzn PNp+mhBXuA+QwJF/x0ycS//68Br6Dp9MYhEZnUqKB35JeCiL9I4apBvhvYYsAiWoLo2E Oxv5ZdFe5szZF2ISYOLUv+EhwCEYz09OIb5at595zwDv4ml/9Tp9gJhWfdV8/Nckwdep 78Ge7XAc4QYpXw9fh2IQm/lJIfsRiBczn3+tMrol0nP5LbRepQCfIVJz1VfkX8wqqVwS VcKG+gnSUYsSCv3S6WFfZCmdu/VxedriFsu0p+HQ+OJLT7FeHnyaOksIVuNWdAZrLh1y Nhmw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature:dkim-filter; bh=kclR9O1Au8wRehRzcfqdqVCqhOZ+OqTDy0X/Usb2D9w=; fh=inwLR9lYdB5i3HbF6N4JscuZL9tLV6nLA90JX1XQmm0=; b=sL5VjrmzgWVbBX6m/be9THHp6Tv92h28t3Fq+rfiDDMkb/aWJ0AX9+ZB+l2CIxWCBM FIXztQOrhAroaGaL7IBQ7zaKJE6ZisTYysd7apS+wPaysN5jU05P7JhP+P1uULfVIZeF kDspSJs4Nq1mvCDLHHZ9IBOhCcxhTk6/aaxTeuHmXCBr0X2aHRDd1Iqa4byqEg5s2sx6 VFqgF34TpJ5sOXqZ7r1uXpZ6kOps2G4Dzi2T2O3odh5Qb/CAx8GNF14lAMxOR/cjxpMI 9/FIOA+GavOL4Hn/ZPfTUyhEekFQslVPOJW9I1L44hXgDFv8gq2er0FuFRqRwR/kOK9B J8zg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@rosalinux.ru header.s=1D4BB666-A0F1-11EB-A1A2-F53579C7F503 header.b=LpF0qO4U; arc=pass (i=1 spf=pass spfdomain=rosalinux.ru dkim=pass dkdomain=rosalinux.ru dmarc=pass fromdomain=rosalinux.ru); spf=pass (google.com: domain of linux-kernel+bounces-88994-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88994-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=rosalinux.ru Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id e25-20020a1709062c1900b00a4452b31420si1378821ejh.246.2024.03.01.11.06.31 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 11:06:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-88994-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@rosalinux.ru header.s=1D4BB666-A0F1-11EB-A1A2-F53579C7F503 header.b=LpF0qO4U; arc=pass (i=1 spf=pass spfdomain=rosalinux.ru dkim=pass dkdomain=rosalinux.ru dmarc=pass fromdomain=rosalinux.ru); spf=pass (google.com: domain of linux-kernel+bounces-88994-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88994-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=rosalinux.ru Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 692A01F25AD4 for <ouuuleilei@gmail.com>; Fri, 1 Mar 2024 19:06:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E8F423A1B0; Fri, 1 Mar 2024 19:06:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rosalinux.ru header.i=@rosalinux.ru header.b="LpF0qO4U" Received: from mail.rosalinux.ru (mail.rosalinux.ru [195.19.76.54]) (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 596D524B23 for <linux-kernel@vger.kernel.org>; Fri, 1 Mar 2024 19:06:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.19.76.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709319979; cv=none; b=JqYCeK0WCERioZ+cei6Bu9nJlu/KNV4mtJYAfrwuu65EOthFuwLEFloCyaeStO34Wr5/eyEfgpkUj/o63bYLYcrjpQ1Kk21kkLSGHyX+oZ0IcVLmGi3kXHz2eUi/9vq6CpFKREaulJX9JyayCMt9DRyow9KTHCTFRWQClgz12do= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709319979; c=relaxed/simple; bh=fBKQb/U2gC/96fp2K2GWljmoZQn9BibE1AkFqiHeIUI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=IlKDUMo3XMqlOdnIYVLvuX3CH6szzvMsO7pWYUYbFNf7ibBcodjdEonyu7G/p83a+INWnThpaPWm+HVV129Cy0v6CqEGeFOf36v9Dh8TkaXIhUgk0/5lfFAXiIPTqjNTX5B82gdKdJskLy5PCZsCxPc0jB7tFpyl/M8xApE2hc4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=rosalinux.ru; spf=pass smtp.mailfrom=rosalinux.ru; dkim=pass (2048-bit key) header.d=rosalinux.ru header.i=@rosalinux.ru header.b=LpF0qO4U; arc=none smtp.client-ip=195.19.76.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=rosalinux.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rosalinux.ru Received: from localhost (localhost [127.0.0.1]) by mail.rosalinux.ru (Postfix) with ESMTP id 18082DCE59BB9; Fri, 1 Mar 2024 22:06:09 +0300 (MSK) Received: from mail.rosalinux.ru ([127.0.0.1]) by localhost (mail.rosalinux.ru [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 67HJQtmzNR1y; Fri, 1 Mar 2024 22:06:08 +0300 (MSK) Received: from localhost (localhost [127.0.0.1]) by mail.rosalinux.ru (Postfix) with ESMTP id D9520DCE59BBA; Fri, 1 Mar 2024 22:06:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rosalinux.ru D9520DCE59BBA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rosalinux.ru; s=1D4BB666-A0F1-11EB-A1A2-F53579C7F503; t=1709319968; bh=kclR9O1Au8wRehRzcfqdqVCqhOZ+OqTDy0X/Usb2D9w=; h=From:To:Date:Message-ID:MIME-Version; b=LpF0qO4UY3zq8WFvfMYTDR419wAIeTTaU+28M4bjF48HF3Fk8cLVDiUVvukA6S3xf LQV5kmSoorpDoEVfmqbF3di3udKnRg4jYZ1IGQ3AXGiMtk6Rit5sfp6Z3LjbacGNRL w2v2AClGz6r4CWLWnTyazNB7IGiIU5ajLdpKUcgdyf1XoBA2+oBUOTSvr/Sqg0s2wj XVpUGrzUB8pYNuzUIt1s10sCFq1tXQnW0qkmRIX4eRQapHb215i5a+lXfW0AufIL5i RUXTL2+VtxS3tRvt0MJEf4ERbuAqjfuLyjsxHAsTGok1lJ86W88XUQ2OVijDjxIGSS 2PazYN5T3KB3A== X-Virus-Scanned: amavisd-new at rosalinux.ru Received: from mail.rosalinux.ru ([127.0.0.1]) by localhost (mail.rosalinux.ru [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VQ-MjpTfyj7b; Fri, 1 Mar 2024 22:06:08 +0300 (MSK) Received: from localhost.localdomain (unknown [62.217.186.174]) by mail.rosalinux.ru (Postfix) with ESMTPSA id A728DDCE59BB9; Fri, 1 Mar 2024 22:06:08 +0300 (MSK) From: Mikhail Lobanov <m.lobanov@rosalinux.ru> To: Rui Miguel Silva <rmfrfs@gmail.com> Cc: Mikhail Lobanov <m.lobanov@rosalinux.ru>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH] greybus: Fix deref of NULL in __gb_lights_flash_brightness_set Date: Fri, 1 Mar 2024 14:04:24 -0500 Message-ID: <20240301190425.120605-1-m.lobanov@rosalinux.ru> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792351919205996772 X-GMAIL-MSGID: 1792351919205996772 |
Series |
greybus: Fix deref of NULL in __gb_lights_flash_brightness_set
|
|
Commit Message
Mikhail Lobanov
March 1, 2024, 7:04 p.m. UTC
Dereference of null pointer in the __gb_lights_flash_brightness_set function.
Assigning the channel the result of executing the get_channel_from_mode function
without checking for NULL may result in an error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
Signed-off-by: Mikhail Lobanov <m.lobanov@rosalinux.ru>
---
drivers/staging/greybus/light.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
Comments
On Fri, Mar 01, 2024 at 02:04:24PM -0500, Mikhail Lobanov wrote: > Dereference of null pointer in the __gb_lights_flash_brightness_set function. > Assigning the channel the result of executing the get_channel_from_mode function > without checking for NULL may result in an error. get_channel_from_mode() can only return NULL when light->channels_count is zero. Although get_channel_from_mode() seems buggy to me. If it can't find the correct mode, it just returns the last channel. So potentially it should be made to return NULL. diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index d62f97249aca..acd435f5d25d 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -95,15 +95,15 @@ static struct led_classdev *get_channel_cdev(struct gb_channel *channel) static struct gb_channel *get_channel_from_mode(struct gb_light *light, u32 mode) { - struct gb_channel *channel = NULL; + struct gb_channel *channel; int i; for (i = 0; i < light->channels_count; i++) { channel = &light->channels[i]; if (channel && channel->mode == mode) - break; + return channel; } - return channel; + return NULL; } static int __gb_lights_flash_intensity_set(struct gb_channel *channel,
On 3/2/24 3:59 AM, Dan Carpenter wrote: > On Fri, Mar 01, 2024 at 02:04:24PM -0500, Mikhail Lobanov wrote: >> Dereference of null pointer in the __gb_lights_flash_brightness_set function. >> Assigning the channel the result of executing the get_channel_from_mode function >> without checking for NULL may result in an error. > > get_channel_from_mode() can only return NULL when light->channels_count > is zero. > > Although get_channel_from_mode() seems buggy to me. If it can't > find the correct mode, it just returns the last channel. So potentially > it should be made to return NULL. I agree with you. This looks quite wrong to me, and I like your fix, *except* there is also no need to check whether the channel pointer is null inside the loop. It's the address of an object, and will always be non-null. static struct gb_channel * get_channel_from_mode(struct gb_light *light, u32 mode) { struct gb_channel *channel; u32 i; for (i = 0; i < light->channels_count; i++) { channel = &light->channels[i]; if (channel->mode == mode) return channel; } return NULL; } Rui, could you please confirm what Dan says (and his proposed change) was your intention? If so (and assuming you also fix the check for a null channel pointer inside the loop): Reviewed-by: Alex Elder <elder@linaro.org> -Alex > > diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c > index d62f97249aca..acd435f5d25d 100644 > --- a/drivers/staging/greybus/light.c > +++ b/drivers/staging/greybus/light.c > @@ -95,15 +95,15 @@ static struct led_classdev *get_channel_cdev(struct gb_channel *channel) > static struct gb_channel *get_channel_from_mode(struct gb_light *light, > u32 mode) > { > - struct gb_channel *channel = NULL; > + struct gb_channel *channel; > int i; > > for (i = 0; i < light->channels_count; i++) { > channel = &light->channels[i]; > if (channel && channel->mode == mode) > - break; > + return channel; > } > - return channel; > + return NULL; > } > > static int __gb_lights_flash_intensity_set(struct gb_channel *channel, > _______________________________________________ > greybus-dev mailing list -- greybus-dev@lists.linaro.org > To unsubscribe send an email to greybus-dev-leave@lists.linaro.org
Hi Mikhail, Thanks for your patch. Mikhail Lobanov <m.lobanov@rosalinux.ru> writes: > Dereference of null pointer in the __gb_lights_flash_brightness_set function. > Assigning the channel the result of executing the get_channel_from_mode function > without checking for NULL may result in an error. > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") > Signed-off-by: Mikhail Lobanov <m.lobanov@rosalinux.ru> Yeah, at the time when this was implemented I recall that we could only set the brightness of the torch mode in a flash led, not in the flash only mode. So, if we were getting here was that for sure we had a torch channel and get_channel_from_mode will always find a channel, so never returning null here. but yeah, this is safer. but maybe just do something like the bellow would be simpler: modified drivers/staging/greybus/light.c @@ -147,6 +147,9 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) channel = get_channel_from_mode(channel->light, GB_CHANNEL_MODE_TORCH); + if (!channel) + return -EINVAL; + /* For not flash we need to convert brightness to intensity */ intensity = channel->intensity_uA.min + (channel->intensity_uA.step * channel->led->brightness); what do you think? Cheers, Rui > --- > drivers/staging/greybus/light.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c > index 87d36948c610..929514350947 100644 > --- a/drivers/staging/greybus/light.c > +++ b/drivers/staging/greybus/light.c > @@ -148,10 +148,15 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) > GB_CHANNEL_MODE_TORCH); > > /* For not flash we need to convert brightness to intensity */ > - intensity = channel->intensity_uA.min + > + > + if (channel) { > + intensity = channel->intensity_uA.min + > (channel->intensity_uA.step * channel->led->brightness); > > - return __gb_lights_flash_intensity_set(channel, intensity); > + return __gb_lights_flash_intensity_set(channel, intensity); > + } > + > + return 0; > } > #else > static struct gb_channel *get_channel_from_cdev(struct led_classdev *cdev) > -- > 2.43.0
Alex Elder <elder@ieee.org> writes: Hey Alex, > On 3/2/24 3:59 AM, Dan Carpenter wrote: >> On Fri, Mar 01, 2024 at 02:04:24PM -0500, Mikhail Lobanov wrote: >>> Dereference of null pointer in the __gb_lights_flash_brightness_set function. >>> Assigning the channel the result of executing the get_channel_from_mode function >>> without checking for NULL may result in an error. >> >> get_channel_from_mode() can only return NULL when light->channels_count >> is zero. >> >> Although get_channel_from_mode() seems buggy to me. If it can't >> find the correct mode, it just returns the last channel. So potentially >> it should be made to return NULL. > > I agree with you. This looks quite wrong to me, and I > like your fix, *except* there is also no need to check > whether the channel pointer is null inside the loop. > It's the address of an object, and will always be non-null. > > static struct gb_channel * > get_channel_from_mode(struct gb_light *light, u32 mode) > { > struct gb_channel *channel; > u32 i; > > for (i = 0; i < light->channels_count; i++) { > channel = &light->channels[i]; > if (channel->mode == mode) > return channel; > } > return NULL; > } > > > Rui, could you please confirm what Dan says (and his > proposed change) was your intention? Yup, Dan is right. > > If so (and assuming you also fix the check for a null > channel pointer inside the loop): And you also here. > > Reviewed-by: Alex Elder <elder@linaro.org> Thanks. Cheers, Rui > > -Alex > >> >> diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c >> index d62f97249aca..acd435f5d25d 100644 >> --- a/drivers/staging/greybus/light.c >> +++ b/drivers/staging/greybus/light.c >> @@ -95,15 +95,15 @@ static struct led_classdev *get_channel_cdev(struct gb_channel *channel) >> static struct gb_channel *get_channel_from_mode(struct gb_light *light, >> u32 mode) >> { >> - struct gb_channel *channel = NULL; >> + struct gb_channel *channel; >> int i; >> >> for (i = 0; i < light->channels_count; i++) { >> channel = &light->channels[i]; >> if (channel && channel->mode == mode) >> - break; >> + return channel; >> } >> - return channel; >> + return NULL; >> } >> >> static int __gb_lights_flash_intensity_set(struct gb_channel *channel, >> _______________________________________________ >> greybus-dev mailing list -- greybus-dev@lists.linaro.org >> To unsubscribe send an email to greybus-dev-leave@lists.linaro.org
Dan Carpenter <dan.carpenter@linaro.org> writes: Hi Dan, > On Fri, Mar 01, 2024 at 02:04:24PM -0500, Mikhail Lobanov wrote: >> Dereference of null pointer in the __gb_lights_flash_brightness_set function. >> Assigning the channel the result of executing the get_channel_from_mode function >> without checking for NULL may result in an error. > > get_channel_from_mode() can only return NULL when light->channels_count > is zero. > > Although get_channel_from_mode() seems buggy to me. If it can't > find the correct mode, it just returns the last channel. So potentially > it should be made to return NULL. Correct, thanks for the fix. Will you or me send a proper patch for this? Taking also the suggestion from Alex. Thanks in advance. Cheers, Rui > > diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c > index d62f97249aca..acd435f5d25d 100644 > --- a/drivers/staging/greybus/light.c > +++ b/drivers/staging/greybus/light.c > @@ -95,15 +95,15 @@ static struct led_classdev *get_channel_cdev(struct gb_channel *channel) > static struct gb_channel *get_channel_from_mode(struct gb_light *light, > u32 mode) > { > - struct gb_channel *channel = NULL; > + struct gb_channel *channel; > int i; > > for (i = 0; i < light->channels_count; i++) { > channel = &light->channels[i]; > if (channel && channel->mode == mode) > - break; > + return channel; > } > - return channel; > + return NULL; > } > > static int __gb_lights_flash_intensity_set(struct gb_channel *channel,
On 3/1/24 1:04 PM, Mikhail Lobanov wrote: > Dereference of null pointer in the __gb_lights_flash_brightness_set function. > Assigning the channel the result of executing the get_channel_from_mode function > without checking for NULL may result in an error. > > Found by Linux Verification Center (linuxtesting.org) with SVACE. I think this is an actual problem but this might not be the right fix. The point of the call to get_channel_from_mode() is to get the attached torch channel if the passed-in channel is a flash channel. It's *possible* that any flash channel will *always* have an attached torch channel, but if so there ought to be a comment to that effect near this call (to explain why there's no need for the null pointer check). I think Dan's suggestion should be implemented as well. It's possible the intention really *was* to have get_channel_from_mode() return the original channel pointer if there is no attached channel with the requested mode. But if so, that should be done differently. I.e., Dan's suggestion should be taken, and the callers should use the passed-in channel if the call to get_channel_from_mode() returns NULL. (I hope that's clear.) So anyway, I think this (and Dan's suggestion) should be addressed, but your fix might not be correct. Rui, can you please shed some light on the situation? -Alex > > Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") > Signed-off-by: Mikhail Lobanov <m.lobanov@rosalinux.ru> > --- > drivers/staging/greybus/light.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c > index 87d36948c610..929514350947 100644 > --- a/drivers/staging/greybus/light.c > +++ b/drivers/staging/greybus/light.c > @@ -148,10 +148,15 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) > GB_CHANNEL_MODE_TORCH); > > /* For not flash we need to convert brightness to intensity */ > - intensity = channel->intensity_uA.min + > + > + if (channel) { > + intensity = channel->intensity_uA.min + > (channel->intensity_uA.step * channel->led->brightness); > > - return __gb_lights_flash_intensity_set(channel, intensity); > + return __gb_lights_flash_intensity_set(channel, intensity); > + } > + > + return 0; > } > #else > static struct gb_channel *get_channel_from_cdev(struct led_classdev *cdev)
Hi Alex, Alex Elder <elder@ieee.org> writes: > On 3/1/24 1:04 PM, Mikhail Lobanov wrote: >> Dereference of null pointer in the __gb_lights_flash_brightness_set function. >> Assigning the channel the result of executing the get_channel_from_mode function >> without checking for NULL may result in an error. >> >> Found by Linux Verification Center (linuxtesting.org) with SVACE. > > I think this is an actual problem but this might not be the > right fix. > > The point of the call to get_channel_from_mode() is to get > the attached torch channel if the passed-in channel is a > flash channel. It's *possible* that any flash channel will > *always* have an attached torch channel, but if so there > ought to be a comment to that effect near this call (to > explain why there's no need for the null pointer check). > > I think Dan's suggestion should be implemented as well. > It's possible the intention really *was* to have > get_channel_from_mode() return the original channel pointer > if there is no attached channel with the requested mode. > But if so, that should be done differently. I.e., Dan's > suggestion should be taken, and the callers should use the > passed-in channel if the call to get_channel_from_mode() > returns NULL. (I hope that's clear.) > > So anyway, I think this (and Dan's suggestion) should be > addressed, but your fix might not be correct. > > Rui, can you please shed some light on the situation? As we talked, this email was sent at the same time as my replies to this thread and you think I addressed your concerns in that replies. If not, just go ahead and ask again. Cheers, Rui > > -Alex > >> >> Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") >> Signed-off-by: Mikhail Lobanov <m.lobanov@rosalinux.ru> >> --- >> drivers/staging/greybus/light.c | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c >> index 87d36948c610..929514350947 100644 >> --- a/drivers/staging/greybus/light.c >> +++ b/drivers/staging/greybus/light.c >> @@ -148,10 +148,15 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) >> GB_CHANNEL_MODE_TORCH); >> >> /* For not flash we need to convert brightness to intensity */ >> - intensity = channel->intensity_uA.min + >> + >> + if (channel) { >> + intensity = channel->intensity_uA.min + >> (channel->intensity_uA.step * channel->led->brightness); >> >> - return __gb_lights_flash_intensity_set(channel, intensity); >> + return __gb_lights_flash_intensity_set(channel, intensity); >> + } >> + >> + return 0; >> } >> #else >> static struct gb_channel *get_channel_from_cdev(struct led_classdev *cdev)
On Sat, Mar 02, 2024 at 03:23:03PM +0000, Rui Miguel Silva wrote: > Dan Carpenter <dan.carpenter@linaro.org> writes: > Hi Dan, > > > On Fri, Mar 01, 2024 at 02:04:24PM -0500, Mikhail Lobanov wrote: > >> Dereference of null pointer in the __gb_lights_flash_brightness_set function. > >> Assigning the channel the result of executing the get_channel_from_mode function > >> without checking for NULL may result in an error. > > > > get_channel_from_mode() can only return NULL when light->channels_count > > is zero. > > > > Although get_channel_from_mode() seems buggy to me. If it can't > > find the correct mode, it just returns the last channel. So potentially > > it should be made to return NULL. > > Correct, thanks for the fix. Will you or me send a proper patch for > this? Taking also the suggestion from Alex. I'll send it. Thanks! regards, dan carpenter
On 3/2/24 9:31 AM, Alex Elder wrote: > On 3/1/24 1:04 PM, Mikhail Lobanov wrote: >> Dereference of null pointer in the __gb_lights_flash_brightness_set >> function. >> Assigning the channel the result of executing the >> get_channel_from_mode function >> without checking for NULL may result in an error. >> >> Found by Linux Verification Center (linuxtesting.org) with SVACE. > > I think this is an actual problem but this might not be the > right fix. The current API for get_channel_from_mode() allows a null pointer to be returned, but it seems that there is at least one case where that should never happen. gb_lights_light_v4l2_register() issues a WARN_ON() if get_channel_from_mode returns NULL (and then proceeds to dereference it). I know BUG_ON() isn't cool, but maybe we should avoid the dereference there. And other than __gb_lights_flash_brightness_set(), all callers properly handle a null pointer return. Regardless of what I said before about commenting for an impossible situation, I think your fix is generally the right thing to do, but it should not return 0 if there is no torch mode channel, it should return -EINVAL or something. Please consider, and post a new version. You could incorporate a similar change in the same patch for gb_lights_light_v4l2_register(). -Alex > The point of the call to get_channel_from_mode() is to get > the attached torch channel if the passed-in channel is a > flash channel. It's *possible* that any flash channel will > *always* have an attached torch channel, but if so there > ought to be a comment to that effect near this call (to > explain why there's no need for the null pointer check). > > I think Dan's suggestion should be implemented as well. > It's possible the intention really *was* to have > get_channel_from_mode() return the original channel pointer > if there is no attached channel with the requested mode. > But if so, that should be done differently. I.e., Dan's > suggestion should be taken, and the callers should use the > passed-in channel if the call to get_channel_from_mode() > returns NULL. (I hope that's clear.) > > So anyway, I think this (and Dan's suggestion) should be > addressed, but your fix might not be correct. > > Rui, can you please shed some light on the situation? > > -Alex > >> >> Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") >> Signed-off-by: Mikhail Lobanov <m.lobanov@rosalinux.ru> >> --- >> drivers/staging/greybus/light.c | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/staging/greybus/light.c >> b/drivers/staging/greybus/light.c >> index 87d36948c610..929514350947 100644 >> --- a/drivers/staging/greybus/light.c >> +++ b/drivers/staging/greybus/light.c >> @@ -148,10 +148,15 @@ static int >> __gb_lights_flash_brightness_set(struct gb_channel *channel) >> GB_CHANNEL_MODE_TORCH); >> /* For not flash we need to convert brightness to intensity */ >> - intensity = channel->intensity_uA.min + >> + >> + if (channel) { >> + intensity = channel->intensity_uA.min + >> (channel->intensity_uA.step * channel->led->brightness); >> - return __gb_lights_flash_intensity_set(channel, intensity); >> + return __gb_lights_flash_intensity_set(channel, intensity); >> + } >> + >> + return 0; >> } >> #else >> static struct gb_channel *get_channel_from_cdev(struct led_classdev >> *cdev) >
On 3/2/24 10:35 AM, Rui Miguel Silva wrote: >> So anyway, I think this (and Dan's suggestion) should be >> addressed, but your fix might not be correct. >> >> Rui, can you please shed some light on the situation? > As we talked, this email was sent at the same time as my replies to > this thread and you think I addressed your concerns in that replies. > If not, just go ahead and ask again. Yes. You said the intention was to return null if not found (rather than "the passed-in value as default"). So that bug should be fixed. Dan says he'll re-send that. Either way, even if it's practically impossible, the get_channel_from_mode() *can* return NULL, therefore __gb_lights_flash_brightness_set() should be fixed to avoid dereferencing the return value in such a case. -Alex
diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index 87d36948c610..929514350947 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -148,10 +148,15 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) GB_CHANNEL_MODE_TORCH); /* For not flash we need to convert brightness to intensity */ - intensity = channel->intensity_uA.min + + + if (channel) { + intensity = channel->intensity_uA.min + (channel->intensity_uA.step * channel->led->brightness); - return __gb_lights_flash_intensity_set(channel, intensity); + return __gb_lights_flash_intensity_set(channel, intensity); + } + + return 0; } #else static struct gb_channel *get_channel_from_cdev(struct led_classdev *cdev)