Date: Wed, 20 Jan 2016 21:57:17 +0100 From: Yves-Alexis Perez <corsac@...ian.org> To: kernel-hardening@...ts.openwall.com, Kees Cook <keescook@...omium.org> Cc: David Windsor <dave@...gbits.org> Subject: Re: [RFC PATCH v2 00/12] Add PAX_REFCOUNT overflow protection On mar., 2016-01-19 at 11:07 -0800, Kees Cook wrote: > Hi David, > > On Thu, Dec 17, 2015 at 12:55 PM, Kees Cook <keescook@...omium.org> wrote: > > On Thu, Dec 17, 2015 at 6:57 AM, David Windsor <dave@...gbits.org> wrote: > > > NOTE: This is a v2 submission because patch 3/5 in v1 was too large to > > > sent > > > to kernel-hardening. Taking that as a sign that the patch needed to be > > > split, > > > I'm sending this version of the patchset, with the patches split more or > > > less > > > on a per-maintainer basis (except for those in drivers/). > > How's the next spin coming? It looks like we have some new real-world > examples of exploits that would have been blocked by this protection: > > http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-k > ernel-vulnerability-cve-2016-0728/ > > One thing which is surprising (I have to admit I'm not really an expert on how SLAB works) is how easy it apparently is to have multiple allocations end up at the same place. You don't even have to *know* the exact address. Wouldn't it be possible to at least have some randomization here, so new object are not at the same place as the not-freed-ones, somehow preventing the use-after-free and forcing an attacker to do some heap massaging? Regards, -- Yves-Alexis Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
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.