d879c0ae3d
need this. Consider the following code: case 'O': output_filename = malloc(strlen(arg)+4); strcpy(output_filename, arg); strcat(output_filename, ".tmp"); real_output_filename = arg; return; The idea here is to malloc() a buffer big enough to hold the name of a supplied file name, plus ".tmp". So we malloc() 'size of filename' bytes plus 4, right? Wrong! ".tmp" is _FIVE_ bytes long! There's a traling '\0' which strcat() gleefully tacks on _outside_ the bounds of the buffer. Result: program corrupts own memory. Program SEGVs at seemingly random times. Bill not like random SEGVs. Bill smash. Know how I found this? I've been trying to bootstrap -current on my 2.1.0-RELEASE machine at work and I couldn't seem to get libc.a built because the linker would intermittently blow chunks while executing things like 'ld -O foo.o -X -r foo.o'. Since this is an initial bootstrap version of ld, it was linked against the 2.1.0 libc, who's malloc() behaves differently than that in -current. Presumeably ld -O doesn't blow up in -current, otherwise someone would have spotted this already. I don't know if this is a bug or a feature. Anyway. I'm changing the strlen(arg)+4 to strlen(arg)+5. Bah. |
||
---|---|---|
.. | ||
i386 | ||
ldconfig | ||
ldd | ||
rtld | ||
sparc | ||
cplus-dem.c | ||
etc.c | ||
ld.1 | ||
ld.1aout | ||
ld.c | ||
ld.h | ||
lib.c | ||
Makefile | ||
PORTING | ||
rrs.c | ||
shlib.c | ||
symbol.c | ||
symseg.h | ||
warnings.c | ||
xbits.c |