bugfix: fru_strncpy was off by one, leading to rare memory corruptions

After correctly allocating the the manufacturer or device name, and correctly copying the not-null-terminated string from ipmi-fru, I put the termination '\0' at string[len + 1] . If you build a recent kernel under slob (which is the default), it may fail miserably at unexpected places. For example, if your string is 15 bytes, I allocated 16 but wrote to the 17th. slob has 16-byte alloc areas, and so I was corrupting the next area. This never happened with slab (which I prefer and run) because the smalles allocation chunk there is 32 bytes -- I would experience the same with a 31-long manufacturer or device name. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

bugfix: fru_strncpy was off by one, leading to rare memory corruptions
After correctly allocating the the manufacturer or device name, and correctly copying the not-null-terminated string from ipmi-fru, I put the termination '\0' at string[len + 1] . If you build a recent kernel under slob (which is the default), it may fail miserably at unexpected places. For example, if your string is 15 bytes, I allocated 16 but wrote to the 17th. slob has 16-byte alloc areas, and so I was corrupting the next area. This never happened with slab (which I prefer and run) because the smalles allocation chunk there is 32 bytes -- I would experience the same with a 31-long manufacturer or device name. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
0d1aca08 · Alessandro Rubini · af52f48a · 0d1aca08
Commit 0d1aca08 authored May 16, 2013 by Alessandro Rubini
Show whitespace changes
Inline Side-by-side

Showing with 1 addition and 1 deletion

ipmi-fru.h kernel/include/linux/ipmi-fru.h +1 -1

No files found.
--- a/kernel/include/linux/ipmi-fru.h
+++ b/kernel/include/linux/ipmi-fru.h
@@ -103,7 +103,7 @@ static inline char *fru_strcpy(char *dest, struct fru_type_length *tl)
 {
 	int len = fru_strlen(tl);
 	memcpy(dest, tl->data, len);
-	dest[len + 1] = '\0';
+	dest[len] = '\0';
 	return dest;
 }