linux-kernel - Re: [PATCH v3 0/3] sched: Always check the integrity of the canary

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Sep 2014 18:44:09 +0100
From:	Aaron Tomlin <atomlin@...hat.com>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	"peterz@...radead.org" <peterz@...radead.org>,
	"dzickus@...hat.com" <dzickus@...hat.com>,
	"jcastillo@...hat.com" <jcastillo@...hat.com>,
	"riel@...hat.com" <riel@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"minchan@...nel.org" <minchan@...nel.org>,
	"mingo@...nel.com" <mingo@...nel.com>,
	"bmr@...hat.com" <bmr@...hat.com>,
	"prarit@...hat.com" <prarit@...hat.com>,
	"oleg@...hat.com" <oleg@...hat.com>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hannes@...xchg.org" <hannes@...xchg.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"aneesh.kumar@...ux.vnet.ibm.com" <aneesh.kumar@...ux.vnet.ibm.com>,
	"akpm@...gle.com" <akpm@...gle.com>,
	"jgh@...hat.com" <jgh@...hat.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"pzijlstr@...hat.com" <pzijlstr@...hat.com>
Subject: Re: [PATCH v3 0/3] sched: Always check the integrity of the canary

On Thu, Sep 11, 2014 at 04:02:45PM +0000, David Laight wrote:
> From: Aaron Tomlin
> > Currently in the event of a stack overrun a call to schedule()
> > does not check for this type of corruption. This corruption is
> > often silent and can go unnoticed. However once the corrupted
> > region is examined at a later stage, the outcome is undefined
> > and often results in a sporadic page fault which cannot be
> > handled.
> > 
> > The first patch adds a canary to init_task's end of stack.
> > While the second patch provides a helper to determine the
> > integrity of the canary. The third checks for a stack
> > overrun and takes appropriate action since the damage
> > is already done, there is no point in continuing.
> 
> Clearly you've just been 'bitten' by a kernel stack overflow.
> But a simple 'canary' isn't going to find most of the overflows
> and will give an incorrect 'sense of security'.

Please note that this is not suppose to be a 'perfect' solution.
Rather a worth while check in this particular code path.
Let's assume that the canary is damaged. In this situation it is
rather likely that the thread_info object has been compromised too.

-- 
Aaron Tomlin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/