replace incorrect strscpy use in FORTIFY_SOURCE

Using strscpy was wrong because FORTIFY_SOURCE is passing the maximum possible size of the outermost object, but strscpy defines the count parameter as the exact buffer size, so this could copy past the end of the source. This would still be wrong with the planned usage of __builtin_object_size(p, 1) for intra-object overflow checks since it's the maximum possible size of the specified object with no guarantee of it being that large.

Reuse of the fortified functions like this currently makes the runtime error reporting less precise but that can be improved later on.

---
 include/linux/string.h | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

index 96f5a5fd0377..049866760e8b 100644
@@ -202,17 +202,6 @@ void __read_overflow2(void) __compiletime_error("detected read beyond size of ob
 void __write_overflow(void) __compiletime_error("detected write beyond size of object passed as 1st parameter");
 
 #if !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && defined(CONFIG_FORTIFY_SOURCE)
-__FORTIFY_INLINE char *strcpy(char *p, const char *q)
-{
-	size_t p_size = __builtin_object_size(p, 0);
-	size_t q_size = __builtin_object_size(q, 0);
-	if (p_size == (size_t)-1 && q_size == (size_t)-1)
-		return __builtin_strcpy(p, q);
-	if (strscpy(p, q, p_size < q_size ? p_size : q_size) < 0)
-		fortify_panic(__func__);
-	return p;
-}
-
 __FORTIFY_INLINE char *strncpy(char *p, const char *q, __kernel_size_t size)
 {
 	size_t p_size = __builtin_object_size(p, 0);

@@ -391,6 +380,18 @@ __FORTIFY_INLINE void *kmemdup(const void *p, size_t size, gfp_t gfp)
 		fortify_panic(__func__);
 	return __real_kmemdup(p, size, gfp);
 }
+
+/* defined after fortified strlen and memcpy to reuse them */
+__FORTIFY_INLINE char *strcpy(char *p, const char *q)
+{
+	size_t p_size = __builtin_object_size(p, 0);
+	size_t q_size = __builtin_object_size(q, 0);
+	if (p_size == (size_t)-1 && q_size == (size_t)-1)
+		return __builtin_strcpy(p, q);
+	memcpy(p, q, strlen(q) + 1);
+	return p;
+}
+
 #endif
 
 #endif /* _LINUX_STRING_H_ */

2.13.3

Thanks for fixing this! Linus, do you want to take this directly or have it go via -mm where fortify landed originally?

As far as testing goes, was the NFS tree not in -next, or was a test not running against -next? I'm curious why it took until the NFS tree landed in Linus's tree for this to get noticed. Fortify was in -next for a while...

-Kees

Kees Cook
Pixel Security

Not sure but one issue is that v1 wasn't broken and that's what I most heavily tested myself. I then switched to testing with intra-object size checks on top of it, and there would have needed to be a case like this to break with those stricter checks:

char a[2];
char b[3];
char *p = cond ? a : b;
strcpy(a, c);

__builtin_object_size(p, 0) / __builtin_object_size(p, 1) will both return 3 there, which is wrong with that incorrect strscpy usage.

I wouldn't have found it via NFS since I've been testing with the string (but not memory) functions switched to the stricter type 1.

I started on some test cases for FORTIFY_SOURCE but I was testing to make sure it catches all the bugs it's supposed to catch, it's probably a good idea to write some more generic string edge case tests too.

One of the somewhat subtle cases (which is handled properly already):

struct foo {
	char a[2];
	char b;
}

struct foo x;
x.a[0] = '1';
x.a[1] = '2';
x.b = '\0';

strlen(x.a); // BUG with stricter intra-object overflow checks on strnlen(x.a, 3); // BUG with stricter intra-object overflow checks on strnlen(x.a, 2); // no overflow

Anyway, it'd be really good if other people looked closely at these. I wasn't sure what to do with test cases that I've made though. It seems ones that are *supposed* to BUG should go in lkdtm, and should the other tests just be together with those? Some should also pass w/o the intra object overflow checks, but BUG with them enabled.

There was a last-minute rebase of that tree. I don't see anything relevant there. The code in question has been the same for ages. But I most be overlooking something.... I guess it could be interesting to bisect to figure out when the warning started.

--b.