From nobody Tue Apr 23 16:24:49 2024 X-Original-To: standards@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VP6sG0dz8z5HYwh for ; Tue, 23 Apr 2024 16:24:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VP6sF3L3Zz465l for ; Tue, 23 Apr 2024 16:24:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713889489; a=rsa-sha256; cv=none; b=VTW8yTWiCEjzqlvI6A1cFSUPZGuDRaDwtAG7LaXXneS9W8bdPudhmOFSxWfV5ZwBEwsPaV pxgqC+ZkOomseKBH4IUNYA8Ad46Hw//+VJg1259inMljVDNmE+wF2SutAsxgUA93M3IdUG lRg2Wm6kNK+jqaUTY/EkIQjO7spDCsC7f8hq9rJSo6N93n3OpI4dngfsAPs4GS79/5evL5 YGcwdj0f8disNEr1xlwozjZx5sVDWpuCaGJoKK1Mk1S0I9S4aWsYM6t848L9nn8bXP+wEo +pqAEkZ5Sy773YDpx5oHvYK3OWDJIroeBev0OyDPJpAMOT96shMiGyRsC0H7pg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713889489; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=XOubsGt9gzn50eblZ1trbVxnBIG7BVkmmya49gmPVmc=; b=nrJQFIT6HUOKvT0NCpRnWx1QZaRp7rvJPY8OXAdxBdoTclrV+6uqbMss1v1ocVUD7I6V8P /+y5BsJ2/o/gT4w8yA99NAW55/8gY42IuqazR/nP/d3ZUoTvsGJK8fh0rX9f82PpBUG5U0 Wpk6A3DnGZx0R624IuSIffk5EU/7CLU301ZSjkWJjcNWOV6xaX7Ab4ixcpazzk5cQZcufg S3cln8caJEOC4/ehuk9IxuNfm6Bqy8cqn8TbR1Xlndc+VzmlNhv+OdPDLODoEy0lo8FXBn SUeOf36uspwd8WrhceQx5y6YfPGCDjZ29gytA7WzVYAB02TY0UnDr7N1sdyi9A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VP6sF2xVTzfdQ for ; Tue, 23 Apr 2024 16:24:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43NGOnMg036517 for ; Tue, 23 Apr 2024 16:24:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43NGOnHR036516 for standards@FreeBSD.org; Tue, 23 Apr 2024 16:24:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 278556] strerror-related race condition and standards violation in printf and friends Date: Tue, 23 Apr 2024 16:24:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jonathan.gruber.jg@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Standards compliance List-Archive: https://lists.freebsd.org/archives/freebsd-standards List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-standards@freebsd.org Sender: owner-freebsd-standards@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278556 Bug ID: 278556 Summary: strerror-related race condition and standards violation in printf and friends Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: standards Assignee: standards@FreeBSD.org Reporter: jonathan.gruber.jg@gmail.com Overview: I was reading the implementation of __vfprintf, the function that appears t= o be main logic for printf and friends, in the file lib/libc/stdio/vfprintf.c in= the main branch of the freebsd-src repo. I noticed that, for the %m format specifier, the __vfprintf function obtains the errno message by calling strerror. FreeBSD's implementation of strerror, in the file lib/libc/string/strerror.c in the same branch of same repo, is not thread-s= afe, since it uses a non-thread-local static buffer for the errno message and returns a pointer to that buffer, so the offending segment in __vfprintf is= not thread-safe. Additionally, the offending segment violates both the ISO C standard and PO= SIX, which both mandate that a conforming implementation behave as if no library functions (including printf and friends) call strerror. Evidently, under FreeBSD's implementation of libc, if a program has a string s returned by strerror and subsequently calls printf (which indirectly calls __vfprintf) = with a format string containing the %m format specifier, then the call to printf will possibly modify the string s. Hence, FreeBSD's libc implementation does indeed behave as if some library functions (printf and friends) call strerr= or. I also noticed that vfprintf_l, in the same file as __vfprintf, has a comme= nt above it reading "MT-safe version" but that vfprintf_l calls __vfprintf, wh= ich has a comment above it reading "Non-MT-safe version". I cannot find any oth= er version of __vfprintf, so I assume that vfprintf_l is calling the __vfprintf function defined in the same file. Is the "Non-MT safe version" comment abo= ve __vfprintf referring to its use of non-thread-safe functions such as strerr= ror, or something else? Furthermore, why would vfprintf_l, which is ostensibly thread-safe according to the aforementioned comment above it, call __vfprin= tf, which is ostensibly non-thread-safe according to the aforementioned comment above it? Steps to Reproduce: I do not run FreeBSD, as I was merely browsing the source code, but I would suggest the following code segment to check for the standards violation: const char *s =3D strerror(ENOENT); printf("s: %s\n", s); errno =3D ELOOP; // set errno to a different error number than the one supp= lied to strerror above printf("%m\n"); printf("s: %s\n", s); Actual Results: I do not run FreeBSD, but my reading of the source code lea= ds me to believe that the bug which I identify here is indeed present. Expected Results: __vfprintf should not call strerror, so that printf and friends will conform to the ISO C standard and POSIX regarding usage of strerror. __vfprintf should also be thread-safe, since ostensibly thread-sa= fe functions like vfprintf_l call it (or, at the very least, functions like vfprintf_l that call __vfprintf should do so in a thread-safe manner). Build Date & Hardware: Not exactly applicable, but the offending segment of __vfprintf is in the main branch of the freebsd-src repo. Additional Builds and Platforms: Not applicable. Additional Information: None. Suggested solution: The offending segment in __vfprintf could easily be fixed by stack-allocati= ng a char buffer of size NL_TEXTMAX in the offending segment and storing the err= no message in that buffer via strerror_r, which is thread-safe and would not unexpectedly modify any external data. A size of NL_TEXTMAX for the buffer ensures that the buffer can store any errno message, given that strerror it= self uses a buffer of this size for the errno message. I have not read the whole of the __vfprintf function, so I do not know if fixing the strerror situation as above would automatically also make __vfpr= intf thread-safe or if it would make all present usages of __vfprintf in the sou= rce code thread-safe. --=20 You are receiving this mail because: You are the assignee for the bug.=