nano

commit 2faad1230a01fee8a00aa51a9646555615885a1e
parent bfe418febb1cd2a6087f92fefce5421b11f8a5ba
Author: Benno Schulenberg <bensberg@justemail.net>
Date:   Sat, 23 Apr 2016 20:39:02 +0200

locking: don't try to read more bytes than the buffer can hold

A normal lock file is apparently 1024 bytes in size, so the second
attempt at reading bytes from the file would try to read 8192 more
bytes into a buffer that has room for only 7168 left.  According to
valgrind, the read() function doesn't like that -- and true: if for
some reason the lock file had suddenly expanded, the buffer would
overflow.

This fixes https://savannah.gnu.org/bugs/?47156.

Diffstat:
M
src/files.c
 | 
8
+++++---

1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/files.c b/src/files.c
@@ -32,6 +32,8 @@
 #include <pwd.h>
 #include <libgen.h>
 
+#define LOCKBUFSIZE 8192
+
 /* Verify that the containing directory of the given filename exists. */
 bool has_valid_path(const char *filename)
 {
@@ -337,11 +339,11 @@ int do_lockfile(const char *filename)
 	    goto free_the_name;
 	}
 
-	lockbuf = charalloc(8192);
+	lockbuf = charalloc(LOCKBUFSIZE);
 	do {
-	    readamt = read(lockfd, &lockbuf[readtot], BUFSIZ);
+	    readamt = read(lockfd, &lockbuf[readtot], LOCKBUFSIZE - readtot);
 	    readtot += readamt;
-	} while (readtot < 8192 && readamt > 0);
+	} while (readamt > 0 && readtot < LOCKBUFSIZE);
 
 	if (readtot < 48) {
 	    statusbar(_("Error reading lock file %s: Not enough data read"),