From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: Sasha Levin <Alexander.Levin@microsoft.com>,
stable <stable@vger.kernel.org>,
Eric Dumazet <edumazet@google.com>,
Peter Oskolkov <posk@google.com>, Mao Wenan <maowenan@huawei.com>
Subject: Re: [4.4] FragmentSmack security fixes
Date: Wed, 6 Feb 2019 22:13:26 +0100 [thread overview]
Message-ID: <20190206211326.GA5425@kroah.com> (raw)
In-Reply-To: <1549395678.2925.236.camel@codethink.co.uk>
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
next prev parent reply other threads:[~2019-02-06 21:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2019-02-07 11:26 ` Greg Kroah-Hartman
2019-02-09 1:58 ` maowenan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190206211326.GA5425@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Alexander.Levin@microsoft.com \
--cc=ben.hutchings@codethink.co.uk \
--cc=edumazet@google.com \
--cc=maowenan@huawei.com \
--cc=posk@google.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.