Date: Thu, 08 Oct 1998 18:53:13 -0700 From: Studded <Studded@gorean.org> To: Mike Smith <mike@smith.net.au> Cc: Archie Cobbs <archie@whistle.com>, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: mail in free(): warning: junk pointer, too high to make sense. Message-ID: <361D6C89.F76B1755@gorean.org> References: <199810090046.RAA01827@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote:
>
> > Mike Smith wrote:
> >
> > > It means that there are two instances of 'msgvec' with global scope,
> > > and the other one needs to be found too.
> > >
> > > You could probably just change the 'msgvec' in lex.c to be static in
> > > order to achieve that goal; then you need to work out which object(s)
> > > are exporting 'msgvec' as globals.
> > >
> > > Any chance of you doing that? Have a look at the output of 'nm' on each
> > > of the .o files, and see which (if any) export or reference _msgvec.
> >
> > ok, when I use the version of lex.c which has msgfoo declared static I
> > get no _msgvec in any .o file. When I restore the original lex.c file,
> > then declare msgvec static here is what I get:
> >
> > 55# for FILE in `ls -1 *.o`; do echo $FILE; nm *.o | grep _msgvec |
> > \more; done
> > aux.o
> > 00001354 b _msgvec
> >
> > and identical output for the following files:
>
> That's because there's a bug in your command; you should be passing
> $FILE to nm, not "*.o"
Well don't I fell silly. I swapped too many things around. With the
stock sources:
105# for FILE in `ls -1 *.o`; do echo $FILE; nm $FILE | grep _msgvec;
done
lex.o
00000004 C _msgvec
With msgvec declared static in lex.c:
lex.o
00001354 b _msgvec
> > However, looking at the files where msgvec is used, the only place it's
> > declared globally is lex.c. When I tested the binary compiled with the
> > static declaration in lex.c using gdb + AJ -> malloc.conf it didn't
> > core, and there were no error messages. So perhaps making it static in
> > lex.c is the answer after all?
>
> I'm still wondering how it gets corrupted. Making it static will have
> the effect of moving it around. The fact that it was corrupted with
> something that looks very much like ASCII has me wondering whether
> there's not a buffer overflow going on.
>
> Can you try 'nm mail | sort | more' and look at the symbols directly
> before msgvec? I'd be inclined to suspect that there's a fixed-size
> character buffer there that's just not big enough for something on your
> system.
Well, I do have 16 character usernames on my 2.2.7 system, and my
normal user is a 16 char name. However the sources for mail are the same
in -Stable and -Current, so I don't think it's a -Stable problem.
However, when I log in as a user with a 5 character username, I don't
get the warning with stock sources so it definitely sounds like a buffer
overflow.
With stock sources:
00015ae0 B _tempQuit
00015af8 B _string_stack
00015b00 B _lexstring
00015f00 D __CurrentRuneLocale
00015f04 B _loading
00015f08 B _wait_status
00015f0c B _tempMesg
00015f24 B _srbuf
00015f48 B _tempMail
00015f60 B _hdrjmp
00015f84 B _groups
00016070 B _tempEdit
00016088 D __DefaultRuneLocale
00016cdc B _message
00016ce0 D ___sF
00016de8 B _lexnumber
00016dec B _prevfile
000171ec B _lastbang
0001726c B _environ
00017270 B _regretstack
00017278 B _ignore
00017458 B _tempResid
00017470 B _rcvmode
00017474 B _image
00017478 B _msgvec
The culprit would seem to be one or more of:
char tempMail[24];
char tempQuit[24];
char tempEdit[24];
char tempResid[24];
char tempMesg[24];
from temp.c, however in my testing I couldn't figure out which one.
Also, to make matters more exciting I have TMPDIR set to
/home/my16charusername/.temporary_dir. The TMPDIR variable is referenced
in the same part of the code in temp.c.
Hoping we're narrowing this down,
Doug
--
*** Chief Operations Officer, DALnet IRC network ***
Go PADRES!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?361D6C89.F76B1755>