[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    [BusyBox] bug#1270: marked as done (busybox vi applet buffer overrun)
From:       owner () busybox ! net (BusyBox ! net bug Tracking System)
Date:       2002-10-26 4:21:49
[Download RAW message or body]

Your message dated Sat, 26 Oct 2002 04:20:03 -0600
with message-id <20021026102002.GC7483@codepoet.org>
and subject line [BusyBox] bug#1270: busybox vi applet buffer overrun
has caused the attached bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Erik Andersen
(administrator, BusyBox.net bugs database)

--------------------------------------
Received: (at submit) by bugs.busybox.net; 25 Sep 2002 18:12:48 +0000
>From jm@jm.epitest.fi  Wed Sep 25 12:12:48 2002
Received: by winder.codepoet.org (Postfix, from userid 104)
	id 1301C1575EE; Wed, 25 Sep 2002 12:12:47 -0600 (MDT)
Received: from jm.epitest.fi (ip213-185-36-89.laajakaista.mtv3.fi [213.185.36.89])
	by winder.codepoet.org (Postfix) with SMTP id CDA351575D0
	for <submit@bugs.busybox.net>; Wed, 25 Sep 2002 12:12:37 -0600 (MDT)
Received: (qmail 13855 invoked by uid 500); 25 Sep 2002 18:12:26 -0000
Date: Wed, 25 Sep 2002 21:12:26 +0300
From: Jouni Malinen <jkmaline@cc.hut.fi>
To: submit@bugs.busybox.net
Subject: busybox vi applet buffer overrun
Message-ID: <20020925211226.A13653@jm.epitest.fi>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/)
X-Spam-Status: No, hits=-5.0 required=5.0
	tests=UNIFIED_PATCH
	version=2.31
X-Spam-Level: 



Package: busybox
Version: 0.60.4 
Severity: normal

Busybox vi applet uses a constant length buffer last_modifying_cmd
(BUFSIZ bytes), but does not check for buffer overruns when adding
characters (e.g., in insert mode) to this buffer in get_one_char(). This
will overwrite something when more than BUFSIZ characters is added in  
one insert command. For example, on ppc-linux and uClibc file name was 
overwritten when 256 bytes was added in one insert command. After this,
file saves failed.

Attached patch checks for buffer overruns and refuses to write over the
buffer (a warning is displayed on status line). This is a workaround 
that prevents odd error cases, but 'dot' command does not get all the
data because of the constant size buffer. The real fix would be to
dynamically enlarge the buffer, but I'm not sure whether it would really
be needed in busybox.. The patch is for 0.60.4, but it seemed to apply  
also for current development version (although, I did not test this with
devel version).

In addition, there seems to other buffer overruns in vi applet, but this
was the one that has caused most problems for me. For example, another  
problem occurred when adding a line with more than about 256 characters.

-- 
Jouni Malinen                                            PGP id EFC895FA

["busybox-0.60.4-vi-buffer_overrun.patch" (text/plain)]

--- vi.c.orig	Wed Sep 25 20:47:19 2002
+++ vi.c	Wed Sep 25 21:07:27 2002
@@ -3435,8 +3435,13 @@
 		// adding STDIN chars to q
 		c = readit();	// get the users input
 		if (last_modifying_cmd != 0) {
-			// add new char to q
-			last_modifying_cmd[strlen((char *) last_modifying_cmd)] = c;
+			int len = strlen((char *) last_modifying_cmd);
+			if (len + 1 >= BUFSIZ) {
+				psbs("last_modifying_cmd overrun");
+			} else {
+				// add new char to q
+				last_modifying_cmd[len] = c;
+			}
 		}
 	}
 #else							/* BB_FEATURE_VI_DOT_CMD */


On Wed Sep 25, 2002 at 09:12:26PM +0300, Jouni Malinen wrote:
> Package: busybox
> Version: 0.60.4
> Severity: normal
> 
> Busybox vi applet uses a constant length buffer last_modifying_cmd
> (BUFSIZ bytes), but does not check for buffer overruns when adding
> characters (e.g., in insert mode) to this buffer in get_one_char(). This
> will overwrite something when more than BUFSIZ characters is added in  
> one insert command. For example, on ppc-linux and uClibc file name was 
> overwritten when 256 bytes was added in one insert command. After this,
> file saves failed.
> 
> Attached patch checks for buffer overruns and refuses to write over the
> buffer (a warning is displayed on status line). This is a workaround 

Thanks, applied,

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--


[prev in list] [next in list] [prev in thread] [next in thread]