diff --git a/core/thread.c b/core/thread.c
index cb828b6df4..1e964c6d22 100644
--- a/core/thread.c
+++ b/core/thread.c
@@ -35,6 +35,15 @@
 #define ENABLE_DEBUG 0
 #include "debug.h"
 
+#if defined(HAVE_VALGRIND_H)
+#  include <valgrind.h>
+#elif defined(HAVE_VALGRIND_VALGRIND_H)
+#  include <valgrind/valgrind.h>
+#else
+#  define   VALGRIND_DISABLE_ERROR_REPORTING    (void)0
+#  define   VALGRIND_ENABLE_ERROR_REPORTING     (void)0
+#endif
+
 thread_status_t thread_getstatus(kernel_pid_t pid)
 {
     thread_t *thread = thread_get(pid);
@@ -178,11 +187,23 @@ uintptr_t measure_stack_free_internal(const char *stack, size_t size)
     uintptr_t *stackp = (uintptr_t *)(uintptr_t)stack;
     uintptr_t end = (uintptr_t)stack + size;
 
+    /* HACK: This will affect native/native64 only.
+     *
+     * The dark magic used here is frowned upon by valgrind. E.g. valgrind may
+     * deduce that a specific value was at some point allocated on the stack,
+     * but has gone out of scope. When that value is now read again to
+     * estimate stack usage, it does look a lot like someone passed a pointer
+     * to a stack allocated value, and that pointer is referenced after that
+     * value has gone out of scope. */
+    VALGRIND_DISABLE_ERROR_REPORTING;
+
     /* assume that the stack grows "downwards" */
     while (((uintptr_t)stackp < end) && (*stackp == (uintptr_t)stackp)) {
         stackp++;
     }
 
+    VALGRIND_ENABLE_ERROR_REPORTING;
+
     uintptr_t space_free = (uintptr_t)stackp - (uintptr_t)stack;
 
     return space_free;