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.