[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20210105121016.ritlzseyjprh5rhg@holly.lan>
Date: Tue, 5 Jan 2021 12:10:16 +0000
From: Daniel Thompson <daniel.thompson@...aro.org>
To: bodefang <bodefang@....com>
Cc: jason.wessel@...driver.com, dianders@...omium.org, arnd@...db.de,
gregkh@...uxfoundation.org, kgdb-bugreport@...ts.sourceforge.net,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kgdbts: Passing ekgdbts to command line causes panic
Please avoid top posting. Threads on LKML are typically presented as
follows.
On Tue, Jan 05, 2021 at 11:21:38AM +0800, bodefang wrote:
> At 2021-01-04 19:28:54, "Daniel Thompson" <daniel.thompson@...aro.org>
> wrote:
> >On Mon, Dec 28, 2020 at 09:58:58AM +0800, Defang Bo wrote:
> >> Similar to commit<1bd54d851f50>("kgdboc: Passing ekgdboc to command
> >> line causes panic"), kgdbts_option_setup does not check input
> >> argument before passing it to strlen. The argument would be a NULL
> >> pointer.
> >
> > Something seems to be missing here.
> >
> > The ekgdbts parameter mentioned in the subject line doesn't exist so
> > how can including it on the kernel command line could provoke a
> > panic.
> >
> > Please can you share the kernel boot arguments you used when you
> > tested this patch?
>
> I use static analysis tool to find these funcs are similar to the
> commit<1bd54d851f50>(kgdboc: Passing ekgdboc to command line causes
> panic), so it's just defensive, I haven't actually hitted this but
> there actually seems a problem here.
I don't see how a problem that occured when ekgdboc is parsed can occur
because this module does not parse ekgdbts! Are there really any
circumstances where kgdbts_option_setup() can be called with a NULL
argument?
Daniel.
Powered by blists - more mailing lists