[PATCH] kref: oops on zero or negative refcount

[PATCH] kref: oops on zero or negative refcount

[Mateusz Guzik]

In use after free situations, it is possible for one thread to write to
memory that has just been reallocated to a new user. This could open up
potential security issues.

Close off those potential security holes by terminating the current
thread when kref encounters such a race condition or underflow.

Signed-off-by: Mateusz Guzik <mguzik@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
---
 include/linux/kref.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/kref.h b/include/linux/kref.h
index 484604d..c3f8a0a 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -43,8 +43,10 @@ static inline void kref_get(struct kref *kref)
 	/* If refcount was 0 before incrementing then we have a race
 	 * condition when this kref is freeing by some other thread right now.
 	 * In this case one should use kref_get_unless_zero()
+	 *
+	 * Terminate the current thread to stop potential security exploits.
 	 */
-	WARN_ON_ONCE(atomic_inc_return(&kref->refcount) < 2);
+	BUG_ON(atomic_inc_return(&kref->refcount) < 2);
 }
 
 /**
-- 
1.8.3.1

Re: [PATCH] kref: oops on zero or negative refcount

[Dave Jones]

On Thu, Feb 20, 2014 at 06:44:59PM +0100, Mateusz Guzik wrote:
 > In use after free situations, it is possible for one thread to write to
 > memory that has just been reallocated to a new user. This could open up
 > potential security issues.
 > 
 > diff --git a/include/linux/kref.h b/include/linux/kref.h
 > index 484604d..c3f8a0a 100644
 > --- a/include/linux/kref.h
 > +++ b/include/linux/kref.h
 > @@ -43,8 +43,10 @@ static inline void kref_get(struct kref *kref)
 >  	/* If refcount was 0 before incrementing then we have a race
 >  	 * condition when this kref is freeing by some other thread right now.
 >  	 * In this case one should use kref_get_unless_zero()
 > +	 *
 > +	 * Terminate the current thread to stop potential security exploits.
 >  	 */
 > -	WARN_ON_ONCE(atomic_inc_return(&kref->refcount) < 2);
 > +	BUG_ON(atomic_inc_return(&kref->refcount) < 2);

This isn't "terminating the thread", this is "lock up the box".

	Dave

 

Re: [PATCH] kref: oops on zero or negative refcount

[Rik van Riel]

On 02/20/2014 01:14 PM, Dave Jones wrote:
> On Thu, Feb 20, 2014 at 06:44:59PM +0100, Mateusz Guzik wrote:
>  > In use after free situations, it is possible for one thread to write to
>  > memory that has just been reallocated to a new user. This could open up
>  > potential security issues.
>  > 
>  > diff --git a/include/linux/kref.h b/include/linux/kref.h
>  > index 484604d..c3f8a0a 100644
>  > --- a/include/linux/kref.h
>  > +++ b/include/linux/kref.h
>  > @@ -43,8 +43,10 @@ static inline void kref_get(struct kref *kref)
>  >  	/* If refcount was 0 before incrementing then we have a race
>  >  	 * condition when this kref is freeing by some other thread right now.
>  >  	 * In this case one should use kref_get_unless_zero()
>  > +	 *
>  > +	 * Terminate the current thread to stop potential security exploits.
>  >  	 */
>  > -	WARN_ON_ONCE(atomic_inc_return(&kref->refcount) < 2);
>  > +	BUG_ON(atomic_inc_return(&kref->refcount) < 2);
> 
> This isn't "terminating the thread", this is "lock up the box".

Only if kref_get holds a lock while encountering a refcount
underflow, right?

-- 
All rights reversed

Re: [PATCH] kref: oops on zero or negative refcount

[Mateusz Guzik]

On Thu, Feb 20, 2014 at 01:14:40PM -0500, Dave Jones wrote:
> On Thu, Feb 20, 2014 at 06:44:59PM +0100, Mateusz Guzik wrote:
>  > In use after free situations, it is possible for one thread to write to
>  > memory that has just been reallocated to a new user. This could open up
>  > potential security issues.
>  > 
>  > diff --git a/include/linux/kref.h b/include/linux/kref.h
>  > index 484604d..c3f8a0a 100644
>  > --- a/include/linux/kref.h
>  > +++ b/include/linux/kref.h
>  > @@ -43,8 +43,10 @@ static inline void kref_get(struct kref *kref)
>  >  	/* If refcount was 0 before incrementing then we have a race
>  >  	 * condition when this kref is freeing by some other thread right now.
>  >  	 * In this case one should use kref_get_unless_zero()
>  > +	 *
>  > +	 * Terminate the current thread to stop potential security exploits.
>  >  	 */
>  > -	WARN_ON_ONCE(atomic_inc_return(&kref->refcount) < 2);
>  > +	BUG_ON(atomic_inc_return(&kref->refcount) < 2);
> 
> This isn't "terminating the thread", this is "lock up the box".
> 

Well, extent of damage caused by non-panicking BUG_ON (if any) depends
on the state when kref_get was executed.

However, since this condition is already a sign of big trouble (and a
potential exploitation attempt), I think a WARN_ON_ONCE is not
sufficient.

That said, can you elaborate on your concers? You just don't like that
comment, don't want that BUG_ON (want a panic instead) or maybe you
don't like the change at all (or something else)?

Thanks,
-- 
Mateusz Guzik

Re: [PATCH] kref: oops on zero or negative refcount

[Rafael Aquini]

On Thu, Feb 20, 2014 at 01:17:44PM -0500, Rik van Riel wrote:
> On 02/20/2014 01:14 PM, Dave Jones wrote:
> > On Thu, Feb 20, 2014 at 06:44:59PM +0100, Mateusz Guzik wrote:
> >  > In use after free situations, it is possible for one thread to write to
> >  > memory that has just been reallocated to a new user. This could open up
> >  > potential security issues.
> >  > 
> >  > diff --git a/include/linux/kref.h b/include/linux/kref.h
> >  > index 484604d..c3f8a0a 100644
> >  > --- a/include/linux/kref.h
> >  > +++ b/include/linux/kref.h
> >  > @@ -43,8 +43,10 @@ static inline void kref_get(struct kref *kref)
> >  >  	/* If refcount was 0 before incrementing then we have a race
> >  >  	 * condition when this kref is freeing by some other thread right now.
> >  >  	 * In this case one should use kref_get_unless_zero()
> >  > +	 *
> >  > +	 * Terminate the current thread to stop potential security exploits.
> >  >  	 */
> >  > -	WARN_ON_ONCE(atomic_inc_return(&kref->refcount) < 2);
> >  > +	BUG_ON(atomic_inc_return(&kref->refcount) < 2);
> > 
> > This isn't "terminating the thread", this is "lock up the box".
> 
> Only if kref_get holds a lock while encountering a refcount
> underflow, right?
>

Yes, and in a quick glance through the tree it seems we have several
codesites where we can find such condition likely to happen,
unfortunately.