[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1459647465.2704.96.camel@decadent.org.uk>
Date: Sun, 03 Apr 2016 02:37:45 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: Theodore Ts'o <tytso@....edu>, Yves-Alexis Perez <corsac@...ian.org>
Cc: oss-security@...ts.openwall.com, Johannes Segitz <jsegitz@...e.com>
Subject: Re: ext4 data corruption due to punch hole races
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.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
