linux-kernel - Re: [ 10/41] CIFS: Do not kmalloc under the flocks spinlock

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 17 Mar 2012 02:37:41 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Jeff Layton <jlayton@...hat.com>,
	Pavel Shilovsky <piastry@...rsoft.ru>,
	Steve French <sfrench@...ibm.com>
Subject: Re: [ 10/41] CIFS: Do not kmalloc under the flocks spinlock

On Fri, Mar 16, 2012 at 04:38:20PM -0700, Greg KH wrote:
> 3.2-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Pavel Shilovsky <piastry@...rsoft.ru>
> 
> commit d5751469f210d2149cc2159ffff66cbeef6da3f2 upstream.
> 
> Reorganize the code to make the memory already allocated before
> spinlock'ed loop.
> 
> Reviewed-by: Jeff Layton <jlayton@...hat.com>
> Signed-off-by: Pavel Shilovsky <piastry@...rsoft.ru>
> Signed-off-by: Steve French <sfrench@...ibm.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> 
> ---
>  fs/cifs/file.c |   69 ++++++++++++++++++++++++++++++++++++++++++++++-----------
>  1 file changed, 56 insertions(+), 13 deletions(-)
> 
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
[....]
> @@ -940,29 +950,55 @@ cifs_push_posix_locks(struct cifsFileInf
>  		return rc;
>  	}
>  
> +	lock_flocks();
> +	cifs_for_each_lock(cfile->dentry->d_inode, before) {
> +		if ((*before)->fl_flags & FL_POSIX)
> +			count++;
> +	}
> +	unlock_flocks();
> +
>  	INIT_LIST_HEAD(&locks_to_send);
>  
> +	/*
> +	 * Allocating count locks is enough because no locks can be added to
> +	 * the list while we are holding cinode->lock_mutex that protects
> +	 * locking operations of this inode.
> +	 */
> +	for (; i < count; i++) {
> +		lck = kmalloc(sizeof(struct lock_to_push), GFP_KERNEL);
> +		if (!lck) {
> +			rc = -ENOMEM;
> +			goto err_out;
> +		}
> +		list_add_tail(&lck->llist, &locks_to_send);
> +	}
> +
> +	i = 0;
> +	el = locks_to_send.next;
>  	lock_flocks();
>  	cifs_for_each_lock(cfile->dentry->d_inode, before) {
> +		if (el == &locks_to_send) {
> +			/* something is really wrong */
> +			cERROR(1, "Can't push all brlocks!");
> +			break;
> +		}
>  		flock = *before;
> +		if ((flock->fl_flags & FL_POSIX) == 0)
> +			continue;
[...]

If I understand the logic correctly, el == &locks_to_send means we
already used all the lock_to_push structures.  (It should also be
equivalent to testing i == count.  Why is i incremented but not
otherwise used in the loop?)

But we test this before flock->fl_flags & FL_POSIX, which means we
don't know whether this lock actually needs to be assigned one of
those structures.  So it appears that we might report a spurious error
if the lock list ends with a mandatory lock.  If so, this is
relatively harmless but does need to be fixed.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)