linux-kernel - Re: 3.6rc6 slab corruption.

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]

Message-ID: <alpine.DEB.2.00.1209181322490.25146@chino.kir.corp.google.com>
Date:	Tue, 18 Sep 2012 13:24:15 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@...ibm.com>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Subject: Re: 3.6rc6 slab corruption.

On Tue, 18 Sep 2012, Konrad Rzeszutek Wilk wrote:

> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index 2340f69..309b235 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -524,6 +524,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_blob);
>  struct array_data {
>  	void *array;
>  	u32 elements;
> +	struct mutex lock;

This should be a spinlock.

>  };
>  
>  static int u32_array_open(struct inode *inode, struct file *file)
> @@ -580,6 +581,7 @@ static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
>  	struct array_data *data = inode->i_private;
>  	size_t size;
>  
> +	mutex_lock(&data->lock);
>  	if (*ppos == 0) {
>  		if (file->private_data) {
>  			kfree(file->private_data);
> @@ -594,6 +596,7 @@ static ssize_t u32_array_read(struct file *file, char __user *buf, size_t len,
>  	if (file->private_data)
>  		size = strlen(file->private_data);
>  
> +	mutex_unlock(&data->lock);
>  	return simple_read_from_buffer(buf, len, ppos,
>  					file->private_data, size);
>  }

Your critical section isn't entirely covered since you're still accessing 
file->private_data in the call to simple_read_from_buffer().  What happens 
if a concurrent reader does file->private_data = NULL immediately after 
your unlock?
--
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/