Skip to contentSkip to conversation

Patch "packet: fix tpacket_snd max frame len" has been added to the 4.3-stable tree

PATCH [email protected] 1 participant 1 message Dec 11, 2015

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

packet: fix tpacket_snd max frame len

to the 4.3-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
packet-fix-tpacket_snd-max-frame-len.patch
and it can be found in the queue-4.3 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Fri Dec 11 11:38:06 EST 2015

From: Daniel Borkmann <[email protected]>
Date: Wed, 11 Nov 2015 23:25:44 +0100
Subject: packet: fix tpacket_snd max frame len

From: Daniel Borkmann <[email protected]>

[ Upstream commit 5cfb4c8d05b4409c4044cb9c05b19705c1d9818b ]

Since it's introduction in commit 69e3c75f4d54 ("net: TX_RING and packet mmap"), TX_RING could be used from SOCK_DGRAM and SOCK_RAW side. When used with SOCK_DGRAM only, the size_max > dev->mtu + reserve check should have reserve as 0, but currently, this is unconditionally set (in it's original form as dev->hard_header_len).

I think this is not correct since tpacket_fill_skb() would then take dev->mtu and dev->hard_header_len into account for SOCK_DGRAM, the extra VLAN_HLEN could be possible in both cases. Presumably, the reserve code was copied from packet_snd(), but later on missed the check. Make it similar as we have it in packet_snd().

Fixes 69e3c75f4d54 ("net: TX_RING and packet mmap")
---
 net/packet/af_packet.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
net/packet/af_packet.c +5 -4
@@ -2510,12 +2510,13 @@ static int tpacket_snd(struct packet_soc
 	if (unlikely(!(dev->flags & IFF_UP)))
 		goto out_put;
 
-	reserve = dev->hard_header_len + VLAN_HLEN;
+	if (po->sk.sk_socket->type == SOCK_RAW)
+		reserve = dev->hard_header_len;
 	size_max = po->tx_ring.frame_size
 		- (po->tp_hdrlen - sizeof(struct sockaddr_ll));
 
-	if (size_max > dev->mtu + reserve)
-		size_max = dev->mtu + reserve;
+	if (size_max > dev->mtu + reserve + VLAN_HLEN)
+		size_max = dev->mtu + reserve + VLAN_HLEN;
 
 	do {
 		ph = packet_current_frame(po, &po->tx_ring,
@@ -2542,7 +2543,7 @@ static int tpacket_snd(struct packet_soc
 		tp_len = tpacket_fill_skb(po, skb, ph, dev, size_max, proto,
 					  addr, hlen);
 		if (likely(tp_len >= 0) &&
-		    tp_len > dev->mtu + dev->hard_header_len &&
+		    tp_len > dev->mtu + reserve &&
 		    !packet_extra_vlan_len_allowed(dev, skb))
 			tp_len = -EMSGSIZE;
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.3/packet-infer-protocol-from-ethernet-header-if-unset.patch queue-4.3/bpf-array-fix-heap-out-of-bounds-access-when-updating-elements.patch queue-4.3/ipv6-sctp-implement-sctp_v6_destroy_sock.patch queue-4.3/packet-only-allow-extra-vlan-len-on-ethernet-devices.patch queue-4.3/net-scm-fix-pax-detected-msg_controllen-overflow-in-scm_detach_fds.patch queue-4.3/packet-fix-tpacket_snd-max-frame-len.patch queue-4.3/packet-always-probe-for-transport-header.patch queue-4.3/packet-do-skb_probe_transport_header-when-we-actually-have-data.patch queue-4.3/tools-net-use-include-uapi-with-__exported_headers__.patch