linux-stable.git/drivers, branch v4.1.36

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

2016-11-26T03:57:03+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-26T03:57:03+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-26T03:57:03+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

md: be careful not lot leak internal curr_resync value into metadata. -- (all)

2016-11-26T03:57:03+00:00

[ Upstream commit 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 ]

mddev->curr_resync usually records where the current resync is up to,
but during the starting phase it has some "magic" values.

 1 - means that the array is trying to start a resync, but has yielded
     to another array which shares physical devices, and also needs to
     start a resync
 2 - means the array is trying to start resync, but has found another
     array which shares physical devices and has already started resync.

 3 - means that resync has commensed, but it is possible that nothing
     has actually been resynced yet.

It is important that this value not be visible to user-space and
particularly that it doesn't get written to the metadata, as the
resync or recovery checkpoint.  In part, this is because it may be
slightly higher than the correct value, though this is very rare.
In part, because it is not a multiple of 4K, and some devices only
support 4K aligned accesses.

There are two places where this value is propagates into either
->curr_resync_completed or ->recovery_cp or ->recovery_offset.
These currently avoid the propagation of values 1 and 3, but will
allow 3 to leak through.

Change them to only propagate the value if it is > 3.

As this can cause an array to fail, the patch is suitable for -stable.

Cc: stable@vger.kernel.org (v3.7+)
Reported-by: Viswesh 
Signed-off-by: NeilBrown 
Signed-off-by: Shaohua Li 
Signed-off-by: Sasha Levin

md: sync sync_completed has correct value as recovery finishes.

2016-11-26T03:57:03+00:00

[ Upstream commit 5ed1df2eacc0ba92c8c7e2499c97594b5ef928a8 ]

There can be a small window between the moment that recovery
actually writes the last block and the time when various sysfs
and /proc/mdstat attributes report that it has finished.
During this time, 'sync_completed' can have the wrong value.
This can confuse monitoring software.

So:
 - don't set curr_resync_completed beyond the end of the devices,
 - set it correctly when resync/recovery has completed.

Signed-off-by: NeilBrown 
Signed-off-by: Sasha Levin

scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware

2016-11-26T03:57:03+00:00

[ Upstream commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f ]

The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller
firmware. Depending on how drive caches are handled internally by
controller firmware this could potentially lead to data integrity
problems.

Ensure that cache flushes are passed to the controller.

[mkp: applied by hand and removed unused vars]

Cc: 
Signed-off-by: Ching Huang 
Reported-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded

2016-11-26T03:57:03+00:00

[ Upstream commit 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d ]

map_storep was not being vfree()'d in the module_exit call.

Cc: 
Signed-off-by: Ewan D. Milne 
Reviewed-by: Laurence Oberman 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

drm/radeon/si_dpm: workaround for SI kickers

2016-11-26T03:57:03+00:00

[ Upstream commit 7dc86ef5ac91642dfc3eb93ee0f0458e702a343e ]

Consolidate existing quirks. Fixes stability issues
on some kickers.

Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/dp/mst: Check peer device type before attempting EDID read

2016-11-26T03:57:03+00:00

[ Upstream commit 4da5caa6a6f82cda3193bca855235b87debf78bd ]

Only certain types of pdts have the DDC bus registered, so check for
that before we attempt the EDID read. Othwewise we risk playing around
with an i2c adapter that doesn't actually exist.

Cc: stable@vger.kernel.org
Cc: Carlos Santa 
Cc: Kirill A. Shutemov 
Tested-by: Carlos Santa 
Tested-by: Kirill A. Shutemov 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666
Signed-off-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-5-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Sasha Levin

drm/dp/mst: add some defines for logical/physical ports

2016-11-26T03:57:02+00:00

[ Upstream commit ccf03d6995fa4b784f5b987726ba98f4859bf326 ]

This just removes the magic number.

Acked-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin