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


Groups > linux.kernel > #1576655

Re: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN

From Andrey Ryabinin <ryabinin.a.a@gmail.com>
Newsgroups linux.kernel
Subject Re: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN
Date 2017-02-08 16:30 +0100
Message-ID <t8ClY-20B-27@gated-at.bofh.it> (permalink)
References <t6P3X-47k-5@gated-at.bofh.it> <t7UXD-7LS-11@gated-at.bofh.it> <t8zeq-a8-25@gated-at.bofh.it> <t8A0P-rN-37@gated-at.bofh.it> <t8Aka-O0-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


2017-02-08 16:10 GMT+03:00 Arnd Bergmann <arnd@arndb.de>:
> On Wed, Feb 8, 2017 at 1:24 PM, Johannes Berg <johannes@sipsolutions.net> wrote:

>
>> Btw, what's causing this to start with? Can't the compiler reuse the
>> stack places?
>
> I have no idea. It's trying to find out of bounds accesses for
> objects on the stack, so maybe it gives each variable a separate
> stack location in order to see which one caused problems?
>

If compiler cannot prove that access to the local variable is valid it
will add redzones around that variable
to be able to detect out of bounds accesses.

For example:
    static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value)
    {
           return nla_put(skb, attrtype, sizeof(u8), &value);
    }
compiler will surround 'value' with redzones to catch potential oob
access in nla_put().


Another way to fix this, would be something like this:

#ifdef CONFIG_KASAN
/* don't bloat stack */
#define __noinline_for_kasan    __noinline __maybe_unused
#else
#define __noinline_for_kasan    inline
#endif

static __noinline_for_kasan int nla_put_u8(struct sk_buff *skb, int
attrtype, u8 value)
{
       return nla_put(skb, attrtype, sizeof(u8), &value);
}

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN Arnd Bergmann <arnd@arndb.de> - 2017-02-03 17:40 +0100
  Re: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN David Miller <davem@davemloft.net> - 2017-02-06 18:10 +0100
    KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN Arnd Bergmann <arnd@arndb.de> - 2017-02-08 13:10 +0100
      Re: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack  overflow with CONFIG_KASAN Johannes Berg <johannes@sipsolutions.net> - 2017-02-08 14:00 +0100
        Re: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow  with CONFIG_KASAN Arnd Bergmann <arnd@arndb.de> - 2017-02-08 14:20 +0100
          Re: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow  with CONFIG_KASAN Andrey Ryabinin <ryabinin.a.a@gmail.com> - 2017-02-08 16:30 +0100
        RE: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack  overflow with CONFIG_KASAN David Laight <David.Laight@ACULAB.COM> - 2017-02-08 17:50 +0100
      Re: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack  overflow with CONFIG_KASAN David Miller <davem@davemloft.net> - 2017-02-08 17:40 +0100

csiph-web