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

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

On Mon, 17 Mar 2014, tytso@....edu wrote:

> Date: Mon, 17 Mar 2014 17:00:30 -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 Mon, Mar 17, 2014 at 01:59:35PM +0100, Lukáš Czerner wrote:
> > > The "dev2" branch in the ext4 git tree has all the patches in this
> > > series (1, 2, and 5) --- 3 was included earlier applied on top of the
> > > "dev" branch.  The "test" branch is the dev2 branch with the
> > > xfs-collapse-range branch pulled in, which actually enables the
> > > ZERO_RANGE flags (as well as the collapse range patches).
> > > 
> > > When I tried testing with the "test" branch, things failed pretty
> > > quickly.  I've attached two of these in this patch set.  I'm guessing
> > > it's some kind of memory corruption problem.  These failures are
> > > pretty repeatable, and it fails fast.
> 
> Can you let me know when you've had a chance to take a look at this
> failure?  Once we put back the EOFBLOCK_FL code, I suspect we should
> be fine with the first two patches in this patch series, but patch #5
> plus the xfs-collapse-range branch appears to still have issues.
> 
> Thanks!!
> 
> 						- Ted
> 

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.

I'll resend the patches including the EOFBLOCK_FL fixes.

Thanks!
-Lukas