From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cventin.lip.ens-lyon.fr (cventin.lip.ens-lyon.fr [140.77.13.17]) by sourceware.org (Postfix) with ESMTPS id 758E43858C66 for ; Mon, 20 Mar 2023 17:36:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 758E43858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vinc17.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=vinc17.net Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.96) (envelope-from ) id 1peJQU-001GTO-29; Mon, 20 Mar 2023 18:36:06 +0100 Date: Mon, 20 Mar 2023 18:36:06 +0100 From: Vincent Lefevre To: libc-alpha@sourceware.org Subject: Re: UB status of snprintf on invalid ptr+size combination? Message-ID: <20230320173606.GH203866@cventin.lip.ens-lyon.fr> Mail-Followup-To: Vincent Lefevre , libc-alpha@sourceware.org References: <9d7ca3d8-6998-e741-b669-03ef42bc99f1@gmail.com> <20230319230722.GD390223@zira.vinc17.org> <20230320135044.GB203866@cventin.lip.ens-lyon.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/2.2.9+71 (caea3018) vl-149028 (2023-03-14) X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-03-20 12:56:34 -0400, Siddhesh Poyarekar wrote: > On 2023-03-20 09:50, Vincent Lefevre wrote: > > On 2023-03-20 08:05:32 -0400, Siddhesh Poyarekar wrote: > > > I think on the glibc front it makes sense from a security > > > perspective to interpret this through POSIX than the C standard. > > > Even if the C standard is clarified to be contrary to POSIX and > > > explicitly state that n is not the size of the buffer (which would > > > be a terrible mistake IMO), I'd lean towards violating the C > > > standard and conforming to POSIX instead. > > > > I disagree about the POSIX behavior (assuming it is intentional). > > Why do you think it may be unintentional? Yes, because it does not warn about a difference with the C standard (and see below...). > The POSIX wording seems pretty deliberate and clear to me. Standards may have clear text, while some corner cases have been overlooked. This occurs frequently. As an example, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 (LDBL_MAX is incorrect with IBM long double format) and a DR eventually changed the definition, even though it was clear: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399#c4 Note: This change of definition was not much an issue in practice because it made the standard match the actual implementations (probably all of them). So it did not break anything. Back to POSIX: The text was probably written like that because in almost all the cases, n is a valid size of the array and the change of formulation made the text a bit simpler. But this broke some legitimate uses, and at that time, the working group may not have been aware of that. It would be useful to know whether this had been brought in the discussions at that time. > The C standard wording on the other hand leaves things to the > imagination, which is why we're having this discussion. What things to the imagination? IMHO, the C standard wording is very clear. > > With it, if the compiler detects that n is larger than the actual > > buffer size, then due to undefined behavior, the compiler could > > assume that this is dead code and introduce erratic behavior in > > code written with the C standard in mind (or when it was introduced > > in BSD). > > In fact, with _FORTIFY_SOURCE, if the runtime detects that n is larger than > the actual buffer size, the code will abort, see pr28989[1]. But that's a > runtime feature, nothing to do with gcc. > > gcc at the moment doesn't have any such check AFAICT but if it does, I > reckon that's a discussion to be had on the gcc mailing list. If the ISO C standard is meant to be changed, all compilers could potentially consider the code as dead code, not just GCC. IMHO, it would be very bad to consider the code as UB. It would be better to standardize _FORTIFY_SOURCE (that would add restrictions, but with a controlled behavior). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)