summaryrefslogtreecommitdiff
path: root/virt
diff options
context:
space:
mode:
authorFlorian Westphal <fw@strlen.de>2016-03-22 18:02:52 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2016-06-24 10:15:29 -0700
commita1a184a2f31575dba677514f2de22ddf1671ad81 (patch)
tree89f1a17f9e5aa62ee419a3f0819bc8b1a818974c /virt
parente0b84cd87763c3bd442a06942ca90a60a7e152e7 (diff)
downloadlwn-a1a184a2f31575dba677514f2de22ddf1671ad81.tar.gz
lwn-a1a184a2f31575dba677514f2de22ddf1671ad81.zip
netfilter: x_tables: fix unconditional helper
commit 54d83fc74aa9ec72794373cb47432c5f7fb1a309 upstream. Ben Hawkes says: In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it is possible for a user-supplied ipt_entry structure to have a large next_offset field. This field is not bounds checked prior to writing a counter value at the supplied offset. Problem is that mark_source_chains should not have been called -- the rule doesn't have a next entry, so its supposed to return an absolute verdict of either ACCEPT or DROP. However, the function conditional() doesn't work as the name implies. It only checks that the rule is using wildcard address matching. However, an unconditional rule must also not be using any matches (no -m args). The underflow validator only checked the addresses, therefore passing the 'unconditional absolute verdict' test, while mark_source_chains also tested for presence of matches, and thus proceeeded to the next (not-existent) rule. Unify this so that all the callers have same idea of 'unconditional rule'. Reported-by: Ben Hawkes <hawkes@google.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'virt')
0 files changed, 0 insertions, 0 deletions