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]

Date:	Wed, 19 Sep 2012 19:46:57 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
cc:	Konrad Rzeszutek Wilk <konrad@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.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>
Subject: Re: 3.6rc6 slab corruption.

On Thu, 20 Sep 2012, Raghavendra K T wrote:

> Only problem, I find is histogram data expands dynamically (because it
> changes). I think having static allocation of 352 bytes as suggested
> Linus is a good idea.
> 

Certainly, but it's a different topic and would be a subsequent patch to 
either my patch or Konrad's patch.  Before that's done, I think we should 
fix the race condition that currently exists either by:

 - merging my patch (which I can sign-off and write a changelog for if
   Konrad agrees), or

 - merging Konrad's patch and introducing a mutex so that it's possible to 
   do many reads to collect statistics after opening the file a single 
   time with a single fd.

Since these files are incapable of doing lseek, it would seem that my 
patch would be best and you'd simply want to close() + open() to read new 
data, which also guarantees that all readers get the same information.  
The only reason I hesitate on that and will defer to Konrad's opinion is 
because the way the code is currently written looks like it was intended 
to copy the data are read() rather than open(); in other words, it almost 
seems as if they were made to be non-seekable after the u32_array_read() 
implementation was complete and it was at one time possible to do an 
lseek(SEEK_SET).

After that's fixed, and to address your concern, we can simply do the 
allocation of file->private_data for the maximum size possible when the 
file is created as a follow-up patch.
--
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/