[PATCH] soc: aspeed: Add NULL pointer check in aspeed_lpc_enable_snoop()

[Andrew Jeffery]

On Wed, 2025-02-12 at 19:37 -0600, Chenyuan Yang wrote:
> Hi Andrew,
> 
> Thanks for your prompt reply!
> 
> On Wed, Feb 12, 2025 at 6:21 PM Andrew Jeffery
> <andrew at codeconstruct.com.au> wrote:
> > 
> > Hi Chenyuan,
> > 
> > On Wed, 2025-02-12 at 15:25 -0600, Chenyuan Yang wrote:
> > > lpc_snoop->chan[channel].miscdev.name could be NULL, thus,
> > > a pointer check is added to prevent potential NULL pointer
> > > dereference.
> > > This is similar to the fix in commit 3027e7b15b02
> > > ("ice: FiI am cx some null pointer dereference issues in ice_ptp.c").
> > > 
> > > This issue is found by our static analysis tool.
> > > 
> > > Signed-off-by: Chenyuan Yang <chenyuan0y at gmail.com>
> > > ---
> > >  drivers/soc/aspeed/aspeed-lpc-snoop.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/soc/aspeed/aspeed-lpc-snoop.c
> > > b/drivers/soc/aspeed/aspeed-lpc-snoop.c
> > > index 9ab5ba9cf1d6..376b3a910797 100644
> > > --- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
> > > +++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
> > > @@ -200,6 +200,8 @@ static int aspeed_lpc_enable_snoop(struct
> > > aspeed_lpc_snoop *lpc_snoop,
> > >         lpc_snoop->chan[channel].miscdev.minor = MISC_DYNAMIC_MINOR;
> > >         lpc_snoop->chan[channel].miscdev.name =
> > >                 devm_kasprintf(dev, GFP_KERNEL, "%s%d", DEVICE_NAME,
> > > channel);
> > > +       if (!lpc_snoop->chan[channel].miscdev.name)
> > > +               return -ENOMEM;
> > 
> > This introduces yet another place where the driver leaks resources in
> > an error path (in this case, the channel kfifo). The misc device also
> > gets leaked later on. It would be nice to address those first so that
> > handling this error can take the appropriate cleanup path.
> > 
> > Andrew
> 
> It seems that the `aspeed_lpc_enable_snoop()` function originally does
> not have a cleanup path. For example, if `misc_register` fails, the
> function directly returns rc without performing any cleanup.
> Similarly, when the `channel` has its default value, the function
> simply returns -EINVAL.
> 
> Given this, I am wondering whether it would be a good idea to
> introduce a cleanup path. If so, should we ensure cleanup for all
> possible exit points?

Yes please!

Thanks,

Andrew