All of lore.kernel.org
 help / color / mirror / Atom feed
* Why KASAN doesn't detect this stack oob fault?
@ 2020-08-23  3:04 richard clark
  2020-08-23  4:55 ` Willy Tarreau
  0 siblings, 1 reply; 3+ messages in thread
From: richard clark @ 2020-08-23  3:04 UTC (permalink / raw)
  To: linux-kernel; +Cc: andreyknvl

Hi guys,

I ins a kmod with below code in a KASAN enabled kernel (
5.7.0,
CONFIG_KASAN=y
CONFIG_KASAN_GENERIC=y
CONFIG_KASAN_OUTLINE=y):

static int kmod_init(void)
{
    int i;
    int arr[4];

    for (i = 0; i < 20; i++) {
        arr[i] = i;
        printk("arr[%d] = %d\n", i, arr[i]);
    }
    return 0;
}

The output is after insmod:

[ 1511.800683] arr[0] = 0
[ 1511.800685] arr[1] = 1
[ 1511.800686] arr[2] = 2
[ 1511.800687] arr[3] = 3
[ 1511.800688] arr[4] = 4
[ 1511.800690] arr[5] = 5
[ 1511.800691] arr[6] = 6
[ 1511.800692] arr[7] = 7
[ 1511.800693] arr[8] = 8
[ 1511.800694] arr[9] = 9
[ 1511.800695] arr[10] = 10
[ 1511.800696] arr[11] = 11
[ 1511.800697] arr[12] = 12
[ 1511.800699] arr[13] = 13
[ 1511.800700] arr[14] = 14
[ 1511.800701] arr[15] = 15
[ 1511.800702] arr[16] = 16
[ 1511.800704] arr[17] = 17
[ 1511.800705] arr[18] = 18
[ 1511.800706] arr[19] = 19

The kernel is not tainted and the gcc version is 7.5 used to build the kernel.
The question is:
1. Why the stack out-of-bound can work?
2. Why the KASAN doesn't detect this?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Why KASAN doesn't detect this stack oob fault?
  2020-08-23  3:04 Why KASAN doesn't detect this stack oob fault? richard clark
@ 2020-08-23  4:55 ` Willy Tarreau
  2020-08-24  6:29   ` richard clark
  0 siblings, 1 reply; 3+ messages in thread
From: Willy Tarreau @ 2020-08-23  4:55 UTC (permalink / raw)
  To: richard clark; +Cc: linux-kernel, andreyknvl

On Sun, Aug 23, 2020 at 11:04:34AM +0800, richard clark wrote:
> Hi guys,
> 
> I ins a kmod with below code in a KASAN enabled kernel (
> 5.7.0,
> CONFIG_KASAN=y
> CONFIG_KASAN_GENERIC=y
> CONFIG_KASAN_OUTLINE=y):
> 
> static int kmod_init(void)
> {
>     int i;
>     int arr[4];
> 
>     for (i = 0; i < 20; i++) {
>         arr[i] = i;
>         printk("arr[%d] = %d\n", i, arr[i]);
>     }
>     return 0;
> }
> 
> The output is after insmod:
> 
> [ 1511.800683] arr[0] = 0
> [ 1511.800685] arr[1] = 1
> [ 1511.800686] arr[2] = 2
> [ 1511.800687] arr[3] = 3
> [ 1511.800688] arr[4] = 4
> [ 1511.800690] arr[5] = 5
> [ 1511.800691] arr[6] = 6
> [ 1511.800692] arr[7] = 7
> [ 1511.800693] arr[8] = 8
> [ 1511.800694] arr[9] = 9
> [ 1511.800695] arr[10] = 10
> [ 1511.800696] arr[11] = 11
> [ 1511.800697] arr[12] = 12
> [ 1511.800699] arr[13] = 13
> [ 1511.800700] arr[14] = 14
> [ 1511.800701] arr[15] = 15
> [ 1511.800702] arr[16] = 16
> [ 1511.800704] arr[17] = 17
> [ 1511.800705] arr[18] = 18
> [ 1511.800706] arr[19] = 19
> 
> The kernel is not tainted and the gcc version is 7.5 used to build the kernel.
> The question is:
> 1. Why the stack out-of-bound can work?
> 2. Why the KASAN doesn't detect this?

Have you verified in the output code that the compiler didn't optimize
the stack access away since it doesn't need it ?

Just to make sure, do it in two distinct loops so that there are more
chances for the stack to be really used:

 static int kmod_init(void)
 {
     int i;
     int arr[4];
 
     for (i = 0; i < 20; i++)
         arr[i] = i;

     for (i = 0; i < 20; i++)
         printk("arr[%d] = %d\n", i, arr[i]);

     return 0;
 }

Willy

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Why KASAN doesn't detect this stack oob fault?
  2020-08-23  4:55 ` Willy Tarreau
@ 2020-08-24  6:29   ` richard clark
  0 siblings, 0 replies; 3+ messages in thread
From: richard clark @ 2020-08-24  6:29 UTC (permalink / raw)
  To: Willy Tarreau; +Cc: linux-kernel, Andrey Konovalov

Willy Tarreau <w@1wt.eu> 于2020年8月23日周日 下午12:56写道:
>
> On Sun, Aug 23, 2020 at 11:04:34AM +0800, richard clark wrote:
> > Hi guys,
> >
> > I ins a kmod with below code in a KASAN enabled kernel (
> > 5.7.0,
> > CONFIG_KASAN=y
> > CONFIG_KASAN_GENERIC=y
> > CONFIG_KASAN_OUTLINE=y):
> >
> > static int kmod_init(void)
> > {
> >     int i;
> >     int arr[4];
> >
> >     for (i = 0; i < 20; i++) {
> >         arr[i] = i;
> >         printk("arr[%d] = %d\n", i, arr[i]);
> >     }
> >     return 0;
> > }
> >
> > The output is after insmod:
> >
> > [ 1511.800683] arr[0] = 0
> > [ 1511.800685] arr[1] = 1
> > [ 1511.800686] arr[2] = 2
> > [ 1511.800687] arr[3] = 3
> > [ 1511.800688] arr[4] = 4
> > [ 1511.800690] arr[5] = 5
> > [ 1511.800691] arr[6] = 6
> > [ 1511.800692] arr[7] = 7
> > [ 1511.800693] arr[8] = 8
> > [ 1511.800694] arr[9] = 9
> > [ 1511.800695] arr[10] = 10
> > [ 1511.800696] arr[11] = 11
> > [ 1511.800697] arr[12] = 12
> > [ 1511.800699] arr[13] = 13
> > [ 1511.800700] arr[14] = 14
> > [ 1511.800701] arr[15] = 15
> > [ 1511.800702] arr[16] = 16
> > [ 1511.800704] arr[17] = 17
> > [ 1511.800705] arr[18] = 18
> > [ 1511.800706] arr[19] = 19
> >
> > The kernel is not tainted and the gcc version is 7.5 used to build the kernel.
> > The question is:
> > 1. Why the stack out-of-bound can work?
> > 2. Why the KASAN doesn't detect this?
>
> Have you verified in the output code that the compiler didn't optimize
> the stack access away since it doesn't need it ?
>
yes, the compiler did optimize the stack access away with this code piece...
> Just to make sure, do it in two distinct loops so that there are more
> chances for the stack to be really used:
>
Right, the KASAN stack oob will be triggered when I update the code to
a memory access with the stack address
>
>  static int kmod_init(void)
>  {
>      int i;
>      int arr[4];
>
>      for (i = 0; i < 20; i++)
>          arr[i] = i;
>
>      for (i = 0; i < 20; i++)
>          printk("arr[%d] = %d\n", i, arr[i]);
>
>      return 0;
>  }
>
> Willy

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-08-24  6:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-23  3:04 Why KASAN doesn't detect this stack oob fault? richard clark
2020-08-23  4:55 ` Willy Tarreau
2020-08-24  6:29   ` richard clark

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.