netdev - Re: [endianness bug?] cxgb4_next_header .match_val/.match

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: <20180805154949.GG15082@ZenIV.linux.org.uk>
Date:   Sun, 5 Aug 2018 16:49:49 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Rahul Lakkireddy <rahul.lakkireddy@...lsio.com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: [endianness bug?] cxgb4_next_header .match_val/.match_mask
 should be net-endian

On Sun, Aug 05, 2018 at 04:28:11PM +0100, Al Viro wrote:
> On little-endian host those do yield the right values - e.g. 0x1100 is
> {0, 17, 0, 0}, etc.  On big-endian, though, these will end up checking
> in IPv4 case the octet at offset 10 (i.e. upper 16 bits of checksum) and for IPv6
> - the octet at offset 5 (i.e.  the lower 8 bits of payload length).
> 
> Unless I'm misreading that code, it needs the following to do the right
> thing both on l-e and b-e.  Comments?

... and it looks like the same story with ->mask - it's compared to ->offmask,
which is __be16.  For little-endian hosts the values make sense (htons(0x0f00),
with offoff 0 and shift 6, i.e. "take the first two octets, treat them as
net-endian, clear everything except IHL bits and shift down by 6, which'd
yield IHL*4"), for big-endian they don't - you'd get TOS * 4 instead...