netdev - Re: [PATCH 0/2] [BUG FIXES - 3.10.27] sit: More backports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140129075745.4227a2ed@gandalf.local.home>
Date:	Wed, 29 Jan 2014 07:57:45 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	nicolas.dichtel@...nd.com
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	stable <stable@...r.kernel.org>,
	Clark Williams <williams@...hat.com>,
	"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
	John Kacur <jkacur@...hat.com>
Subject: Re: [PATCH 0/2] [BUG FIXES - 3.10.27] sit: More backports

On Wed, 29 Jan 2014 12:04:05 +0100
Nicolas Dichtel <nicolas.dichtel@...nd.com> wrote:

> Le 28/01/2014 21:57, Steven Rostedt a écrit :
> > At Red Hat we base our real-time kernel off of 3.10.27 and do lots of
> > stress testing on that kernel. This has discovered some bugs that we
> > can hit with the vanilla 3.10.27 kernel (no -rt patches applied).
> >
> > I sent out a bug fix that can cause a crash with the current 3.10.27
> > when you add and then remove the sit module. That patch is obsoleted by
> > these patches, as that patch was not enough.
> Can you explain a bit more which problem remains after that patch?
> I wonder if a problem remains also with ip6_tunnel.ko (net/ipv6/ip6_tunnel.c),
> the same problem was spotted into this module.

Hmm, OK it may only need the first version of the patch. It was one of
those cases where it didn't fix the second bug, so we added the full
patch as well. Then we found the second bug but never tried all the
tests with the smaller version of the patch. I'll put back the first
patch and then ask our QA to retest it with the older version and the
other patch.

> 
> >
> > A previous patch that was backported:
> >
> >    Upstream commit 205983c43700ac3a81e7625273a3fa83cd2759b5
> >    sit: allow to use rtnl ops on fb tunnel
> >
> > Had a depenency on commit 5e6700b3bf98 ("sit: add support of x-netns")
> > which was not backported. The dependency was only on part of that
> > commit which is what I backported.
> I cannot comment directly the patch, it was an attachement, hence I put my

It's not really an attachment. It was sent with quilt mail, which only
makes it look like one. What mail client are you using? mutt, alpine,
evolution, claws-mail, and thunderbird all show it as a normal patch.
I do know that k9-mail on android makes it into an attachment.

> comments here.
> In patch 0001-sit-Unregister-sit-devices-with-rtnl_link_ops.patch, I wonder how
> 'if (dev_net(t->dev) != net)' can be wrong. If commit 5e6700b3bf98 ("sit: add
> support of x-netns") has not been backported, this test is always true.

Should it just be removed then? This has fixed our bugs, but perhaps it
opened new ones we haven't detected yet. I can remove the if and
unregister and see if it still works. Or perhaps calling unregister all
the time isn't bad.

-- Steve


> 
> >
> > The other upstream commit 9434266f2c645d4fcf62a03a8e36ad8075e37943
> > sit: fix use after free of fb_tunnel_dev
> >
> > fixes another bug we encountered, it also fixes the 3.10.27 bug
> > where removing the sit module cause the crash. This is the patch
> > that obsoletes my previous patch.
> >
> > -- Steve
> >
> >
> > Steven Rostedt (Red Hat) (1):
> >        sit: Unregister sit devices with rtnl_link_ops
> >
> > Willem de Bruijn (1):
> >        sit: fix use after free of fb_tunnel_dev
> >
> > ----
> >   net/ipv6/sit.c | 30 +++++++++++++++++++++++++-----
> >   1 file changed, 25 insertions(+), 5 deletions(-)
> >

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html