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): minicom-2.00.0-12 How reproducible: Always 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 shifted right. Additional info:
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