From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Description of problem:
minicom crashes when you insert a character near the begining of an existing
line. By "existing line" I mean a line that has already has characters after
the insertion point.
The problem is caused by a buffer overwrite in winscar2() in window.c. "buf",
the buffer that is overwritten, is allocated on the stack, so overwriting the
buffer munges some other stack variables. Eventually, wputc tries to
dereference a bad pointer.
Even though this is a stack-smashing bug, I doubt this is a security risk.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log into a terminal using minicom
2. Type "echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX". DO NOT PRESS
ENTER. (I can repro with about fifty chars. YYMV).
3. Use the back arrow to get to the begining of the line. DO NOT USE DELETE.
It's important that the point of insertion have many characters after it.
4. Type space.
Another way to get an "existing line" is to type and execute a long line, then
press the up-arrow to retreive it from your history.
Actual Results: minicom crashes by raising an "unknown signal".
Expected Results: The character is inserted and the remainder of the line is
Created attachment 92789 [details]
patch to fix buffer overwrite
This patch simply restricts the number of bytes written by memcpy to be within
the bounds of buf. Note that, while this fixes the crash, the output still
gets a little munged. I think this is a separate bug, though.
This patch also fixes the inaccurate comment describing what winschar2() does.
thanks for the patch. incorporated into release 16