* Patch "packet: fix tpacket_snd max frame len" has been added to the 4.1-stable tree
@ 2015-12-11 16:48 gregkh
0 siblings, 0 replies; only message in thread
From: gregkh @ 2015-12-11 16:48 UTC (permalink / raw)
To: daniel, davem, gregkh, willemb; +Cc: stable, stable-commits
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.1-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.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Fri Dec 11 11:39:13 EST 2015
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 11 Nov 2015 23:25:44 +0100
Subject: packet: fix tpacket_snd max frame len
From: Daniel Borkmann <daniel@iogearbox.net>
[ 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")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/packet/af_packet.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2293,12 +2293,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,
@@ -2325,7 +2326,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 daniel@iogearbox.net are
queue-4.1/packet-infer-protocol-from-ethernet-header-if-unset.patch
queue-4.1/bpf-array-fix-heap-out-of-bounds-access-when-updating-elements.patch
queue-4.1/ipv6-sctp-implement-sctp_v6_destroy_sock.patch
queue-4.1/packet-only-allow-extra-vlan-len-on-ethernet-devices.patch
queue-4.1/net-scm-fix-pax-detected-msg_controllen-overflow-in-scm_detach_fds.patch
queue-4.1/packet-fix-tpacket_snd-max-frame-len.patch
queue-4.1/packet-always-probe-for-transport-header.patch
queue-4.1/packet-do-skb_probe_transport_header-when-we-actually-have-data.patch
queue-4.1/tools-net-use-include-uapi-with-__exported_headers__.patch
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2015-12-11 20:21 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-12-11 16:48 Patch "packet: fix tpacket_snd max frame len" has been added to the 4.1-stable tree gregkh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).