Date: Fri, 7 Jun 1996 21:52:59 -0700 (PDT) From: Bill Paul <wpaul> To: CVS-committers, cvs-all, cvs-gnu Subject: cvs commit: src/gnu/usr.bin/ld ld.c Message-ID: <199606080452.VAA06824@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
wpaul 96/06/07 21:52:58 Modified: gnu/usr.bin/ld ld.c Log: Aw c'mon. I'm being driven mad by plenty of other things. I don't 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. Revision Changes Path 1.34 +2 -2 src/gnu/usr.bin/ld/ld.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606080452.VAA06824>