Received-SPF: pass (google.com: domain of linux-kernel+bounces-51574-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240109145121.8850-1-rand.sec96@gmail.com> <CAHb3i=ttHrFw7NuL3qw1xdXDkGu9tOQdH+WuCMWgukmU6QrTKA@mail.gmail.com>
 <111837c6-6c60-4bd4-9e66-1c652a43f3ae-pchelkin@ispras.ru> <Zb6luAVHcnX2fXz3@shikoro>
 <f5f26a7d-973a-4232-b0cb-b0543fddefe0-pchelkin@ispras.ru>
In-Reply-To: <f5f26a7d-973a-4232-b0cb-b0543fddefe0-pchelkin@ispras.ru>
From: Rand Deeb <rand.sec96@gmail.com>
Date: Sun, 4 Feb 2024 13:12:17 +0300
Message-ID: <CAN8dotnOgU5cgi3y3f74=bJQt_G7qKpP9imB+REvT7AUeFbQ2Q@mail.gmail.com>
Subject: Re: Re: Re: [lvc-project] [PATCH] i2c: Fix NULL pointer dereference
 in npcm_i2c_reg_slave
To: Fedor Pchelkin <pchelkin@ispras.ru>
Cc: Wolfram Sang <wsa@kernel.org>, Tali Perry <tali.perry1@gmail.com>, lvc-project@linuxtesting.org, 
	voskresenski.stanislav@confident.ru, Benjamin Fair <benjaminfair@google.com>, 
	Avi Fishman <avifishman70@gmail.com>, Patrick Venture <venture@google.com>, openbmc@lists.ozlabs.org, 
	linux-kernel@vger.kernel.org, Nancy Yuen <yuenn@google.com>, linux-i2c@vger.kernel.org, 
	deeb.rand@confident.ru, Tomer Maimon <tmaimon77@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 4, 2024 at 11:54=E2=80=AFAM Fedor Pchelkin <pchelkin@ispras.ru>=
 wrote:
>
> On 24/02/03 09:44PM, Wolfram Sang wrote:
> >
> > > If I'm not missing something, npcm_i2c_reg_slave() is called via a
> > > function pointer ->reg_slave here [1]. And seems `client` can't be NU=
LL
> > > there. Other drivers implementing ->reg_slave function don't check it=
s
> > > argument.
> >
> > Correct, we trust ourselves here.
> >
> > > Maybe we should just drop `if (!bus->slave)` check?
> >
> > Yes.
> >
>
> Okay, thanks for confirmation.
>
> Rand, would you like to prepare the patch, please?
>

Hi Fedor!,

Sure, In fact, there were two scenarios from the beginning, either
redundant condition or potential NULL pointer dereference.I relied on
the condition to determine the type of issue because I did not find
it logical to add a useless condition, but based on the Wolfram Sang
words "we trust ourselves here." then the scenario will change to
redundant condition, so i'll write a new patch and send it in new
thread.