1. 06 8月, 2018 21 次提交
  2. 05 8月, 2018 15 次提交
  3. 04 8月, 2018 4 次提交
    • K
      jfs: Fix usercopy whitelist for inline inode data · 961b33c2
      Kees Cook 提交于
      Bart Massey reported what turned out to be a usercopy whitelist false
      positive in JFS when symlink contents exceeded 128 bytes. The inline
      inode data (i_inline) is actually designed to overflow into the "extended
      area" following it (i_inline_ea) when needed. So the whitelist needed to
      be expanded to include both i_inline and i_inline_ea (the whole size
      of which is calculated internally using IDATASIZE, 256, instead of
      sizeof(i_inline), 128).
      
      $ cd /mnt/jfs
      $ touch $(perl -e 'print "B" x 250')
      $ ln -s B* b
      $ ls -l >/dev/null
      
      [  249.436410] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'jfs_ip' (offset 616, size 250)!
      Reported-by: NBart Massey <bart.massey@gmail.com>
      Fixes: 8d2704d3 ("jfs: Define usercopy region in jfs_ip slab cache")
      Cc: Dave Kleikamp <shaggy@kernel.org>
      Cc: jfs-discussion@lists.sourceforge.net
      Cc: stable@vger.kernel.org
      Signed-off-by: NKees Cook <keescook@chromium.org>
      961b33c2
    • Y
      tcp: remove unneeded variable 'err' · a01512b1
      YueHaibing 提交于
      variable 'err' is unmodified after initalization,
      so simply cleans up it and returns 0.
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a01512b1
    • J
      af_unix: ensure POLLOUT on remote close() for connected dgram socket · 51f7e951
      Jason Baron 提交于
      Applications use -ECONNREFUSED as returned from write() in order to
      determine that a socket should be closed. However, when using connected
      dgram unix sockets in a poll/write loop, a final POLLOUT event can be
      missed when the remote end closes. Thus, the poll is stuck forever:
      
                thread 1 (client)                   thread 2 (server)
      
      connect() to server
      write() returns -EAGAIN
      unix_dgram_poll()
       -> unix_recvq_full() is true
                                             close()
                                              ->unix_release_sock()
                                               ->wake_up_interruptible_all()
      unix_dgram_poll() (due to the
           wake_up_interruptible_all)
       -> unix_recvq_full() still is true
                                               ->free all skbs
      
      Now thread 1 is stuck and will not receive anymore wakeups. In this
      case, when thread 1 gets the -EAGAIN, it has not queued any skbs
      otherwise the 'free all skbs' step would in fact cause a wakeup and
      a POLLOUT return. So the race here is probably fairly rare because
      it means there are no skbs that thread 1 queued and that thread 1
      schedules before the 'free all skbs' step.
      
      This issue was reported as a hang when /dev/log is closed.
      
      The fix is to signal POLLOUT if the socket is marked as SOCK_DEAD, which
      means a subsequent write() will get -ECONNREFUSED.
      Reported-by: NIan Lance Taylor <iant@golang.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NJason Baron <jbaron@akamai.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      51f7e951
    • P
      netfilter: nft_tunnel: fix sparse errors · 483f3fdc
      Pablo Neira Ayuso 提交于
      [...]
      net/netfilter/nft_tunnel.c:117:25:    expected unsigned int [unsigned] [usertype] flags
      net/netfilter/nft_tunnel.c:117:25:    got restricted __be16 [usertype] <noident>
      [...]
      net/netfilter/nft_tunnel.c:246:33:    expected restricted __be16 [addressable] [assigned] [usertype] tp_dst
      net/netfilter/nft_tunnel.c:246:33:    got int
      
      Fixes: af308b94 ("netfilter: nf_tables: add tunnel support")
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      483f3fdc