[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] new class of printf issue: int overflow
- To: full-disclosure@xxxxxxxxxxxxxxxxx
- Subject: Re: [Full-disclosure] new class of printf issue: int overflow
- From: Felix von Leitner <felix-fulldisclosure@xxxxxxx>
- Date: Thu, 11 Jan 2007 15:18:21 +0100
Thus spake Pierre Habouzit (madcoder@xxxxxxxxxx):
> > But that got me thinking. *printf return an int, and it's supposed to
> > be the number of chars written. So a typical idiom is
> >
> > size_t memory_needed=snprintf(NULL,0,format_string,...);
> > char* ptr=malloc(memory_needed+1);
> > sprintf(ptr,format_string,...);
> that's not the sole braindead idiom that generate errors. In my
> software I use an xmalloc that returns NULL if its argument is <= 0,
That does not help. The negative value is just an example, there could
also be a complete 32-bit overflow leading to snprintf returning 23
although it was going to write more than 4 GB.
> > The question is: do we want to do something about it? What should
> > printf do if it detects an int overflow? Return -1? Is there a good
> > solution to this? Solaris apparently returns -1.
> like said for your aprintf case, IMHO, MIN_INT for a '*' width
> specifier has to be taken as an erroneous value. At least, it really
> feels sensible.
The example had two %.d statements, neither of the * values was MIN_INT.
Felix
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/