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
| ||
|
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
Powered by blists - more mailing lists