From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7240 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: buffer overflow in regcomp and a way to find more of those Date: Fri, 20 Mar 2015 22:17:17 -0400 Message-ID: <20150321021717.GV23507@brightrain.aerifal.cx> References: <20150321002616.GF16260@port70.net> <20150321004637.GQ23507@brightrain.aerifal.cx> <20150321010043.GR23507@brightrain.aerifal.cx> <20150321012341.GG16260@port70.net> <20150321013016.GS23507@brightrain.aerifal.cx> <20150321021018.GH16260@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1426904257 15437 80.91.229.3 (21 Mar 2015 02:17:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 02:17:37 +0000 (UTC) To: Konstantin Serebryany , musl@lists.openwall.com Original-X-From: musl-return-7253-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 21 03:17:36 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YZ8yh-0004uL-E2 for gllmg-musl@m.gmane.org; Sat, 21 Mar 2015 03:17:31 +0100 Original-Received: (qmail 24505 invoked by uid 550); 21 Mar 2015 02:17:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24487 invoked from network); 21 Mar 2015 02:17:29 -0000 Content-Disposition: inline In-Reply-To: <20150321021018.GH16260@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7240 Archived-At: On Sat, Mar 21, 2015 at 03:10:18AM +0100, Szabolcs Nagy wrote: > * Rich Felker [2015-03-20 21:30:16 -0400]: > > > > int main() { > > > > regex_t preg; > > > > const char *s = ".****\\Z$<\\0)_"; > > > > Isn't the \0 an invalid backreference? Could it be getting processed > > in a way that's causing the slowdown, but simply rejected by glibc? > > ah you were right the \0 causes the slow down here: > it switches to the backtracking mode and there are > many ways to backtrack on .**** Right. But \0 isn't even a valid backreference. It would refer to "the whole match" which could never match as a backreference. Valid backrefs are only the digits 1-9 though. \0 is not defined and should probably be treated as a literal or a parse error. Rich