Skip to contentSkip to conversation

WTF: patch "[PATCH] kasan: support use-after-scope detection" was seriously submitted to be applied to the 4.8-stable tree?

PATCH [email protected] 3 participants 4 messages Dec 2, 2016 – Dec 8, 2016

Subsystems (4)
Stable branch Memory management Library code KASAN
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below was submitted to be applied to the 4.8-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/stable_kernel_rules.txt.

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

Quoted 1 line

From 828347f8f9a558cf1af2faa46387a26564f2ac3e Mon Sep 17 00:00:00 2001

From: Dmitry Vyukov <[email protected]>
Date: Wed, 30 Nov 2016 15:54:16 -0800
Subject: [PATCH] kasan: support use-after-scope detection

Gcc revision 241896 implements use-after-scope detection. Will be available in gcc 7. Support it in KASAN.

Gcc emits 2 new callbacks to poison/unpoison large stack objects when they go in/out of scope. Implement the callbacks and add a test.

[[email protected]: v3]
Link http://lkml.kernel.org/r/[email protected] open here
Link http://lkml.kernel.org/r/[email protected] open here
Signed-off-by Dmitry Vyukov <[email protected]>
Acked-by Andrey Ryabinin <[email protected]>
Cc Alexander Potapenko <[email protected]>
Cc <[email protected]> [4.0+]
Signed-off-by Andrew Morton <[email protected]>
Signed-off-by Linus Torvalds <[email protected]>
lib/test_kasan.c +29 -0
index 5e51872b3fc1..fbdf87920093 100644
@@ -20,6 +20,11 @@
 #include <linux/uaccess.h>
 #include <linux/module.h>
 
+/*
+ * Note: test functions are marked noinline so that their names appear in
+ * reports.
+ */
+
 static noinline void __init kmalloc_oob_right(void)
 {
 	char *ptr;

@@ -411,6 +416,29 @@ static noinline void __init copy_user_test(void)
 	kfree(kmem);
 }
 
+static noinline void __init use_after_scope_test(void)
+{
+	volatile char *volatile p;
+
+	pr_info("use-after-scope on int\n");
+	{
+		int local = 0;
+
+		p = (char *)&local;
+	}
+	p[0] = 1;
+	p[3] = 1;
+
+	pr_info("use-after-scope on array\n");
+	{
+		char local[1024] = {0};
+
+		p = local;
+	}
+	p[0] = 1;
+	p[1023] = 1;
+}
+
 static int __init kmalloc_tests_init(void)
 {
 	kmalloc_oob_right();

@@ -436,6 +464,7 @@ static int __init kmalloc_tests_init(void)
 	kasan_global_oob();
 	ksize_unpoisons_memory();
 	copy_user_test();
+	use_after_scope_test();
 	return -EAGAIN;
 }
mm/kasan/kasan.c +19 -0
index 70c009741aab..0e9505f66ec1 100644
@@ -764,6 +764,25 @@ EXPORT_SYMBOL(__asan_storeN_noabort);
 void __asan_handle_no_return(void) {}
 EXPORT_SYMBOL(__asan_handle_no_return);
 
+/* Emitted by compiler to poison large objects when they go out of scope. */
+void __asan_poison_stack_memory(const void *addr, size_t size)
+{
+	/*
+	 * Addr is KASAN_SHADOW_SCALE_SIZE-aligned and the object is surrounded
+	 * by redzones, so we simply round up size to simplify logic.
+	 */
+	kasan_poison_shadow(addr, round_up(size, KASAN_SHADOW_SCALE_SIZE),
+			    KASAN_USE_AFTER_SCOPE);
+}
+EXPORT_SYMBOL(__asan_poison_stack_memory);
+
+/* Emitted by compiler to unpoison large objects when they go into scope. */
+void __asan_unpoison_stack_memory(const void *addr, size_t size)
+{
+	kasan_unpoison_shadow(addr, size);
+}
+EXPORT_SYMBOL(__asan_unpoison_stack_memory);
+
 #ifdef CONFIG_MEMORY_HOTPLUG
 static int kasan_mem_notifier(struct notifier_block *nb,
 			unsigned long action, void *data)
mm/kasan/kasan.h +1 -0
index 03f4545b103d..1c260e6b3b3c 100644
@@ -21,6 +21,7 @@
 #define KASAN_STACK_MID         0xF2
 #define KASAN_STACK_RIGHT       0xF3
 #define KASAN_STACK_PARTIAL     0xF4
+#define KASAN_USE_AFTER_SCOPE   0xF8
 
 /* Don't break randconfig/all*config builds */
 #ifndef KASAN_ABI_VERSION
mm/kasan/report.c +3 -0
index 24c1211fe9d5..073325aedc68 100644
@@ -90,6 +90,9 @@ static void print_error_description(struct kasan_access_info *info)
 	case KASAN_KMALLOC_FREE:
 		bug_type = "use-after-free";
 		break;
+	case KASAN_USE_AFTER_SCOPE:
+		bug_type = "use-after-scope";
+		break;
 	}
 
 	pr_err("BUG: KASAN: %s in %pS at addr %p\n",
#1 lore raw
Quoted 10 lines · On 12/02/2016 08:03 PM, [email protected] wrote:

The patch below was submitted to be applied to the 4.8-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/stable_kernel_rules.txt.

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

Yes, it was seriously submitted to stable. The reason for this is that gcc7 enables use-after-scope option by default (-fsanitze=kernel-address enables -fsanitize-address-use-after-scope). With this options gcc7 emits calls to __asan_[un]poison_stack_memory(),
but they are not present in older kernels. So compiling with gcc7 without this patch would cause link errors.

But I've got better idea. gcc7 isn't released yet, so we can fix this on gcc7 site simply by changing default to -fNO-sanitize-address-use-after-scope for -fsanitize=kernel-address

This should be trivial. Dmitry, can you do that? Or we can file a bug and someone else will fix that.

Quoted 4 lines

thanks,

greg k-h

reviewer
#2 lore raw
Quoted 17 lines · Andrey Ryabinin
Quoted 10 lines · On 12/02/2016 08:03 PM, [email protected] wrote:

The patch below was submitted to be applied to the 4.8-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/stable_kernel_rules.txt.

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

Yes, it was seriously submitted to stable. The reason for this is that gcc7 enables use-after-scope option by default (-fsanitze=kernel-address enables -fsanitize-address-use-after-scope). With this options gcc7 emits calls to __asan_[un]poison_stack_memory(),
but they are not present in older kernels. So compiling with gcc7 without this patch would cause link errors.

Quoted 4 lines

But I've got better idea. gcc7 isn't released yet, so we can fix this on gcc7 site simply by changing default to -fNO-sanitize-address-use-after-scope for -fsanitize=kernel-address

This should be trivial. Dmitry, can you do that? Or we can file a bug and someone else will fix that.

Mailed a patch for gcc:
https://groups.google.com/forum/#!topic/kasan-dev/D12SNoIUJKI
Is it what you mean?

Andrey, do you mind mailing a patch for kernel to enable -fsanitize-address-use-after-scope on tip kernels?

#3 lore raw
Quoted 18 lines · Dmitry Vyukov
Quoted 17 lines · Andrey Ryabinin
Quoted 10 lines · On 12/02/2016 08:03 PM, [email protected] wrote:

The patch below was submitted to be applied to the 4.8-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/stable_kernel_rules.txt.

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

Yes, it was seriously submitted to stable. The reason for this is that gcc7 enables use-after-scope option by default (-fsanitze=kernel-address enables -fsanitize-address-use-after-scope). With this options gcc7 emits calls to __asan_[un]poison_stack_memory(),
but they are not present in older kernels. So compiling with gcc7 without this patch would cause link errors.

Quoted 9 lines
Quoted 4 lines

But I've got better idea. gcc7 isn't released yet, so we can fix this on gcc7 site simply by changing default to -fNO-sanitize-address-use-after-scope for -fsanitize=kernel-address

This should be trivial. Dmitry, can you do that? Or we can file a bug and someone else will fix that.

Mailed a patch for gcc:
https://groups.google.com/forum/#!topic/kasan-dev/D12SNoIUJKI
Is it what you mean?

Exactly. Thanks.

Quoted 3 lines

Andrey, do you mind mailing a patch for kernel to enable -fsanitize-address-use-after-scope on tip kernels?

Will do.