Please apply the attached backported patches to 4.4-stable. The upstream commits are:
06bd3c36a733 ext4: fix data exposure after a crash c8401dda2f0a KVM: x86: fix singlestepping over syscall 0d0e57697f16 bpf: don't let ldimm64 leak map addresses on unprivileged 089bc0143f48 xen-blkback: don't leak stack data via response ring df80cd9b28b9 sctp: do not peel off an assoc from one netns to another one 2cb80187ba06 net: cdc_ether: fix divide by 0 on bad descriptors 7fd078337201 net: qmi_wwan: fix divide by 0 on bad descriptors
The last three are not in later stable branches yet. The USB net driver fixes are already in David Miller's queue for stable, and i have asked him to add the sctp fix.
Ben.
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?
thanks,
greg k-h
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
On Thu, Nov 16, 2017 at 05:07:42PM -0500, Theodore Ts'o wrote:
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? :-)
Well, some people are stuck on 4.4 kernels for the obviously shitty reasons (SoC crap), so that option is not always available to them. So if you do happen to be running these backports through some testing, I would appreciate the results :)
thanks,
greg k-h
On Thu, 2017-11-16 at 17:07 -0500, Theodore Ts'o wrote:
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 previously backported this to 3.16 and simply removed that flag check, on the basis that the feature it represents is not supported at all. The backports to 3.10 and 3.12, and the backport I sent to Greg for 4.4 (as an attachment), also made that change. Are you saying that a backport of the fix actually needs to check for a similar condition, even in branches where the flag doesn't exist?
Ben.
On Fri 17-11-17 13:30:16, Ben Hutchings wrote:
On Thu, 2017-11-16 at 17:07 -0500, Theodore Ts'o wrote:
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 previously backported this to 3.16 and simply removed that flag check, on the basis that the feature it represents is not supported at all. The backports to 3.10 and 3.12, and the backport I sent to Greg for 4.4 (as an attachment), also made that change. Are you saying that a backport of the fix actually needs to check for a similar condition, even in branches where the flag doesn't exist?
No, you did the right thing. Just removing the !(flags & EXT4_GET_BLOCKS_ZERO) check is the right thing to do for the kernels not supporting EXT4_GET_BLOCKS_ZERO. The rationale is: The condition just avoids adding inode to transaction's list when we know blocks were zeroed-out by the allocator. For kernels not supporting zeroing in the allocator we can just remove this optimization. Thanks for sending the backports!
Honza
On Thu, 2017-11-16 at 12:29 +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) && ^~~~~~~~~~~~~~~~~~~~
I attached a mailbox with backported versions of all of these. The inline list was just for reference.
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?
The Fixes field refers to a commit that went into 3.8, so if that's correct then yes this is needed.
Ben.
On Fri, Nov 17, 2017 at 12:06:50PM +0000, Ben Hutchings wrote:
On Thu, 2017-11-16 at 12:29 +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) && ^~~~~~~~~~~~~~~~~~~~
I attached a mailbox with backported versions of all of these. The inline list was just for reference.
Oh crap, I totally missed that, my fault. I'll queue them all up for the next release after this one.
Again, my apologies and thanks for making them easy to apply,
greg k-h
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:
c8401dda2f0a KVM: x86: fix singlestepping over syscall
Does not apply to 4.4-stable, are you sure it is needed? If so, anyone know where I can get a backported version? :)
thanks,
greg k-h
On 16/11/2017 12:31, 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:
c8401dda2f0a KVM: x86: fix singlestepping over syscall
Does not apply to 4.4-stable, are you sure it is needed? If so, anyone know where I can get a backported version? :)
I'll send one.
Paolo
On Thu, Nov 16, 2017 at 12:32:50PM +0100, Paolo Bonzini wrote:
On 16/11/2017 12:31, 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:
c8401dda2f0a KVM: x86: fix singlestepping over syscall
Does not apply to 4.4-stable, are you sure it is needed? If so, anyone know where I can get a backported version? :)
I'll send one.
Wonderful!
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:
df80cd9b28b9 sctp: do not peel off an assoc from one netns to another one 2cb80187ba06 net: cdc_ether: fix divide by 0 on bad descriptors 7fd078337201 net: qmi_wwan: fix divide by 0 on bad descriptors
The last three are not in later stable branches yet. The USB net driver fixes are already in David Miller's queue for stable, and i have asked him to add the sctp fix.
I'll wait for these to come in through David's patch submission.
thanks,
greg k-h
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 c8401dda2f0a KVM: x86: fix singlestepping over syscall 0d0e57697f16 bpf: don't let ldimm64 leak map addresses on unprivileged 089bc0143f48 xen-blkback: don't leak stack data via response ring df80cd9b28b9 sctp: do not peel off an assoc from one netns to another one 2cb80187ba06 net: cdc_ether: fix divide by 0 on bad descriptors 7fd078337201 net: qmi_wwan: fix divide by 0 on bad descriptors
The last three are not in later stable branches yet. The USB net driver fixes are already in David Miller's queue for stable, and i have asked him to add the sctp fix.
All now applied, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org
-
Ben Hutchings -
Greg Kroah-Hartman -
Jan Kara -
Paolo Bonzini -
Theodore Ts'o