1. 16 Oct, 2018 3 commits
    • Wenwen Wang's avatar
      ethtool: fix a privilege escalation bug · 58f5bbe3
      Wenwen Wang authored
      In dev_ethtool(), the eth command 'ethcmd' is firstly copied from the
      use-space buffer 'useraddr' and checked to see whether it is
      ETHTOOL_PERQUEUE. If yes, the sub-command 'sub_cmd' is further copied from
      the user space. Otherwise, 'sub_cmd' is the same as 'ethcmd'. Next,
      according to 'sub_cmd', a permission check is enforced through the function
      ns_capable(). For example, the permission check is required if 'sub_cmd' is
      ETHTOOL_SCOALESCE, but it is not necessary if 'sub_cmd' is
      ETHTOOL_GCOALESCE, as suggested in the comment "Allow some commands to be
      done by anyone". The following execution invokes different handlers
      according to 'ethcmd'. Specifically, if 'ethcmd' is ETHTOOL_PERQUEUE,
      ethtool_set_per_queue() is called. In ethtool_set_per_queue(), the kernel
      object 'per_queue_opt' is copied again from the user-space buffer
      'useraddr' and 'per_queue_opt.sub_command' is used to determine which
      operation should be performed. Given that the buffer 'useraddr' is in the
      user space, a malicious user can race to change the sub-command between the
      two copies. In particular, the attacker can supply ETHTOOL_PERQUEUE and
      ETHTOOL_GCOALESCE to bypass the permission check in dev_ethtool(). Then
      before ethtool_set_per_queue() is called, the attacker changes
      ETHTOOL_GCOALESCE to ETHTOOL_SCOALESCE. In this way, the attacker can
      bypass the permission check and execute ETHTOOL_SCOALESCE.
      
      This patch enforces a check in ethtool_set_per_queue() after the second
      copy from 'useraddr'. If the sub-command is different from the one obtained
      in the first copy in dev_ethtool(), an error code EINVAL will be returned.
      
      Fixes: f38d138a ("net/ethtool: support set coalesce per queue")
      Signed-off-by: default avatarWenwen Wang <wang6495@umn.edu>
      Reviewed-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58f5bbe3
    • Wenwen Wang's avatar
      ethtool: fix a missing-check bug · 2bb3207d
      Wenwen Wang authored
      In ethtool_get_rxnfc(), the eth command 'cmd' is compared against
      'ETHTOOL_GRXFH' to see whether it is necessary to adjust the variable
      'info_size'. Then the whole structure of 'info' is copied from the
      user-space buffer 'useraddr' with 'info_size' bytes. In the following
      execution, 'info' may be copied again from the buffer 'useraddr' depending
      on the 'cmd' and the 'info.flow_type'. However, after these two copies,
      there is no check between 'cmd' and 'info.cmd'. In fact, 'cmd' is also
      copied from the buffer 'useraddr' in dev_ethtool(), which is the caller
      function of ethtool_get_rxnfc(). Given that 'useraddr' is in the user
      space, a malicious user can race to change the eth command in the buffer
      between these copies. By doing so, the attacker can supply inconsistent
      data and cause undefined behavior because in the following execution 'info'
      will be passed to ops->get_rxnfc().
      
      This patch adds a necessary check on 'info.cmd' and 'cmd' to confirm that
      they are still same after the two copies in ethtool_get_rxnfc(). Otherwise,
      an error code EINVAL will be returned.
      Signed-off-by: default avatarWenwen Wang <wang6495@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2bb3207d
    • Jian-Hong Pan's avatar
      r8169: Enable MSI-X on RTL8106e · d49c88d7
      Jian-Hong Pan authored
      Originally, we have an issue where r8169 MSI-X interrupt is broken after
      S3 suspend/resume on RTL8106e of ASUS X441UAR.
      
      02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
      RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [10ec:8136]
      (rev 07)
      	Subsystem: ASUSTeK Computer Inc. RTL810xE PCI Express Fast
      Ethernet controller [1043:200f]
      	Flags: bus master, fast devsel, latency 0, IRQ 16
      	I/O ports at e000 [size=256]
      	Memory at ef100000 (64-bit, non-prefetchable) [size=4K]
      	Memory at e0000000 (64-bit, prefetchable) [size=16K]
      	Capabilities: [40] Power Management version 3
      	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
      	Capabilities: [70] Express Endpoint, MSI 01
      	Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
      	Capabilities: [d0] Vital Product Data
      	Capabilities: [100] Advanced Error Reporting
      	Capabilities: [140] Virtual Channel
      	Capabilities: [160] Device Serial Number 01-00-00-00-36-4c-e0-00
      	Capabilities: [170] Latency Tolerance Reporting
      	Kernel driver in use: r8169
      	Kernel modules: r8169
      
      We found the all of the values in PCI BAR=4 of the ethernet adapter
      become 0xFF after system resumes.  That breaks the MSI-X interrupt.
      Therefore, we can only fall back to MSI interrupt to fix the issue at
      that time.
      
      However, there is a commit which resolves the drivers getting nothing in
      PCI BAR=4 after system resumes.  It is 04cb3ae895d7 "PCI: Reprogram
      bridge prefetch registers on resume" by Daniel Drake.
      
      After apply the patch, the ethernet adapter works fine before suspend
      and after resume.  So, we can revert the workaround after the commit
      "PCI: Reprogram bridge prefetch registers on resume" is merged into main
      tree.
      
      This patch reverts commit 7bb05b85
      "r8169: don't use MSI-X on RTL8106e".
      
      Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=201181
      Fixes: 7bb05b85 ("r8169: don't use MSI-X on RTL8106e")
      Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d49c88d7
  2. 14 Oct, 2018 1 commit
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 028c99fa
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2018-10-14
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) Fix xsk map update and delete operation to not call synchronize_net()
         but to piggy back on SOCK_RCU_FREE for sockets instead as we are not
         allowed to sleep under RCU, from Björn.
      
      2) Do not change RLIMIT_MEMLOCK in reuseport_bpf selftest if the process
         already has unlimited RLIMIT_MEMLOCK, from Eric.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      028c99fa
  3. 12 Oct, 2018 15 commits
  4. 11 Oct, 2018 21 commits