Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 25 2月, 2017 6 次提交
  3. 20 2月, 2017 2 次提交
    • A
      Fix missing sanity check in /dev/sg · 137d01df
      由 Al Viro 提交于 
      What happens is that a write to /dev/sg is given a request with non-zero
->iovec_count combined with zero ->dxfer_len.  Or with ->dxferp pointing
to an array full of empty iovecs.

Having write permission to /dev/sg shouldn't be equivalent to the
ability to trigger BUG_ON() while holding spinlocks...

Found by Dmitry Vyukov and syzkaller.

[ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the
  underlying issue.  - Linus ]
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      137d01df
    • J
      scsi: don't BUG_ON() empty DMA transfers · fd3fc0b4
      由 Johannes Thumshirn 提交于 
      Don't crash the machine just because of an empty transfer. Use WARN_ON()
combined with returning an error.

Found by Dmitry Vyukov and syzkaller.

[ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root
  cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON()
  might still be a cause of excessive log spamming.

  NOTE! If this warning ever triggers, we may end up leaking resources,
  since this doesn't bother to try to clean the command up. So this
  WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is
  much worse.

  People really need to stop using BUG_ON() for "this shouldn't ever
  happen". It makes pretty much any bug worse.     - Linus ]
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Cc: James Bottomley <jejb@linux.vnet.ibm.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fd3fc0b4
  5. 18 2月, 2017 2 次提交
    • P
      vxlan: fix oops in dev_fill_metadata_dst · 22f0708a
      由 Paolo Abeni 提交于 
      Since the commit 0c1d70af ("net: use dst_cache for vxlan device")
vxlan_fill_metadata_dst() calls vxlan_get_route() passing a NULL
dst_cache pointer, so the latter should explicitly check for
valid dst_cache ptr. Unfortunately the commit d71785ff ("net: add
dst_cache to ovs vxlan lwtunnel") removed said check.

As a result is possible to trigger a null pointer access calling
vxlan_fill_metadata_dst(), e.g. with:

ovs-vsctl add-br ovs-br0
ovs-vsctl add-port ovs-br0 vxlan0 -- set interface vxlan0 \
	type=vxlan options:remote_ip=192.168.1.1 \
	options:key=1234 options:dst_port=4789 ofport_request=10
ip address add dev ovs-br0 172.16.1.2/24
ovs-vsctl set Bridge ovs-br0 ipfix=@i -- --id=@i create IPFIX \
	targets=\"172.16.1.1:1234\" sampling=1
iperf -c 172.16.1.1 -u -l 1000 -b 10M -t 1 -p 1234

This commit addresses the issue passing to vxlan_get_route() the
dst_cache already available into the lwt info processed by
vxlan_fill_metadata_dst().

Fixes: d71785ff ("net: add dst_cache to ovs vxlan lwtunnel")
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Acked-by: NJiri Benc <jbenc@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22f0708a
    • D
      dpaa_eth: small leak on error · 785f3577
      由 Dan Carpenter 提交于 
      This should be >= instead of > here.  It means that we don't increment
the free count enough so it becomes off by one.

Fixes: 9ad1a374 ("dpaa_eth: add support for DPAA Ethernet")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      785f3577
  7. 17 2月, 2017 6 次提交
  9. 16 2月, 2017 4 次提交
    • T
      ibmvnic: Fix endian errors in error reporting output · 75224c93
      由 Thomas Falcon 提交于 
      Error reports received from firmware were not being converted from
big endian values, leading to bogus error codes reported on little
endian systems.
Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75224c93
    • T
      ibmvnic: Fix endian error when requesting device capabilities · 28f4d165
      由 Thomas Falcon 提交于 
      When a vNIC client driver requests a faulty device setting, the
server returns an acceptable value for the client to request.
This 64 bit value was incorrectly being swapped as a 32 bit value,
resulting in loss of data. This patch corrects that by using
the 64 bit swap function.
Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28f4d165
    • A
      net: xilinx_emaclite: fix freezes due to unordered I/O · acf138f1
      由 Anssi Hannula 提交于 
      The xilinx_emaclite uses __raw_writel and __raw_readl for register
accesses. Those functions do not imply any kind of memory barriers and
they may be reordered.

The driver does not seem to take that into account, though, and the
driver does not satisfy the ordering requirements of the hardware.
For clear examples, see xemaclite_mdio_write() and xemaclite_mdio_read()
which try to set MDIO address before initiating the transaction.

I'm seeing system freezes with the driver with GCC 5.4 and current
Linux kernels on Zynq-7000 SoC immediately when trying to use the
interface.

In commit 123c1407 ("net: emaclite: Do not use microblaze and ppc
IO functions") the driver was switched from non-generic
in_be32/out_be32 (memory barriers, big endian) to
__raw_readl/__raw_writel (no memory barriers, native endian), so
apparently the device follows system endianness and the driver was
originally written with the assumption of memory barriers.

Rather than try to hunt for each case of missing barrier, just switch
the driver to use iowrite32/ioread32/iowrite32be/ioread32be depending
on endianness instead.

Tested on little-endian Zynq-7000 ARM SoC FPGA.
Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
Fixes: 123c1407 ("net: emaclite: Do not use microblaze and ppc IO
functions")
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acf138f1
    • A
      net: xilinx_emaclite: fix receive buffer overflow · cd224553
      由 Anssi Hannula 提交于 
      xilinx_emaclite looks at the received data to try to determine the
Ethernet packet length but does not properly clamp it if
proto_type == ETH_P_IP or 1500 < proto_type <= 1518, causing a buffer
overflow and a panic via skb_panic() as the length exceeds the allocated
skb size.

Fix those cases.

Also add an additional unconditional check with WARN_ON() at the end.
Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
Fixes: bb81b2dd ("net: add Xilinx emac lite device driver")
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd224553
  11. 15 2月, 2017 8 次提交
  13. 14 2月, 2017 3 次提交
  15. 13 2月, 2017 1 次提交
  17. 12 2月, 2017 2 次提交
  19. 11 2月, 2017 3 次提交
  21. 10 2月, 2017 3 次提交