Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Jan 2016 21:57:17 +0100
From: Yves-Alexis Perez <>
To:, Kees Cook <>
Cc: David Windsor <>
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 <> wrote:
> > On Thu, Dec 17, 2015 at 6:57 AM, David Windsor <> 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:
> 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?


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.