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

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]

Date:	Mon, 25 Jun 2007 00:02:03 +0200
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	"Richard Henderson" <rth@...u.edu>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Avoid potential NULL deref in scripts/genksyms/lex.l

On 24/06/07, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Sun, 24 Jun 2007 23:40:03 +0200 Jesper Juhl <jesper.juhl@...il.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@...il.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@...il.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/