[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Jan 2017 12:06:19 -0800
From: Kees Cook <keescook@...omium.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Elena Reshetova <elena.reshetova@...el.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Arnd Bergmann <arnd@...db.de>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <h.peter.anvin@...el.com>, Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will.deacon@....com>, David Windsor <dwindsor@...il.com>
Subject: Re: [RFCv2 PATCH 00/18] refcount_t API + usage
On Wed, Jan 18, 2017 at 2:30 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Wed, Jan 18, 2017 at 11:11:29AM +0200, Elena Reshetova wrote:
>> Changes since v1:
>> - kref INIT fixes are moved to a proper separate commit
>> - Peter's commits are now properly integrated into series
>> - various small fixes are incorporated based on testing
>> results and feedback
>>
>> This patch series is build on top of Peter's Zijlstra patches
>> that provide refcount_t type and API definition.
>> The rest of patches convert various places of kernel subsystems
>> where atomic_t was used for reference counting to new refcount_t type and API.
>> By doing this, we make sure that underflows and overflows
>> cannot occur in these places and therefore no use-after-free situation
>> can be created and misused by an attacker.
>
> Your first 7 patches are fine, and most of them are already in the tip
> tree and getting use in linux-next now. I'd recommend submitting the
Where do you see this? I haven't seen refcount_t land in -next yet.
Should I carry these in the KSPP tree, or who should take them?
-Kees
--
Kees Cook
Nexus Security
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.
