lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 12 Jul 2012 00:24:11 +0200
From:	Miklos Szeredi <mszeredi@...e.cz>
To:	Eric Paris <eparis@...hat.com>
Cc:	Miklos Szeredi <miklos@...redi.hu>, viro@...IV.linux.org.uk,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 2/3] audit: fix refcounting in audit-tree

On Fri, 2012-07-06 at 13:52 -0400, Eric Paris wrote:
> On Mon, 2012-06-25 at 19:46 +0200, Miklos Szeredi wrote:
> > From: Miklos Szeredi <mszeredi@...e.cz>
> > 
> > Refcounting of fsnotify_mark in audit tree is broken.  E.g:
> > 
> >                               refcount
> > create_chunk
> >   alloc_chunk                 1
> >   fsnotify_add_mark           2
> > 
> > untag_chunk
> >   fsnotify_get_mark           3
> >   fsnotify_destroy_mark
> >     audit_tree_freeing_mark   2
> >   fsnotify_put_mark           1
> >   fsnotify_put_mark           0
> >   via destroy_list
> >     fsnotify_mark_destroy    -1
> > 
> > This was reported by various people as triggering Oops when stopping auditd.
> > 
> > We could just remove the put_mark from audit_tree_freeing_mark() but that would
> > break freeing via inode destruction.  So this patch simply omits a put_mark
> > after calling destroy_mark (or adds a get_mark before).
> > 
> > Next patch will clean up the remaining mess.
> > 
> > Signed-off-by: Miklos Szeredi <mszeredi@...e.cz>
> > CC: stable@...r.kernel.org
> 
> Agreed this is needed.  My changelog was:
> 
>     audit: fix ref count problems in audit trees
>     
>     Before the switch from in kernel inotify to fsnotify for audit trees the
>     code regularly did:
>         inotify_evict_watch(&chunk->watch);
>         put_inotify_watch(&chunk->watch);
>     
>     I translated this in fsnotify_speak into:
>         fsnotify_destroy_mark_by_entry(chunk_entry);
>         fsnotify_put_mark(chunk_entry);
>     
>     The problem is that the inotify_evict_watch function actually took a
>     reference on chunk->watch, which is what was being dropped by
>     put_inotify_watch().  The fsnotify code does not take such a reference
>     during fsnotify_destroy_mark_by_entry().  Thus we are dropping reference
>     counts prematurely and eventually we hit a use after free!  Whoops!
>     
>     Fix these call sites to not drop the extra reference.
>     
>     Reported-by: Valentin Avram <aval13@...il.com>
>     Reported-by: Peter Moody <pmoody@...gle.com>
>     Partial-patch-by: Marcelo Cerri <mhcerri@...ux.vnet.ibm.com>
>     Signed-off-by: Eric Paris <eparis@...hat.com>
> 
> Maybe you can use some of that changelog in your next post?  (If you do
> one?)  The only reason you would repost is because I don't understand
> why you took a ref in some places instead of just not dropping it
> everywhere...
> 
> > ---
> >  kernel/audit_tree.c |    5 ++---
> >  1 files changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
> > index d52d247..31fdc48 100644
> > --- a/kernel/audit_tree.c
> > +++ b/kernel/audit_tree.c
> > @@ -250,7 +250,6 @@ static void untag_chunk(struct node *p)
> >  		spin_unlock(&hash_lock);
> >  		spin_unlock(&entry->lock);
> >  		fsnotify_destroy_mark(entry);
> > -		fsnotify_put_mark(entry);
> >  		goto out;
> >  	}
> >  
> > @@ -293,7 +292,6 @@ static void untag_chunk(struct node *p)
> >  	spin_unlock(&hash_lock);
> >  	spin_unlock(&entry->lock);
> >  	fsnotify_destroy_mark(entry);
> > -	fsnotify_put_mark(entry);
> >  	goto out;
> >  
> >  Fallback:
> > @@ -332,6 +330,7 @@ static int create_chunk(struct inode *inode, struct audit_tree *tree)
> >  		spin_unlock(&hash_lock);
> >  		chunk->dead = 1;
> >  		spin_unlock(&entry->lock);
> > +		fsnotify_get_mark(entry);
> >  		fsnotify_destroy_mark(entry);
> >  		fsnotify_put_mark(entry);
> >  		return 0;
> 
> Like here?  Why not just avoid the atomic op altogether?

Simply because fsnotify_destroy_mark() assumes that the caller is
holding a reference to the mark (or the inode is keeping the mark
pinned, not the case here AFAICS).  Without that ref it can Oops.

> 
> > @@ -412,6 +411,7 @@ static int tag_chunk(struct inode *inode, struct audit_tree *tree)
> >  		spin_unlock(&chunk_entry->lock);
> >  		spin_unlock(&old_entry->lock);
> >  
> > +		fsnotify_get_mark(chunk_entry);
> >  		fsnotify_destroy_mark(chunk_entry);
> >  
> >  		fsnotify_put_mark(chunk_entry);
> > @@ -445,7 +445,6 @@ static int tag_chunk(struct inode *inode, struct audit_tree *tree)
> >  	spin_unlock(&old_entry->lock);
> >  	fsnotify_destroy_mark(old_entry);
> >  	fsnotify_put_mark(old_entry); /* pair to fsnotify_find mark_entry */
> > -	fsnotify_put_mark(old_entry); /* and kill it */
> >  	return 0;
> >  }
> >  
> 
> 


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ