1. 26 Mar, 2019 15 commits
  2. 25 Mar, 2019 4 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 27602e2c
      David S. Miller authored
      Alexei Starovoitov says:
      
      ====================
      pull-request: bpf 2019-03-24
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) libbpf verision fix up from Daniel.
      
      2) fix liveness propagation from Jakub.
      
      3) fix verbose print of refcounted regs from Martin.
      
      4) fix for large map allocations from Martynas.
      
      5) fix use after free in sanitize_ptr_alu from Xu.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27602e2c
    • Alexei Starovoitov's avatar
      Merge branch 'libbpf-fixup' · a7d6ac37
      Alexei Starovoitov authored
      Daniel Borkmann says:
      
      ====================
      First one is fixing version in Makefile and shared object and
      second one clarifies bump in version. Thanks!
      
      v1 -> v2:
        - Fix up soname, thanks Stanislav!
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      a7d6ac37
    • Daniel Borkmann's avatar
      bpf, libbpf: clarify bump in libbpf version info · 63197f78
      Daniel Borkmann authored
      The current documentation suggests that we would need to bump the
      libbpf version on every change. Lets clarify this a bit more and
      reflect what we do today in practice, that is, bumping it once per
      development cycle.
      
      Fixes: 76d1b894 ("libbpf: Document API and ABI conventions")
      Reported-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      63197f78
    • Daniel Borkmann's avatar
      bpf, libbpf: fix version info and add it to shared object · 1d382264
      Daniel Borkmann authored
      Even though libbpf's versioning script for the linker (libbpf.map)
      is pointing to 0.0.2, the BPF_EXTRAVERSION in the Makefile has
      not been updated along with it and is therefore still on 0.0.1.
      
      While fixing up, I also noticed that the generated shared object
      versioning information is missing, typical convention is to have
      a linker name (libbpf.so), soname (libbpf.so.0) and real name
      (libbpf.so.0.0.2) for library management. This is based upon the
      LIBBPF_VERSION as well.
      
      The build will then produce the following bpf libraries:
      
        # ll libbpf*
        libbpf.a
        libbpf.so -> libbpf.so.0.0.2
        libbpf.so.0 -> libbpf.so.0.0.2
        libbpf.so.0.0.2
      
        # readelf -d libbpf.so.0.0.2 | grep SONAME
        0x000000000000000e (SONAME)             Library soname: [libbpf.so.0]
      
      And install them accordingly:
      
        # rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld install
      
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...                           bpf: [ on  ]
      
          CC       /tmp/bld/libbpf.o
          CC       /tmp/bld/bpf.o
          CC       /tmp/bld/nlattr.o
          CC       /tmp/bld/btf.o
          CC       /tmp/bld/libbpf_errno.o
          CC       /tmp/bld/str_error.o
          CC       /tmp/bld/netlink.o
          CC       /tmp/bld/bpf_prog_linfo.o
          CC       /tmp/bld/libbpf_probes.o
          CC       /tmp/bld/xsk.o
          LD       /tmp/bld/libbpf-in.o
          LINK     /tmp/bld/libbpf.a
          LINK     /tmp/bld/libbpf.so.0.0.2
          LINK     /tmp/bld/test_libbpf
          INSTALL  /tmp/bld/libbpf.a
          INSTALL  /tmp/bld/libbpf.so.0.0.2
      
        # ll /usr/local/lib64/libbpf.*
        /usr/local/lib64/libbpf.a
        /usr/local/lib64/libbpf.so -> libbpf.so.0.0.2
        /usr/local/lib64/libbpf.so.0 -> libbpf.so.0.0.2
        /usr/local/lib64/libbpf.so.0.0.2
      
      Fixes: 1bf4b058 ("tools: bpftool: add probes for eBPF program types")
      Fixes: 1b76c13e ("bpf tools: Introduce 'bpf' library and add bpf feature check")
      Reported-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      1d382264
  3. 24 Mar, 2019 8 commits
    • Arnd Bergmann's avatar
      rxrpc: avoid clang -Wuninitialized warning · 526949e8
      Arnd Bergmann authored
      clang produces a false-positive warning as it fails to notice
      that "lost = true" implies that "ret" is initialized:
      
      net/rxrpc/output.c:402:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
              if (lost)
                  ^~~~
      net/rxrpc/output.c:437:6: note: uninitialized use occurs here
              if (ret >= 0) {
                  ^~~
      net/rxrpc/output.c:402:2: note: remove the 'if' if its condition is always false
              if (lost)
              ^~~~~~~~~
      net/rxrpc/output.c:339:9: note: initialize the variable 'ret' to silence this warning
              int ret, opt;
                     ^
                      = 0
      
      Rearrange the code to make that more obvious and avoid the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      526949e8
    • Jon Maloy's avatar
      tipc: tipc clang warning · 737889ef
      Jon Maloy authored
      When checking the code with clang -Wsometimes-uninitialized we get the
      following warning:
      
      if (!tipc_link_is_establishing(l)) {
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      net/tipc/node.c:847:46: note: uninitialized use occurs here
            tipc_bearer_xmit(n->net, bearer_id, &xmitq, maddr);
      
      net/tipc/node.c:831:2: note: remove the 'if' if its condition is always
      true
      if (!tipc_link_is_establishing(l)) {
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      net/tipc/node.c:821:31: note: initialize the variable 'maddr' to silence
      this warning
      struct tipc_media_addr *maddr;
      
      We fix this by initializing 'maddr' to NULL. For the matter of clarity,
      we also test if 'xmitq' is non-empty before we use it and 'maddr'
      further down in the  function. It will never happen that 'xmitq' is non-
      empty at the same time as 'maddr' is NULL, so this is a sufficient test.
      
      Fixes: 598411d7 ("tipc: make resetting of links non-atomic")
      Reported-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      737889ef
    • John Hurley's avatar
      net: sched: fix cleanup NULL pointer exception in act_mirr · 064c5d68
      John Hurley authored
      A new mirred action is created by the tcf_mirred_init function. This
      contains a list head struct which is inserted into a global list on
      successful creation of a new action. However, after a creation, it is
      still possible to error out and call the tcf_idr_release function. This,
      in turn, calls the act_mirr cleanup function via __tcf_idr_release and
      __tcf_action_put. This cleanup function tries to delete the list entry
      which is as yet uninitialised, leading to a NULL pointer exception.
      
      Fix this by initialising the list entry on creation of a new action.
      
      Bug report:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      PGD 8000000840c73067 P4D 8000000840c73067 PUD 858dcc067 PMD 0
      Oops: 0002 [#1] SMP PTI
      CPU: 32 PID: 5636 Comm: handler194 Tainted: G           OE     5.0.0+ #186
      Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.3.6 06/03/2015
      RIP: 0010:tcf_mirred_release+0x42/0xa7 [act_mirred]
      Code: f0 90 39 c0 e8 52 04 57 c8 48 c7 c7 b8 80 39 c0 e8 94 fa d4 c7 48 8b 93 d0 00 00 00 48 8b 83 d8 00 00 00 48 c7 c7 f0 90 39 c0 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 d0 00
      RSP: 0018:ffffac4aa059f688 EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffff9dcd1b214d00 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffff9dcd1fa165f8 RDI: ffffffffc03990f0
      RBP: ffff9dccf9c7af80 R08: 0000000000000a3b R09: 0000000000000000
      R10: ffff9dccfa11f420 R11: 0000000000000000 R12: 0000000000000001
      R13: ffff9dcd16b433c0 R14: ffff9dcd1b214d80 R15: 0000000000000000
      FS:  00007f441bfff700(0000) GS:ffff9dcd1fa00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000008 CR3: 0000000839e64004 CR4: 00000000001606e0
      Call Trace:
      tcf_action_cleanup+0x59/0xca
      __tcf_action_put+0x54/0x6b
      __tcf_idr_release.cold.33+0x9/0x12
      tcf_mirred_init.cold.20+0x22e/0x3b0 [act_mirred]
      tcf_action_init_1+0x3d0/0x4c0
      tcf_action_init+0x9c/0x130
      tcf_exts_validate+0xab/0xc0
      fl_change+0x1ca/0x982 [cls_flower]
      tc_new_tfilter+0x647/0x8d0
      ? load_balance+0x14b/0x9e0
      rtnetlink_rcv_msg+0xe3/0x370
      ? __switch_to_asm+0x40/0x70
      ? __switch_to_asm+0x34/0x70
      ? _cond_resched+0x15/0x30
      ? __kmalloc_node_track_caller+0x1d4/0x2b0
      ? rtnl_calcit.isra.31+0xf0/0xf0
      netlink_rcv_skb+0x49/0x110
      netlink_unicast+0x16f/0x210
      netlink_sendmsg+0x1df/0x390
      sock_sendmsg+0x36/0x40
      ___sys_sendmsg+0x27b/0x2c0
      ? futex_wake+0x80/0x140
      ? do_futex+0x2b9/0xac0
      ? ep_scan_ready_list.constprop.22+0x1f2/0x210
      ? ep_poll+0x7a/0x430
      __sys_sendmsg+0x47/0x80
      do_syscall_64+0x55/0x100
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 4e232818 ("net: sched: act_mirred: remove dependency on rtnl lock")
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      064c5d68
    • Heiner Kallweit's avatar
      r8169: fix cable re-plugging issue · 23c78343
      Heiner Kallweit authored
      Bartek reported that after few cable unplug/replug cycles suddenly
      replug isn't detected any longer. His system uses a RTL8106, I wasn't
      able to reproduce the issue with RTL8168g. According to his bisect
      the referenced commit caused the regression. As Realtek doesn't
      release datasheets or errata it's hard to say what's the actual root
      cause, but this change was reported to fix the issue.
      
      Fixes: 38caff5a ("r8169: handle all interrupt events in the hard irq handler")
      Reported-by: default avatarBartosz Skrzypczak <barteks2x@gmail.com>
      Suggested-by: default avatarBartosz Skrzypczak <barteks2x@gmail.com>
      Tested-by: default avatarBartosz Skrzypczak <barteks2x@gmail.com>
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      23c78343
    • Wen Yang's avatar
      net: ethernet: ti: fix possible object reference leak · 75eac7b5
      Wen Yang authored
      The call to of_get_child_by_name returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/net/ethernet/ti/netcp_ethss.c:3661:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3654, but without a corresponding object release within this function.
      ./drivers/net/ethernet/ti/netcp_ethss.c:3665:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3654, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Wingman Kwok <w-kwok2@ti.com>
      Cc: Murali Karicheri <m-karicheri2@ti.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      75eac7b5
    • Wen Yang's avatar
      net: ibm: fix possible object reference leak · be693df3
      Wen Yang authored
      The call to ehea_get_eth_dn returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/net/ethernet/ibm/ehea/ehea_main.c:3163:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3154, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Douglas Miller <dougmill@linux.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be693df3
    • Wen Yang's avatar
      net: xilinx: fix possible object reference leak · fa3a419d
      Wen Yang authored
      The call to of_parse_phandle returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1624:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1569, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Anirudha Sarangi <anirudh@xilinx.com>
      Cc: John Linn <John.Linn@xilinx.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa3a419d
    • Florian Fainelli's avatar
      net: phy: Re-parent menus for MDIO bus drivers correctly · a7fb107b
      Florian Fainelli authored
      After 90eff909 ("net: phy: Allow splitting MDIO bus/device support
      from PHYs") the various MDIO bus drivers were no longer parented with
      config PHYLIB but with config MDIO_BUS which is not a menuconfig, fix
      this by depending on MDIO_DEVICE which is a menuconfig.
      
      This is visually nicer and less confusing for users.
      
      Fixes: 90eff909 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7fb107b
  4. 22 Mar, 2019 2 commits
  5. 21 Mar, 2019 11 commits
    • Yunsheng Lin's avatar
      net: hns3: fix for not calculating tx bd num correctly · 5f543a54
      Yunsheng Lin authored
      When there is only one byte in a frag, the current calculation
      using "(size + HNS3_MAX_BD_SIZE - 1) >> HNS3_MAX_BD_SIZE_OFFSET"
      will return zero, because HNS3_MAX_BD_SIZE is 65535 and
      HNS3_MAX_BD_SIZE_OFFSET is 16. So it will cause tx error when
      a frag's size is one byte.
      
      This patch fixes it by using DIV_ROUND_UP.
      
      Fixes: 3fe13ed9 ("net: hns3: avoid mult + div op in critical data path")
      Signed-off-by: default avatarYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f543a54
    • Herbert Xu's avatar
      rhashtable: Still do rehash when we get EEXIST · 408f13ef
      Herbert Xu authored
      As it stands if a shrink is delayed because of an outstanding
      rehash, we will go into a rescheduling loop without ever doing
      the rehash.
      
      This patch fixes this by still carrying out the rehash and then
      rescheduling so that we can shrink after the completion of the
      rehash should it still be necessary.
      
      The return value of EEXIST captures this case and other cases
      (e.g., another thread expanded/rehashed the table at the same
      time) where we should still proceed with the rehash.
      
      Fixes: da20420f ("rhashtable: Add nested tables")
      Reported-by: default avatarJosh Elsasser <jelsasser@appneta.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarJosh Elsasser <jelsasser@appneta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      408f13ef
    • 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