linux-ext4 - Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO

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] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1403181350590.2121@localhost.localdomain>
Date:	Tue, 18 Mar 2014 13:52:55 +0100 (CET)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	tytso@....edu
cc:	Lukáš Czerner <lczerner@...hat.com>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for
 fallocate

On Tue, 18 Mar 2014, tytso@....edu wrote:

> Date: Tue, 18 Mar 2014 08:39:19 -0400
> From: tytso@....edu
> To: =?utf-8?B?THVrw6HFoSBDemVybmVyIDxsY3plcm5lckByZWRoYXQuY29tPg==?=@...nk.org
> Cc: linux-ext4@...r.kernel.org
> Subject: Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate
> 
> On Tue, Mar 18, 2014 at 12:37:47PM +0100, Lukáš Czerner wrote:
> > Ok, finally I got it. The problem is that we now have commit 
> > 
> > 97d39798f77aef626130db8590cc79195300227b ext4: delete path dealloc
> > code in ext4_ext_handle_uninitialized_extents
> > 
> > which I was not aware of before. And when merging you have used the
> > same out2 label out of the function. However when creating my new
> > function ext4_ext_convert_initialized_exten() so I've done the same
> > thing as with ext4_ext_handle_uninitialized_extents() and freed the
> > path. And since we do not set path to NULL in ext4_ext_map_blocks
> > after calling ext4_ext_convert_initialized_extent() when we hit the
> > condition at the out2:
> > 
> > 	if (path) {
> > 		ext4_ext_drop_refs(path);
> > 		kfree(path);
> > 	}
> > 
> > we will double-free possibly destroying data from someone else. That
> > is why we've seen what looked like a random memory corruption.
> 
> My bad!  I remember noticing that particular semantic conflict, and I
> *thought* I had fixed it up.  The fixup must have gotten lost when I
> was doing some patch wrangling (I was moving aronud some patch hunks
> around to be the most logical with respect to the COLLAPSE RANGE, and
> I must have dropped the fixup somewhere along the way).
> 
> Thanks for finding it!
> 
> 						- Ted
> 

No problem. I am running some tests right now to make sure that
everything is in order and will send out patches 1, 2, and 5 once
again in a separate patch set based on ext4/dev branch.

Thanks!
-Lukas