Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1247502 > unrolled thread

some problems about kasan

Started byzhong jiang <zhongjiang@huawei.com>
First post2015-10-15 09:10 +0200
Last post2015-10-15 09:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  some problems about kasan zhong jiang <zhongjiang@huawei.com> - 2015-10-15 09:10 +0200
    Re: some problems about kasan Dmitry Vyukov <dvyukov@google.com> - 2015-10-15 09:50 +0200

#1247502 — some problems about kasan

Fromzhong jiang <zhongjiang@huawei.com>
Date2015-10-15 09:10 +0200
Subjectsome problems about kasan
Message-ID<qjKPL-7vI-1@gated-at.bofh.it>
1、 I feel confused about one of the cases when  testing the cases  kasan can solve . the function come from the kernel in the /lib/test_kasan.c.

  static noinline void __init kmalloc_uaf2(void)
{
	char *ptr1, *ptr2;
	size_t size = 43;

	pr_info("use-after-free after another kmalloc\n");
	ptr1 = kmalloc(size, GFP_KERNEL);
	if (!ptr1) {
		pr_err("Allocation failed\n");
		return;
	}

	kfree(ptr1);
	ptr2 = kmalloc(size, GFP_KERNEL);
	if (!ptr2) {
		pr_err("Allocation failed\n");
		return;
	}

	ptr1[40] = 'x';
	kfree(ptr2);
}

In the above function, the point ptr1 are probably  the same as the ptr2 . so the error not certain to occur.

2、Is the stack local variable out of bound access set by the GCC  ? I don't see any operate in the kernel

3、I want to know that the global variable size include redzone is allocated by the module_alloc().

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1247534

FromDmitry Vyukov <dvyukov@google.com>
Date2015-10-15 09:50 +0200
Message-ID<qjLsu-8id-7@gated-at.bofh.it>
In reply to#1247502
On Thu, Oct 15, 2015 at 8:59 AM, zhong jiang <zhongjiang@huawei.com> wrote:
> 1、 I feel confused about one of the cases when  testing the cases  kasan can solve . the function come from the kernel in the /lib/test_kasan.c.
>
>   static noinline void __init kmalloc_uaf2(void)
> {
>         char *ptr1, *ptr2;
>         size_t size = 43;
>
>         pr_info("use-after-free after another kmalloc\n");
>         ptr1 = kmalloc(size, GFP_KERNEL);
>         if (!ptr1) {
>                 pr_err("Allocation failed\n");
>                 return;
>         }
>
>         kfree(ptr1);
>         ptr2 = kmalloc(size, GFP_KERNEL);
>         if (!ptr2) {
>                 pr_err("Allocation failed\n");
>                 return;
>         }
>
>         ptr1[40] = 'x';
>         kfree(ptr2);
> }
>
> In the above function, the point ptr1 are probably  the same as the ptr2 . so the error not certain to occur.

Hi Zhong,

You are right that ptr1 and ptr2 are most likely will be equal.
To detect such bugs KASAN it meant to use "quarantine" and delay reuse
of heap objects. We have quarantine implementation in the following
branch:

https://github.com/google/kasan/blob/dmitryc-patches-original/mm/kasan/quarantine.c

It is not committed upstream yet.


> 2、Is the stack local variable out of bound access set by the GCC  ? I don't see any operate in the kernel

Yes, stack redzones and code to poison/unpoison them is emitted by compiler.
You can use objdump to look at generated machine code, you should see
instructions that poison/unpoison stack redzones.



> 3、I want to know that the global variable size include redzone is allocated by the module_alloc().

I don't understand the question. Please re-phrase it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web