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

scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer()

2016-12-23T15:39:29+00:00

[ Upstream commit 7bc2b55a5c030685b399bb65b6baa9ccc3d1f167 ]

We need to put an upper bound on "user_len" so the memcpy() doesn't
overflow.

Cc: 
Reported-by: Marco Grassi 
Signed-off-by: Dan Carpenter 
Reviewed-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

can: dev: fix deadlock reported after bus-off

2016-12-23T14:41:16+00:00

[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] https://github.com/victronenergy/venus/issues/24

Signed-off-by: Sergei Miroshnichenko 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Sasha Levin

mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl

2016-12-23T14:41:05+00:00

[ Upstream commit f6d7c1b5598b6407c3f1da795dd54acf99c1990c ]

This fixes subpage writes when using 4-bit HW ECC.

There has been numerous reports about ECC errors with devices using this
driver for a while.  Also the 4-bit ECC has been reported as broken with
subpages in [1] and with 16 bits NANDs in the driver and in mach* board
files both in mainline and in the vendor BSPs.

What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to
try reinitializing the ECC engine:
- R/W on whole pages properly generates/checks RS code
- try writing the 1st subpage only of a blank page, the subpage is well
  written and the RS code properly generated, re-reading the same page
  the HW detects some ECC error, reading the same page again no ECC
  error is detected

Note that the ECC engine is already reinitialized in the 1-bit case.

Tested on my LCDK with UBI+UBIFS using subpages.
This could potentially get rid of the issue workarounded in [1].

[1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand")

Fixes: 6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage")
Cc: 
Signed-off-by: Karl Beldan 
Acked-by: Boris Brezillon 
Signed-off-by: Brian Norris 
Signed-off-by: Sasha Levin

drm/msm: fix use of copy_from_user() while holding spinlock

2016-12-23T14:40:55+00:00

[ Upstream commit 89f82cbb0d5c0ab768c8d02914188aa2211cd2e3 ]

Use instead __copy_from_user_inatomic() and fallback to slow-path where
we drop and re-aquire the lock in case of fault.

Cc: stable@vger.kernel.org
Reported-by: Vaishali Thakkar 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin

bus: arm-ccn: Fix PMU handling of MN

2016-12-23T14:40:49+00:00

[ Upstream commit 4e486cba285ff06a1f28f0fc2991dde1482d1dcf ]

The "Miscellaneous Node" fell through cracks of node initialisation,
as its ID is shared with HN-I.

This patch treats MN as a special case (which it is), adding separate
validation check for it and pre-defining the node ID in relevant events
descriptions. That way one can simply run:

	# perf stat -a -e ccn/mn_ecbarrier/ 

Additionally, direction in the MN pseudo-events XP watchpoint
definitions is corrected to be "TX" (1) as they are defined from the
crosspoint point of view (thus barriers are transmitted from XP to MN).

Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Pawel Moll 
Signed-off-by: Sasha Levin

bus: arm-ccn: Provide required event arguments

2016-12-23T14:40:28+00:00

[ Upstream commit 8f06c51fac1ca4104b8b64872f310e28186aea42 ]

Since 688d4dfcdd624192cbf03c08402e444d1d11f294 "perf tools: Support
parsing parameterized events" the perf userspace tools understands
"argument=?" syntax in the events file, making sure that required
arguments are provided by the user and not defaulting to 0, causing
confusion.

This patch adds the required arguments lists for CCN events.

Signed-off-by: Pawel Moll 
Signed-off-by: Sasha Levin

scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression

2016-12-02T15:17:05+00:00

[ Upstream commit 5e5ec1759dd663a1d5a2f10930224dd009e500e8 ]

This patch will fix regression caused by commit 1e793f6fc0db ("scsi:
megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices").

The problem was that the MEGASAS_IS_LOGICAL macro did not have braces
and as a result the driver ended up exposing a lot of non-existing SCSI
devices (all SCSI commands to channels 1,2,3 were returned as
SUCCESS-DID_OK by driver).

[mkp: clarified patch description]

Fixes: 1e793f6fc0db920400574211c48f9157a37e3945
Reported-by: Jens Axboe 
CC: stable@vger.kernel.org
Signed-off-by: Kashyap Desai 
Signed-off-by: Sumit Saxena 
Tested-by: Sumit Saxena 
Reviewed-by: Tomas Henzl 
Tested-by: Jens Axboe 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

firewire: net: fix fragmented datagram_size off-by-one

2016-11-24T04:09:35+00:00

[ Upstream commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f ]

RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:

    datagram_size:  The encoded size of the entire IP datagram.  The
    value of datagram_size [...] SHALL be one less than the value of
    Total Length in the datagram's IP header (see STD 5, RFC 791).

Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:

    ether1394_tx() /* transmit */
        ether1394_encapsulate_prep()
            hdr->ff.dg_size = dg_size - 1;

    ether1394_data_handler() /* receive */
        if (hdr->common.lf == ETH1394_HDR_LF_FF)
            dg_size = hdr->ff.dg_size + 1;
        else
            dg_size = hdr->sf.dg_size + 1;

Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.

Only firewire-net sets and gets datagram_size without this offset.  The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394.  (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
  - from OS X fail entirely,
  - from Win XP start out with a bunch of fragmented datagrams which
    time out, then continue with unfragmented datagrams because Win XP
    temporarily reduces the MTU to 576 bytes.

So let's fix firewire-net's datagram_size accessors.

Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed.  (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)

Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter 
Signed-off-by: Sasha Levin

firewire: net: guard against rx buffer overflows

2016-11-24T04:09:29+00:00

[ Upstream commit 667121ace9dbafb368618dbabcf07901c962ddac ]

The IP-over-1394 driver firewire-net lacked input validation when
handling incoming fragmented datagrams.  A maliciously formed fragment
with a respectively large datagram_offset would cause a memcpy past the
datagram buffer.

So, drop any packets carrying a fragment with offset + length larger
than datagram_size.

In addition, ensure that
  - GASP header, unfragmented encapsulation header, or fragment
    encapsulation header actually exists before we access it,
  - the encapsulated datagram or fragment is of nonzero size.

Reported-by: Eyal Itkin 
Reviewed-by: Eyal Itkin 
Fixes: CVE 2016-8633
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter 
Signed-off-by: Sasha Levin

virtio: console: Unlock vqs while freeing buffers

2016-11-24T04:09:12+00:00

[ Upstream commit 34563769e438d2881f62cf4d9badc4e589ac0ec0 ]

Commit c6017e793b93 ("virtio: console: add locks around buffer removal
in port unplug path") added locking around the freeing of buffers in the
vq. However, when free_buf() is called with can_sleep = true and rproc
is enabled, it calls dma_free_coherent() directly, requiring interrupts
to be enabled. Currently a WARNING is triggered due to the spin locking
around free_buf, with a call stack like this:

WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
free_buf+0x1a8/0x288
Call Trace:
[<8040c538>] show_stack+0x74/0xc0
[<80757240>] dump_stack+0xd0/0x110
[<80430d98>] __warn+0xfc/0x130
[<80430ee0>] warn_slowpath_null+0x2c/0x3c
[<807e7c6c>] free_buf+0x1a8/0x288
[<807ea590>] remove_port_data+0x50/0xac
[<807ea6a0>] unplug_port+0xb4/0x1bc
[<807ea858>] virtcons_remove+0xb0/0xfc
[<807b6734>] virtio_dev_remove+0x58/0xc0
[<807f918c>] __device_release_driver+0xac/0x134
[<807f924c>] device_release_driver+0x38/0x50
[<807f7edc>] bus_remove_device+0xfc/0x130
[<807f4b74>] device_del+0x17c/0x21c
[<807f4c38>] device_unregister+0x24/0x38
[<807b6b50>] unregister_virtio_device+0x28/0x44

Fix this by restructuring the loops to allow the locks to only be taken
where it is necessary to protect the vqs, and release it while the
buffer is being freed.

Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path")
Cc: stable@vger.kernel.org
Signed-off-by: Matt Redfearn 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin