Re: [PATCH net v3] netfilter: nat: cope with negative port range

2018-02-14 Thread Pablo Neira Ayuso
On Wed, Feb 14, 2018 at 05:21:19PM +0100, Paolo Abeni wrote:
> syzbot reported a division by 0 bug in the netfilter nat code:
> 
> divide error:  [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 4168 Comm: syzkaller034710 Not tainted 4.16.0-rc1+ #309
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:nf_nat_l4proto_unique_tuple+0x291/0x530
> net/netfilter/nf_nat_proto_common.c:88
> RSP: 0018:8801b2466778 EFLAGS: 00010246
> RAX: f153 RBX: 8801b2466dd8 RCX: 8801b2466c7c
> RDX:  RSI: 8801b2466c58 RDI: 8801db5293ac
> RBP: 8801b24667d8 R08: 8801b8ba6dc0 R09: 88af5900
> R10: 8801b24666f0 R11:  R12: 2990f153
> R13: 0001 R14:  R15: 8801b2466c7c
> FS:  017e3880() GS:8801db50() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 208fdfe4 CR3: 0001b5340002 CR4: 001606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>   dccp_unique_tuple+0x40/0x50 net/netfilter/nf_nat_proto_dccp.c:30
>   get_unique_tuple+0xc28/0x1c10 net/netfilter/nf_nat_core.c:362
>   nf_nat_setup_info+0x1c2/0xe00 net/netfilter/nf_nat_core.c:406
>   nf_nat_redirect_ipv6+0x306/0x730 net/netfilter/nf_nat_redirect.c:124
>   redirect_tg6+0x7f/0xb0 net/netfilter/xt_REDIRECT.c:34
>   ip6t_do_table+0xc2a/0x1a30 net/ipv6/netfilter/ip6_tables.c:365
>   ip6table_nat_do_chain+0x65/0x80 net/ipv6/netfilter/ip6table_nat.c:41
>   nf_nat_ipv6_fn+0x594/0xa80 net/ipv6/netfilter/nf_nat_l3proto_ipv6.c:302
>   nf_nat_ipv6_local_fn+0x33/0x5d0
> net/ipv6/netfilter/nf_nat_l3proto_ipv6.c:407
>   ip6table_nat_local_fn+0x2c/0x40 net/ipv6/netfilter/ip6table_nat.c:69
>   nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
>   nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483
>   nf_hook include/linux/netfilter.h:243 [inline]
>   NF_HOOK include/linux/netfilter.h:286 [inline]
>   ip6_xmit+0x10ec/0x2260 net/ipv6/ip6_output.c:277
>   inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
>   dccp_transmit_skb+0x9ac/0x10f0 net/dccp/output.c:142
>   dccp_connect+0x369/0x670 net/dccp/output.c:564
>   dccp_v6_connect+0xe17/0x1bf0 net/dccp/ipv6.c:946
>   __inet_stream_connect+0x2d4/0xf00 net/ipv4/af_inet.c:620
>   inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:684
>   SYSC_connect+0x213/0x4a0 net/socket.c:1639
>   SyS_connect+0x24/0x30 net/socket.c:1620
>   do_syscall_64+0x282/0x940 arch/x86/entry/common.c:287
>   entry_SYSCALL_64_after_hwframe+0x26/0x9b
> RIP: 0033:0x441c69
> RSP: 002b:7ffe50cc0be8 EFLAGS: 0217 ORIG_RAX: 002a
> RAX: ffda RBX:  RCX: 00441c69
> RDX: 001c RSI: 208fdfe4 RDI: 0003
> RBP: 006cc018 R08:  R09: 
> R10: 0538 R11: 0217 R12: 00403590
> R13: 00403620 R14:  R15: 
> Code: 48 89 f0 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 46 02 00 00 48 8b
> 45 c8 44 0f b7 20 e8 88 97 04 fd 31 d2 41 0f b7 c4 4c 89 f9 <41> f7 f6 48
> c1 e9 03 48 b8 00 00 00 00 00 fc ff df 0f b6 0c 01
> RIP: nf_nat_l4proto_unique_tuple+0x291/0x530
> net/netfilter/nf_nat_proto_common.c:88 RSP: 8801b2466778
> 
> The problem is that currently we don't have any check on the
> configured port range. A port range == -1 triggers the bug, while
> other negative values may require a very long time to complete the
> following loop.
> 
> This commit addresses the issue swapping the two ends on negative
> ranges. The check is performed in nf_nat_l4proto_unique_tuple() since
> the nft nat loads the port values from nft registers at runtime.

Applied, thanks.


[PATCH net v3] netfilter: nat: cope with negative port range

2018-02-14 Thread Paolo Abeni
syzbot reported a division by 0 bug in the netfilter nat code:

divide error:  [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 4168 Comm: syzkaller034710 Not tainted 4.16.0-rc1+ #309
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:nf_nat_l4proto_unique_tuple+0x291/0x530
net/netfilter/nf_nat_proto_common.c:88
RSP: 0018:8801b2466778 EFLAGS: 00010246
RAX: f153 RBX: 8801b2466dd8 RCX: 8801b2466c7c
RDX:  RSI: 8801b2466c58 RDI: 8801db5293ac
RBP: 8801b24667d8 R08: 8801b8ba6dc0 R09: 88af5900
R10: 8801b24666f0 R11:  R12: 2990f153
R13: 0001 R14:  R15: 8801b2466c7c
FS:  017e3880() GS:8801db50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 208fdfe4 CR3: 0001b5340002 CR4: 001606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
  dccp_unique_tuple+0x40/0x50 net/netfilter/nf_nat_proto_dccp.c:30
  get_unique_tuple+0xc28/0x1c10 net/netfilter/nf_nat_core.c:362
  nf_nat_setup_info+0x1c2/0xe00 net/netfilter/nf_nat_core.c:406
  nf_nat_redirect_ipv6+0x306/0x730 net/netfilter/nf_nat_redirect.c:124
  redirect_tg6+0x7f/0xb0 net/netfilter/xt_REDIRECT.c:34
  ip6t_do_table+0xc2a/0x1a30 net/ipv6/netfilter/ip6_tables.c:365
  ip6table_nat_do_chain+0x65/0x80 net/ipv6/netfilter/ip6table_nat.c:41
  nf_nat_ipv6_fn+0x594/0xa80 net/ipv6/netfilter/nf_nat_l3proto_ipv6.c:302
  nf_nat_ipv6_local_fn+0x33/0x5d0
net/ipv6/netfilter/nf_nat_l3proto_ipv6.c:407
  ip6table_nat_local_fn+0x2c/0x40 net/ipv6/netfilter/ip6table_nat.c:69
  nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
  nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483
  nf_hook include/linux/netfilter.h:243 [inline]
  NF_HOOK include/linux/netfilter.h:286 [inline]
  ip6_xmit+0x10ec/0x2260 net/ipv6/ip6_output.c:277
  inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
  dccp_transmit_skb+0x9ac/0x10f0 net/dccp/output.c:142
  dccp_connect+0x369/0x670 net/dccp/output.c:564
  dccp_v6_connect+0xe17/0x1bf0 net/dccp/ipv6.c:946
  __inet_stream_connect+0x2d4/0xf00 net/ipv4/af_inet.c:620
  inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:684
  SYSC_connect+0x213/0x4a0 net/socket.c:1639
  SyS_connect+0x24/0x30 net/socket.c:1620
  do_syscall_64+0x282/0x940 arch/x86/entry/common.c:287
  entry_SYSCALL_64_after_hwframe+0x26/0x9b
RIP: 0033:0x441c69
RSP: 002b:7ffe50cc0be8 EFLAGS: 0217 ORIG_RAX: 002a
RAX: ffda RBX:  RCX: 00441c69
RDX: 001c RSI: 208fdfe4 RDI: 0003
RBP: 006cc018 R08:  R09: 
R10: 0538 R11: 0217 R12: 00403590
R13: 00403620 R14:  R15: 
Code: 48 89 f0 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 46 02 00 00 48 8b
45 c8 44 0f b7 20 e8 88 97 04 fd 31 d2 41 0f b7 c4 4c 89 f9 <41> f7 f6 48
c1 e9 03 48 b8 00 00 00 00 00 fc ff df 0f b6 0c 01
RIP: nf_nat_l4proto_unique_tuple+0x291/0x530
net/netfilter/nf_nat_proto_common.c:88 RSP: 8801b2466778

The problem is that currently we don't have any check on the
configured port range. A port range == -1 triggers the bug, while
other negative values may require a very long time to complete the
following loop.

This commit addresses the issue swapping the two ends on negative
ranges. The check is performed in nf_nat_l4proto_unique_tuple() since
the nft nat loads the port values from nft registers at runtime.

v1 -> v2: use the correct 'Fixes' tag
v2 -> v3: update commit message, drop unneeded READ_ONCE()

Fixes: 5b1158e909ec ("[NETFILTER]: Add NAT support for nf_conntrack")
Reported-by: syzbot+8012e198bd037f487...@syzkaller.appspotmail.com
Signed-off-by: Paolo Abeni 
---
 net/netfilter/nf_nat_proto_common.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_nat_proto_common.c 
b/net/netfilter/nf_nat_proto_common.c
index fbce552a796e..7d7466dbf663 100644
--- a/net/netfilter/nf_nat_proto_common.c
+++ b/net/netfilter/nf_nat_proto_common.c
@@ -41,7 +41,7 @@ void nf_nat_l4proto_unique_tuple(const struct nf_nat_l3proto 
*l3proto,
 const struct nf_conn *ct,
 u16 *rover)
 {
-   unsigned int range_size, min, i;
+   unsigned int range_size, min, max, i;
__be16 *portptr;
u_int16_t off;
 
@@ -71,7 +71,10 @@ void nf_nat_l4proto_unique_tuple(const struct nf_nat_l3proto 
*l3proto,
}
} else {
min = ntohs(range->min_proto.all);
-   range_size = ntohs(range->max_proto.all) - min + 1;
+   max = ntohs(range->max_proto.all);
+   if (unlikely(max < min))
+