netdev - Re: Looking for a lost patch

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: <20150527.114603.897841724165037352.davem@davemloft.net>
Date:	Wed, 27 May 2015 11:46:03 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	steffen.klassert@...unet.com
Cc:	alexander.h.duyck@...hat.com, alexander.duyck@...il.com,
	netdev@...r.kernel.org
Subject: Re: Looking for a lost patch

From: Steffen Klassert <steffen.klassert@...unet.com>
Date: Wed, 27 May 2015 10:35:16 +0200

> We currently check if a socket is attached to a skb and do socket
> error notification in this case, otherwise we do PMTU discovery if
> the packet is too big. Looks like this socket check is not sufficient
> if the packet is already transmitted through a tunnel device.
> 
> I wonder if we have something to know that a packet was already
> transmitted through a tunnel device. We could switch from socket
> notification to PMTU discovery in this case.

Generally speaking, we should not be orphaning the socket as it
traverses through tunnels.

In fact we have taken great pains to avoid doing this.

See, for example, commits:

7026b1ddb6b8d4e6ee33dc2bd06c0ca8746fa7ab
aad88724c9d54acb1a9737cb6069d8470fa85f74
b0270e91014dabfceaf37f5b40ad51bbf21a1302

Therefore what we always should do is retain the original socket
ownership on the SKB, and layers that implement tunneling using
sockets should pass the socket pointer through their output path(s)
and never use skb->sk for this.

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