netdev - Re: [PATCH net 1/1] uapi: fix big endian definition of ipv6_rpl_sr

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 Jan 2021 12:25:39 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     David Ahern <dsahern@...il.com>
Cc:     Justin Iurman <justin.iurman@...ege.be>, netdev@...r.kernel.org,
        davem@...emloft.net, alex aring <alex.aring@...il.com>
Subject: Re: [PATCH net 1/1] uapi: fix big endian definition of
 ipv6_rpl_sr_hdr

On Mon, 25 Jan 2021 13:12:42 -0700 David Ahern wrote:
> On 1/25/21 12:32 PM, Jakub Kicinski wrote:
> >>>>> diff --git a/include/uapi/linux/rpl.h b/include/uapi/linux/rpl.h
> >>>>> index 1dccb55cf8c6..708adddf9f13 100644
> >>>>> --- a/include/uapi/linux/rpl.h
> >>>>> +++ b/include/uapi/linux/rpl.h
> >>>>> @@ -28,10 +28,10 @@ struct ipv6_rpl_sr_hdr {
> >>>>>  		pad:4,
> >>>>>  		reserved1:16;
> >>>>>  #elif defined(__BIG_ENDIAN_BITFIELD)
> >>>>> -	__u32	reserved:20,
> >>>>> +	__u32	cmpri:4,
> >>>>> +		cmpre:4,
> >>>>>  		pad:4,
> >>>>> -		cmpri:4,
> >>>>> -		cmpre:4;
> >>>>> +		reserved:20;
> >>>>>  #else
> >>>>>  #error  "Please fix <asm/byteorder.h>"
> >>>>>  #endif    
> >>
> >> cross-checking with other headers - tcp and vxlan-gpe - this patch looks
> >> correct.  
> > 
> > What are you cross-checking?
> >   
> 
> https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-10, Section 3.1
> header definition and vxlanhdr_gpe in include/net/vxlan.h. The
> __BIG_ENDIAN_BITFIELD part follows the definition in the spec.
> 
> Similarly for the TCP header - RFC header definition and tcphdr in
> include/uapi/linux/tcp.h. TCP header shows doff + res1 order which is
> comparable to cmpri + cpmre in this header as both sets are 4-bits and
> start a word.

Ack, thanks for the pointers. The LE definition is broken as well,
then, right?