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.