[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 28 Nov 2015 10:25:17 +0100
From: Quentin Casasnovas <quentin.casasnovas@...cle.com>
To: Kees Cook <keescook@...omium.org>
Cc: Quentin Casasnovas <quentin.casasnovas@...cle.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: status: GRKERNSEC_KSTACKOVERFLOW
On Fri, Nov 27, 2015 at 12:23:58PM -0800, Kees Cook wrote:
> On Wed, Nov 25, 2015 at 3:45 PM, Quentin Casasnovas
> <quentin.casasnovas@...cle.com> wrote:
> >
> > Finally, I'd like to find a real life example where one could overflow the
> > kernel stack, so it can be used to test the feature (once properly split)
> > and show it can happen, for real, before sending real patches for review.
> > I might have found such a case because of what appears to me like a gcc
> > bug, more on this in another follow up :)
>
> I think at least some of the past flaws have been related to having
> dynamic stack allocations, where an attacker could control the size of
> the object. And "alloca" overflow style attack.
>
It turns out there isn't any gcc problems and huge stack usage (sometimes
even 5Kb, like for nl80211_send_wiphy(), or 2Kb in interrupt context for
kbd_event()) in functions not supposed to require a lot of stack was caused
by KASAN on my tests. The THREAD_SIZE is properly augmented when using
KASAN so that shouldn't cause any problems, sorry for the noise.
>
> I will see about getting an lkdtm test written too. Though testing
> this when there is no guard page seems like a bad idea. I'll have to
> get creative on the overwrite. Hmm.
>
:)
Quentin
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
