]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
netfilter: xtables: zero padding in data_to_user
authorWillem de Bruijn <willemb@google.com>
Tue, 9 May 2017 20:17:37 +0000 (16:17 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 29 Jun 2017 11:02:55 +0000 (13:02 +0200)
commit865cdeeae70ae9f9a0ecce183401cc61ee756287
treed0f99d3ef2ef4313d5109fb5a1f9385d82f141c4
parent958c8a07d59e196b577d7b81817f5fc9f17edf19
netfilter: xtables: zero padding in data_to_user

commit 324318f0248c31be8a08984146e7e4dd7cdd091d upstream.

When looking up an iptables rule, the iptables binary compares the
aligned match and target data (XT_ALIGN). In some cases this can
exceed the actual data size to include padding bytes.

Before commit f77bc5b23fb1 ("iptables: use match, target and data
copy_to_user helpers") the malloc()ed bytes were overwritten by the
kernel with kzalloced contents, zeroing the padding and making the
comparison succeed. After this patch, the kernel copies and clears
only data, leaving the padding bytes undefined.

Extend the clear operation from data size to aligned data size to
include the padding bytes, if any.

Padding bytes can be observed in both match and target, and the bug
triggered, by issuing a rule with match icmp and target ACCEPT:

  iptables -t mangle -A INPUT -i lo -p icmp --icmp-type 1 -j ACCEPT
  iptables -t mangle -D INPUT -i lo -p icmp --icmp-type 1 -j ACCEPT

Fixes: f77bc5b23fb1 ("iptables: use match, target and data copy_to_user helpers")
Reported-by: Paul Moore <pmoore@redhat.com>
Reported-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
include/linux/netfilter/x_tables.h
net/bridge/netfilter/ebtables.c
net/netfilter/x_tables.c