linux-stable.git/drivers, branch v3.18.52

dm ioctl: prevent stack leak in dm ioctl call

2017-05-08T05:44:13+00:00

commit 4617f564c06117c7d1b611be49521a4430042287 upstream.

When calling a dm ioctl that doesn't process any data
(IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct
dm_ioctl are left initialized.  Current code is incorrectly extending
the size of data copied back to user, causing the contents of kernel
stack to be leaked to user.  Fix by only copying contents before data
and allow the functions processing the ioctl to override.

Signed-off-by: Adrian Salido 
Reviewed-by: Alasdair G Kergon 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

e1000e: fix call to do_div() to use u64 arg

2017-05-08T05:44:12+00:00

commit 30544af5483755b11bb5924736e9e0b45ef0644a upstream.

We were using s64 for lat_ns (latency nano-second value) since in
our calculations a negative value could be a resultant.  For negative
values, we then assign lat_ns to be zero, so the value passed to
do_div() was never negative, but do_div() expects the argument type
to be u64, so do a cast to resolve a compile warning seen on
PowerPC.

CC: Yanjiang Jin 
CC: Yanir Lubetkin 
Reported-by: Yanjiang Jin 
Signed-off-by: Jeff Kirsher 
Tested-by: Aaron Brown 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

cpumask_set_cpu_local_first => cpumask_local_spread, lament

2017-05-08T05:44:12+00:00

commit f36963c9d3f6f415732710da3acdd8608a9fa0e5 upstream.

da91309e0a7e (cpumask: Utility function to set n'th cpu...) created a
genuinely weird function.  I never saw it before, it went through DaveM.
(He only does this to make us other maintainers feel better about our own
mistakes.)

cpumask_set_cpu_local_first's purpose is say "I need to spread things
across N online cpus, choose the ones on this numa node first"; you call
it in a loop.

It can fail.  One of the two callers ignores this, the other aborts and
fails the device open.

It can fail in two ways: allocating the off-stack cpumask, or through a
convoluted codepath which AFAICT can only occur if cpu_online_mask
changes.  Which shouldn't happen, because if cpu_online_mask can change
while you call this, it could return a now-offline cpu anyway.

It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
drawn to my attention by Geert, who said this causes a warning on Sparc.
It sets a single bit in a cpumask instead of returning a cpu number,
because that's what the callers want.

It could be made more efficient by passing the previous cpu rather than
an index, but that would be more invasive to the callers.

[backporting for 3.18: only two callers exist, otherwise no change.
 The same warning shows up for "!cpumask_of_node()", and I thought
 about just addressing the warning, but using the whole fix seemed
 better in the end as one of the two callers also lacks the error
 handling]

Fixes: da91309e0a7e8966d916a74cce42ed170fde06bf
Signed-off-by: Rusty Russell  (then rebased)
Tested-by: Amir Vadai 
Acked-by: Amir Vadai 
Acked-by: David S. Miller 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

scsi: advansys: remove #warning message

2017-05-08T05:44:12+00:00

The advansys driver was converted to the proper DMA API in linux-4.2, but
the 3.18-stable kernel still warns about this:

drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not properly converted to the DMA API [-Wcpp]

The warning clearly is not helpful in 3.18 any more, it just clutters up
the build log. This removes the warning instead, and clarifies the
comment above it.

Cc: Hannes Reinecke 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

i2o: hide unsafe ioctl on 64-bit

2017-05-08T05:44:12+00:00

We get a warning about a broken pointer conversion on 64-bit architectures:

drivers/message/i2o/i2o_config.c: In function 'i2o_cfg_passthru':
drivers/message/i2o/i2o_config.c:893:19: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
         (p->virt, (void __user *)sg[i].addr_bus,
                   ^
drivers/message/i2o/i2o_config.c:953:10: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
         ((void __user *)sg[j].addr_bus, sg_list[j].virt,
          ^

This has clearly never worked right, so we can add an #ifdef around the code.
The driver was moved to staging in linux-4.0 and finally removed in 4.2,
so upstream does not have a fix for it.

The driver originally got this mostly right, though probably by accident.

Fixes: f4c2c15b930b ("[PATCH] Convert i2o to compat_ioctl")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

staging: unisys: correctly handle return value from queue_delayed_work()

2017-05-08T05:44:12+00:00

commit f84bd6267d623b49f196d54ba9edc41ff1c4d5e3 upstream.

Properly handle the return value from queue_delayed_work() - it's a
bool, not an int, so using a less than comparison isn't appropriate.

This mistake was found by David Binderman .

[arnd: the fix is from 4.4 but needed some minor fixup to adapt
 to context changes]

Signed-off-by: Benjamin Romer 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Arnd Bergmann

mISDN: avoid arch specific __builtin_return_address call

2017-05-08T05:44:11+00:00

commit 3e7a8716e20b759eec0ad88145255bb33174f0c8 upstream.

Not all architectures are able to call __builtin_return_address().
On ARM, the mISDN code produces this warning:

hardware/mISDN/w6692.c: In function 'w6692_dctrl':
hardware/mISDN/w6692.c:1181:75: warning: unsupported argument to '__builtin_return_address'
  pr_debug("%s: %s dev(%d) open from %p\n", card->name, __func__,
                                                                           ^
hardware/mISDN/mISDNipac.c: In function 'open_dchannel':
hardware/mISDN/mISDNipac.c:759:75: warning: unsupported argument to '__builtin_return_address'
  pr_debug("%s: %s dev(%d) open from %p\n", isac->name, __func__,
                                                                           ^

In a lot of cases, this is relatively easy to work around by
passing the value of __builtin_return_address(0) from the
callers into the functions that want it. One exception is
the indirect 'open' function call in struct isac_hw. While it
would be possible to fix this as well, this patch only addresses
the other callers properly and lets this one return the direct
parent function, which should be good enough.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ips: remove pointless #warning

2017-05-08T05:44:11+00:00

commit e03c2da6574223081b786960e39c1e5ecf5d492d upstream.

non-x86 builds want the #warning in the IPS code about compiling on the wrong
architecture removed because it keeps triggering on their platforms build
farms.  Transform from a compile time warning into a runtime one with taint to
preserve the original intent of the authors.

Acked-by: Arnd Bergmann 
Signed-off-by: James Bottomley 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

infiniband: mlx5: avoid a compile-time warning

2017-05-08T05:44:11+00:00

commit 7835bfb5261501590a508b3de3379e2231cb4853 upstream.

The return type of find_first_bit() is architecture specific,
on ARM it is 'unsigned int', while the asm-generic code used
on x86 and a lot of other architectures returns 'unsigned long'.

When building the mlx5 driver on ARM, we get a warning about
this:

infiniband/hw/mlx5/mem.c: In function 'mlx5_ib_cont_pages':
infiniband/hw/mlx5/mem.c:84:143: warning: comparison of distinct pointer types lacks a cast
     m = min(m, find_first_bit(&tmp, sizeof(tmp)));

This patch changes the driver to use min_t to make it behave
the same way on all architectures.

Signed-off-by: Arnd Bergmann 
Acked-by: Eli Cohen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tty/isicom: fix big-endian compile warning

2017-05-08T05:44:11+00:00

commit f3e2d56dce47dbd0bb3f69f84741b439542fef37 upstream.

Building an arm allmodconfig kernel triggers a lengthy but harmless
warning in the isicom driver:

drvers/tty/isicom.c: In function 'isicom_send_break':
uapi/linux/swab.h:13:15: warning: integer overflow in expression [-Woverflow]
  (((__u16)(x) & (__u16)0x00ffU) << 8) |   \
               ^
uapi/linux/swab.h:107:2: note: in expansion of macro '___constant_swab16'
  ___constant_swab16(x) :   \
  ^
uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro '__swab16'
 #define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
                                           ^
linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le16'
 #define cpu_to_le16 __cpu_to_le16
                     ^
include/asm/io.h:270:6: note: in expansion of macro 'cpu_to_le16'
      cpu_to_le16(v),__io(p)); })
      ^
drivers/tty/isicom.c:1058:2: note: in expansion of macro 'outw'
  outw((length & 0xff00), base);
  ^

Apparently, the problem is related to the fact that the value 0xff00,
when used as a 16-bit number, is negative and passed into bitwise
operands of the generic byte swapping code.

Marking the input argument as unsigned in both technically correct
and avoids the warning.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman