From e6d468d32cd084edd030a8bae76440b17b854b5c Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Wed, 18 Aug 2021 10:48:55 -0700 Subject: lkdtm/heap: Avoid __alloc_size hint warning for VMALLOC_LINEAR_OVERFLOW 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 Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210818174855.2307828-5-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman --- drivers/misc/lkdtm/heap.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'drivers/misc/lkdtm') diff --git a/drivers/misc/lkdtm/heap.c b/drivers/misc/lkdtm/heap.c index 3d9aae5821a0..8a92f5a800fa 100644 --- a/drivers/misc/lkdtm/heap.c +++ b/drivers/misc/lkdtm/heap.c @@ -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); -- cgit v1.2.3