Re: ext4 data corruption due to punch hole races

[Ben Hutchings <ben () decadent org uk>]

On Sat, 2016-04-02 at 11:46 -0400, Theodore Ts'o wrote:
> On Sat, Apr 02, 2016 at 03:14:57PM +0200, Yves-Alexis Perez wrote:
> > > "When punching holes into a file races with the page fault of the same
> > > area, it is possible that freed blocks remain referenced from page cache
> > > pages mapped to process' address space. Thus modification of these blocks
> > > can corrupt data someone else is now storing in those blocks (which
> > > obviously has security implications if you can trick filesystem into
> > > storing some important file in those blocks).
> > >
> > > This affects all the kernels where we support ext4 for writing. Relevant
> > > fixes upstream are commits ea3d7209ca01da209cda6f0dea8be9cc4b7a933b,
> > > 17048e8a083fec7ad841d88ef0812707fbc7e39f,
> > > 32ebffd3bbb4162da5ff88f9a35dd32d0a28ea70,
> > > 011278485ecc3cd2a3954b5d4c73101d919bf1fa."
> > any reason why those commits weren't CC: stable? If this really affects all
> > kernels where ext4 writing is possible, that means basically all current
> > stable kernels more or less, I guess?
> They weren't cc'ed stable because they're fairly complex patches,
> which (a) means they probably wouldn't auto-apply anyway, and (b)
> someone who does do the (probably manual) back port they would be
> *very* strongly advised to run them through a complete ext4 regression
> test series[1] to make sure the patches actually don't make things
> worse from a stability perspective.

Regardless of how difficult it is, we probably need to fix the bugs
somehow in Debian stable.  It looks like the commits are:

ea3d7209ca01 fix for PUNCH_HOLE (3.0+)
17048e8a083f fix for default fallocate (all) and ZERO_RANGE (3.15+)
32ebffd3bbb4 fix for COLLAPSE_RANGE (3.15+) and INSERT_RANGE (4.2+)
011278485ecc fix for PUNCH_HOLE (3.0+) and ZERO_RANGE (3.15+)

So the third would not be needed for stable branches up to 3.14 but
otherwise they're all needed (at least in part) for all live stable
branches - right?

(As there are clearly multiple bugs here; why only one CVE ID?)

> [1] http://thunk.org/gce-xfstests
>
> I do spend *small* amount of work testing the stable kernels (3.10,
> 3.14, 3.18, 4.1, 4.4) using gce-xfstests and backporting and testing
> patches that weren't cc'ed to stable for various reasons.  It's a
> pretty low priority task, though, and I'd really love to delegate this
> to someone else.  I just don't have the bandwidth to support back
> level kernels (this is why distributions get paid the big bucks), and
> note that even if I or someone else stepped up, this won't necessarily
> help Debian, which isn't on a one of the stable kernel versions.

wheezy is: https://www.kernel.org/category/releases.html

> If anyone is interested, please contact me.  Otherwise, I'll get to it
> eventually.

Since I do most of the security backports for Debian, of course I am
interested.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.

Attachment: signature.asc
Description: This is a digitally signed message part