linux-stable.git/net/ipv6/netfilter, branch v4.16.2

netfilter: nf_socket: Fix out of bounds access in nf_sk_lookup_slow_v{4,6}

2018-03-24T20:17:14+00:00

skb_header_pointer will copy data into a buffer if data is non linear,
otherwise it will return a pointer in the linear section of the data.
nf_sk_lookup_slow_v{4,6} always copies data of size udphdr but later
accesses memory within the size of tcphdr (th->doff) in case of TCP
packets. This causes a crash when running with KASAN with the following
call stack -

BUG: KASAN: stack-out-of-bounds in xt_socket_lookup_slow_v4+0x524/0x718
net/netfilter/xt_socket.c:178
Read of size 2 at addr ffffffe3d417a87c by task syz-executor/28971
CPU: 2 PID: 28971 Comm: syz-executor Tainted: G    B   W  O    4.9.65+ #1
Call trace:
[] dump_backtrace+0x0/0x428 arch/arm64/kernel/traps.c:76
[] show_stack+0x28/0x38 arch/arm64/kernel/traps.c:226
[] __dump_stack lib/dump_stack.c:15 [inline]
[] dump_stack+0xd4/0x124 lib/dump_stack.c:51
[] print_address_description+0x68/0x258 mm/kasan/report.c:248
[] kasan_report_error mm/kasan/report.c:347 [inline]
[] kasan_report.part.2+0x228/0x2f0 mm/kasan/report.c:371
[] kasan_report+0x5c/0x70 mm/kasan/report.c:372
[] check_memory_region_inline mm/kasan/kasan.c:308 [inline]
[] __asan_load2+0x84/0x98 mm/kasan/kasan.c:739
[] __tcp_hdrlen include/linux/tcp.h:35 [inline]
[] xt_socket_lookup_slow_v4+0x524/0x718 net/netfilter/xt_socket.c:178

Fix this by copying data into appropriate size headers based on protocol.

Fixes: a583636a83ea ("inet: refactor inet[6]_lookup functions to take skb")
Signed-off-by: Tejaswi Tanikella 
Signed-off-by: Subash Abhinov Kasiviswanathan 
Signed-off-by: Pablo Neira Ayuso

net: rename skb_gso_validate_mtu -> skb_gso_validate_network_len

2018-03-04T22:49:17+00:00

If you take a GSO skb, and split it into packets, will the network
length (L3 headers + L4 headers + payload) of those packets be small
enough to fit within a given MTU?

skb_gso_validate_mtu gives you the answer to that question. However,
we recently added to add a way to validate the MAC length of a split GSO
skb (L2+L3+L4+payload), and the names get confusing, so rename
skb_gso_validate_mtu to skb_gso_validate_network_len

Signed-off-by: Daniel Axtens 
Reviewed-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller

netfilter: don't set F_IFACE on ipv6 fib lookups

2018-02-25T19:15:53+00:00

"fib" starts to behave strangely when an ipv6 default route is
added - the FIB lookup returns a route using 'oif' in this case.

This behaviour was inherited from ip6tables rpfilter so change
this as well.

Bugzilla: https://bugzilla.netfilter.org/show_bug.cgi?id=1221
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

netfilter: ipv6: fix use-after-free Write in nf_nat_ipv6_manip_pkt

2018-02-25T19:03:54+00:00

l4proto->manip_pkt() can cause reallocation of skb head so pointer
to the ipv6 header must be reloaded.

Reported-and-tested-by: 
Fixes: 58a317f1061c89 ("netfilter: ipv6: add IPv6 NAT support")
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

netfilter: x_tables: use pr ratelimiting in all remaining spots

2018-02-14T20:05:38+00:00

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

netfilter: x_tables: rate-limit table mismatch warnings

2018-02-14T20:05:36+00:00

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

netfilter: add back stackpointer size checks

2018-02-14T19:47:41+00:00

The rationale for removing the check is only correct for rulesets
generated by ip(6)tables.

In iptables, a jump can only occur to a user-defined chain, i.e.
because we size the stack based on number of user-defined chains we
cannot exceed stack size.

However, the underlying binary format has no such restriction,
and the validation step only ensures that the jump target is a
valid rule start point.

IOW, its possible to build a rule blob that has no user-defined
chains but does contain a jump.

If this happens, no jump stack gets allocated and crash occurs
because no jumpstack was allocated.

Fixes: 7814b6ec6d0d6 ("netfilter: xtables: don't save/restore jumpstack offset")
Reported-by: syzbot+e783f671527912cd9403@syzkaller.appspotmail.com
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

netfilter: nf_tables: fix flowtable free

2018-02-06T23:58:57+00:00

Every flow_offload entry is added into the table twice. Because of this,
rhashtable_free_and_destroy can't be used, since it would call kfree for
each flow_offload object twice.

This patch cleans up the flowtable via nf_flow_table_iterate() to
schedule removal of entries by setting on the dying bit, then there is
an explicitly invocation of the garbage collector to release resources.

Based on patch from Felix Fietkau.

Signed-off-by: Pablo Neira Ayuso

netfilter: flowtable infrastructure depends on NETFILTER_INGRESS

2018-02-02T12:21:48+00:00

config NF_FLOW_TABLE depends on NETFILTER_INGRESS. If users forget to
enable this toggle, flowtable registration fails with EOPNOTSUPP.

Moreover, turn 'select NF_FLOW_TABLE' in every flowtable family flavour
into dependency instead, otherwise this new dependency on
NETFILTER_INGRESS causes a warning. This also allows us to remove the
explicit dependency between family flowtables <-> NF_TABLES and
NF_CONNTRACK, given they depend on the NF_FLOW_TABLE core that already
expresses the general dependencies for this new infrastructure.

Moreover, NF_FLOW_TABLE_INET depends on NF_FLOW_TABLE_IPV4 and
NF_FLOWTABLE_IPV6, which already depends on NF_FLOW_TABLE. So we can get
rid of direct dependency with NF_FLOW_TABLE.

In general, let's avoid 'select', it just makes things more complicated.

Reported-by: John Crispin 
Signed-off-by: Pablo Neira Ayuso

netfilter: ipv6: nf_defrag: Kill frag queue on RFC2460 failure

2018-02-02T11:45:17+00:00

Failures were seen in ICMPv6 fragmentation timeout tests if they were
run after the RFC2460 failure tests. Kernel was not sending out the
ICMPv6 fragment reassembly time exceeded packet after the fragmentation
reassembly timeout of 1 minute had elapsed.

This happened because the frag queue was not released if an error in
IPv6 fragmentation header was detected by RFC2460.

Fixes: 83f1999caeb1 ("netfilter: ipv6: nf_defrag: Pass on packets to stack per RFC2460")
Signed-off-by: Subash Abhinov Kasiviswanathan 
Signed-off-by: Pablo Neira Ayuso