linux-stable.git/drivers/infiniband, branch v3.2.70

IB/mlx4: Fix WQE LSO segment calculation

2015-08-06T23:32:05+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: Ben Hutchings

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

2015-08-06T23:32:05+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: Ben Hutchings

IB/core: disallow registering 0-sized memory region

2015-08-06T23:32:05+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: Ben Hutchings

IB/core: Avoid leakage from kernel to user space

2015-05-09T22:16:40+00:00

commit 377b513485fd885dea1083a9a5430df65b35e048 upstream.

Clear the reserved field of struct ib_uverbs_async_event_desc which is
copied to user space.

Signed-off-by: Eli Cohen 
Reviewed-by: Yann Droneaud 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings 
Cc: Yann Droneaud

IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic

2015-05-09T22:16:34+00:00

commit 8494057ab5e40df590ef6ef7d66324d3ae33356b upstream.

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
Signed-off-by: Shachar Raindel 
Signed-off-by: Jack Morgenstein 
Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings

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

2015-05-09T22:16:30+00:00

commit 61a3855bb726cbb062ef02a31a832dea455456e0 upstream.

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 
[bwh: Backported to 3.2:
 - Adjust context
 - Open-code U32_MAX]
Signed-off-by: Ben Hutchings

IB/qib: Do not write EEPROM

2015-05-09T22:16:18+00:00

commit 18c0b82a3e4501511b08d0e8676fb08ac08734a3 upstream.

This changeset removes all the code that allows the driver to write to
the EEPROM and update the recorded error counters and power on hours.

These two stats are unused and writing them exposes a timing risk
which could leave the EEPROM in a bad state preventing further normal
operation of the HCA.

Reviewed-by: Mike Marciniszyn 
Signed-off-by: Mitko Haralanov 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Roland Dreier 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

RDMA/iwcm: Use a default listen backlog if needed

2014-09-13T22:41:43+00:00

commit 2f0304d21867476394cd51a54e97f7273d112261 upstream.

If the user creates a listening cm_id with backlog of 0 the IWCM ends
up not allowing any connection requests at all.  The correct behavior
is for the IWCM to pick a default value if the user backlog parameter
is zero.

Lustre from version 1.8.8 onward uses a backlog of 0, which breaks
iwarp support without this fix.

Signed-off-by: Steve Wise 
Signed-off-by: Roland Dreier 
[bwh: Backported to 3.2: use register_net_sysctl_table()]
Signed-off-by: Ben Hutchings

RDMA/cxgb4: Add missing padding at end of struct c4iw_create_cq_resp

2014-07-11T12:33:44+00:00

commit b6f04d3d21458818073a2f5af5339f958864bf71 upstream.

The i386 ABI disagrees with most other ABIs regarding alignment of
data types larger than 4 bytes: on most ABIs a padding must be added
at end of the structures, while it is not required on i386.

So for most ABI struct c4iw_create_cq_resp gets implicitly padded
to be aligned on a 8 bytes multiple, while for i386, such padding
is not added.

The tool pahole can be used to find such implicit padding:

  $ pahole --anon_include \
           --nested_anon_include \
           --recursive \
           --class_name c4iw_create_cq_resp \
           drivers/infiniband/hw/cxgb4/iw_cxgb4.o

Then, structure layout can be compared between i386 and x86_64:

# +++ obj-i386/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt   2014-03-28 11:43:05.547432195 +0100
# --- obj-x86_64/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 10:55:10.990133017 +0100
  @@ -14,9 +13,8 @@ struct c4iw_create_cq_resp {
          __u32                      size;                 /*    28     4 */
          __u32                      qid_mask;             /*    32     4 */

  -       /* size: 36, cachelines: 1, members: 6 */
  -       /* last cacheline: 36 bytes */
  +       /* size: 40, cachelines: 1, members: 6 */
  +       /* padding: 4 */
  +       /* last cacheline: 40 bytes */
   };

This ABI disagreement will make an x86_64 kernel try to write past the
buffer provided by an i386 binary.

When boundary check will be implemented, the x86_64 kernel will refuse
to write past the i386 userspace provided buffer and the uverbs will
fail.

If the structure is on a page boundary and the next page is not
mapped, ib_copy_to_udata() will fail and the uverb will fail.

This patch adds an explicit padding at end of structure
c4iw_create_cq_resp, and, like 92b0ca7cb149 ("IB/mlx5: Fix stack info
leak in mlx5_ib_alloc_ucontext()"), makes function c4iw_create_cq()
not writting this padding field to userspace. This way, x86_64 kernel
will be able to write struct c4iw_create_cq_resp as expected by
unpatched and patched i386 libcxgb4.

Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com
Fixes: cfdda9d764362 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC")
Fixes: e24a72a3302a6 ("RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()")
Cc: Dan Carpenter 
Signed-off-by: Yann Droneaud 
Acked-by: Steve Wise 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings

RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()

2014-07-11T12:33:44+00:00

commit e24a72a3302a638d4c6e77f0b40c45cc61c3f089 upstream.

There is a four byte hole at the end of the "uresp" struct after the
->qid_mask member.

Signed-off-by: Dan Carpenter 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings