GNU bug report logs - #59544
[PATCH] Fixed lib-src/etags.c command execute vulnerability

Previous Next

Package: emacs;

Reported by: "lux" <lx <at> shellcodes.org>

Date: Thu, 24 Nov 2022 15:28:02 UTC

Severity: normal

Tags: patch, security

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #70 received at 59544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: lux <lx <at> shellcodes.org>
Cc: 59544 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#59544: [PATCH] Fixed lib-src/etags.c command execute
 vulnerability
Date: Sat, 26 Nov 2022 16:17:55 +0200
> Date: Sat, 26 Nov 2022 21:42:48 +0800
> Cc: stefankangas <at> gmail.com, 59544 <at> debbugs.gnu.org
> From: lux <lx <at> shellcodes.org>
> 
> On 2022/11/26 21:21, Eli Zaretskii wrote:
> >> Date: Sat, 26 Nov 2022 11:09:26 +0800
> >> Cc: 59544 <59544 <at> debbugs.gnu.org>
> >> From: lux <lx <at> shellcodes.org>
> >>
> >> +          linebuffer line;
> >> +          linebuffer_init (&line);
> >> +          while (readline_internal (&line, tag_f, tagfile) > 0)
> > This needs a minor adjustment: readline_internal removes the CR characters
> > from CR-LF end-of-lines, so I think using it unaltered will convert files
> > with DOS-style EOLs to Unix-style EOLs, because we write them with a single
> > newline at the end.  I think the best fix is to add one more argument to
> > readline_internal, which, if non-zero, will cause it to avoid removing the
> > CR characters.
> 
> Hmm.. but doing this doesn't have much to do with fixing the this 
> vulnerability, since
> 
> the previous hardcoded one doesn't work on Windows, so can it be changed 
> later?

I'd prefer to fix them together.  It's very simple, isn't it?




This bug report was last modified 2 years and 129 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.