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