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

    packet: infer protocol from ethernet header if unset

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-infer-protocol-from-ethernet-header-if-unset.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.


>From foo@baz Fri Dec 11 11:38:06 EST 2015
From: Daniel Borkmann <[email protected]>
Date: Wed, 11 Nov 2015 23:25:43 +0100
Subject: packet: infer protocol from ethernet header if unset

From: Daniel Borkmann <[email protected]>

[ Upstream commit c72219b75fde768efccf7666342282fab7f9e4e7 ]

In case no struct sockaddr_ll has been passed to packet
socket's sendmsg() when doing a TX_RING flush run, then
skb->protocol is set to po->num instead, which is the protocol
passed via socket(2)/bind(2).

Applications only xmitting can go the path of allocating the
socket as socket(PF_PACKET, <mode>, 0) and do a bind(2) on the
TX_RING with sll_protocol of 0. That way, register_prot_hook()
is neither called on creation nor on bind time, which saves
cycles when there's no interest in capturing anyway.

That leaves us however with po->num 0 instead and therefore
the TX_RING flush run sets skb->protocol to 0 as well. Eric
reported that this leads to problems when using tools like
trafgen over bonding device. I.e. the bonding's hash function
could invoke the kernel's flow dissector, which depends on
skb->protocol being properly set. In the current situation, all
the traffic is then directed to a single slave.

Fix it up by inferring skb->protocol from the Ethernet header
when not set and we have ARPHRD_ETHER device type. This is only
done in case of SOCK_RAW and where we have a dev->hard_header_len
length. In case of ARPHRD_ETHER devices, this is guaranteed to
cover ETH_HLEN, and therefore being accessed on the skb after
the skb_store_bits().

Reported-by: Eric Dumazet <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Willem de Bruijn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
 net/packet/af_packet.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2338,6 +2338,15 @@ static bool ll_header_truncated(const st
        return false;
 }
 
+static void tpacket_set_protocol(const struct net_device *dev,
+                                struct sk_buff *skb)
+{
+       if (dev->type == ARPHRD_ETHER) {
+               skb_reset_mac_header(skb);
+               skb->protocol = eth_hdr(skb)->h_proto;
+       }
+}
+
 static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
                void *frame, struct net_device *dev, int size_max,
                __be16 proto, unsigned char *addr, int hlen)
@@ -2419,6 +2428,8 @@ static int tpacket_fill_skb(struct packe
                                dev->hard_header_len);
                if (unlikely(err))
                        return err;
+               if (!skb->protocol)
+                       tpacket_set_protocol(dev, skb);
 
                data += dev->hard_header_len;
                to_write -= dev->hard_header_len;


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
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to