linux-kernel - Re: [PATCH] soc: aspeed: Add NULL pointer check in aspeed_lpc_enable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8e6c7913fda39baa50309886f9f945864301660f.camel@codeconstruct.com.au>
Date: Thu, 13 Feb 2025 12:09:42 +1030
From: Andrew Jeffery <andrew@...econstruct.com.au>
To: Chenyuan Yang <chenyuan0y@...il.com>
Cc: joel@....id.au, richardcochran@...il.com, 
	linux-arm-kernel@...ts.infradead.org, linux-aspeed@...ts.ozlabs.org, 
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] soc: aspeed: Add NULL pointer check in
 aspeed_lpc_enable_snoop()

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@...econstruct.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@...il.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