linux-stable.git/drivers/infiniband, branch v4.0.4

RDMA/CMA: Canonize IPv4 on IPV6 sockets properly

2015-05-17T16:55:06+00:00

commit 285214409a9e5fceba2215461b4682b6069d8e77 upstream.

When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to
canonize the address family to IPv4, but does not properly process
the listening sockaddr to get the listening port, and does not properly
set the address family of the canonized sockaddr.

Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager")

Reported-By: Yotam Kenneth 
Signed-off-by: Jason Gunthorpe 
Tested-by: Haggai Eran 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/iser: Fix wrong calculation of protection buffer length

2015-05-06T20:04:01+00:00

commit a065fe6aa25ba6ba93c02dc13486131bb3c64d5f upstream.

This length miss-calculation may cause a silent data corruption
in the DIX case and cause the device to reference unmapped area.

Fixes: d77e65350f2d ('libiscsi, iser: Adjust data_length to include protection information')
Signed-off-by: Sagi Grimberg 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/mlx4: Fix WQE LSO segment calculation

2015-05-06T20:04:01+00:00

commit ca9b590caa17bcbbea119594992666e96cde9c2f upstream.

The current code decreases from the mss size (which is the gso_size
from the kernel skb) the size of the packet headers.

It shouldn't do that because the mss that comes from the stack
(e.g IPoIB) includes only the tcp payload without the headers.

The result is indication to the HW that each packet that the HW sends
is smaller than what it could be, and too many packets will be sent
for big messages.

An easy way to demonstrate one more aspect of the problem is by
configuring the ipoib mtu to be less than 2*hlen (2*56) and then
run app sending big TCP messages. This will tell the HW to send packets
with giant (negative value which under unsigned arithmetics becomes
a huge positive one) length and the QP moves to SQE state.

Fixes: b832be1e4007 ('IB/mlx4: Add IPoIB LSO support')
Reported-by: Matthew Finlay 
Signed-off-by: Erez Shitrit 
Signed-off-by: Or Gerlitz 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/core: don't disallow registering region starting at 0x0

2015-05-06T20:04:01+00:00

commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 upstream.

In a call to ib_umem_get(), if address is 0x0 and size is
already page aligned, check added in commit 8494057ab5e4
("IB/uverbs: Prevent integer overflow in ib_umem_get address
arithmetic") will refuse to register a memory region that
could otherwise be valid (provided vm.mmap_min_addr sysctl
and mmap_low_allowed SELinux knobs allow userspace to map
something at address 0x0).

This patch allows back such registration: ib_umem_get()
should probably don't care of the base address provided it
can be pinned with get_user_pages().

There's two possible overflows, in (addr + size) and in
PAGE_ALIGN(addr + size), this patch keep ensuring none
of them happen while allowing to pin memory at address
0x0. Anyway, the case of size equal 0 is no more (partially)
handled as 0-length memory region are disallowed by an
earlier check.

Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com
Cc: Shachar Raindel 
Cc: Jack Morgenstein 
Cc: Or Gerlitz 
Signed-off-by: Yann Droneaud 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Haggai Eran 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/core: disallow registering 0-sized memory region

2015-05-06T20:04:01+00:00

commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 upstream.

If ib_umem_get() is called with a size equal to 0 and an
non-page aligned address, one page will be pinned and a
0-sized umem will be returned to the caller.

This should not be allowed: it's not expected for a memory
region to have a size equal to 0.

This patch adds a check to explicitly refuse to register
a 0-sized region.

Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com
Cc: Shachar Raindel 
Cc: Jack Morgenstein 
Cc: Or Gerlitz 
Signed-off-by: Yann Droneaud 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

iser-target: Fix possible deadlock in RDMA_CM connection error

2015-05-06T20:03:53+00:00

commit 4a579da2586bd3b79b025947ea24ede2bbfede62 upstream.

Before we reach to connection established we may get an
error event. In this case the core won't teardown this
connection (never established it), so we take care of freeing
it ourselves.

Signed-off-by: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

iser-target: Fix session hang in case of an rdma read DIF error

2015-05-06T20:03:53+00:00

commit 364189f0ada5478e4faf8a552d6071a650d757cd upstream.

This hang was a result of a missing command put when
a DIF error occurred during a rdma read (and we sent
an CHECK_CONDITION error without passing it to the
backend).

Signed-off-by: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic

2015-04-02T16:53:59+00:00

Properly verify that the resulting page aligned end address is larger
than both the start address and the length of the memory area requested.

Both the start and length arguments for ib_umem_get are controlled by
the user. A misbehaving user can provide values which will cause an
integer overflow when calculating the page aligned end address.

This overflow can cause also miscalculation of the number of pages
mapped, and additional logic issues.

Addresses: CVE-2014-8159
Cc: 
Signed-off-by: Shachar Raindel 
Signed-off-by: Jack Morgenstein 
Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier

IB/mlx4: Saturate RoCE port PMA counters in case of overflow

2015-03-18T19:17:11+00:00

For RoCE ports, we set the u32 PMA values based on u64 HCA counters. In case of
overflow, according to the IB spec, we have to saturate a counter to its
max value, do that.

Fixes: c37791349cc7 ('IB/mlx4: Support PMA counters for IBoE')
Signed-off-by: Majd Dibbiny 
Signed-off-by: Eran Ben Elisha 
Signed-off-by: Hadar Hen Zion 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller

IB/mlx4: Verify net device validity on port change event

2015-03-18T19:17:11+00:00

Processing an event is done in a different context from the one when
the event was dispatched. This requires a check that the slave
net device is still valid when the event is being processed. The check is done
under the iboe lock which ensure correctness.

Fixes: a57500903093 ('IB/mlx4: Add port aggregation support')
Signed-off-by: Moni Shoua 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller