lkdtm/heap: Avoid __alloc_size hint warning for VMALLOC_LINEAR_OVERFLOW
authorKees Cook <keescook@chromium.org>
Wed, 18 Aug 2021 17:48:55 +0000 (10:48 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 18 Aug 2021 20:28:51 +0000 (22:28 +0200)
Once __alloc_size hints have been added, the compiler will (correctly!)
see this as an overflow. We are, however, trying to test for this
condition at run-time (not compile-time), so work around it with a
volatile int offset.

Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210818174855.2307828-5-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/misc/lkdtm/heap.c

index 3d9aae5821a03a8974d0d9061c0e8e733edab5e6..8a92f5a800faa51fd180d2a6bcf2a1d9f4294be4 100644 (file)
@@ -12,6 +12,13 @@ static struct kmem_cache *double_free_cache;
 static struct kmem_cache *a_cache;
 static struct kmem_cache *b_cache;
 
+/*
+ * Using volatile here means the compiler cannot ever make assumptions
+ * about this value. This means compile-time length checks involving
+ * this variable cannot be performed; only run-time checks.
+ */
+static volatile int __offset = 1;
+
 /*
  * If there aren't guard pages, it's likely that a consecutive allocation will
  * let us overflow into the second allocation without overwriting something real.
@@ -24,7 +31,7 @@ void lkdtm_VMALLOC_LINEAR_OVERFLOW(void)
        two = vzalloc(PAGE_SIZE);
 
        pr_info("Attempting vmalloc linear overflow ...\n");
-       memset(one, 0xAA, PAGE_SIZE + 1);
+       memset(one, 0xAA, PAGE_SIZE + __offset);
 
        vfree(two);
        vfree(one);