Skip to content
  1. Mar 22, 2019
    • Wang Hai's avatar
      net-sysfs: Fix memory leak in netdev_register_kobject · 6b70fc94
      Wang Hai authored
      
      
      When registering struct net_device, it will call
      	register_netdevice ->
      		netdev_register_kobject ->
      			device_initialize(dev);
      			dev_set_name(dev, "%s", ndev->name)
      			device_add(dev)
      			register_queue_kobjects(ndev)
      
      In netdev_register_kobject(), if device_add(dev) or
      register_queue_kobjects(ndev) failed. Register_netdevice()
      will return error, causing netdev_freemem(ndev) to be
      called to free net_device, however put_device(&dev->dev)->..->
      kobject_cleanup() won't be called, resulting in a memory leak.
      
      syzkaller report this:
      BUG: memory leak
      unreferenced object 0xffff8881f4fad168 (size 8):
      comm "syz-executor.0", pid 3575, jiffies 4294778002 (age 20.134s)
      hex dump (first 8 bytes):
        77 70 61 6e 30 00 ff ff                          wpan0...
      backtrace:
        [<000000006d2d91d7>] kstrdup_const+0x3d/0x50 mm/util.c:73
        [<00000000ba9ff953>] kvasprintf_const+0x112/0x170 lib/kasprintf.c:48
        [<000000005555ec09>] kobject_set_name_vargs+0x55/0x130 lib/kobject.c:281
        [<0000000098d28ec3>] dev_set_name+0xbb/0xf0 drivers/base/core.c:1915
        [<00000000b7553017>] netdev_register_kobject+0xc0/0x410 net/core/net-sysfs.c:1727
        [<00000000c826a797>] register_netdevice+0xa51/0xeb0 net/core/dev.c:8711
        [<00000000857bfcfd>] cfg802154_update_iface_num.isra.2+0x13/0x90 [ieee802154]
        [<000000003126e453>] ieee802154_llsec_fill_key_id+0x1d5/0x570 [ieee802154]
        [<00000000e4b3df51>] 0xffffffffc1500e0e
        [<00000000b4319776>] platform_drv_probe+0xc6/0x180 drivers/base/platform.c:614
        [<0000000037669347>] really_probe+0x491/0x7c0 drivers/base/dd.c:509
        [<000000008fed8862>] driver_probe_device+0xdc/0x240 drivers/base/dd.c:671
        [<00000000baf52041>] device_driver_attach+0xf2/0x130 drivers/base/dd.c:945
        [<00000000c7cc8dec>] __driver_attach+0x10e/0x210 drivers/base/dd.c:1022
        [<0000000057a757c2>] bus_for_each_dev+0x154/0x1e0 drivers/base/bus.c:304
        [<000000005f5ae04b>] bus_add_driver+0x427/0x5e0 drivers/base/bus.c:645
      
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 1fa5ae85
      
       ("driver core: get rid of struct device's bus_id string array")
      Signed-off-by: default avatarWang Hai <wanghai26@huawei.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b70fc94
    • David S. Miller's avatar
      Merge branch 'net-sched-validate-the-control-action-with-all-the-other-parameters' · 1ea186e3
      David S. Miller authored
      
      
      Davide Caratti says:
      
      ====================
      net/sched: validate the control action with all the other parameters
      
      currently, the kernel checks for bad values of the control action in
      tcf_action_init_1(), after a successful call to the action's init()
      function. When the control action is 'goto chain', this causes two
      undesired behaviors:
      
      1. "misconfigured action after replace that causes kernel crash":
         if users replace a valid TC action with another one having invalid
         control action, all the new configuration data (including the bad
         control action) are applied successfully, even if the kernel returned
         an error. As a consequence, it's possible to trigger a NULL pointer
         dereference in the traffic path of every TC action (1), replacing the
         control action with 'goto chain x', when chain <x> doesn't exist.
      
      2. "refcount leak that makes kmemleak complain"
         when a valid 'goto chain' action is overwritten with another action,
         the kernel forgets to decrease refcounts in the chain.
      
      The above problems can be fixed if we validate the control action in each
      action's init() function, the same way as we are already doing for all the
      other configuration parameters.
      Now that chains can be released after an action is replaced, we need to
      care about concurrent access of 'goto_chain' pointer: ensure we access it
      through RCU, like we did with most action-specific configuration parameters.
      
      - Patch 1 removes the wrong checks and provides functions that can be
        used to properly validate control actions in  individual actions
      - Patch 2 to 16 fix individual actions, and add TDC selftest code to
        verify the correct behavior (2)
      - Patch 17 and 18 fix concurrent access issues on 'goto_chain', that can be
        observed after the chain refcount leak is fixed.
      
      Changes since v1:
      - reword the cover letter
      - condense the extack message in case tc_action_check_ctrlact() is called
        with invalid parameters.
      - add tcf_action_set_ctrlact() to avoid code duplication an make the
        RCU-ification of 'goto_chain' easier.
      - fix errors in act_ife, act_simple, act_skbedit, and avoid useless 'goto
        end' in act_connmark, thanks a lot to Vlad Buslov.
      - avoid dereferencing 'goto_chain' in tcf_gact_goto_chain_index(), so
        we don't have to care about the grace period there.
      - let actions respect the grace period when they release chains, thanks
        to Cong Wang and Vlad Buslov.
      
      Changes since RFC:
      - include a fix for all TC actions
      - add a selftest for each TC action
      - squash fix for refcount leaks into a single patch, the first in the
        series, thanks to Cong Wang
      - ensure that chain refcount is released without tcfa_lock held, thanks
        to Vlad Buslov
      
      Notes:
      (1) act_ipt didn't need any fix, as the control action is constantly equal
          to TC_ACT_OK.
      (2) the selftest for act_simple fails because userspace tc backend for
          'simple' does not parse the control action correctly (and hardcodes it
          to TC_ACT_PIPE).
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ea186e3
    • Davide Caratti's avatar
      net/sched: let actions use RCU to access 'goto_chain' · ee3bbfe8
      Davide Caratti authored
      
      
      use RCU when accessing the action chain, to avoid use after free in the
      traffic path when 'goto chain' is replaced on existing TC actions (see
      script below). Since the control action is read in the traffic path
      without holding the action spinlock, we need to explicitly ensure that
      a->goto_chain is not NULL before dereferencing (i.e it's not sufficient
      to rely on the value of TC_ACT_GOTO_CHAIN bits). Not doing so caused NULL
      dereferences in tcf_action_goto_chain_exec() when the following script:
      
       # tc chain add dev dd0 chain 42 ingress protocol ip flower \
       > ip_proto udp action pass index 4
       # tc filter add dev dd0 ingress protocol ip flower \
       > ip_proto udp action csum udp goto chain 42 index 66
       # tc chain del dev dd0 chain 42 ingress
       (start UDP traffic towards dd0)
       # tc action replace action csum udp pass index 66
      
      was run repeatedly for several hours.
      
      Suggested-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Suggested-by: default avatarVlad Buslov <vladbu@mellanox.com>
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee3bbfe8
    • Davide Caratti's avatar
      net/sched: don't dereference a->goto_chain to read the chain index · fe384e2f
      Davide Caratti authored
      callers of tcf_gact_goto_chain_index() can potentially read an old value
      of the chain index, or even dereference a NULL 'goto_chain' pointer,
      because 'goto_chain' and 'tcfa_action' are read in the traffic path
      without caring of concurrent write in the control path. The most recent
      value of chain index can be read also from a->tcfa_action (it's encoded
      there together with TC_ACT_GOTO_CHAIN bits), so we don't really need to
      dereference 'goto_chain': just read the chain id from the control action.
      
      Fixes: e457d86a
      
       ("net: sched: add couple of goto_chain helpers")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe384e2f
    • Davide Caratti's avatar
      net/sched: act_vlan: validate the control action inside init() · 7e0c8892
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action vlan pop pass index 90
       # tc actions replace action vlan \
       > pop goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action vlan
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: vlan  pop goto chain 42
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 800000007974f067 P4D 800000007974f067 PUD 79638067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.0.0-rc4.gotochain_crash+ #536
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffff982dfdb83be0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff982dfc55db00 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffff982df97099c0 RDI: ffff982dfc55db00
       RBP: ffff982dfdb83c80 R08: ffff982df983fec8 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000000 R12: ffff982df5aacd00
       R13: ffff982df5aacd08 R14: 0000000000000001 R15: ffff982df97099c0
       FS:  0000000000000000(0000) GS:ffff982dfdb80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 00000000796d0005 CR4: 00000000001606e0
       Call Trace:
        <IRQ>
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ip6_finish_output2+0x369/0x590
        ip6_finish_output2+0x369/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.35+0x79/0xc0
        mld_sendpack+0x16f/0x220
        mld_ifc_timer_expire+0x195/0x2c0
        ? igmp6_timer_handler+0x70/0x70
        call_timer_fn+0x2b/0x130
        run_timer_softirq+0x3e8/0x440
        ? enqueue_hrtimer+0x39/0x90
        __do_softirq+0xe3/0x2f5
        irq_exit+0xf0/0x100
        smp_apic_timer_interrupt+0x6c/0x130
        apic_timer_interrupt+0xf/0x20
        </IRQ>
       RIP: 0010:native_safe_halt+0x2/0x10
       Code: 7b ff ff ff 7f f3 c3 65 48 8b 04 25 00 5c 01 00 f0 80 48 02 20 48 8b 00 a8 08 74 8b eb c1 90 90 90 90 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
       RSP: 0018:ffffa4714038feb8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
       RAX: ffffffff840184f0 RBX: 0000000000000003 RCX: 0000000000000000
       RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000001e57d3f387
       RBP: 0000000000000003 R08: 001125d9ca39e1eb R09: 0000000000000000
       R10: 000000000000027d R11: 000000000009f400 R12: 0000000000000000
       R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
        ? __sched_text_end+0x1/0x1
        default_idle+0x1c/0x140
        do_idle+0x1c4/0x280
        cpu_startup_entry+0x19/0x20
        start_secondary+0x1a7/0x200
        secondary_startup_64+0xa4/0xb0
       Modules linked in: act_vlan veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 snd_hda_codec_generic mbcache crct10dif_pclmul jbd2 snd_hda_intel crc32_pclmul snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd glue_helper joydev snd_timer virtio_balloon snd pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt virtio_net fb_sys_fops virtio_blk ttm net_failover virtio_console failover ata_piix drm libata crc32c_intel virtio_pci serio_raw virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_vlan_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e0c8892
    • Davide Caratti's avatar
      net/sched: act_tunnel_key: validate the control action inside init() · e5fdabac
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action tunnel_key set src_ip 10.10.10.1 dst_ip 20.20.2 dst_port 3128 \
       > nocsum id 1 pass index 90
       # tc actions replace action tunnel_key \
       > set src_ip 10.10.10.1 dst_ip 20.20.2 dst_port 3128 nocsum id 1 \
       > goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action tunnel_key
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: tunnel_key  set
               src_ip 10.10.10.1
               dst_ip 20.20.2.0
               key_id 1
               dst_port 3128
               nocsum goto chain 42
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 800000002aba4067 P4D 800000002aba4067 PUD 795f9067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.0.0-rc4.gotochain_crash+ #536
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffff9346bdb83be0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff9346bb795c00 RCX: 0000000000000002
       RDX: 0000000000000000 RSI: ffff93466c881700 RDI: 0000000000000246
       RBP: ffff9346bdb83c80 R08: ffff9346b3e1e0c8 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000000 R12: ffff9346b978f000
       R13: ffff9346b978f008 R14: 0000000000000001 R15: ffff93466dceeb40
       FS:  0000000000000000(0000) GS:ffff9346bdb80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000007a6c2002 CR4: 00000000001606e0
       Call Trace:
        <IRQ>
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ip6_finish_output2+0x369/0x590
        ip6_finish_output2+0x369/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.35+0x79/0xc0
        mld_sendpack+0x16f/0x220
        mld_ifc_timer_expire+0x195/0x2c0
        ? igmp6_timer_handler+0x70/0x70
        call_timer_fn+0x2b/0x130
        run_timer_softirq+0x3e8/0x440
        ? tick_sched_timer+0x37/0x70
        __do_softirq+0xe3/0x2f5
        irq_exit+0xf0/0x100
        smp_apic_timer_interrupt+0x6c/0x130
        apic_timer_interrupt+0xf/0x20
        </IRQ>
       RIP: 0010:native_safe_halt+0x2/0x10
       Code: 55 ff ff ff 7f f3 c3 65 48 8b 04 25 00 5c 01 00 f0 80 48 02 20 48 8b 00 a8 08 74 8b eb c1 90 90 90 90 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
       RSP: 0018:ffffa48a8038feb8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
       RAX: ffffffffaa8184f0 RBX: 0000000000000003 RCX: 0000000000000000
       RDX: 0000000000000001 RSI: 0000000000000087 RDI: 0000000000000003
       RBP: 0000000000000003 R08: 0011251c6fcfac49 R09: ffff9346b995be00
       R10: ffffa48a805e7ce8 R11: 00000000024c38dd R12: 0000000000000000
       R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
        ? __sched_text_end+0x1/0x1
        default_idle+0x1c/0x140
        do_idle+0x1c4/0x280
        cpu_startup_entry+0x19/0x20
        start_secondary+0x1a7/0x200
        secondary_startup_64+0xa4/0xb0
       Modules linked in: act_tunnel_key veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 crct10dif_pclmul crc32_pclmul snd_hda_codec_generic ghash_clmulni_intel mbcache snd_hda_intel jbd2 snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd glue_helper joydev snd_timer snd pcspkr virtio_balloon soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect virtio_net sysimgblt fb_sys_fops ttm net_failover virtio_console virtio_blk failover drm serio_raw crc32c_intel ata_piix virtio_pci floppy virtio_ring libata virtio dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_tunnel_key_init() proved to fix
      the above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e5fdabac
    • Davide Caratti's avatar
      net/sched: act_skbmod: validate the control action inside init() · 7c3d825d
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action skbmod set smac 00:c1:a0:c1:a0:00 pass index 90
       # tc actions replace action skbmod \
       > set smac 00:c1:a0:c1:a0:00 goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action skbmod
      
      had the following output:
      
       src MAC address <00:c1:a0:c1:a0:00>
       src MAC address <00:c1:a0:c1:a0:00>
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: skbmod goto chain 42 set smac 00:c1:a0:c1:a0:00
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 800000002d5c7067 P4D 800000002d5c7067 PUD 77e16067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.0.0-rc4.gotochain_crash+ #536
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffff8987ffd83be0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff8987aeb68800 RCX: ffff8987fa263640
       RDX: 0000000000000000 RSI: ffff8987f51c8802 RDI: 00000000000000a0
       RBP: ffff8987ffd83c80 R08: ffff8987f939bac8 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000000 R12: ffff8987f5c77d00
       R13: ffff8987f5c77d08 R14: 0000000000000001 R15: ffff8987f0c29f00
       FS:  0000000000000000(0000) GS:ffff8987ffd80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000007832c004 CR4: 00000000001606e0
       Call Trace:
        <IRQ>
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ip6_finish_output2+0x369/0x590
        ip6_finish_output2+0x369/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.35+0x79/0xc0
        mld_sendpack+0x16f/0x220
        mld_ifc_timer_expire+0x195/0x2c0
        ? igmp6_timer_handler+0x70/0x70
        call_timer_fn+0x2b/0x130
        run_timer_softirq+0x3e8/0x440
        ? tick_sched_timer+0x37/0x70
        __do_softirq+0xe3/0x2f5
        irq_exit+0xf0/0x100
        smp_apic_timer_interrupt+0x6c/0x130
        apic_timer_interrupt+0xf/0x20
        </IRQ>
       RIP: 0010:native_safe_halt+0x2/0x10
       Code: 56 ff ff ff 7f f3 c3 65 48 8b 04 25 00 5c 01 00 f0 80 48 02 20 48 8b 00 a8 08 74 8b eb c1 90 90 90 90 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
       RSP: 0018:ffffa2a1c038feb8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
       RAX: ffffffffa94184f0 RBX: 0000000000000003 RCX: 0000000000000001
       RDX: 0000000000000001 RSI: 0000000000000087 RDI: 0000000000000003
       RBP: 0000000000000003 R08: 001123cfc2ba71ac R09: 0000000000000000
       R10: 0000000000000000 R11: 00000000000f4240 R12: 0000000000000000
       R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
        ? __sched_text_end+0x1/0x1
        default_idle+0x1c/0x140
        do_idle+0x1c4/0x280
        cpu_startup_entry+0x19/0x20
        start_secondary+0x1a7/0x200
        secondary_startup_64+0xa4/0xb0
       Modules linked in: act_skbmod veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel mbcache jbd2 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device aesni_intel crypto_simd cryptd glue_helper snd_pcm joydev pcspkr virtio_balloon snd_timer snd i2c_piix4 soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect virtio_net sysimgblt fb_sys_fops net_failover virtio_console ttm virtio_blk failover drm crc32c_intel serio_raw ata_piix virtio_pci libata virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_skbmod_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c3d825d
    • Davide Caratti's avatar
      net/sched: act_skbedit: validate the control action inside init() · ec7727bb
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action skbedit ptype host pass index 90
       # tc actions replace action skbedit \
       > ptype host goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action skbedit
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: skbedit  ptype host goto chain 42
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 3 PID: 3467 Comm: kworker/3:3 Not tainted 5.0.0-rc4.gotochain_crash+ #536
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       Workqueue: ipv6_addrconf addrconf_dad_work
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffffb50a81e1fad0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff9aa47ba4ea00 RCX: 0000000000000001
       RDX: 0000000000000000 RSI: ffff9aa469eeb3c0 RDI: ffff9aa47ba4ea00
       RBP: ffffb50a81e1fb70 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: ffff9aa47bce0638 R12: ffff9aa4793b0c00
       R13: ffff9aa4793b0c08 R14: 0000000000000001 R15: ffff9aa469eeb3c0
       FS:  0000000000000000(0000) GS:ffff9aa474780000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000007360e005 CR4: 00000000001606e0
       Call Trace:
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ndisc_next_option+0x50/0x50
        ? ___neigh_create+0x4d5/0x680
        ? ip6_finish_output2+0x1b5/0x590
        ip6_finish_output2+0x1b5/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.28+0x79/0xc0
        ndisc_send_skb+0x248/0x2e0
        ndisc_send_ns+0xf8/0x200
        ? addrconf_dad_work+0x389/0x4b0
        addrconf_dad_work+0x389/0x4b0
        ? __switch_to_asm+0x34/0x70
        ? process_one_work+0x195/0x380
        ? addrconf_dad_completed+0x370/0x370
        process_one_work+0x195/0x380
        worker_thread+0x30/0x390
        ? process_one_work+0x380/0x380
        kthread+0x113/0x130
        ? kthread_park+0x90/0x90
        ret_from_fork+0x35/0x40
       Modules linked in: act_skbedit veth ip6table_filter ip6_tables iptable_filter binfmt_misc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ext4 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep mbcache snd_hda_core jbd2 snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd snd_timer glue_helper snd joydev soundcore pcspkr virtio_balloon i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm virtio_net net_failover drm failover virtio_blk virtio_console ata_piix virtio_pci crc32c_intel serio_raw libata virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_skbedit_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec7727bb
    • Davide Caratti's avatar
      net/sched: act_simple: validate the control action inside init() · 4b006b0c
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action simple sdata hello pass index 90
       # tc actions replace action simple \
       > sdata world goto chain 42 index 90 cookie c1a0c1a0
       # tc action show action simple
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: Simple <world>
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 800000006a6fb067 P4D 800000006a6fb067 PUD 6aed6067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 2 PID: 3241 Comm: kworker/2:0 Not tainted 5.0.0-rc4.gotochain_crash+ #536
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       Workqueue: ipv6_addrconf addrconf_dad_work
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffffbe6781763ad0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff9e59bdb80e00 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffff9e59b4716738 RDI: ffff9e59ab12d140
       RBP: ffffbe6781763b70 R08: 0000000000000234 R09: 0000000000aaaaaa
       R10: 0000000000000000 R11: ffff9e59b247cd50 R12: ffff9e59b112f100
       R13: ffff9e59b112f108 R14: 0000000000000001 R15: ffff9e59ab12d0c0
       FS:  0000000000000000(0000) GS:ffff9e59b4700000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000006af92004 CR4: 00000000001606e0
       Call Trace:
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ndisc_next_option+0x50/0x50
        ? ___neigh_create+0x4d5/0x680
        ? ip6_finish_output2+0x1b5/0x590
        ip6_finish_output2+0x1b5/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.28+0x79/0xc0
        ndisc_send_skb+0x248/0x2e0
        ndisc_send_ns+0xf8/0x200
        ? addrconf_dad_work+0x389/0x4b0
        addrconf_dad_work+0x389/0x4b0
        ? __switch_to_asm+0x34/0x70
        ? process_one_work+0x195/0x380
        ? addrconf_dad_completed+0x370/0x370
        process_one_work+0x195/0x380
        worker_thread+0x30/0x390
        ? process_one_work+0x380/0x380
        kthread+0x113/0x130
        ? kthread_park+0x90/0x90
        ret_from_fork+0x35/0x40
       Modules linked in: act_simple veth ip6table_filter ip6_tables iptable_filter binfmt_misc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ext4 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep mbcache snd_hda_core jbd2 snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd snd_timer glue_helper snd joydev virtio_balloon pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops virtio_net ttm net_failover virtio_console virtio_blk failover drm crc32c_intel serio_raw floppy ata_piix libata virtio_pci virtio_ring virtio dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_simple_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b006b0c
    • Davide Caratti's avatar
      net/sched: act_sample: validate the control action inside init() · e8c87c64
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action sample rate 1024 group 4 pass index 90
       # tc actions replace action sample \
       > rate 1024 group 4 goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action sample
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: sample rate 1/1024 group 4 goto chain 42
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 8000000079966067 P4D 8000000079966067 PUD 7987b067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.0.0-rc4.gotochain_crash+ #536
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       Workqueue: ipv6_addrconf addrconf_dad_work
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffffbee60033fad0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff99d7ae6e3b00 RCX: 00000000e555df9b
       RDX: 0000000000000000 RSI: 00000000b0352718 RDI: ffff99d7fda1fcf0
       RBP: ffffbee60033fb70 R08: 0000000070731ab1 R09: 0000000000000400
       R10: 0000000000000000 R11: ffff99d7ac733838 R12: ffff99d7f3c2be00
       R13: ffff99d7f3c2be08 R14: 0000000000000001 R15: ffff99d7f3c2b600
       FS:  0000000000000000(0000) GS:ffff99d7fda00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 00000000797de006 CR4: 00000000001606f0
       Call Trace:
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ndisc_next_option+0x50/0x50
        ? ___neigh_create+0x4d5/0x680
        ? ip6_finish_output2+0x1b5/0x590
        ip6_finish_output2+0x1b5/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.28+0x79/0xc0
        ndisc_send_skb+0x248/0x2e0
        ndisc_send_ns+0xf8/0x200
        ? addrconf_dad_work+0x389/0x4b0
        addrconf_dad_work+0x389/0x4b0
        ? __switch_to_asm+0x34/0x70
        ? process_one_work+0x195/0x380
        ? addrconf_dad_completed+0x370/0x370
        process_one_work+0x195/0x380
        worker_thread+0x30/0x390
        ? process_one_work+0x380/0x380
        kthread+0x113/0x130
        ? kthread_park+0x90/0x90
        ret_from_fork+0x35/0x40
       Modules linked in: act_sample psample veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel mbcache jbd2 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device aesni_intel crypto_simd snd_pcm cryptd glue_helper snd_timer joydev snd pcspkr virtio_balloon i2c_piix4 soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect virtio_net sysimgblt fb_sys_fops net_failover ttm failover virtio_blk virtio_console drm ata_piix serio_raw crc32c_intel libata virtio_pci virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_sample_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8c87c64
    • Davide Caratti's avatar
      net/sched: act_police: validate the control action inside init() · d6124d6b
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action police rate 3mbit burst 250k pass index 90
       # tc actions replace action police \
       > rate 3mbit burst 250k goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action police rate 3mbit burst
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0:  police 0x5a rate 3Mbit burst 250Kb mtu 2Kb  action goto chain 42 overhead 0b
               ref 2 bind 1
               cookie c1a0c1a0
      
      Then, when crash0 starts transmitting more than 3Mbit/s, the following
      kernel crash is observed:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 800000007a779067 P4D 800000007a779067 PUD 2ad96067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 3 PID: 5032 Comm: netperf Not tainted 5.0.0-rc4.gotochain_crash+ #533
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffffb0e04064fa60 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff93bb3322cce0 RCX: 0000000000000005
       RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff93bb3322cce0
       RBP: ffffb0e04064fb00 R08: 0000000000000022 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000001 R12: ffff93bb3beed300
       R13: ffff93bb3beed308 R14: 0000000000000001 R15: ffff93bb3b64d000
       FS:  00007f0bc6be5740(0000) GS:ffff93bb3db80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 00000000746a8001 CR4: 00000000001606e0
       Call Trace:
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ipt_do_table+0x31c/0x420 [ip_tables]
        ? ip_finish_output2+0x16f/0x430
        ip_finish_output2+0x16f/0x430
        ? ip_output+0x69/0xe0
        ip_output+0x69/0xe0
        ? ip_forward_options+0x1a0/0x1a0
        __tcp_transmit_skb+0x563/0xa40
        tcp_write_xmit+0x243/0xfa0
        __tcp_push_pending_frames+0x32/0xf0
        tcp_sendmsg_locked+0x404/0xd30
        tcp_sendmsg+0x27/0x40
        sock_sendmsg+0x36/0x40
        __sys_sendto+0x10e/0x140
        ? __sys_connect+0x87/0xf0
        ? syscall_trace_enter+0x1df/0x2e0
        ? __audit_syscall_exit+0x216/0x260
        __x64_sys_sendto+0x24/0x30
        do_syscall_64+0x5b/0x180
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7f0bc5ffbafd
       Code: 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 8b 05 ae c4 2c 00 85 c0 75 2d 45 31 c9 45 31 c0 4c 63 d1 48 63 ff b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 8b 15 63 63 2c 00 f7 d8 64 89 02 48
       RSP: 002b:00007fffef94b7f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
       RAX: ffffffffffffffda RBX: 0000000000004000 RCX: 00007f0bc5ffbafd
       RDX: 0000000000004000 RSI: 00000000017e5420 RDI: 0000000000000004
       RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004
       R13: 00000000017e51d0 R14: 0000000000000010 R15: 0000000000000006
       Modules linked in: act_police veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 snd_hda_codec_generic mbcache crct10dif_pclmul jbd2 crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd glue_helper snd_timer snd joydev pcspkr virtio_balloon soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm virtio_blk virtio_net virtio_console net_failover failover crc32c_intel ata_piix libata serio_raw virtio_pci virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_police_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6124d6b
    • Davide Caratti's avatar
      net/sched: act_pedit: validate the control action inside init() · 6ac86ca3
      Davide Caratti authored
      the following script:
      
       # tc filter add dev crash0 egress matchall \
       > action pedit ex munge ip ttl set 10 pass index 90
       # tc actions replace action pedit \
       > ex munge ip ttl set 10 goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action pedit
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0:  pedit action goto chain 42 keys 1
                index 90 ref 2 bind 1
                key #0  at ipv4+8: val 0a000000 mask 00ffffff
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.0.0-rc4.gotochain_crash+ #533
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffff94a73db03be0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff94a6ee4c0700 RCX: 000000000000000a
       RDX: 0000000000000000 RSI: ffff94a6ed22c800 RDI: 0000000000000000
       RBP: ffff94a73db03c80 R08: ffff94a7386fa4c8 R09: ffff94a73229ea20
       R10: 0000000000000000 R11: 0000000000000000 R12: ffff94a6ed22cb00
       R13: ffff94a6ed22cb08 R14: 0000000000000001 R15: ffff94a6ed22c800
       FS:  0000000000000000(0000) GS:ffff94a73db00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000007120e002 CR4: 00000000001606e0
       Call Trace:
        <IRQ>
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ip6_finish_output2+0x369/0x590
        ip6_finish_output2+0x369/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.35+0x79/0xc0
        mld_sendpack+0x16f/0x220
        mld_ifc_timer_expire+0x195/0x2c0
        ? igmp6_timer_handler+0x70/0x70
        call_timer_fn+0x2b/0x130
        run_timer_softirq+0x3e8/0x440
        ? tick_sched_timer+0x37/0x70
        __do_softirq+0xe3/0x2f5
        irq_exit+0xf0/0x100
        smp_apic_timer_interrupt+0x6c/0x130
        apic_timer_interrupt+0xf/0x20
        </IRQ>
       RIP: 0010:native_safe_halt+0x2/0x10
       Code: 4e ff ff ff 7f f3 c3 65 48 8b 04 25 00 5c 01 00 f0 80 48 02 20 48 8b 00 a8 08 74 8b eb c1 90 90 90 90 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
       RSP: 0018:ffffab1740387eb8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
       RAX: ffffffffb18184f0 RBX: 0000000000000002 RCX: 0000000000000001
       RDX: 0000000000000001 RSI: 0000000000000087 RDI: 0000000000000002
       RBP: 0000000000000002 R08: 000f168fa695f9a9 R09: 0000000000000020
       R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000000
       R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
        ? __sched_text_end+0x1/0x1
        default_idle+0x1c/0x140
        do_idle+0x1c4/0x280
        cpu_startup_entry+0x19/0x20
        start_secondary+0x1a7/0x200
        secondary_startup_64+0xa4/0xb0
       Modules linked in: act_pedit veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 mbcache jbd2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep aesni_intel snd_hda_core crypto_simd snd_seq cryptd glue_helper snd_seq_device snd_pcm joydev snd_timer pcspkr virtio_balloon snd soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs qxl ata_generic pata_acpi drm_kms_helper virtio_net net_failover syscopyarea sysfillrect sysimgblt failover virtio_blk fb_sys_fops virtio_console ttm drm crc32c_intel serio_raw ata_piix virtio_pci libata virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_pedit_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ac86ca3
    • Davide Caratti's avatar
      net/sched: act_nat: validate the control action inside init() · 1e45d043
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action nat ingress 1.18.1.1 1.18.2.2 pass index 90
       # tc actions replace action nat \
       > ingress 1.18.1.1 1.18.2.2 goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action nat
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0:  nat ingress 1.18.1.1/32 1.18.2.2 goto chain 42
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 800000002d180067 P4D 800000002d180067 PUD 7cb8b067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 3 PID: 164 Comm: kworker/3:1 Not tainted 5.0.0-rc4.gotochain_crash+ #533
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       Workqueue: ipv6_addrconf addrconf_dad_work
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffffae4500e2fad0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff9fa52e28c800 RCX: 0000000001011201
       RDX: 0000000000000000 RSI: 0000000000000056 RDI: ffff9fa52ca12800
       RBP: ffffae4500e2fb70 R08: 0000000000000022 R09: 000000000000000e
       R10: 00000000ffffffff R11: 0000000001011201 R12: ffff9fa52cbc9c00
       R13: ffff9fa52cbc9c08 R14: 0000000000000001 R15: ffff9fa52ca12780
       FS:  0000000000000000(0000) GS:ffff9fa57db80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 0000000073f8c004 CR4: 00000000001606e0
       Call Trace:
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ndisc_next_option+0x50/0x50
        ? ___neigh_create+0x4d5/0x680
        ? ip6_finish_output2+0x1b5/0x590
        ip6_finish_output2+0x1b5/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.28+0x79/0xc0
        ndisc_send_skb+0x248/0x2e0
        ndisc_send_ns+0xf8/0x200
        ? addrconf_dad_work+0x389/0x4b0
        addrconf_dad_work+0x389/0x4b0
        ? __switch_to_asm+0x34/0x70
        ? process_one_work+0x195/0x380
        ? addrconf_dad_completed+0x370/0x370
        process_one_work+0x195/0x380
        worker_thread+0x30/0x390
        ? process_one_work+0x380/0x380
        kthread+0x113/0x130
        ? kthread_park+0x90/0x90
        ret_from_fork+0x35/0x40
       Modules linked in: act_nat veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel mbcache jbd2 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd glue_helper snd_timer snd joydev virtio_balloon pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs qxl ata_generic pata_acpi drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm virtio_net virtio_blk net_failover failover virtio_console drm crc32c_intel floppy ata_piix libata virtio_pci virtio_ring virtio serio_raw dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_nat_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e45d043
    • Davide Caratti's avatar
      net/sched: act_connmark: validate the control action inside init() · c53075ea
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action connmark pass index 90
       # tc actions replace action connmark \
       > goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action connmark
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: connmark zone 0 goto chain 42
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 0 PID: 302 Comm: kworker/0:2 Not tainted 5.0.0-rc4.gotochain_crash+ #533
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       Workqueue: ipv6_addrconf addrconf_dad_work
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffff9bea406c3ad0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff8c5dfc009f00 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffff9bea406c3a80 RDI: ffff8c5dfb9d6ec0
       RBP: ffff9bea406c3b70 R08: ffff8c5dfda222a0 R09: ffffffff90933c3c
       R10: 0000000000000000 R11: 0000000092793f7d R12: ffff8c5df48b3c00
       R13: ffff8c5df48b3c08 R14: 0000000000000001 R15: ffff8c5dfb9d6e40
       FS:  0000000000000000(0000) GS:ffff8c5dfda00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 0000000062e0e006 CR4: 00000000001606f0
       Call Trace:
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ndisc_next_option+0x50/0x50
        ? ___neigh_create+0x4d5/0x680
        ? ip6_finish_output2+0x1b5/0x590
        ip6_finish_output2+0x1b5/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.28+0x79/0xc0
        ndisc_send_skb+0x248/0x2e0
        ndisc_send_ns+0xf8/0x200
        ? addrconf_dad_work+0x389/0x4b0
        addrconf_dad_work+0x389/0x4b0
        ? __switch_to_asm+0x34/0x70
        ? process_one_work+0x195/0x380
        ? addrconf_dad_completed+0x370/0x370
        process_one_work+0x195/0x380
        worker_thread+0x30/0x390
        ? process_one_work+0x380/0x380
        kthread+0x113/0x130
        ? kthread_park+0x90/0x90
        ret_from_fork+0x35/0x40
       Modules linked in: act_connmark nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 crct10dif_pclmul mbcache crc32_pclmul jbd2 snd_hda_codec_generic ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm aesni_intel snd_timer crypto_simd cryptd snd glue_helper joydev virtio_balloon pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper virtio_net net_failover syscopyarea virtio_blk failover virtio_console sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix crc32c_intel serio_raw libata virtio_pci virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_connmark_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c53075ea
    • Davide Caratti's avatar
      net/sched: act_mirred: validate the control action inside init() · ff9721d3
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action mirred ingress mirror dev lo pass
       # tc actions replace action mirred \
       > ingress mirror dev lo goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action mirred
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: mirred (Ingress Mirror to device lo) goto chain 42
               index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       Mirror/redirect action on
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 3 PID: 47 Comm: kworker/3:1 Not tainted 5.0.0-rc4.gotochain_crash+ #533
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       Workqueue: ipv6_addrconf addrconf_dad_work
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffffa772404b7ad0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff9c5afc3f4300 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffff9c5afdba9380 RDI: 0000000000029380
       RBP: ffffa772404b7b70 R08: ffff9c5af7010028 R09: ffff9c5af7010029
       R10: 0000000000000000 R11: ffff9c5af94c6a38 R12: ffff9c5af7953000
       R13: ffff9c5af7953008 R14: 0000000000000001 R15: ffff9c5af7953d00
       FS:  0000000000000000(0000) GS:ffff9c5afdb80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000007c514004 CR4: 00000000001606e0
       Call Trace:
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ndisc_next_option+0x50/0x50
        ? ___neigh_create+0x4d5/0x680
        ? ip6_finish_output2+0x1b5/0x590
        ip6_finish_output2+0x1b5/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.28+0x79/0xc0
        ndisc_send_skb+0x248/0x2e0
        ndisc_send_ns+0xf8/0x200
        ? addrconf_dad_work+0x389/0x4b0
        addrconf_dad_work+0x389/0x4b0
        ? __switch_to_asm+0x34/0x70
        ? process_one_work+0x195/0x380
        ? addrconf_dad_completed+0x370/0x370
        process_one_work+0x195/0x380
        worker_thread+0x30/0x390
        ? process_one_work+0x380/0x380
        kthread+0x113/0x130
        ? kthread_park+0x90/0x90
        ret_from_fork+0x35/0x40
       Modules linked in: act_mirred veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 crct10dif_pclmul snd_hda_codec_generic crc32_pclmul snd_hda_intel snd_hda_codec mbcache ghash_clmulni_intel jbd2 snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm aesni_intel snd_timer snd crypto_simd cryptd glue_helper soundcore virtio_balloon joydev pcspkr i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops virtio_net ttm virtio_blk net_failover virtio_console failover drm ata_piix crc32c_intel virtio_pci serio_raw libata virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_mirred_init() proved to fix the
      above issue. For the same reason, postpone the assignment of tcfa_action
      and tcfm_eaction to avoid partial reconfiguration of a mirred rule when
      it's replaced by another one that mirrors to a device that does not
      exist. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff9721d3
    • Davide Caratti's avatar
      net/sched: act_ife: validate the control action inside init() · 11a94d7f
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action ife encode allow mark pass index 90
       # tc actions replace action ife \
       > encode allow mark goto chain 42 index 90 cookie c1a0c1a0
       # tc action show action ife
      
      had the following output:
      
       IFE type 0xED3E
       IFE type 0xED3E
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: ife encode action goto chain 42 type 0XED3E
               allow mark
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 800000007b4e7067 P4D 800000007b4e7067 PUD 7b4e6067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 2 PID: 164 Comm: kworker/2:1 Not tainted 5.0.0-rc4.gotochain_crash+ #533
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       Workqueue: ipv6_addrconf addrconf_dad_work
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffffa6a7c0553ad0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff9796ee1bbd00 RCX: 0000000000000001
       RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
       RBP: ffffa6a7c0553b70 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: ffff9797385bb038 R12: ffff9796ead9d700
       R13: ffff9796ead9d708 R14: 0000000000000001 R15: ffff9796ead9d800
       FS:  0000000000000000(0000) GS:ffff97973db00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000007c41e006 CR4: 00000000001606e0
       Call Trace:
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ndisc_next_option+0x50/0x50
        ? ___neigh_create+0x4d5/0x680
        ? ip6_finish_output2+0x1b5/0x590
        ip6_finish_output2+0x1b5/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.28+0x79/0xc0
        ndisc_send_skb+0x248/0x2e0
        ndisc_send_ns+0xf8/0x200
        ? addrconf_dad_work+0x389/0x4b0
        addrconf_dad_work+0x389/0x4b0
        ? __switch_to_asm+0x34/0x70
        ? process_one_work+0x195/0x380
        ? addrconf_dad_completed+0x370/0x370
        process_one_work+0x195/0x380
        worker_thread+0x30/0x390
        ? process_one_work+0x380/0x380
        kthread+0x113/0x130
        ? kthread_park+0x90/0x90
        ret_from_fork+0x35/0x40
       Modules linked in: act_gact act_meta_mark act_ife dummy veth ip6table_filter ip6_tables iptable_filter binfmt_misc snd_hda_codec_generic ext4 snd_hda_intel snd_hda_codec crct10dif_pclmul mbcache crc32_pclmul jbd2 snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq snd_seq_device snd_pcm snd_timer aesni_intel crypto_simd snd cryptd glue_helper virtio_balloon joydev pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl virtio_net drm_kms_helper virtio_blk net_failover syscopyarea failover sysfillrect virtio_console sysimgblt fb_sys_fops ttm drm crc32c_intel serio_raw ata_piix virtio_pci virtio_ring libata virtio floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_ife]
       CR2: 0000000000000000
      
      Validating the control action within tcf_ife_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      11a94d7f
    • Davide Caratti's avatar
      net/sched: act_gact: validate the control action inside init() · 0da2dbd6
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall \
       > action gact pass index 90
       # tc actions replace action gact \
       > goto chain 42 index 90 cookie c1a0c1a0
       # tc actions show action gact
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: gact action goto chain 42
                random type none pass val 0
                index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.0.0-rc4.gotochain_crash+ #533
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffff8c2434703be0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff8c23ed6d7e00 RCX: 000000000000005a
       RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8c23ed6d7e00
       RBP: ffff8c2434703c80 R08: ffff8c243b639ac8 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000000 R12: ffff8c2429e68b00
       R13: ffff8c2429e68b08 R14: 0000000000000001 R15: ffff8c2429c5a480
       FS:  0000000000000000(0000) GS:ffff8c2434700000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 000000002dc0e005 CR4: 00000000001606e0
       Call Trace:
        <IRQ>
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ip6_finish_output2+0x369/0x590
        ip6_finish_output2+0x369/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.35+0x79/0xc0
        mld_sendpack+0x16f/0x220
        mld_ifc_timer_expire+0x195/0x2c0
        ? igmp6_timer_handler+0x70/0x70
        call_timer_fn+0x2b/0x130
        run_timer_softirq+0x3e8/0x440
        ? tick_sched_timer+0x37/0x70
        __do_softirq+0xe3/0x2f5
        irq_exit+0xf0/0x100
        smp_apic_timer_interrupt+0x6c/0x130
        apic_timer_interrupt+0xf/0x20
        </IRQ>
       RIP: 0010:native_safe_halt+0x2/0x10
       Code: 74 ff ff ff 7f f3 c3 65 48 8b 04 25 00 5c 01 00 f0 80 48 02 20 48 8b 00 a8 08 74 8b eb c1 90 90 90 90 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
       RSP: 0018:ffff9c8640387eb8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
       RAX: ffffffff8b2184f0 RBX: 0000000000000002 RCX: 0000000000000001
       RDX: 0000000000000001 RSI: 0000000000000087 RDI: 0000000000000002
       RBP: 0000000000000002 R08: 000eb57882b36cc3 R09: 0000000000000020
       R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000000
       R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
        ? __sched_text_end+0x1/0x1
        default_idle+0x1c/0x140
        do_idle+0x1c4/0x280
        cpu_startup_entry+0x19/0x20
        start_secondary+0x1a7/0x200
        secondary_startup_64+0xa4/0xb0
       Modules linked in: act_gact act_bpf veth ip6table_filter ip6_tables iptable_filter binfmt_misc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic ext4 snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core mbcache jbd2 snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd glue_helper virtio_balloon joydev pcspkr snd_timer snd i2c_piix4 soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea virtio_net sysfillrect net_failover virtio_blk sysimgblt fb_sys_fops virtio_console ttm failover drm crc32c_intel serio_raw ata_piix libata floppy virtio_pci virtio_ring virtio dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_bpf]
       CR2: 0000000000000000
      
      Validating the control action within tcf_gact_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0da2dbd6
    • Davide Caratti's avatar
      net/sched: act_csum: validate the control action inside init() · f5c29d83
      Davide Caratti authored
      the following script:
      
       # tc qdisc add dev crash0 clsact
       # tc filter add dev crash0 egress matchall action csum icmp pass index 90
       # tc actions replace action csum icmp goto chain 42 index 90 \
       > cookie c1a0c1a0
       # tc actions show action csum
      
      had the following output:
      
      Error: Failed to init TC action chain.
      We have an error talking to the kernel
      total acts 1
      
              action order 0: csum (icmp) action goto chain 42
              index 90 ref 2 bind 1
              cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       #PF error: [normal kernel read fault]
       PGD 8000000074692067 P4D 8000000074692067 PUD 2e210067 PMD 0
       Oops: 0000 [#1] SMP PTI
       CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.0.0-rc4.gotochain_crash+ #533
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffff93153da03be0 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff9314ee40f700 RCX: 0000000000003a00
       RDX: 0000000000000000 RSI: ffff931537c87828 RDI: ffff931537c87818
       RBP: ffff93153da03c80 R08: 00000000527cffff R09: 0000000000000003
       R10: 000000000000003f R11: 0000000000000028 R12: ffff9314edf68400
       R13: ffff9314edf68408 R14: 0000000000000001 R15: ffff9314ed67b600
       FS:  0000000000000000(0000) GS:ffff93153da00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 0000000073e32003 CR4: 00000000001606f0
       Call Trace:
        <IRQ>
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ip6_finish_output2+0x369/0x590
        ip6_finish_output2+0x369/0x590
        ? ip6_output+0x68/0x110
        ip6_output+0x68/0x110
        ? nf_hook.constprop.35+0x79/0xc0
        mld_sendpack+0x16f/0x220
        mld_ifc_timer_expire+0x195/0x2c0
        ? igmp6_timer_handler+0x70/0x70
        call_timer_fn+0x2b/0x130
        run_timer_softirq+0x3e8/0x440
        ? tick_sched_timer+0x37/0x70
        __do_softirq+0xe3/0x2f5
        irq_exit+0xf0/0x100
        smp_apic_timer_interrupt+0x6c/0x130
        apic_timer_interrupt+0xf/0x20
        </IRQ>
       RIP: 0010:native_safe_halt+0x2/0x10
       Code: 66 ff ff ff 7f f3 c3 65 48 8b 04 25 00 5c 01 00 f0 80 48 02 20 48 8b 00 a8 08 74 8b eb c1 90 90 90 90 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
       RSP: 0018:ffffffff9a803e98 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
       RAX: ffffffff99e184f0 RBX: 0000000000000000 RCX: 0000000000000001
       RDX: 0000000000000001 RSI: 0000000000000087 RDI: 0000000000000000
       RBP: 0000000000000000 R08: 000eb5c4572376b3 R09: 0000000000000000
       R10: ffffa53e806a3ca0 R11: 00000000000f4240 R12: 0000000000000000
       R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
        ? __sched_text_end+0x1/0x1
        default_idle+0x1c/0x140
        do_idle+0x1c4/0x280
        cpu_startup_entry+0x19/0x20
        start_kernel+0x49e/0x4be
        secondary_startup_64+0xa4/0xb0
       Modules linked in: act_csum veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 crct10dif_pclmul crc32_pclmul snd_hda_codec_generic ghash_clmulni_intel snd_hda_intel mbcache snd_hda_codec jbd2 snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd snd_timer glue_helper snd joydev virtio_balloon pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect virtio_net sysimgblt net_failover fb_sys_fops virtio_console virtio_blk ttm failover drm ata_piix crc32c_intel floppy virtio_pci serio_raw libata virtio_ring virtio dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_csum_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5c29d83
    • Davide Caratti's avatar
      net/sched: act_bpf: validate the control action inside init() · 4e181004
      Davide Caratti authored
      the following script:
      
       # tc filter add dev crash0 egress matchall \
       > action bpf bytecode '1,6 0 0 4294967295' pass index 90
       # tc actions replace action bpf \
       > bytecode '1,6 0 0 4294967295' goto chain 42 index 90 cookie c1a0c1a0
       # tc action show action bpf
      
      had the following output:
      
       Error: Failed to init TC action chain.
       We have an error talking to the kernel
       total acts 1
      
               action order 0: bpf bytecode '1,6 0 0 4294967295' default-action goto chain 42
               index 90 ref 2 bind 1
               cookie c1a0c1a0
      
      Then, the first packet transmitted by crash0 made the kernel crash:
      
       RIP: 0010:tcf_action_exec+0xb8/0x100
       Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
       RSP: 0018:ffffb3a0803dfa90 EFLAGS: 00010246
       RAX: 000000002000002a RBX: ffff942b347ada00 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffffb3a08034d038 RDI: ffff942b347ada00
       RBP: ffffb3a0803dfb30 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: ffffb3a0803dfb0c R12: ffff942b3b682b00
       R13: ffff942b3b682b08 R14: 0000000000000001 R15: ffff942b3b682f00
       FS:  00007f6160a72740(0000) GS:ffff942b3da80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000000 CR3: 00000000795a4002 CR4: 00000000001606e0
       Call Trace:
        tcf_classify+0x58/0x120
        __dev_queue_xmit+0x40a/0x890
        ? ip_finish_output2+0x16f/0x430
        ip_finish_output2+0x16f/0x430
        ? ip_output+0x69/0xe0
        ip_output+0x69/0xe0
        ? ip_forward_options+0x1a0/0x1a0
        ip_send_skb+0x15/0x40
        raw_sendmsg+0x8e1/0xbd0
        ? sched_clock+0x5/0x10
        ? sched_clock_cpu+0xc/0xa0
        ? try_to_wake_up+0x54/0x480
        ? ldsem_down_read+0x3f/0x280
        ? _cond_resched+0x15/0x40
        ? down_read+0xe/0x30
        ? copy_termios+0x1e/0x70
        ? tty_mode_ioctl+0x1b6/0x4c0
        ? sock_sendmsg+0x36/0x40
        sock_sendmsg+0x36/0x40
        __sys_sendto+0x10e/0x140
        ? do_vfs_ioctl+0xa4/0x640
        ? handle_mm_fault+0xdc/0x210
        ? syscall_trace_enter+0x1df/0x2e0
        ? __audit_syscall_exit+0x216/0x260
        __x64_sys_sendto+0x24/0x30
        do_syscall_64+0x5b/0x180
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7f615f7e3c03
       Code: 48 8b 0d 90 62 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 9d c3 2c 00 00 75 13 49 89 ca b8 2c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 4b cc 00 00 48 89 04 24
       RSP: 002b:00007ffee5d8cc28 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
       RAX: ffffffffffffffda RBX: 000055a4f28f1700 RCX: 00007f615f7e3c03
       RDX: 0000000000000040 RSI: 000055a4f28f1700 RDI: 0000000000000003
       RBP: 00007ffee5d8e340 R08: 000055a4f28ee510 R09: 0000000000000010
       R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
       R13: 000055a4f28f16c0 R14: 000055a4f28ef69c R15: 0000000000000080
       Modules linked in: act_bpf veth ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 mbcache crct10dif_pclmul jbd2 crc32_pclmul snd_hda_codec_generic ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd cryptd glue_helper pcspkr joydev virtio_balloon snd_timer snd i2c_piix4 soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs ata_generic pata_acpi qxl drm_kms_helper virtio_blk virtio_net virtio_console net_failover failover syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crc32c_intel ata_piix serio_raw libata virtio_pci virtio_ring virtio floppy dm_mirror dm_region_hash dm_log dm_mod
       CR2: 0000000000000000
      
      Validating the control action within tcf_bpf_init() proved to fix the
      above issue. A TDC selftest is added to verify the correct behavior.
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e181004
    • Davide Caratti's avatar
      net/sched: prepare TC actions to properly validate the control action · 85d0966f
      Davide Caratti authored
      - pass a pointer to struct tcf_proto in each actions's init() handler,
        to allow validating the control action, checking whether the chain
        exists and (eventually) refcounting it.
      - remove code that validates the control action after a successful call
        to the action's init() handler, and replace it with a test that forbids
        addition of actions having 'goto_chain' and NULL goto_chain pointer at
        the same time.
      - add tcf_action_check_ctrlact(), that will validate the control action
        and eventually allocate the action 'goto_chain' within the init()
        handler.
      - add tcf_action_set_ctrlact(), that will assign the control action and
        swap the current 'goto_chain' pointer with the new given one.
      
      This disallows 'goto_chain' on actions that don't initialize it properly
      in their init() handler, i.e. calling tcf_action_check_ctrlact() after
      successful IDR reservation and then calling tcf_action_set_ctrlact()
      to assign 'goto_chain' and 'tcf_action' consistently.
      
      By doing this, the kernel does not leak anymore refcounts when a valid
      'goto chain' handle is replaced in TC actions, causing kmemleak splats
      like the following one:
      
       # tc chain add dev dd0 chain 42 ingress protocol ip flower \
       > ip_proto tcp action drop
       # tc chain add dev dd0 chain 43 ingress protocol ip flower \
       > ip_proto udp action drop
       # tc filter add dev dd0 ingress matchall \
       > action gact goto chain 42 index 66
       # tc filter replace dev dd0 ingress matchall \
       > action gact goto chain 43 index 66
       # echo scan >/sys/kernel/debug/kmemleak
       <...>
       unreferenced object 0xffff93c0ee09f000 (size 1024):
       comm "tc", pid 2565, jiffies 4295339808 (age 65.426s)
       hex dump (first 32 bytes):
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
         00 00 00 00 08 00 06 00 00 00 00 00 00 00 00 00  ................
       backtrace:
         [<000000009b63f92d>] tc_ctl_chain+0x3d2/0x4c0
         [<00000000683a8d72>] rtnetlink_rcv_msg+0x263/0x2d0
         [<00000000ddd88f8e>] netlink_rcv_skb+0x4a/0x110
         [<000000006126a348>] netlink_unicast+0x1a0/0x250
         [<00000000b3340877>] netlink_sendmsg+0x2c1/0x3c0
         [<00000000a25a2171>] sock_sendmsg+0x36/0x40
         [<00000000f19ee1ec>] ___sys_sendmsg+0x280/0x2f0
         [<00000000d0422042>] __sys_sendmsg+0x5e/0xa0
         [<000000007a6c61f9>] do_syscall_64+0x5b/0x180
         [<00000000ccd07542>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
         [<0000000013eaa334>] 0xffffffffffffffff
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0
      
       ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      85d0966f
    • Harini Katakam's avatar
      net: macb: Add null check for PCLK and HCLK · cd5afa91
      Harini Katakam authored
      
      
      Both PCLK and HCLK are "required" clocks according to macb devicetree
      documentation. There is a chance that devm_clk_get doesn't return a
      negative error but just a NULL clock structure instead. In such a case
      the driver proceeds as usual and uses pclk value 0 to calculate MDC
      divisor which is incorrect. Hence fix the same in clock initialization.
      
      Signed-off-by: default avatarHarini Katakam <harini.katakam@xilinx.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd5afa91
    • Dan Murphy's avatar
      net: phy: Add DP83825I to the DP83822 driver · 06acc17a
      Dan Murphy authored
      Add the DP83825I ethernet PHY to the DP83822 driver.
      These devices share the same WoL register bits and addresses.
      
      The phy_driver init was made into a macro as there may be future
      devices appended to this driver that will share the register space.
      
      http://www.ti.com/lit/gpn/dp83825i
      
      
      
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDan Murphy <dmurphy@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06acc17a
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · e0831ef7
      David S. Miller authored
      
      
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for your net tree:
      
      1) Remove a direct dependency with IPv6 introduced by the
         sip_external_media feature, from Alin Nastac.
      
      2) Fix bogus ENOENT when removing interval elements from set.
      
      3) Set transport_header from br_netfilter to mimic the stack
         behaviour, this partially fixes a checksum validation bug
         from the SCTP connection tracking, from Xin Long.
      
      4) Fix undefined reference to symbol in xt_TEE, due to missing
         Kconfig dependencies, from Arnd Bergmann.
      
      5) Check for NULL in skb_header_pointer() calls in ip6t_shr,
         from Kangjie Lu.
      
      6) Fix bogus EBUSY when removing an existing conntrack helper from
         a transaction.
      
      7) Fix module autoload of the redirect extension.
      
      8) Remove duplicated transition in flowtable diagram in the existing
         documentation.
      
      9) Missing .release_ops call from error path in newrule() which
         results module refcount leak, from Taehee Yoo.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0831ef7
    • YueHaibing's avatar
      genetlink: Fix a memory leak on error path · ceabee6c
      YueHaibing authored
      
      
      In genl_register_family(), when idr_alloc() fails,
      we forget to free the memory we possibly allocate for
      family->attrbuf.
      
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 2ae0f17d
      
       ("genetlink: use idr to track families")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ceabee6c
    • Erik Hugne's avatar
      tipc: fix cancellation of topology subscriptions · 33872d79
      Erik Hugne authored
      When cancelling a subscription, we have to clear the cancel bit in the
      request before iterating over any established subscriptions with memcmp.
      Otherwise no subscription will ever be found, and it will not be
      possible to explicitly unsubscribe individual subscriptions.
      
      Fixes: 8985ecc7
      
       ("tipc: simplify endianness handling in topology subscriber")
      Signed-off-by: default avatarErik Hugne <erik.hugne@gmail.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33872d79
  2. Mar 21, 2019
    • Ioana Ciocoi Radulescu's avatar
      dpaa2-eth: Fix possible access beyond end of array · 64447506
      Ioana Ciocoi Radulescu authored
      Make sure we don't try to enqueue XDP_REDIRECT frames to an
      inexistent FQ.
      
      While it is guaranteed not to have more than one queue per core,
      having fewer queues than CPUs on an interface is a valid
      configuration.
      
      Fixes: d678be1d
      
       ("dpaa2-eth: add XDP_REDIRECT support")
      Reported-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarIoana Radulescu <ruxandra.radulescu@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64447506
    • David S. Miller's avatar
      Merge branch 'ks8851-fixes' · cb8075d9
      David S. Miller authored
      
      
      Lukas Wunner says:
      
      ====================
      ks8851 fixes & cleanups
      
      Four fixes and two cleanups for the Microchip (formerly Micrel) KSZ8851
      SPI Ethernet driver.
      
      Some of the fixes might even pass as stable material, but I haven't marked
      them as such for cautiousness: Doesn't hurt letting them bake in linux-next
      for a few weeks to raise the confidence, even though we've tested them
      extensively on our Revolution Pi open source PLCs.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb8075d9
    • Lukas Wunner's avatar
      net: ks8851: Deduplicate register macros · aae079aa
      Lukas Wunner authored
      The ks8851 chip is sold either with an SPI interface (KSZ8851SNL) or
      with a so-called non-PCI interface (KSZ8851-16MLL).  When the driver
      for the latter was introduced with commit a55c0a0e ("drivers/net:
      ks8851_mll ethernet network driver"), it duplicated the register macros
      introduced by the driver for the former with commit 3ba81f3e
      
       ("net:
      Micrel KS8851 SPI network driver").
      
      The chips are almost identical, so the duplication seems unwarranted.
      There are a handful of bits which are in use on the KSZ8851-16MLL but
      reserved on the KSZ8851SNL, and vice-versa, but there are no actual
      collisions.
      
      Thus, remove the duplicate definitions from the KSZ8851-16MLL driver.
      Mark all bits which differ between the two chips.  Move the SPI frame
      opcodes, which are specific to KSZ8851SNL, to its driver.
      
      The KSZ8851-16MLL driver added a RXFCTR_THRESHOLD_MASK macro which is a
      duplication of the RXFCTR_RXFCT_MASK macro, rename it where it's used.
      Same for P1MBCR_FORCE_FDX, which duplicates the BMCR_FULLDPLX macro and
      OBCR_ODS_16MA, which duplicates OBCR_ODS_16mA.
      
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aae079aa
    • Lukas Wunner's avatar
      net: ks8851: Fix register macro misnomers · cbda74a1
      Lukas Wunner authored
      In the header file accompanying the ks8851 driver, the P1SCLMD register
      macros are misnamed, they actually pertain to the P1CR register.
      
      The P1CR macros in turn pertain to the P1SR register, see pages 65 to 68
      of the spec:
      http://www.hqchip.com/uploads/pdf/201703/47c98946d6c97a4766e14db3f24955f2.pdf
      
      
      
      The misnomers have no negative consequences so far because the macros
      aren't used by ks8851.c, but that's about to change.
      
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cbda74a1
    • Lukas Wunner's avatar
      net: ks8851: Set initial carrier state to down · 9624bafa
      Lukas Wunner authored
      
      
      The ks8851 chip's initial carrier state is down. A Link Change Interrupt
      is signaled once interrupts are enabled if the carrier is up.
      
      The ks8851 driver has it backwards by assuming that the initial carrier
      state is up. The state is therefore misrepresented if the interface is
      opened with no cable attached. Fix it.
      
      The Link Change interrupt is sometimes not signaled unless the P1MBSR
      register (which contains the Link Status bit) is read on ->ndo_open().
      This might be a hardware erratum. Read the register by calling
      mii_check_link(), which has the desirable side effect of setting the
      carrier state to down if the cable was detached while the interface was
      closed.
      
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9624bafa
    • Lukas Wunner's avatar
      net: ks8851: Delay requesting IRQ until opened · d268f315
      Lukas Wunner authored
      
      
      The ks8851 driver currently requests the IRQ before registering the
      net_device.  Because the net_device name is used as IRQ name and is
      still "eth%d" when the IRQ is requested, it's impossibe to tell IRQs
      apart if multiple ks8851 chips are present.  Most other drivers delay
      requesting the IRQ until the net_device is opened.  Do the same.
      
      The driver doesn't enable interrupts on the chip before opening the
      net_device and disables them when closing it, so there doesn't seem to
      be a need to request the IRQ already on probe.
      
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d268f315
    • Lukas Wunner's avatar
      net: ks8851: Reassert reset pin if chip ID check fails · 761cfa97
      Lukas Wunner authored
      Commit 73fdeb82
      
       ("net: ks8851: Add optional vdd_io regulator and
      reset gpio") amended the ks8851 driver to briefly assert the chip's
      reset pin on probe. It also amended the probe routine's error path to
      reassert the reset pin if a subsequent initialization step fails.
      
      However the commit misplaced reassertion of the reset pin in the error
      path such that it is not performed if the check of the Chip ID and
      Enable Register (CIDER) fails. The error path is therefore slightly
      asymmetrical to the probe routine's body. Fix it.
      
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      761cfa97
    • Lukas Wunner's avatar
      net: ks8851: Dequeue RX packets explicitly · 536d3680
      Lukas Wunner authored
      
      
      The ks8851 driver lets the chip auto-dequeue received packets once they
      have been read in full. It achieves that by setting the ADRFE flag in
      the RXQCR register ("Auto-Dequeue RXQ Frame Enable").
      
      However if allocation of a packet's socket buffer or retrieval of the
      packet over the SPI bus fails, the packet will not have been read in
      full and is not auto-dequeued. Such partial retrieval of a packet
      confuses the chip's RX queue management:  On the next RX interrupt,
      the first packet read from the queue will be the one left there
      previously and this one can be retrieved without issues. But for any
      newly received packets, the frame header status and byte count registers
      (RXFHSR and RXFHBCR) contain bogus values, preventing their retrieval.
      
      The chip allows explicitly dequeueing a packet from the RX queue by
      setting the RRXEF flag in the RXQCR register ("Release RX Error Frame").
      This could be used to dequeue the packet in case of an error, but if
      that error is a failed SPI transfer, it is unknown if the packet was
      transferred in full and was auto-dequeued or if it was only transferred
      in part and requires an explicit dequeue. The safest approach is thus
      to always dequeue packets explicitly and forgo auto-dequeueing.
      
      Without this change, I've witnessed packet retrieval break completely
      when an SPI DMA transfer fails, requiring a chip reset. Explicit
      dequeueing magically fixes this and makes packet retrieval absolutely
      robust for me.
      
      The chip's documentation suggests auto-dequeuing and uses the RRXEF
      flag only to dequeue error frames which the driver doesn't want to
      retrieve. But that seems to be a fair-weather approach.
      
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      536d3680
    • Xin Long's avatar
      sctp: use memdup_user instead of vmemdup_user · ef82bcfa
      Xin Long authored
      In sctp_setsockopt_bindx()/__sctp_setsockopt_connectx(), it allocates
      memory with addrs_size which is passed from userspace. We used flag
      GFP_USER to put some more restrictions on it in Commit cacc0621
      ("sctp: use GFP_USER for user-controlled kmalloc").
      
      However, since Commit c981f254
      
       ("sctp: use vmemdup_user() rather
      than badly open-coding memdup_user()"), vmemdup_user() has been used,
      which doesn't check GFP_USER flag when goes to vmalloc_*(). So when
      addrs_size is a huge value, it could exhaust memory and even trigger
      oom killer.
      
      This patch is to use memdup_user() instead, in which GFP_USER would
      work to limit the memory allocation with a huge addrs_size.
      
      Note we can't fix it by limiting 'addrs_size', as there's no demand
      for it from RFC.
      
      Reported-by: default avatar <syzbot+ec1b7575afef85a0e5ca@syzkaller.appspotmail.com>
      Fixes: c981f254
      
       ("sctp: use vmemdup_user() rather than badly open-coding memdup_user()")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef82bcfa
    • Xin Long's avatar
      ipv6: make ip6_create_rt_rcu return ip6_null_entry instead of NULL · 1c87e79a
      Xin Long authored
      Jianlin reported a crash:
      
        [  381.484332] BUG: unable to handle kernel NULL pointer dereference at 0000000000000068
        [  381.619802] RIP: 0010:fib6_rule_lookup+0xa3/0x160
        [  382.009615] Call Trace:
        [  382.020762]  <IRQ>
        [  382.030174]  ip6_route_redirect.isra.52+0xc9/0xf0
        [  382.050984]  ip6_redirect+0xb6/0xf0
        [  382.066731]  icmpv6_notify+0xca/0x190
        [  382.083185]  ndisc_redirect_rcv+0x10f/0x160
        [  382.102569]  ndisc_rcv+0xfb/0x100
        [  382.117725]  icmpv6_rcv+0x3f2/0x520
        [  382.133637]  ip6_input_finish+0xbf/0x460
        [  382.151634]  ip6_input+0x3b/0xb0
        [  382.166097]  ipv6_rcv+0x378/0x4e0
      
      It was caused by the lookup function __ip6_route_redirect() returns NULL in
      fib6_rule_lookup() when ip6_create_rt_rcu() returns NULL.
      
      So we fix it by simply making ip6_create_rt_rcu() return ip6_null_entry
      instead of NULL.
      
      v1->v2:
        - move down 'fallback:' to make it more readable.
      
      Fixes: e873e4b9
      
       ("ipv6: use fib6_info_hold_safe() when necessary")
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Suggested-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Acked-by: default avatarWei Wang <weiwan@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c87e79a
    • Christoph Paasch's avatar
      net/packet: Set __GFP_NOWARN upon allocation in alloc_pg_vec · 398f0132
      Christoph Paasch authored
      Since commit fc62814d ("net/packet: fix 4gb buffer limit due to overflow check")
      one can now allocate packet ring buffers >= UINT_MAX. However, syzkaller
      found that that triggers a warning:
      
      [   21.100000] WARNING: CPU: 2 PID: 2075 at mm/page_alloc.c:4584 __alloc_pages_nod0
      [   21.101490] Modules linked in:
      [   21.101921] CPU: 2 PID: 2075 Comm: syz-executor.0 Not tainted 5.0.0 #146
      [   21.102784] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
      [   21.103887] RIP: 0010:__alloc_pages_nodemask+0x2a0/0x630
      [   21.104640] Code: fe ff ff 65 48 8b 04 25 c0 de 01 00 48 05 90 0f 00 00 41 bd 01 00 00 00 48 89 44 24 48 e9 9c fe 3
      [   21.107121] RSP: 0018:ffff88805e1cf920 EFLAGS: 00010246
      [   21.107819] RAX: 0000000000000000 RBX: ffffffff85a488a0 RCX: 0000000000000000
      [   21.108753] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000000
      [   21.109699] RBP: 1ffff1100bc39f28 R08: ffffed100bcefb67 R09: ffffed100bcefb67
      [   21.110646] R10: 0000000000000001 R11: ffffed100bcefb66 R12: 000000000000000d
      [   21.111623] R13: 0000000000000000 R14: ffff88805e77d888 R15: 000000000000000d
      [   21.112552] FS:  00007f7c7de05700(0000) GS:ffff88806d100000(0000) knlGS:0000000000000000
      [   21.113612] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   21.114405] CR2: 000000000065c000 CR3: 000000005e58e006 CR4: 00000000001606e0
      [   21.115367] Call Trace:
      [   21.115705]  ? __alloc_pages_slowpath+0x21c0/0x21c0
      [   21.116362]  alloc_pages_current+0xac/0x1e0
      [   21.116923]  kmalloc_order+0x18/0x70
      [   21.117393]  kmalloc_order_trace+0x18/0x110
      [   21.117949]  packet_set_ring+0x9d5/0x1770
      [   21.118524]  ? packet_rcv_spkt+0x440/0x440
      [   21.119094]  ? lock_downgrade+0x620/0x620
      [   21.119646]  ? __might_fault+0x177/0x1b0
      [   21.120177]  packet_setsockopt+0x981/0x2940
      [   21.120753]  ? __fget+0x2fb/0x4b0
      [   21.121209]  ? packet_release+0xab0/0xab0
      [   21.121740]  ? sock_has_perm+0x1cd/0x260
      [   21.122297]  ? selinux_secmark_relabel_packet+0xd0/0xd0
      [   21.123013]  ? __fget+0x324/0x4b0
      [   21.123451]  ? selinux_netlbl_socket_setsockopt+0x101/0x320
      [   21.124186]  ? selinux_netlbl_sock_rcv_skb+0x3a0/0x3a0
      [   21.124908]  ? __lock_acquire+0x529/0x3200
      [   21.125453]  ? selinux_socket_setsockopt+0x5d/0x70
      [   21.126075]  ? __sys_setsockopt+0x131/0x210
      [   21.126533]  ? packet_release+0xab0/0xab0
      [   21.127004]  __sys_setsockopt+0x131/0x210
      [   21.127449]  ? kernel_accept+0x2f0/0x2f0
      [   21.127911]  ? ret_from_fork+0x8/0x50
      [   21.128313]  ? do_raw_spin_lock+0x11b/0x280
      [   21.128800]  __x64_sys_setsockopt+0xba/0x150
      [   21.129271]  ? lockdep_hardirqs_on+0x37f/0x560
      [   21.129769]  do_syscall_64+0x9f/0x450
      [   21.130182]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      We should allocate with __GFP_NOWARN to handle this.
      
      Cc: Kal Conley <kal.conley@dectris.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Fixes: fc62814d
      
       ("net/packet: fix 4gb buffer limit due to overflow check")
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      398f0132
  3. Mar 20, 2019
    • Taehee Yoo's avatar
      netfilter: nf_tables: add missing ->release_ops() in error path of newrule() · b25a31bf
      Taehee Yoo authored
      ->release_ops() callback releases resources and this is used in error path.
      If nf_tables_newrule() fails after ->select_ops(), it should release
      resources. but it can not call ->destroy() because that should be called
      after ->init().
      At this point, ->release_ops() should be used for releasing resources.
      
      Test commands:
         modprobe -rv xt_tcpudp
         iptables-nft -I INPUT -m tcp   <-- error command
         lsmod
      
      Result:
         Module                  Size  Used by
         xt_tcpudp              20480  2      <-- it should be 0
      
      Fixes: b8e20400
      
       ("netfilter: nft_compat: use .release_ops and remove list of extension")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      b25a31bf
    • Vinay K Nallamothu's avatar
      mpls: Fix 6PE forwarding · f84532ce
      Vinay K Nallamothu authored
      
      
      This patch adds support for 6PE (RFC 4798) which uses IPv4-mapped IPv6
      nexthop to connect IPv6 islands over IPv4 only MPLS network core.
      
      Prior to this fix, to find the link-layer destination mac address, 6PE
      enabled host/router was sending IPv6 ND requests for IPv4-mapped IPv6
      nexthop address over the interface facing the IPv4 only core which
      wouldn't success as the core is IPv6 free.
      
      This fix changes that behavior on 6PE host to treat the nexthop as IPv4
      address and send ARP requests whenever the next-hop address is an
      IPv4-mapped IPv6 address.
      
      Below topology illustrates the issue and how the patch addresses it.
      
      abcd::1.1.1.1 (lo)                                              abcd::2.2.2.2 (lo)
      R0 (PE/host)------------------------R1--------------------------------R2 (PE/host)
                  <--- IPv4 MPLS core --->   <------ IPv4 MPLS core -------->
                 eth1               eth2       eth3                       eth4
                172.18.0.10     172.18.0.11   172.19.0.11              172.19.0.12
          ffff::172.18.0.10                                      ffff::172.19.0.12
                  <------------------IPv6 MPLS tunnel ---------------------->
      
      R0 and R2 act as 6PE routers of IPv6 islands. R1 is IPv4 only with MPLS tunnels
      between R0,R1 and R1,R2.
      
       docker exec r0 ip -f inet6 route add abcd::2.2.2.2/128 nexthop encap mpls 100 via ::ffff:172.18.0.11 dev eth1
       docker exec r2 ip -f inet6 route add abcd::1.1.1.1/128 nexthop encap mpls 200 via ::ffff:172.19.0.11 dev eth4
      
       docker exec r1 ip -f mpls route add 100 via inet 172.19.0.12 dev eth3
       docker exec r1 ip -f mpls route add 200 via inet 172.18.0.10 dev eth2
      
      With the change, when R0 sends an IPv6 packet over MPLS tunnel to abcd::2.2.2.2,
      using ::ffff:172.18.0.11 as the nexthop, it does neighbor discovery for
      172.18.18.0.11.
      
      Signed-off-by: default avatarVinay K Nallamothu <nvinay@juniper.net>
      Tested-by: default avatarAvinash Lingala <ar977m@att.com>
      Tested-by: default avatarAravind Srinivas Srinivasa Prabhakar <aprabh@juniper.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f84532ce
    • Arnd Bergmann's avatar
      3c515: fix integer overflow warning · fb6fafbc
      Arnd Bergmann authored
      
      
      clang points out a harmless signed integer overflow:
      
      drivers/net/ethernet/3com/3c515.c:1530:66: error: implicit conversion from 'int' to 'short' changes value from 32783 to -32753 [-Werror,-Wconstant-conversion]
                      new_mode = SetRxFilter | RxStation | RxMulticast | RxBroadcast | RxProm;
                               ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      drivers/net/ethernet/3com/3c515.c:1532:52: error: implicit conversion from 'int' to 'short' changes value from 32775 to -32761 [-Werror,-Wconstant-conversion]
                      new_mode = SetRxFilter | RxStation | RxMulticast | RxBroadcast;
                               ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
      drivers/net/ethernet/3com/3c515.c:1534:38: error: implicit conversion from 'int' to 'short' changes value from 32773 to -32763 [-Werror,-Wconstant-conversion]
                      new_mode = SetRxFilter | RxStation | RxBroadcast;
                               ~ ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
      
      Make the variable unsigned to avoid the overflow.
      
      Fixes: Linux-2.1.128pre1
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb6fafbc
    • Eric Dumazet's avatar
      dccp: do not use ipv6 header for ipv4 flow · e0aa6770
      Eric Dumazet authored
      When a dual stack dccp listener accepts an ipv4 flow,
      it should not attempt to use an ipv6 header or
      inet6_iif() helper.
      
      Fixes: 3df80d93
      
       ("[DCCP]: Introduce DCCPv6")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0aa6770