From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12962 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible out of bounds memory write in initialization of xdigits in src/stdio/vfprintf.c Date: Thu, 28 Jun 2018 13:48:59 -0400 Message-ID: <20180628174859.GH1392@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1530208026 14522 195.159.176.226 (28 Jun 2018 17:47:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 28 Jun 2018 17:47:06 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12978-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 28 19:47:02 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fYb0Y-0003fe-88 for gllmg-musl@m.gmane.org; Thu, 28 Jun 2018 19:47:02 +0200 Original-Received: (qmail 13679 invoked by uid 550); 28 Jun 2018 17:49:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13661 invoked from network); 28 Jun 2018 17:49:10 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12962 Archived-At: On Thu, Jun 28, 2018 at 10:31:55AM -0700, Mark Winterrowd wrote: > Hi all, > > On line 148 of src/stdio/vfprintf.c in the source tree head, you can > observe the following global initialization: > > static const char xdigits[16] = { > "0123456789ABCDEF" > }; > > Note that while this xdigits array has a length of 16, the string it is > being initialized to has a length of 17, due to the implicit null > terminator. Thus, an additional '\0' will be written just past the end of > this global. I believe this could cause unpredictable effects depending > upon how the compiler and linker handle this situation. There's no write here, just initialization, and there's no such thing as initialization past/outside of the object. While I'm not sure in general if over-long string initializers are a constraint violation (if so, this would be a compile-time warning/error), this specific type (non-null-terminated) definitely isn't. See 6.7.9 ΒΆ14: "An array of character type may be initialized by a character string literal or UTF-8 string literal, optionally enclosed in braces. Successive bytes of the string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the elements of the array." Rich