netdev - Re: [PATCH RFC] xfrm{4,6}: only report errors back to local sockets if we don't cross address family

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: <20130730102611.GB25511@secunet.com>
Date:	Tue, 30 Jul 2013 12:26:11 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	netdev@...r.kernel.org, vi0oss@...il.com
Subject: Re: [PATCH RFC] xfrm{4,6}: only report errors back to local sockets
 if we don't cross address family

On Tue, Jul 30, 2013 at 10:30:17AM +0200, Hannes Frederic Sowa wrote:
> On Tue, Jul 30, 2013 at 10:21:18AM +0200, Steffen Klassert wrote:
> > On Mon, Jul 29, 2013 at 04:50:17PM +0200, Hannes Frederic Sowa wrote:
> > > xfrm6_local_error/xfrm4_tunnel_check_size report mtu errors back to a
> > > socket in case it is locally generated. If the packet first traversed
> > > a 6in4/4in6 tunnel before passing the xfrm layer, we could get a panic
> > > because of address family type mismatch in the error reporting functions.
> > > 
> > 
> > So the skb is still owned by a socket of the inner address family.
> > Is this intentional? Maybe the ndo_start_xmit() function of the
> > tunnel device should orphan the skb if we tunnel the packet
> > through a different address family.
> 
> I thought about this, too. But then we would stop accounting the data
> to the socket while it is travelling the stack. I don't know about the
> possible problems resulting from this.
> 

I'm also not absolutely sure, but we reinsert the packet to
the ipv4/ipv6 output path which is also used to output forwarded
packets. So the code should be prepared for handling a skb without
socket context.

There are already situations where we orphan the skb in some
tunnel xmit functions. For example if we tunnel through
another namespace.

Lets see if anyone else has an opinion to that. I'll go
and look what we can do if we have to fix it in the IPsec
code in the meantime.

--
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