[PATCH] Avoid potential NULL deref in scripts/genksyms/lex.l

[PATCH] Avoid potential NULL deref in scripts/genksyms/lex.l

[Jesper Juhl]

strchr() returns NULL in case the string is not found and if that 
happens we risk dereferencing a NULL pointer. It never hurts to 
check for that condition and exit normally with an error rather 
than crashing.

(no, the indentation is not according to CodingStyle, it's simply 
 following whatever else is in that file)


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 scripts/genksyms/lex.l        |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/genksyms/lex.l b/scripts/genksyms/lex.l
index 5e544a0..28edc0c 100644
--- a/scripts/genksyms/lex.l
+++ b/scripts/genksyms/lex.l
@@ -154,6 +154,8 @@ repeat:
 
       file = strchr(yytext, '\"')+1;
       e = strchr(file, '\"');
+      if (!file || !e)
+	exit(1);
       *e = '\0';
       cur_filename = memcpy(xmalloc(e-file+1), file, e-file+1);
       cur_line = atoi(yytext+2);

Re: [PATCH] Avoid potential NULL deref in scripts/genksyms/lex.l

[Andrew Morton]

On Sun, 24 Jun 2007 23:40:03 +0200 Jesper Juhl <jesper.juhl@gmail.com> wrote:

> strchr() returns NULL in case the string is not found and if that 
> happens we risk dereferencing a NULL pointer. It never hurts to 
> check for that condition and exit normally with an error rather 
> than crashing.
> 
> (no, the indentation is not according to CodingStyle, it's simply 
>  following whatever else is in that file)
> 
> 
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> ---
> 
>  scripts/genksyms/lex.l        |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/scripts/genksyms/lex.l b/scripts/genksyms/lex.l
> index 5e544a0..28edc0c 100644
> --- a/scripts/genksyms/lex.l
> +++ b/scripts/genksyms/lex.l
> @@ -154,6 +154,8 @@ repeat:
>  
>        file = strchr(yytext, '\"')+1;
>        e = strchr(file, '\"');

If `file' can be null we'd have oopsed here.

> +      if (!file || !e)
> +	exit(1);
>        *e = '\0';
>        cur_filename = memcpy(xmalloc(e-file+1), file, e-file+1);
>        cur_line = atoi(yytext+2);

I don't think the bug which you're fixing can occur:

^#[ \t]+{INT}[ \t]+\"[^\"\n]+\".*\n     return FILENAME;

has anyone reported crashes in there?

Re: [PATCH] Avoid potential NULL deref in scripts/genksyms/lex.l

[Jesper Juhl]

On 24/06/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sun, 24 Jun 2007 23:40:03 +0200 Jesper Juhl <jesper.juhl@gmail.com> wrote:
>
> > strchr() returns NULL in case the string is not found and if that
> > happens we risk dereferencing a NULL pointer. It never hurts to
> > check for that condition and exit normally with an error rather
> > than crashing.
> >
> > (no, the indentation is not according to CodingStyle, it's simply
> >  following whatever else is in that file)
> >
> >
> > Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> > ---
> >
> >  scripts/genksyms/lex.l        |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/scripts/genksyms/lex.l b/scripts/genksyms/lex.l
> > index 5e544a0..28edc0c 100644
> > --- a/scripts/genksyms/lex.l
> > +++ b/scripts/genksyms/lex.l
> > @@ -154,6 +154,8 @@ repeat:
> >
> >        file = strchr(yytext, '\"')+1;
> >        e = strchr(file, '\"');
>
> If `file' can be null we'd have oopsed here.
>
> > +      if (!file || !e)
> > +     exit(1);
> >        *e = '\0';
> >        cur_filename = memcpy(xmalloc(e-file+1), file, e-file+1);
> >        cur_line = atoi(yytext+2);
>
> I don't think the bug which you're fixing can occur:
>
> ^#[ \t]+{INT}[ \t]+\"[^\"\n]+\".*\n     return FILENAME;
>
> has anyone reported crashes in there?
>

It may indeed not be possible. Found by inspection, not by any actual
observed crashes.
But does it really hurt to be defensive here? In case it can somehow
be caused to fail, with my patch it'll fail a bit nicer :) It's not
like it's at all speed critical code that will be hurt by that extra
'if'...

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [PATCH] Avoid potential NULL deref in scripts/genksyms/lex.l

[Andrew Morton]

On Mon, 25 Jun 2007 00:02:03 +0200 "Jesper Juhl" <jesper.juhl@gmail.com> wrote:

> > > +      if (!file || !e)
> > > +     exit(1);
> > >        *e = '\0';
> > >        cur_filename = memcpy(xmalloc(e-file+1), file, e-file+1);
> > >        cur_line = atoi(yytext+2);
> >
> > I don't think the bug which you're fixing can occur:
> >
> > ^#[ \t]+{INT}[ \t]+\"[^\"\n]+\".*\n     return FILENAME;
> >
> > has anyone reported crashes in there?
> >
> 
> It may indeed not be possible. Found by inspection, not by any actual
> observed crashes.
> But does it really hurt to be defensive here? In case it can somehow
> be caused to fail, with my patch it'll fail a bit nicer :) It's not
> like it's at all speed critical code that will be hurt by that extra
> 'if'...

We can only get NULL pointers here if the regexp is wrong or if there's
a bug in the regexp parser.  Getting a coredump at the failure site is
much better behaviour than mysteriously exiting.

Re: [PATCH] Avoid potential NULL deref in scripts/genksyms/lex.l

[Jesper Juhl]

On 25/06/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 25 Jun 2007 00:02:03 +0200 "Jesper Juhl" <jesper.juhl@gmail.com> wrote:
>
> > > > +      if (!file || !e)
> > > > +     exit(1);
> > > >        *e = '\0';
> > > >        cur_filename = memcpy(xmalloc(e-file+1), file, e-file+1);
> > > >        cur_line = atoi(yytext+2);
> > >
> > > I don't think the bug which you're fixing can occur:
> > >
> > > ^#[ \t]+{INT}[ \t]+\"[^\"\n]+\".*\n     return FILENAME;
> > >
> > > has anyone reported crashes in there?
> > >
> >
> > It may indeed not be possible. Found by inspection, not by any actual
> > observed crashes.
> > But does it really hurt to be defensive here? In case it can somehow
> > be caused to fail, with my patch it'll fail a bit nicer :) It's not
> > like it's at all speed critical code that will be hurt by that extra
> > 'if'...
>
> We can only get NULL pointers here if the regexp is wrong or if there's
> a bug in the regexp parser.  Getting a coredump at the failure site is
> much better behaviour than mysteriously exiting.
>
Fair enough. Just ignore the patch then :-)

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html