On Wed, Jan 07, 2004 at 12:48:32PM +0000, Edmund GRIMLEY EVANS wrote: > Richard Todd <richardt@xxxxxxxxxxxx>: > Since that kind of buffer overflow could happen on other systems but > there don't seem to be other reports about this, I would guess that > you have a buggy version of iconv, but it is not impossible that you > have a different but equally correct iconv and mutt is at fault. Yeah, it could definitely be iconv, since the path I force the code to go down seems like it would have been triggered normally by iconv return codes. > If you want to investigate this further, you could try using gdb to > set a watch point on *l, or putting a wrapper round iconv that checks > the values going in and out or prints a log. The former approach might > be quick to do, if it works, and it might tell you exactly where *l > becomes huge. Well, like I said in my original mail, *l becomes huge when the string data from 'decline' overflows over it. Until then, it jumps up by ~70 at a time (line-lengths--normal stuff, AFAICT). I'm on a different machine now, without the source at hand, but the function I mentioned in my original mail has local variables like: char src[STRING]; char decline[STRING*2]; int l; When l goes past 512 (i.e. STRING*2), it has been overwritten by characters from decline, and the next iteration causes a core in memmove because l is the numeric equivalent of four characters from the message. Richard
Attachment:
pgpqFRKnaCwxm.pgp
Description: PGP signature