Security fixes for 4.4

Security fixes for 4.4

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

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.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

[-- Attachment #2: security-4.4.mbox --]
[-- Type: application/mbox, Size: 22890 bytes --]

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

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

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

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

Re: Security fixes for 4.4

[Paolo Bonzini]

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

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

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:
> 
> 0d0e57697f16 bpf: don't let ldimm64 leak map addresses on unprivileged

Breaks the build when backported to 4.4 :(

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

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:
> 
> 089bc0143f48 xen-blkback: don't leak stack data via response ring

Does not apply to 4.4-stable at all :(

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

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

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

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!

Re: Security fixes for 4.4

[Theodore Ts'o]

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

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

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

Re: Security fixes for 4.4

[Ben Hutchings]

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.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

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

Re: Security fixes for 4.4

[Ben Hutchings]

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.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

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

Re: Security fixes for 4.4

[Jan Kara]

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
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Security fixes for 4.4

[Greg Kroah-Hartman]

On Thu, Dec 13, 2018 at 06:51:19PM +0000, Ben Hutchings wrote:
> I've backported a number of fixes for security issues affecting 4.4-
> stable.��All of these are already fixed in the newer stable branches.
> 
> For the BPF fix, I verified that the self-tests (taken from 4.14)
> didn't regress and temporarily added logging to check that the
> mitigation is applied when needed.
> 
> For the KVM changes, I verified that IBPB/IBRS are now exposed to and
> used by a guest on Intel hardware.
> 
> I also verified that the current self-tests for timers, usercopy and vm
> didn't regress.

Thanks a lot for these!

All now queued up.

greg k-h

Re: Security fixes for 4.4

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

And here they really are.

Ben.

On Thu, 2018-12-13 at 18:51 +0000, Ben Hutchings wrote:
> I've backported a number of fixes for security issues affecting 4.4-
> stable.  All of these are already fixed in the newer stable branches.
> 
> For the BPF fix, I verified that the self-tests (taken from 4.14)
> didn't regress and temporarily added logging to check that the
> mitigation is applied when needed.
> 
> For the KVM changes, I verified that IBPB/IBRS are now exposed to and
> used by a guest on Intel hardware.
> 
> I also verified that the current self-tests for timers, usercopy and
> vm
> didn't regress.
> 
> Ben.
> 
-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

[-- Attachment #2: security-4.4.mbox --]
[-- Type: application/mbox, Size: 179877 bytes --]

Security fixes for 4.4

[Ben Hutchings]

I've backported a number of fixes for security issues affecting 4.4-
stable.  All of these are already fixed in the newer stable branches.

For the BPF fix, I verified that the self-tests (taken from 4.14)
didn't regress and temporarily added logging to check that the
mitigation is applied when needed.

For the KVM changes, I verified that IBPB/IBRS are now exposed to and
used by a guest on Intel hardware.

I also verified that the current self-tests for timers, usercopy and vm
didn't regress.

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom