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.1209191608160.17867@chino.kir.corp.google.com>
Date:	Wed, 19 Sep 2012 16:20:25 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Konrad Rzeszutek Wilk <konrad@...nel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	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 Wed, 19 Sep 2012, Linus Torvalds wrote:

> That does look simpler, and avoiding the lock is a good idea. Since we
> don't support lseek() (or pread/pwrite) on that thing anyway, there's
> no way to keep the fd open and just re-use it to read the data over
> and over, so populating it at open time sounds like a good solution
> with no real downsides.
> 

Yeah, my patch is functionally the same as what we currently have with the 
only exception being that it isn't racy.  I'm wondering if that's what we 
really want, though, since the data read from the file will remain 
persistent as long as it is opened.  That obviously happens in my patch 
because we allocate and copy the buffer at open(), but also happens 
implicitly with the old code precisely because it's a non-seekable file 
and *ppos == 0 only once (when not racy).

So if the API for these xen files is to remain persistent after open() as 
it currently does, then my patch solves the issue.  However, if the API 
wants to allow to only open() once and then read the spinlock_stats data 
continuously, then we'll need the mutex: allocate the file->private_data 
buffer once at open() for the maximum allowable size and then copy to the 
buffer from xen's spinlock_stats under the protection of the mutex to 
read().

Konrad?
--
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/