[Bug stdio/26201] New: printf_fp integer / buffer overflow with outdigits

["jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26201

            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 buffer
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 <locale.h>
#include <stdio.h>
#include <stdlib.h>

int
main (void)
{
  FILE *fp;
  if ((fp = fopen ("/dev/null", "w")) == NULL)
    exit (1);
  if (setlocale (LC_CTYPE, "en_US.UTF-8") == 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 = (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 precision
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 largest
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 =
FLT128_MAX_10_EXP + 1 digits before the decimal point or 16494 =
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.