From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6A6C5386F830; Fri, 3 Jul 2020 19:55:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6A6C5386F830 From: "jsm28 at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug stdio/26201] New: printf_fp integer / buffer overflow with outdigits Date: Fri, 03 Jul 2020 19:55:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Version: 2.29 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jsm28 at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 19:55:02 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26201 Bug ID: 26201 Summary: printf_fp integer / buffer overflow with outdigits Product: glibc Version: 2.29 Status: NEW Severity: normal Priority: P2 Component: stdio Assignee: unassigned at sourceware dot org Reporter: jsm28 at gcc dot gnu.org Target Milestone: --- I believe the buffer overflow described below can only be triggered in 2.29= or before, because of the change in 2.30 to stop allowing memory allocations of over half the address space. However, the code in question in __printf_fp_= l is unchanged and a buffer overflow might be appropriate to fix on older release branches. The following test, on 32-bit systems with glibc 2.29 or earlier, has a buf= fer overrun if it is capable of setting the locale and allocating all the memory required by printf up to the point of the buffer overrun (which is about 5/= 6 of the address space; I only had the allocations succeed when using static linking). #include #include #include int main (void) { FILE *fp; if ((fp =3D fopen ("/dev/null", "w")) =3D=3D NULL) exit (1); if (setlocale (LC_CTYPE, "en_US.UTF-8") =3D=3D NULL) exit (2); fprintf (fp, "%I.*f", (int) (0xffffffff / 6), 1e100); } The relevant code in __printf_fp_l has been unchanged for some years. It computes the size of a buffer for converting to locale-specific outdigits (= 'I') flag. size_t nbuffer =3D (2 + chars_needed * factor + decimal_len + ngroups * thousands_sep_len); For a UTF-8 locale, "factor" is 6. The chars_needed * factor multiplication can overflow. chars_needed cannot be much more than INT_MAX (because preci= sion for printf is limited to the size of int), so overflow is not possible on 64-bit systems. And it's limited to (size_t) -1 / sizeof (wchar_t) - 2, so overflow is not possible with "factor" less than 4. An allocation of size = (2 + chars_needed) * sizeof (wchar_t) has to succeed, which effectively means the overflow is not possible with factor equal to 4, and means that with glibc = 2.30 or later the overflow could not occur with factor less than 8, but the larg= est MB_CUR_MAX value for any locale in glibc is 6. Ideally this would be addressed by changing memory management in __printf_fp (with smarter code there would never be any need to store more than 4933 =3D FLT128_MAX_10_EXP + 1 digits before the decimal point or 16494 =3D FLT128_MANT_DIG - FLT128_MIN_EXP digits after it, as all digits outside that range will always be 0), thereby helping with some of the other open bugs relating to memory usage with large precision (note that other printf code = also allocates space equal to precision, however, though this code is allocating sizeof (wchar_t) * precision). But a smaller fix to check for overflow in = this calculation might be more suitable for backporting to past release branches. --=20 You are receiving this mail because: You are on the CC list for the bug.=