public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "steve dot hawkes at motorola dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/4514] New: printf_unknown calculates work_buffer size incorrectly
Date: Wed, 16 May 2007 19:59:00 -0000	[thread overview]
Message-ID: <20070516205925.4514.steve.hawkes@motorola.com> (raw)

The printf_unknown() function, which is called when an unknown format specifier
is encountered, calculates the size of its local work_buffer array incorrectly.
The code uses the maximum of the format width specifier and the format letter
value where it should be using the maximum width of the text representation of
these values.

Here is the current code:

/* Handle an unknown format specifier.  This prints out a canonicalized
   representation of the format spec itself.  */
static int
printf_unknown (FILE *s, const struct printf_info *info,
		const void *const *args)

{
  int done = 0;
  CHAR_T work_buffer[MAX (info->width, info->spec) + 32];
  CHAR_T *const workend
    = &work_buffer[sizeof (work_buffer) / sizeof (CHAR_T)];

This code uses the integer value of the format width specifier and the integer
value of the unrecognized format letter to calculate the array size. Since
work_buffer[] is used to store the canonicalized representation of the
unrecognized format specification, the sizes that should be used are the widths
of the text representation of the info->width and info->spec values.

The following code typically causes a processor exception:

#include <stdio.h>

int
main(int	argc,
     char**	argv)
{
    printf("This is a bad format string: %*\"\n", 0x12345678);
    
    return (0);
}

For this code, info->width is 0x12345678 and info->spec is '"'. The
printf_unknown() function calculates MAX(info->width, info->spec) + 32, or
MAX(0x12345678, 0x22) + 32, and uses this to size the work_buffer array on the
stack. Since the resultant size exceeds the stack bounds, the code segfaults
instead of printing what the glibc coder intended, %305419896".

-- 
           Summary: printf_unknown calculates work_buffer size incorrectly
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: steve dot hawkes at motorola dot com
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: all
  GCC host triplet: all
GCC target triplet: all


http://sourceware.org/bugzilla/show_bug.cgi?id=4514

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


             reply	other threads:[~2007-05-16 19:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-16 19:59 steve dot hawkes at motorola dot com [this message]
2007-05-21 17:51 ` [Bug libc/4514] " drepper at redhat dot com
2007-07-12 13:31 ` cvs-commit at gcc dot gnu dot org
2007-07-12 15:23 ` cvs-commit at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070516205925.4514.steve.hawkes@motorola.com \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).