Doubts about bug types reported by KASAN
46 views
Skip to first unread message
慕冬亮
May 19, 2020, 6:00:59 PM5/19/20
to syzkaller
Hi all,
I have some doubts about the bug types reported by KASAN.
1. In Line 126 of "get_bug_type", it verifies if the address has the corresponding shadow memory. However, from the description of KASAN(https://www.kernel.org/doc/html/latest/dev-tools/kasan.html), all the kernel space should be mapped into the shadow memory region. Why there are some accesses that not mapped into the shadow region? And in the code of "get_wild_bug_type", what's the logic to distinguish each type?
2. How does KASAN add redzone(e.g., KASAN_PAGE_REDZONE) for Page-level allocator?
60 static const char *get_shadow_bug_type(struct kasan_access_info *info)
......
76
77 switch (*shadow_addr) {
78 case 0 ... KASAN_SHADOW_SCALE_SIZE - 1:
79 /*
80 * In theory it's still possible to see these shadow values
81 * due to a data race in the kernel code.
82 */
83 bug_type = "out-of-bounds";
84 break;
85 case KASAN_PAGE_REDZONE:
86 case KASAN_KMALLOC_REDZONE:
87 bug_type = "slab-out-of-bounds";
88 break;
89 case KASAN_GLOBAL_REDZONE:
90 bug_type = "global-out-of-bounds";
91 break;
92 case KASAN_STACK_LEFT:
93 case KASAN_STACK_MID:
94 case KASAN_STACK_RIGHT:
95 case KASAN_STACK_PARTIAL:
96 bug_type = "stack-out-of-bounds";
97 break;
98 case KASAN_FREE_PAGE:
99 case KASAN_KMALLOC_FREE:
100 bug_type = "use-after-free";
101 break;
102 case KASAN_USE_AFTER_SCOPE:
103 bug_type = "use-after-scope";
104 break;
105 }
106
107 return bug_type;
108 }
109
110 static const char *get_wild_bug_type(struct kasan_access_info *info)
111 {
112 const char *bug_type = "unknown-crash";
113
114 if ((unsigned long)info->access_addr < PAGE_SIZE)
115 bug_type = "null-ptr-deref";
116 else if ((unsigned long)info->access_addr < TASK_SIZE)
117 bug_type = "user-memory-access";
118 else
119 bug_type = "wild-memory-access";
120
121 return bug_type;
122 }
123
124 static const char *get_bug_type(struct kasan_access_info *info)
125 {
126 if (addr_has_shadow(info))
127 return get_shadow_bug_type(info);
128 return get_wild_bug_type(info);
129 }
Dmitry Vyukov
May 20, 2020, 12:51:07 AM5/20/20
to 慕冬亮, kasan-dev
BCC syzkaller
Andrey Konovalov
May 20, 2020, 1:21:13 PM5/20/20
to 慕冬亮, syzkaller
> Hi all,
>
> I have some doubts about the bug types reported by KASAN.
> 1. In Line 126 of "get_bug_type", it verifies if the address has the corresponding shadow memory. However, from the description of KASAN(https://www.kernel.org/doc/html/latest/dev-tools/kasan.html), all the kernel space should be mapped into the shadow memory region. Why there are some accesses that not mapped into the shadow region? And in the code of "get_wild_bug_type", what's the logic to distinguish each type?
AFAIR user space memory region has no shadow. And if the kernel
>
> I have some doubts about the bug types reported by KASAN.
> 1. In Line 126 of "get_bug_type", it verifies if the address has the corresponding shadow memory. However, from the description of KASAN(https://www.kernel.org/doc/html/latest/dev-tools/kasan.html), all the kernel space should be mapped into the shadow memory region. Why there are some accesses that not mapped into the shadow region? And in the code of "get_wild_bug_type", what's the logic to distinguish each type?
directly accesses the user space, KASAN calls this
"wild-memory-access".
>
> 2. How does KASAN add redzone(e.g., KASAN_PAGE_REDZONE) for Page-level allocator?
KASAN_PAGE_REDZONE is used for redzone for large kmalloc().
There's a bug entry related to this:
https://bugzilla.kernel.org/show_bug.cgi?id=203967
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/c9ef35d4-5365-4e37-9e7e-68bad7355c21%40googlegroups.com.
Andrey Konovalov
May 20, 2020, 1:21:51 PM5/20/20
to 慕冬亮, syzkaller, kasan-dev
On Wed, May 20, 2020 at 7:21 PM Andrey Konovalov <andre...@google.com> wrote:
>
> On Wed, May 20, 2020 at 12:01 AM 慕冬亮 <mudongl...@gmail.com> wrote:
> >
> > Hi all,
> >
> > I have some doubts about the bug types reported by KASAN.
> > 1. In Line 126 of "get_bug_type", it verifies if the address has the corresponding shadow memory. However, from the description of KASAN(https://www.kernel.org/doc/html/latest/dev-tools/kasan.html), all the kernel space should be mapped into the shadow memory region. Why there are some accesses that not mapped into the shadow region? And in the code of "get_wild_bug_type", what's the logic to distinguish each type?
>
> AFAIR user space memory region has no shadow. And if the kernel
> directly accesses the user space, KASAN calls this
> "wild-memory-access".
>
> >
> > 2. How does KASAN add redzone(e.g., KASAN_PAGE_REDZONE) for Page-level allocator?
>
> I don't think there are redzones for pagealloc, AFAICS
> KASAN_PAGE_REDZONE is used for redzone for large kmalloc().
>
> There's a bug entry related to this:
> https://bugzilla.kernel.org/show_bug.cgi?id=203967
+kasan-dev
>
> On Wed, May 20, 2020 at 12:01 AM 慕冬亮 <mudongl...@gmail.com> wrote:
> >
> > Hi all,
> >
> > I have some doubts about the bug types reported by KASAN.
> > 1. In Line 126 of "get_bug_type", it verifies if the address has the corresponding shadow memory. However, from the description of KASAN(https://www.kernel.org/doc/html/latest/dev-tools/kasan.html), all the kernel space should be mapped into the shadow memory region. Why there are some accesses that not mapped into the shadow region? And in the code of "get_wild_bug_type", what's the logic to distinguish each type?
>
> AFAIR user space memory region has no shadow. And if the kernel
> directly accesses the user space, KASAN calls this
> "wild-memory-access".
>
> >
> > 2. How does KASAN add redzone(e.g., KASAN_PAGE_REDZONE) for Page-level allocator?
>
> I don't think there are redzones for pagealloc, AFAICS
> KASAN_PAGE_REDZONE is used for redzone for large kmalloc().
>
> There's a bug entry related to this:
> https://bugzilla.kernel.org/show_bug.cgi?id=203967
慕冬亮
May 20, 2020, 3:59:59 PM5/20/20
to syzkaller
On Wednesday, May 20, 2020 at 1:21:13 PM UTC-4, Andrey Konovalov wrote:
On Wed, May 20, 2020 at 12:01 AM 慕冬亮 <mudongl...@gmail.com> wrote:
>
> Hi all,
>
> I have some doubts about the bug types reported by KASAN.
> 1. In Line 126 of "get_bug_type", it verifies if the address has the corresponding shadow memory. However, from the description of KASAN(https://www.kernel.org/doc/html/latest/dev-tools/kasan.html), all the kernel space should be mapped into the shadow memory region. Why there are some accesses that not mapped into the shadow region? And in the code of "get_wild_bug_type", what's the logic to distinguish each type?
AFAIR user space memory region has no shadow. And if the kernel
directly accesses the user space, KASAN calls this
"wild-memory-access".
From the code of get_wild_bug_type, the bug type is like this in x86_64.
0000000000 - PAGE_SIZE -> null pointer dereference
PAGE_SIZE - TASK_SIZE(0x7ffffffff000) -> user memory access
UNUSED HOLE -> wild memory access
This is the reason why this bug(https://syzkaller.appspot.com/bug?id=159d03c53cb4c57b1a3b2f29373271bc2536b4df) reports wild-memory-access, right?
114 if ((unsigned long)info->access_addr < PAGE_SIZE)
115 bug_type = "null-ptr-deref";
116 else if ((unsigned long)info->access_addr < TASK_SIZE)
117 bug_type = "user-memory-access";
118 else
119 bug_type = "wild-memory-access";
115 bug_type = "null-ptr-deref";
116 else if ((unsigned long)info->access_addr < TASK_SIZE)
117 bug_type = "user-memory-access";
118 else
119 bug_type = "wild-memory-access";
>
> 2. How does KASAN add redzone(e.g., KASAN_PAGE_REDZONE) for Page-level allocator?
I don't think there are redzones for pagealloc, AFAICS
KASAN_PAGE_REDZONE is used for redzone for large kmalloc().
So there is only one behavior for pagealloc - Use-after-free. If shadow memory is filled with KASAN_FREE_PAGE after the page is freed, it reports "Use-after-free".
Even if it actually is OOB, it will still report "Use-after-free" with the accessed region freed, right?
> To unsubscribe from this group and stop receiving emails from it, send an email to syzk...@googlegroups.com.
Andrey Konovalov
May 22, 2020, 10:36:58 AM5/22/20
to 慕冬亮, syzkaller
On Wed, May 20, 2020 at 10:00 PM 慕冬亮 <mudongl...@gmail.com> wrote:
>
>
>
> On Wednesday, May 20, 2020 at 1:21:13 PM UTC-4, Andrey Konovalov wrote:
>>
>> On Wed, May 20, 2020 at 12:01 AM 慕冬亮 <mudongl...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > I have some doubts about the bug types reported by KASAN.
>> > 1. In Line 126 of "get_bug_type", it verifies if the address has the corresponding shadow memory. However, from the description of KASAN(https://www.kernel.org/doc/html/latest/dev-tools/kasan.html), all the kernel space should be mapped into the shadow memory region. Why there are some accesses that not mapped into the shadow region? And in the code of "get_wild_bug_type", what's the logic to distinguish each type?
>>
>> AFAIR user space memory region has no shadow. And if the kernel
>> directly accesses the user space, KASAN calls this
>> "wild-memory-access".
>>
>
> From the code of get_wild_bug_type, the bug type is like this in x86_64.
>
> 0000000000 - PAGE_SIZE -> null pointer dereference
> PAGE_SIZE - TASK_SIZE(0x7ffffffff000) -> user memory access
> UNUSED HOLE -> wild memory access
Ah, indeed, wild-memory-access is used when the kernel dereferences
>
>
>
> On Wednesday, May 20, 2020 at 1:21:13 PM UTC-4, Andrey Konovalov wrote:
>>
>> On Wed, May 20, 2020 at 12:01 AM 慕冬亮 <mudongl...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > I have some doubts about the bug types reported by KASAN.
>> > 1. In Line 126 of "get_bug_type", it verifies if the address has the corresponding shadow memory. However, from the description of KASAN(https://www.kernel.org/doc/html/latest/dev-tools/kasan.html), all the kernel space should be mapped into the shadow memory region. Why there are some accesses that not mapped into the shadow region? And in the code of "get_wild_bug_type", what's the logic to distinguish each type?
>>
>> AFAIR user space memory region has no shadow. And if the kernel
>> directly accesses the user space, KASAN calls this
>> "wild-memory-access".
>>
>
> From the code of get_wild_bug_type, the bug type is like this in x86_64.
>
> 0000000000 - PAGE_SIZE -> null pointer dereference
> PAGE_SIZE - TASK_SIZE(0x7ffffffff000) -> user memory access
> UNUSED HOLE -> wild memory access
non-canonical addresses.
>
> This is the reason why this bug(https://syzkaller.appspot.com/bug?id=159d03c53cb4c57b1a3b2f29373271bc2536b4df) reports wild-memory-access, right?
>
>
> 114 if ((unsigned long)info->access_addr < PAGE_SIZE)
> 115 bug_type = "null-ptr-deref";
> 116 else if ((unsigned long)info->access_addr < TASK_SIZE)
> 117 bug_type = "user-memory-access";
> 118 else
> 119 bug_type = "wild-memory-access";
>
>>
>> >
>> > 2. How does KASAN add redzone(e.g., KASAN_PAGE_REDZONE) for Page-level allocator?
>>
>> I don't think there are redzones for pagealloc, AFAICS
>> KASAN_PAGE_REDZONE is used for redzone for large kmalloc().
>>
>
> So there is only one behavior for pagealloc - Use-after-free. If shadow memory is filled with KASAN_FREE_PAGE after the page is freed, it reports "Use-after-free".
> Even if it actually is OOB, it will still report "Use-after-free" with the accessed region freed, right?
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/c2a71cce-cd6c-4cbf-a9d6-f09387a346e2%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages