netdev - Re: [RFC] Kernel unaligned access at __skb_flow

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: <20160129192218.GB17127@oracle.com>
Date:	Fri, 29 Jan 2016 14:22:18 -0500
From:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	mwdalton@...gle.com, netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [RFC] Kernel unaligned access at __skb_flow_dissect

On (01/29/16 10:54), Eric Dumazet wrote:
> > Why ipv6 stack itself does not trigger the issue ?
> > Maybe the driver itself does not properly align IP headers on sparc ?
> > Make sure NET_IP_ALIGN is 2 on your build.
> > Note that x86 does not care, but a driver should always align Ethernet
> > header to NET_IP_ALIGN, so that IP headers are aligned to 4 bytes
> > boundaries.

Consolidating a few responses:

NET_IP_ALIGN is 2, of course, or else I would have seen errors about unaligned
access in many more places. The issue is being triggered by ipv6
stack (I'm running iperf over ipv6) so I'm not sure I understand the
first question.

I tried out the suggested patch of setting page_offset to NET_IP_ALIGN
in ixgbe_main.c - and yes, it kills the unaligned errors, so that's a
Good Thing. (though I see davem just responded to the patch)

However, the patch itself is not arch specific, and the unaligned 
address issue should have impacted other archs (silently) as well - 
even for ipv4, 

It would also impact other logic in __skb_flow_dissect: 
e.g., the access to iph->saddr for ipv4 frags would be
unaligned in __skb_flow_dissect? (And Ias I mentioned in my original
mail, the comments in __skb_get_poff seem to indicate that others
have tripped up on this before - and yes, casting is not a good thing
but seems like that's what they did to paper over the problem)

> Hmmm.... it seems that flow dissector can "support L2 GRE", leading to
> unaligned accesses since a header is 14 bytes (not multiple of 4)
  :
> IP stacks in linux assume IP headers are always aligned to 4 bytes,
> so it means having a GRE header like this would align trap on some
> arches.

I'm not sure I see how the above commit could have been impacting me,
I dont have any l2 gre invovled (simple p2p Ethernet II + ipv6 + tcp, 
no vlans, gre or other exotic stuff).

--Sowmini