ixgbe: Avoid unaligned access in ixgbe_atr() for LLC packets

For LLC based protocols like lldp, stp etc., the ethernet header is an 802.3 header with a h_proto that is not 0x800, 0x86dd, or even 0x806. In this world, the skb_network_header() points at the DSAP/SSAP/.. and is not likely to be NET_IP_ALIGNed in ixgbe_atr().

With LLC, drivers are not likely to correctly find IPVERSION, or "6", at hdr.ipv4->version, but will instead just needlessly trigger an unaligned access. (IPv4/IPv6 over LLC is almost never implemented).

The unaligned access is thus avoidable: bail out quickly after examining skb->protocol. The only Ethernet II protocols handled are IPv4 and IPv6

---
v2: Alexander Duyck comments
v3: filter out all ethertypes except for Ethernet II and (IPv4 or IPv6)

 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

index 4d6223d..aeab2fe 100644
@@ -7574,6 +7574,11 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
 	if (!ring->atr_sample_rate)
 		return;
 
+	/* this function only handles IPv4 or IPv6 */
+	if (first->protocol != htons(ETH_P_IP) &&
+	    first->protocol != htons(ETH_P_IPV6))
+		return;
+
 	ring->atr_count++;
 
 	/* snag network header to get L4 type and address */

1.7.1

This does not apply since Alex Duyck beat you to the fix. ?Here is the patch he submitted on 3/15 which corrects the issue. ?So I am dropping your patch from the queue.

commit 04b8b51c34837765cf6250f69d419c439dc393bf
Author: Alexander Duyck <[email protected]>
Date:???Tue Mar 15 15:10:22 2016 -0700

????ixgbe: Fix ATR so that it correctly handles IPv6 extension headers
????
????The ATR code was assuming that it would be able to use tcp_hdr for
????every TCP frame that came through.??However this isn't the case as
it
????is possible for a frame to arrive that is TCP but sent through
something
????like a raw socket.??As a result the driver was setting up bad
filters in
????which tcp_hdr was really pointing to the network header so the data
was
????all invalid.
????
????In order to correct this I have added a bit of parsing logic that
will
????determine the TCP header location based off of the network header
and
????either the offset in the case of the IPv4 header, or a walk through
the
????IPv6 extension headers until it encounters the header that
indicates
????IPPROTO_TCP.??In addition I have added checks to verify that the
lowest
????protocol provided is recognized as IPv4 or IPv6 to help mitigate
raw
????sockets using ETH_P_ALL from having ATR applied to them.
????
????Signed-off-by: Alexander Duyck <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160316/05758d47/attachment.asc>

That's weird because Alexander was reviewing my fix on the various lists yesterday, so he could have just told me about this.

But, whatever.

--sowmini

Sowmini,

Just for the record I didn't submit it on March 15 I submitted it on January 26th as per the log in patchwork,
http://patchwork.ozlabs.org/patch/573058/.

Sorry I didn't realize the patch was not against the next-queue. Back when I made that fix I was focused on the IPv6 portion of it so that piece of it had slipped my mind. If it is any consolation at least my patch is 7+ weeks ahead in the queue so hopefully the fix will make it into net-next as soon as the merge window opens.

- Alex