1. 14 Feb, 2018 15 commits
    • Paolo Abeni's avatar
      netfilter: nat: cope with negative port range · db57ccf0
      Paolo Abeni authored
      syzbot reported a division by 0 bug in the netfilter nat code:
      
      divide error: 0000 [#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:ffff8801b2466778 EFLAGS: 00010246
      RAX: 000000000000f153 RBX: ffff8801b2466dd8 RCX: ffff8801b2466c7c
      RDX: 0000000000000000 RSI: ffff8801b2466c58 RDI: ffff8801db5293ac
      RBP: ffff8801b24667d8 R08: ffff8801b8ba6dc0 R09: ffffffff88af5900
      R10: ffff8801b24666f0 R11: 0000000000000000 R12: 000000002990f153
      R13: 0000000000000001 R14: 0000000000000000 R15: ffff8801b2466c7c
      FS:  00000000017e3880(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000208fdfe4 CR3: 00000001b5340002 CR4: 00000000001606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      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:00007ffe50cc0be8 EFLAGS: 00000217 ORIG_RAX: 000000000000002a
      RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 0000000000441c69
      RDX: 000000000000001c RSI: 00000000208fdfe4 RDI: 0000000000000003
      RBP: 00000000006cc018 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000538 R11: 0000000000000217 R12: 0000000000403590
      R13: 0000000000403620 R14: 0000000000000000 R15: 0000000000000000
      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: ffff8801b2466778
      
      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: 5b1158e9 ("[NETFILTER]: Add NAT support for nf_conntrack")
      Reported-by: syzbot+8012e198bd037f4871e5@syzkaller.appspotmail.com
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      db57ccf0
    • Paolo Abeni's avatar
      netfilter: x_tables: fix missing timer initialization in xt_LED · 10414014
      Paolo Abeni authored
      syzbot reported that xt_LED may try to use the ledinternal->timer
      without previously initializing it:
      
      ------------[ cut here ]------------
      kernel BUG at kernel/time/timer.c:958!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
          (ftrace buffer empty)
      Modules linked in:
      CPU: 1 PID: 1826 Comm: kworker/1:2 Not tainted 4.15.0+ #306
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Workqueue: ipv6_addrconf addrconf_dad_work
      RIP: 0010:__mod_timer kernel/time/timer.c:958 [inline]
      RIP: 0010:mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102
      RSP: 0018:ffff8801d24fe9f8 EFLAGS: 00010293
      RAX: ffff8801d25246c0 RBX: ffff8801aec6cb50 RCX: ffffffff816052c6
      RDX: 0000000000000000 RSI: 00000000fffbd14b RDI: ffff8801aec6cb68
      RBP: ffff8801d24fec98 R08: 0000000000000000 R09: 1ffff1003a49fd6c
      R10: ffff8801d24feb28 R11: 0000000000000005 R12: dffffc0000000000
      R13: ffff8801d24fec70 R14: 00000000fffbd14b R15: ffff8801af608f90
      FS:  0000000000000000(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000206d6fd0 CR3: 0000000006a22001 CR4: 00000000001606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        led_tg+0x1db/0x2e0 net/netfilter/xt_LED.c:75
        ip6t_do_table+0xc2a/0x1a30 net/ipv6/netfilter/ip6_tables.c:365
        ip6table_raw_hook+0x65/0x80 net/ipv6/netfilter/ip6table_raw.c:42
        nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
        nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483
        nf_hook.constprop.27+0x3f6/0x830 include/linux/netfilter.h:243
        NF_HOOK include/linux/netfilter.h:286 [inline]
        ndisc_send_skb+0xa51/0x1370 net/ipv6/ndisc.c:491
        ndisc_send_ns+0x38a/0x870 net/ipv6/ndisc.c:633
        addrconf_dad_work+0xb9e/0x1320 net/ipv6/addrconf.c:4008
        process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2113
        worker_thread+0x223/0x1990 kernel/workqueue.c:2247
        kthread+0x33c/0x400 kernel/kthread.c:238
        ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:429
      Code: 85 2a 0b 00 00 4d 8b 3c 24 4d 85 ff 75 9f 4c 8b bd 60 fd ff ff e8 bb
      57 10 00 65 ff 0d 94 9a a1 7e e9 d9 fc ff ff e8 aa 57 10 00 <0f> 0b e8 a3
      57 10 00 e9 14 fb ff ff e8 99 57 10 00 4c 89 bd 70
      RIP: __mod_timer kernel/time/timer.c:958 [inline] RSP: ffff8801d24fe9f8
      RIP: mod_timer+0x7d6/0x13c0 kernel/time/timer.c:1102 RSP: ffff8801d24fe9f8
      ---[ end trace f661ab06f5dd8b3d ]---
      
      The ledinternal struct can be shared between several different
      xt_LED targets, but the related timer is currently initialized only
      if the first target requires it. Fix it by unconditionally
      initializing the timer struct.
      
      v1 -> v2: call del_timer_sync() unconditionally, too.
      
      Fixes: 268cb38e ("netfilter: x_tables: add LED trigger target")
      Reported-by: syzbot+10c98dc5725c6c8fc7fb@syzkaller.appspotmail.com
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      10414014
    • Zhu Lingshan's avatar
      .gitignore: ignore ASN.1 auto generated files · d682026d
      Zhu Lingshan authored
      when build kernel with default configure, files:
      
      generatenet/ipv4/netfilter/nf_nat_snmp_basic-asn1.c
      net/ipv4/netfilter/nf_nat_snmp_basic-asn1.h
      
      will be automatically generated by ASN.1 compiler, so
      No need to track them in git, it's better to ignore them.
      Signed-off-by: default avatarZhu Lingshan <lszhu@suse.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      d682026d
    • Florian Westphal's avatar
    • Florian Westphal's avatar
      netfilter: x_tables: use pr ratelimiting in matches/targets · c08e5e1e
      Florian Westphal authored
      all of these print simple error message - use single pr_ratelimit call.
      checkpatch complains about lines > 80 but this would require splitting
      several "literals" over multiple lines which is worse.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      c08e5e1e
    • Florian Westphal's avatar
    • Florian Westphal's avatar
      netfilter: bridge: use pr ratelimiting · 7ecbf103
      Florian Westphal authored
      ebt_among still uses pr_err -- these errors indicate ebtables tool bug,
      not a usage error.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      7ecbf103
    • Florian Westphal's avatar
      netfilter: xt_set: use pr ratelimiting · c82b31c5
      Florian Westphal authored
      also convert this to info for consistency.
      These errors are informational message to user, given iptables doesn't
      have netlink extack equivalent.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      c82b31c5
    • Florian Westphal's avatar
      netfilter: xt_NFQUEUE: use pr ratelimiting · e016c5e4
      Florian Westphal authored
      switch this to info, since these aren't really errors.
      We only use printk because we cannot report meaningful errors
      in the xtables framework.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      e016c5e4
    • Florian Westphal's avatar
      netfilter: xt_CT: use pr ratelimiting · 11f7aee2
      Florian Westphal authored
      checkpatch complains about line > 80 but this would require splitting
      "literal" over two lines which is worse.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      11f7aee2
    • Florian Westphal's avatar
      netfilter: x_tables: use pr ratelimiting in xt core · 1b6cd671
      Florian Westphal authored
      most messages are converted to info, since they occur in response to
      wrong usage.
      
      Size mismatch however is a real error (xtables ABI bug) that should not
      occur.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      1b6cd671
    • Florian Westphal's avatar
      netfilter: x_tables: remove pr_info where possible · 0cc9501f
      Florian Westphal authored
      remove several pr_info messages that cannot be triggered with iptables,
      the check is only to ensure input is sane.
      
      iptables(8) already prints error messages in these cases.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      0cc9501f
    • Cong Wang's avatar
      netfilter: ipt_CLUSTERIP: fix a refcount bug in clusterip_config_find_get() · db93a363
      Cong Wang authored
      In clusterip_config_find_get() we hold RCU read lock so it could
      run concurrently with clusterip_config_entry_put(), as a result,
      the refcnt could go back to 1 from 0, which leads to a double
      list_del()... Just replace refcount_inc() with
      refcount_inc_not_zero(), as for c->refcount.
      
      Fixes: d73f33b1 ("netfilter: CLUSTERIP: RCU conversion")
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Pablo Neira Ayuso <pablo@netfilter.org>
      Cc: Florian Westphal <fw@strlen.de>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      db93a363
    • Florian Westphal's avatar
      netfilter: add back stackpointer size checks · 57ebd808
      Florian Westphal authored
      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: 7814b6ec ("netfilter: xtables: don't save/restore jumpstack offset")
      Reported-by: syzbot+e783f671527912cd9403@syzkaller.appspotmail.com
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      57ebd808
    • Paolo Abeni's avatar
      netfilter: drop outermost socket lock in getsockopt() · 01ea306f
      Paolo Abeni authored
      The Syzbot reported a possible deadlock in the netfilter area caused by
      rtnl lock, xt lock and socket lock being acquired with a different order
      on different code paths, leading to the following backtrace:
      Reviewed-by: default avatarXin Long <lucien.xin@gmail.com>
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.15.0+ #301 Not tainted
      ------------------------------------------------------
      syzkaller233489/4179 is trying to acquire lock:
        (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
      net/core/rtnetlink.c:74
      
      but task is already holding lock:
        (&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
      xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
      
      which lock already depends on the new lock.
      ===
      
      Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
      only in the required scope"), we already acquire the socket lock in
      the innermost scope, where needed. In such commit I forgot to remove
      the outer-most socket lock from the getsockopt() path, this commit
      addresses the issues dropping it now.
      
      v1 -> v2: fix bad subj, added relavant 'fixes' tag
      
      Fixes: 22265a5c ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
      Fixes: 202f59af ("netfilter: ipt_CLUSTERIP: do not hold dev")
      Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
      Reported-by: syzbot+ddde1c7b7ff7442d7f2d@syzkaller.appspotmail.com
      Suggested-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      01ea306f
  2. 08 Feb, 2018 13 commits
  3. 07 Feb, 2018 12 commits