Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1576655
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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