On Thu, Nov 16, 2017 at 12:29:56PM +0100, Greg Kroah-Hartman wrote:
On Wed, Nov 15, 2017 at 09:10:46PM +0000, Ben Hutchings wrote:
Please apply the attached backported patches to 4.4-stable. The upstream commits are:
06bd3c36a733 ext4: fix data exposure after a crash
This patch did not apply, and when I worked at it by hand to apply, it then broke the build with: fs/ext4/inode.c: In function ‘ext4_map_blocks’: fs/ext4/inode.c:669:17: error: ‘EXT4_GET_BLOCKS_ZERO’ undeclared (first use in this function); did you mean ‘EXT4_GET_BLOCKS_PRE_IO’? !(flags & EXT4_GET_BLOCKS_ZERO) && ^~~~~~~~~~~~~~~~~~~~
As Ted didn't provide this on the list of ext4 patches to backport to 4.4 in the past, I'm a bit hesitant to take this now. Are you sure it is needed?
As Greg noted, EXT4_GET_BLOCKS_ZERO is not in the Linux 4.4 kernel. To make this works requires at least three pre-requisite commits:
2dcba4781fa3: ext4: get rid of EXT4_GET_BLOCKS_NO_LOCK flag 53085fac02d1: ext4: provide ext4_issue_zeroout() c86d8db33a92: ext4: implement allocation of pre-zeroed blocks
I do *not* know if backporting these patches plus 06bd3c36a733 will result in a kernel that has no regressions. I'm doing a build and will run a regression test run. But it's a background low-priority work item, and if I see any regressions when I run the regression tests, I reserve the right not to decide not to care about trying to fix this particular backport.
Personally, I don't think the fix is *that* important. If you care about this kind of expore of stale data after a crash (which only happens if you get unlucky and/or your storage device reorders writes very aggressively), then you should care about all of the zero-days that result in privilege escalation that *don't* get backported to 4.4, and consider using something a lot more recent. Say, 4.9 or preferably 4.14? :-)
- Ted