lkml.org 
[lkml]   [2012]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [kernel-hardening] Re: Add overflow protection to kref
    On 2012-02-24 23:13 +0400, Vasiliy Kulikov wrote:
    > On Fri, Feb 24, 2012 at 14:05 -0500, Nick Bowler wrote:
    > > On 2012-02-24 10:52 -0800, Kees Cook wrote:
    > > > On Fri, Feb 24, 2012 at 10:37 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
    > > > > On Fri, Feb 24, 2012 at 12:58:35PM -0500, David Windsor wrote:
    > > [...]
    > > > >> diff --git a/include/linux/kref.h b/include/linux/kref.h
    > > > >> index 9c07dce..fc0756a 100644
    > > > >> --- a/include/linux/kref.h
    > > > >> +++ b/include/linux/kref.h
    > > > >> @@ -38,8 +38,12 @@ static inline void kref_init(struct kref *kref)
    > > > >>   */
    > > > >>  static inline void kref_get(struct kref *kref)
    > > > >>  {
    > > > >> +   int rc = 0;
    > > > >>     WARN_ON(!atomic_read(&kref->refcount));
    > > > >> -   atomic_inc(&kref->refcount);
    > > > >> +   smp_mb__before_atomic_inc();
    > > > >> +   rc = atomic_add_unless(&kref->refcount, 1, INT_MAX);
    > > > >> +   smp_mb__after_atomic_inc();
    > > > >> +   BUG_ON(!rc);
    > > > >
    > > > > So you are guaranteeing to crash a machine here if this fails?  And you
    > > > > were trying to say this is a "security" based fix?
    > > >
    > > > This is the same principle as the stack protector. When something has
    > > > gone horribly wrong and cannot be sensibly recovered from, crash the
    > > > machine. Wrapping the refcount would cause all kinds of problems, so
    > > > that certainly seems worthy of a BUG().
    > >
    > > But in this case, the principle does not apply because we can recover.
    > > The reason we cannot recover from the stack protector case is because
    > > the stack protector is reacting after the fact, which is not the case
    > > here. Simply peg the reference count at the maximum value, neither
    > > incrementing it nor decrementing it further.
    >
    > ...and simply loose one reference, which leads to use-after-free.

    Please explain how a use-after-free could possibly occur if the
    reference count is never incremented or decremented again?

    Cheers,
    --
    Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-02-24 20:39    [W:0.023 / U:91.716 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site