Liping Zhang 10596608c4 netfilter: nf_tables: fix mismatch in big-endian system ... Currently, there are two different methods to store an u16 integer to the u32 data register. For example: u32 *dest = &regs->data[priv->dreg]; 1. *dest = 0; *(u16 *) dest = val_u16; 2. *dest = val_u16; For method 1, the u16 value will be stored like this, either in big-endian or little-endian system: 0 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+ | Value | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+ For method 2, in little-endian system, the u16 value will be the same as listed above. But in big-endian system, the u16 value will be stored like this: 0 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+ So later we use "memcmp(&regs->data[priv->sreg], data, 2);" to do compare in nft_cmp, nft_lookup expr ..., method 2 will get the wrong result in big-endian system, as 0~15 bits will always be zero. For the similar reason, when loading an u16 value from the u32 data register, we should use "*(u16 *) sreg;" instead of "(u16)*sreg;", the 2nd method will get the wrong value in the big-endian system. So introduce some wrapper functions to store/load an u8 or u16 integer to/from the u32 data register, and use them in the right place. Signed-off-by: Liping Zhang <zlpnobody@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>		2017-03-13 13:30:28 +01:00
..
ip6_tables.c
ip6t_ah.c
ip6t_eui64.c
ip6t_frag.c
ip6t_hbh.c
ip6t_ipv6header.c
ip6t_MASQUERADE.c
ip6t_mh.c
ip6t_NPT.c
ip6t_REJECT.c
ip6t_rpfilter.c
ip6t_rt.c
ip6t_SYNPROXY.c
ip6table_filter.c
ip6table_mangle.c
ip6table_nat.c
ip6table_raw.c
ip6table_security.c
Kconfig
Makefile
nf_conntrack_l3proto_ipv6.c
nf_conntrack_proto_icmpv6.c
nf_conntrack_reasm.c
nf_defrag_ipv6_hooks.c
nf_dup_ipv6.c
nf_log_ipv6.c
nf_nat_l3proto_ipv6.c
nf_nat_masquerade_ipv6.c
nf_nat_proto_icmpv6.c
nf_reject_ipv6.c
nf_socket_ipv6.c
nf_tables_ipv6.c
nft_chain_nat_ipv6.c
nft_chain_route_ipv6.c
nft_dup_ipv6.c
nft_fib_ipv6.c
nft_masq_ipv6.c
nft_redir_ipv6.c
nft_reject_ipv6.c