Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Jan 2017 12:06:19 -0800
From: Kees Cook <>
To: Greg KH <>
Cc: Elena Reshetova <>, 
	"" <>, Arnd Bergmann <>, 
	Thomas Gleixner <>, Ingo Molnar <>, 
	"H. Peter Anvin" <>, Peter Zijlstra <>, 
	Will Deacon <>, David Windsor <>
Subject: Re: [RFCv2 PATCH 00/18] refcount_t API + usage

On Wed, Jan 18, 2017 at 2:30 AM, Greg KH <> 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 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.