<<< Date Index >>>     <<< Thread Index >>>

Re: Core when displaying non-ascii chars



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