login
Header Space

 
 

[PATCH net-2.6] tcp_probe buffer overflow and incorrect return value

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <netdev@...>
Date: Thursday, April 24, 2008 - 5:37 pm

tcp_probe has a bounds-checking bug that causes many programs (less, python) to
crash reading /proc/net/tcp_probe. When it outputs a log line to the reader, it
only checks if that line alone will fit in the reader's buffer, rather than that
line and all the previous lines it has already written.

tcpprobe_read also returns the wrong value if copy_to_user fails--it just passes
on the return value of copy_to_user (number of bytes not copied), which makes a
failure look like a success.

This patch fixes the buffer overflow and sets the return value to -EFAULT if
copy_to_user fails.

Patch is against latest net-2.6; tested briefly and seems to fix the crashes in
less and python.

Signed-off-by: Tom Quetchenbach <virtualphtn@gmail.com>


diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
index 1c50959..5ff0ce6 100644
--- a/net/ipv4/tcp_probe.c
+++ b/net/ipv4/tcp_probe.c
@@ -190,19 +190,18 @@ static ssize_t tcpprobe_read(struct file
 
 		width = tcpprobe_sprint(tbuf, sizeof(tbuf));
 
-		if (width < len)
+		if (cnt + width < len)
 			tcp_probe.tail = (tcp_probe.tail + 1) % bufsize;
 
 		spin_unlock_bh(&tcp_probe.lock);
 
 		/* if record greater than space available
 		   return partial buffer (so far) */
-		if (width >= len)
+		if (cnt + width >= len)
 			break;
 
-		error = copy_to_user(buf + cnt, tbuf, width);
-		if (error)
-			break;
+		if (copy_to_user(buf + cnt, tbuf, width))
+			return -EFAULT;
 		cnt += width;
 	}
 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH net-2.6] tcp_probe buffer overflow and incorrect retu..., Tom Quetchenbach, (Thu Apr 24, 5:37 pm)
speck-geostationary