From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29835 invoked from network); 14 Apr 2023 15:48:37 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 14 Apr 2023 15:48:37 -0000 Received: (qmail 32674 invoked by uid 550); 14 Apr 2023 15:48:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32636 invoked from network); 14 Apr 2023 15:48:33 -0000 Date: Fri, 14 Apr 2023 11:48:20 -0400 From: Rich Felker To: Gabriel Ravier Cc: musl@lists.openwall.com Message-ID: <20230414154820.GM4163@brightrain.aerifal.cx> References: <20230414145543.2877269-1-gabravier@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230414145543.2877269-1-gabravier@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] fix wide printf numbered argument buffer overflow On Fri, Apr 14, 2023 at 04:55:42PM +0200, Gabriel Ravier wrote: > The nl_type and nl_arg arrays defined in vfwprintf may be accessed > with an index up to and including NL_ARGMAX, but they are only of size > NL_ARGMAX, meaning they may be written to or read from 1 element too > far. > > For example, the following program: > > #include > #include > #include > #include > > int main(void) { > char buffer[500]; > for (size_t i = 0; i < sizeof(buffer); ++i) > buffer[i] = (i % 3) ? 0 : 42; > > wchar_t result; > > int ret = swprintf(&result, 1, L"%1$s", ""); > assert(ret != -1); > } > > evidences the bug, by sometimes mistakenly failing the assertion > and always triggering a warning under valgrind (the behavior is highly > dependent on build configuration - I could only reproduce the assert > failure with GCC 12.2.1 on a very specific system - but the bug is > still there, as evidenced by the warning valgrind always emits) Thanks! To clarify for readers, the reason it fails is that the wide printf core checks that the argument type list consists of a contiguous run of used positions followed by unused positions all the way up to the end of the buffer. This involves checking the 9 position, which was out-of-bounds due to an off-by-one error in the declaration. If the overlapping memory happened to have a nonzero value, it would appear as a present %9$ slot with one or more prior slots unused, thereby triggering the error condition. While all instances of nonconforming behavior and UB are bad, I don't think this is of particular security relevance, despite being out-of-bounds array read/write. Write is only reachable if the application is using format strings with a 9th numbered argument position, and affected programs seem like they should be malfunctioning already regardless of any attacker-controlled input. Still I'm glad to have this fix in time for a release. Rich