* [4.4] FragmentSmack security fixes
@ 2019-02-05 18:26 Ben Hutchings
2019-02-05 18:41 ` Greg Kroah-Hartman
0 siblings, 1 reply; 6+ messages in thread
From: Ben Hutchings @ 2019-02-05 18:26 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable, Eric Dumazet, Peter Oskolkov
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [4.4] FragmentSmack security fixes 2019-02-05 18:26 [4.4] FragmentSmack security fixes Ben Hutchings @ 2019-02-05 18:41 ` Greg Kroah-Hartman 2019-02-05 19:41 ` Ben Hutchings 0 siblings, 1 reply; 6+ messages in thread From: Greg Kroah-Hartman @ 2019-02-05 18:41 UTC (permalink / raw) To: Ben Hutchings; +Cc: Sasha Levin, stable, Eric Dumazet, Peter Oskolkov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [4.4] FragmentSmack security fixes 2019-02-05 18:41 ` Greg Kroah-Hartman @ 2019-02-05 19:41 ` Ben Hutchings 2019-02-06 21:13 ` Greg Kroah-Hartman 0 siblings, 1 reply; 6+ messages in thread From: Ben Hutchings @ 2019-02-05 19:41 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Sasha Levin, stable, Eric Dumazet, Peter Oskolkov, Mao Wenan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [4.4] FragmentSmack security fixes 2019-02-05 19:41 ` Ben Hutchings @ 2019-02-06 21:13 ` Greg Kroah-Hartman 2019-02-07 11:26 ` Greg Kroah-Hartman 0 siblings, 1 reply; 6+ messages in thread From: Greg Kroah-Hartman @ 2019-02-06 21:13 UTC (permalink / raw) To: Ben Hutchings Cc: Sasha Levin, stable, Eric Dumazet, Peter Oskolkov, Mao Wenan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [4.4] FragmentSmack security fixes 2019-02-06 21:13 ` Greg Kroah-Hartman @ 2019-02-07 11:26 ` Greg Kroah-Hartman 2019-02-09 1:58 ` maowenan 0 siblings, 1 reply; 6+ messages in thread From: Greg Kroah-Hartman @ 2019-02-07 11:26 UTC (permalink / raw) To: Mao Wenan, Ben Hutchings Cc: Sasha Levin, stable, Eric Dumazet, Peter Oskolkov, Mao Wenan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [4.4] FragmentSmack security fixes 2019-02-07 11:26 ` Greg Kroah-Hartman @ 2019-02-09 1:58 ` maowenan 0 siblings, 0 replies; 6+ messages in thread From: maowenan @ 2019-02-09 1:58 UTC (permalink / raw) To: Greg Kroah-Hartman, Ben Hutchings Cc: Sasha Levin, stable, Eric Dumazet, Peter Oskolkov 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 > > . > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-02-09 1:58 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-05 18:26 [4.4] FragmentSmack security fixes Ben Hutchings 2019-02-05 18:41 ` Greg Kroah-Hartman 2019-02-05 19:41 ` Ben Hutchings 2019-02-06 21:13 ` Greg Kroah-Hartman 2019-02-07 11:26 ` Greg Kroah-Hartman 2019-02-09 1:58 ` maowenan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.