netfilter: nft_set_bitmap: fetch the element key based on the set->klen
authorLiping Zhang <zlpnobody@gmail.com>
Sun, 5 Mar 2017 16:02:52 +0000 (00:02 +0800)
committerPablo Neira Ayuso <pablo@netfilter.org>
Mon, 13 Mar 2017 12:16:42 +0000 (13:16 +0100)
commitfd89b23a4632d3cbdee398048497e026edadfb71
treed3e08e0f8a6ea13d55c5197cd0a164bedccee629
parent568af6de058cb2b0c5b98d98ffcf37cdc6bc38a7
netfilter: nft_set_bitmap: fetch the element key based on the set->klen

Currently we just assume the element key as a u32 integer, regardless of
the set key length.

This is incorrect, for example, the tcp port number is only 16 bits.
So when we use the nft_payload expr to get the tcp dport and store
it to dreg, the dport will be stored at 0~15 bits, and 16~31 bits
will be padded with zero.

So the reg->data[dreg] will be looked like as below:
  0          15           31
  +-+-+-+-+-+-+-+-+-+-+-+-+
  | tcp dport |      0    |
  +-+-+-+-+-+-+-+-+-+-+-+-+
But for these big-endian systems, if we treate this register as a u32
integer, the element key will be larger than 65535, so the following
lookup in bitmap set will cause out of bound access.

Another issue is that if we add element with comments in bitmap
set(although the comments will be ignored eventually), the element will
vanish strangely. Because we treate the element key as a u32 integer, so
the comments will become the part of the element key, then the element
key will also be larger than 65535 and out of bound access will happen:
  # nft add element t s { 1 comment test }

Since set->klen is 1 or 2, it's fine to treate the element key as a u8 or
u16 integer.

Fixes: 665153ff5752 ("netfilter: nf_tables: add bitmap set type")
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
net/netfilter/nft_set_bitmap.c