Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-3041470 ] buffer overflow in assembler
|
From: SourceForge.net <no...@so...> - 2010-08-17 07:03:21
|
Bugs item #3041470, was opened at 2010-08-08 13:00 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3041470&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: assembler Group: fixed Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Maarten Brock (maartenbrock) Assigned to: Maarten Brock (maartenbrock) Summary: buffer overflow in assembler Initial Comment: When I run the regression tests with the --debug flag the assembler crashes with a buffer overflow. Processing uminus.c *** buffer overflow detected ***: ../../bin/sdas6808 terminated Processing uminus.c *** buffer overflow detected ***: ../../bin/sdas8051 terminated Processing uminus.c *** buffer overflow detected ***: ../../bin/sdasz80 terminated Tested with svn revision 5917. ---------------------------------------------------------------------- >Comment By: Borut Ražem (borutr) Date: 2010-08-17 09:03 Message: > This time with multiple definition errors as the symbol is inserted in the lookup table. This is the one I saw and that's whi I serached in the wroh place. I've made a version which is using dbuf (dymanic buffer allocation), but I came to the same result as you: multiple definition errors. I commited the dbuf version but kept your change too. Be careful: I renamef asnoice.c to asdbg.c, to be more in sync with asxxxx. Borut ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2010-08-16 23:16 Message: Well my original post mentioned sdas crashing, not sdld. That should have been a give away ;-) I tried to use PATH_MAX directly now with NCPS back to 80, but as I kind of expected it just fails later. This time with multiple definition errors as the symbol is inserted in the lookup table. I'll look some further but for now I keep my fix. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2010-08-16 21:36 Message: So my assumption about the problem was totally wrong :-(. I thought that sdld is crashing... I also think that revering NCPS back to 80 and increase the size on name[] array to PATH_MAX in function DefimeCDB_Line() is better solution. And use of snprintf() instead sprintf() would prevent the buffer overflow also in case of file name longer then PATH_MAX. Borut ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2010-08-16 09:48 Message: On second thought, perhaps I should have fixed it by using PATH_MAX instead of NCPS as length for name in DefineCDB_Line(). After all it is a path it's printing here. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2010-08-16 09:46 Message: The large identifier was a debug symbol which contains the filename. It was not an identifier in the source code. The buffer overflow check was performed by glibc sprintf in DefineCDB_Line() in asnoice.c. I agree that a malloc'ed buffer is better though it is also costlier esp. in performance. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2010-08-15 23:20 Message: Hi Maarten, this bug disclosed two probems: - the first one is that the diferrent identifiers match in first 80 characters. I haven't check the c standard yet, but I found this: http://publications.gbdirect.co.uk/c_book/chapter2/keywords_and_identifiers.html, so I don't know if this is really a sdcc bug, or we should somehow redesign the regression teting. But at this level I agree with your fix, even that I would be more satisfied if dsas / sdld would accept identifiers of arbitrary lenght (using malloc instead fixed lenght buffers). - the second one is: why it crashes? I took a quick look to the code and I didn't find the buffer overflows (neither did you fix them). Currently I can't chek it, since I'm on the WIN32 / cygwin machine which doesn't crash (the compiler doesn't produce run-time buffer overflow checks). Do you already know something more about it? Borut ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2010-08-15 22:39 Message: Fixed by enlarging NCPS in the assembler in revision #5932. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3041470&group_id=599 |