[4.4] FragmentSmack security fixes

[4.4] FragmentSmack security fixes

[Ben Hutchings]

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

This is a backport of upstream changes to fix the FragmentSmack (CVE-
2018-5391) vulnerability.

Peter Oskolkov checked an earlier version of this backport, but I have
since rebased and added another 3 commits to it.  I tested with the
ip_defrag.sh self-test that he added upstream, and it passed.  I have
included the fix that is currently queued for the 4.9, 4.14 and 4.19
branches.

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-fragmentsmack.mbox --]
[-- Type: application/mbox, Size: 175807 bytes --]

Re: [4.4] FragmentSmack security fixes

[Greg Kroah-Hartman]

On Tue, Feb 05, 2019 at 06:26:23PM +0000, Ben Hutchings wrote:
> This is a backport of upstream changes to fix the FragmentSmack (CVE-
> 2018-5391) vulnerability.
> 
> Peter Oskolkov checked an earlier version of this backport, but I have
> since rebased and added another 3 commits to it.  I tested with the
> ip_defrag.sh self-test that he added upstream, and it passed.  I have
> included the fix that is currently queued for the 4.9, 4.14 and 4.19
> branches.

That's a lot of patches, some of which I have already queued up in the
next 4.4 release which will happen in a day or so.  Are they all still
needed after the changes there are merged?

thanks,

greg k-h

Re: [4.4] FragmentSmack security fixes

[Ben Hutchings]

On Tue, 2019-02-05 at 19:41 +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2019 at 06:26:23PM +0000, Ben Hutchings wrote:
> > This is a backport of upstream changes to fix the FragmentSmack (CVE-
> > 2018-5391) vulnerability.
> > 
> > Peter Oskolkov checked an earlier version of this backport, but I have
> > since rebased and added another 3 commits to it.  I tested with the
> > ip_defrag.sh self-test that he added upstream, and it passed.  I have
> > included the fix that is currently queued for the 4.9, 4.14 and 4.19
> > branches.
> 
> That's a lot of patches, some of which I have already queued up in the
> next 4.4 release which will happen in a day or so.  Are they all still
> needed after the changes there are merged?

Ah, yes, a lot of the changes are already in your queue and I'm not
certain that all of mine are needed.  However I can say that the
changes currently in the queue are not correct:

* The ip_defrag.sh self-test fails: in the ipv4 non-overlap case, after
 a few seconds, recv() returns an EAGAIN error. If I modify the script
to continue running the other cases, however, they pass.

* There is a reference leak which prevents the new network namespaces
being torn down ("unregister_netdevice: waiting for lo to become free.
Usage count = 61").  (I see similar warnings with my backport, but the
number gradually decreases and they stop after 

* Shutdown hangs.

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom
On Tue, 2019-02-05 at 19:41 +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2019 at 06:26:23PM +0000, Ben Hutchings wrote:
> > This is a backport of upstream changes to fix the FragmentSmack (CVE-
> > 2018-5391) vulnerability.
> > 
> > Peter Oskolkov checked an earlier version of this backport, but I have
> > since rebased and added another 3 commits to it.  I tested with the
> > ip_defrag.sh self-test that he added upstream, and it passed.  I have
> > included the fix that is currently queued for the 4.9, 4.14 and 4.19
> > branches.
> 
> That's a lot of patches, some of which I have already queued up in the
> next 4.4 release which will happen in a day or so.  Are they all still
> needed after the changes there are merged?

Ah, yes, a lot of the fragment-handling changes are already in your
queue and I'm not certain that all of mine are needed.  However I don't
think the changes in your queue are complete and correct.  When I run
the ip_defrag.sh self-test:

1. The ipv4 non-overlap case fails after a few seconds, with recv()
returning an EAGAIN error. If I modify the script to continue after an
error, the other cases do pass, however.  This is not a regression from
4.4.172, but with my changes all cases pass.

2. There is a reference leak which prevents the new network namespaces
being cleaned up ("unregister_netdevice: waiting for lo to become free.
Usage count = 61").  With 4.4.172 or with my changes applied, the
warnings appear, but only for about a minute with the number gradually
decreasing.  So this is a regression.

3. If I run the test again, it hangs.  Shutting down the VM also hangs.
 I think this is related to the previous issue.  Again, this is a
regression.

Ben.

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

Re: [4.4] FragmentSmack security fixes

[Greg Kroah-Hartman]

On Tue, Feb 05, 2019 at 07:41:18PM +0000, Ben Hutchings wrote:
> > > Peter Oskolkov checked an earlier version of this backport, but I have
> > > since rebased and added another 3 commits to it.  I tested with the
> > > ip_defrag.sh self-test that he added upstream, and it passed.  I have
> > > included the fix that is currently queued for the 4.9, 4.14 and 4.19
> > > branches.
> > 
> > That's a lot of patches, some of which I have already queued up in the
> > next 4.4 release which will happen in a day or so.  Are they all still
> > needed after the changes there are merged?
> 
> Ah, yes, a lot of the fragment-handling changes are already in your
> queue and I'm not certain that all of mine are needed.  However I don't
> think the changes in your queue are complete and correct.  When I run
> the ip_defrag.sh self-test:
> 
> 1. The ipv4 non-overlap case fails after a few seconds, with recv()
> returning an EAGAIN error. If I modify the script to continue after an
> error, the other cases do pass, however.  This is not a regression from
> 4.4.172, but with my changes all cases pass.
> 
> 2. There is a reference leak which prevents the new network namespaces
> being cleaned up ("unregister_netdevice: waiting for lo to become free.
> Usage count = 61").  With 4.4.172 or with my changes applied, the
> warnings appear, but only for about a minute with the number gradually
> decreasing.  So this is a regression.
> 
> 3. If I run the test again, it hangs.  Shutting down the VM also hangs.
>  I think this is related to the previous issue.  Again, this is a
> regression.

Ok, I dropped those patches from the 4.4 queue before releasing it.  Let
me go add them back for the moment and then I'll dig through all of this
over the next few days and see what it looks like...

thanks,

greg k-h

Re: [4.4] FragmentSmack security fixes

[Greg Kroah-Hartman]

On Wed, Feb 06, 2019 at 10:13:26PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2019 at 07:41:18PM +0000, Ben Hutchings wrote:
> > > > Peter Oskolkov checked an earlier version of this backport, but I have
> > > > since rebased and added another 3 commits to it.  I tested with the
> > > > ip_defrag.sh self-test that he added upstream, and it passed.  I have
> > > > included the fix that is currently queued for the 4.9, 4.14 and 4.19
> > > > branches.
> > > 
> > > That's a lot of patches, some of which I have already queued up in the
> > > next 4.4 release which will happen in a day or so.  Are they all still
> > > needed after the changes there are merged?
> > 
> > Ah, yes, a lot of the fragment-handling changes are already in your
> > queue and I'm not certain that all of mine are needed.  However I don't
> > think the changes in your queue are complete and correct.  When I run
> > the ip_defrag.sh self-test:
> > 
> > 1. The ipv4 non-overlap case fails after a few seconds, with recv()
> > returning an EAGAIN error. If I modify the script to continue after an
> > error, the other cases do pass, however.  This is not a regression from
> > 4.4.172, but with my changes all cases pass.
> > 
> > 2. There is a reference leak which prevents the new network namespaces
> > being cleaned up ("unregister_netdevice: waiting for lo to become free.
> > Usage count = 61").  With 4.4.172 or with my changes applied, the
> > warnings appear, but only for about a minute with the number gradually
> > decreasing.  So this is a regression.
> > 
> > 3. If I run the test again, it hangs.  Shutting down the VM also hangs.
> >  I think this is related to the previous issue.  Again, this is a
> > regression.
> 
> Ok, I dropped those patches from the 4.4 queue before releasing it.  Let
> me go add them back for the moment and then I'll dig through all of this
> over the next few days and see what it looks like...

I've reviewed all of these and they look good.  There were some
duplications with what was in my tree, but I have taken your versions
instead.

Mao, you will note that 4.4.173 did not get released with your patches
in it.  I have added your signed-off-by to the same ones that Ben did
here in this series, as the changes were minimal at most, to what you
had.  If you have any objections to these, please let me know.

I'll probably just push out a -rc release for 4.4.y later today with
these in it to get some testing and a release out so that we can get
this issue finally resolved.

thanks,

greg k-h

Re: [4.4] FragmentSmack security fixes

[maowenan]

On 2019/2/7 19:26, Greg Kroah-Hartman wrote:
> On Wed, Feb 06, 2019 at 10:13:26PM +0100, Greg Kroah-Hartman wrote:
>> On Tue, Feb 05, 2019 at 07:41:18PM +0000, Ben Hutchings wrote:
>>>>> Peter Oskolkov checked an earlier version of this backport, but I have
>>>>> since rebased and added another 3 commits to it.  I tested with the
>>>>> ip_defrag.sh self-test that he added upstream, and it passed.  I have
>>>>> included the fix that is currently queued for the 4.9, 4.14 and 4.19
>>>>> branches.
>>>>
>>>> That's a lot of patches, some of which I have already queued up in the
>>>> next 4.4 release which will happen in a day or so.  Are they all still
>>>> needed after the changes there are merged?
>>>
>>> Ah, yes, a lot of the fragment-handling changes are already in your
>>> queue and I'm not certain that all of mine are needed.  However I don't
>>> think the changes in your queue are complete and correct.  When I run
>>> the ip_defrag.sh self-test:
>>>
>>> 1. The ipv4 non-overlap case fails after a few seconds, with recv()
>>> returning an EAGAIN error. If I modify the script to continue after an
>>> error, the other cases do pass, however.  This is not a regression from
>>> 4.4.172, but with my changes all cases pass.
>>>
>>> 2. There is a reference leak which prevents the new network namespaces
>>> being cleaned up ("unregister_netdevice: waiting for lo to become free.
>>> Usage count = 61").  With 4.4.172 or with my changes applied, the
>>> warnings appear, but only for about a minute with the number gradually
>>> decreasing.  So this is a regression.
>>>
>>> 3. If I run the test again, it hangs.  Shutting down the VM also hangs.
>>>  I think this is related to the previous issue.  Again, this is a
>>> regression.
>>
>> Ok, I dropped those patches from the 4.4 queue before releasing it.  Let
>> me go add them back for the moment and then I'll dig through all of this
>> over the next few days and see what it looks like...
> 
> I've reviewed all of these and they look good.  There were some
> duplications with what was in my tree, but I have taken your versions
> instead.
> 
> Mao, you will note that 4.4.173 did not get released with your patches
> in it.  I have added your signed-off-by to the same ones that Ben did
> here in this series, as the changes were minimal at most, to what you
> had.  If you have any objections to these, please let me know.
> 

It looks well.

> I'll probably just push out a -rc release for 4.4.y later today with
> these in it to get some testing and a release out so that we can get
> this issue finally resolved.
> 
> thanks,
> 
> greg k-h
> 
> .
>