lkdtm/heap: Note conditions for SLAB_LINEAR_OVERFLOW
authorKees Cook <keescook@chromium.org>
Wed, 16 Feb 2022 18:20:47 +0000 (10:20 -0800)
committerKees Cook <keescook@chromium.org>
Tue, 12 Apr 2022 23:11:49 +0000 (16:11 -0700)
It wasn't clear when SLAB_LINEAR_OVERFLOW would be expected to trip.
Explicitly describe it and include the CONFIGs in the kselftest.

Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: linux-kselftest@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
drivers/misc/lkdtm/heap.c
tools/testing/selftests/lkdtm/config

index 8a92f5a800faa51fd180d2a6bcf2a1d9f4294be4..b4ac726a548f3a78c88aad374571174635455151 100644 (file)
@@ -22,6 +22,9 @@ 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.
+ *
+ * This should always be caught because there is an unconditional unmapped
+ * page after vmap allocations.
  */
 void lkdtm_VMALLOC_LINEAR_OVERFLOW(void)
 {
@@ -41,6 +44,9 @@ void lkdtm_VMALLOC_LINEAR_OVERFLOW(void)
  * This tries to stay within the next largest power-of-2 kmalloc cache
  * to avoid actually overwriting anything important if it's not detected
  * correctly.
+ *
+ * This should get caught by either memory tagging, KASan, or by using
+ * CONFIG_SLUB_DEBUG=y and slub_debug=ZF (or CONFIG_SLUB_DEBUG_ON=y).
  */
 void lkdtm_SLAB_LINEAR_OVERFLOW(void)
 {
index 46f39ee762086eb2eca566ab12a08a2d05e0a819..3041236887394db4b518adff1ac896461ce0ecdc 100644 (file)
@@ -9,3 +9,5 @@ CONFIG_UBSAN=y
 CONFIG_UBSAN_BOUNDS=y
 CONFIG_UBSAN_TRAP=y
 CONFIG_STACKPROTECTOR_STRONG=y
+CONFIG_SLUB_DEBUG=y
+CONFIG_SLUB_DEBUG_ON=y