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 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?) >  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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ