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.
Signed-off-by: Daniel Micay <[email protected]>
---
include/linux/string.h | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/linux/string.h b/include/linux/string.h
index 96f5a5fd0377..049866760e8b 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -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
On Fri, Jul 14, 2017 at 2:28 PM, Daniel Micay <[email protected]> wrote:
> 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.
>
> Signed-off-by: Daniel Micay <[email protected]>
Thanks for fixing this! Linus, do you want to take this directly or
have it go via -mm where fortify landed originally?
Acked-by: Kees Cook <[email protected]>
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
On Fri, 2017-07-14 at 16:51 -0700, Kees Cook wrote:
> On Fri, Jul 14, 2017 at 2:28 PM, Daniel Micay <[email protected]>
> wrote:
> > 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.
> >
> > Signed-off-by: Daniel Micay <[email protected]>
>
> Thanks for fixing this! Linus, do you want to take this directly or
> have it go via -mm where fortify landed originally?
>
> Acked-by: Kees Cook <[email protected]>
>
> 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
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.
On Fri, Jul 14, 2017 at 04:51:31PM -0700, Kees Cook wrote:
> On Fri, Jul 14, 2017 at 2:28 PM, Daniel Micay <[email protected]> wrote:
> > 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.
> >
> > Signed-off-by: Daniel Micay <[email protected]>
>
> Thanks for fixing this! Linus, do you want to take this directly or
> have it go via -mm where fortify landed originally?
>
> Acked-by: Kees Cook <[email protected]>
>
> 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...
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.