6 years agoext4: add sanity checking to count_overhead()
Theodore Ts'o [Fri, 18 Nov 2016 18:37:47 +0000 (13:37 -0500)]
ext4: add sanity checking to count_overhead()

commit c48ae41bafe31e9a66d8be2ced4e42a6b57fa814 upstream.

The commit "ext4: sanity check the block and cluster size at mount
time" should prevent any problems, but in case the superblock is
modified while the file system is mounted, add an extra safety check
to make sure we won't overrun the allocated buffer.

Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: use more strict checks for inodes_per_block on mount
Theodore Ts'o [Fri, 18 Nov 2016 18:28:30 +0000 (13:28 -0500)]
ext4: use more strict checks for inodes_per_block on mount

commit cd6bb35bf7f6d7d922509bf50265383a0ceabe96 upstream.

Centralize the checks for inodes_per_block and be more strict to make
sure the inodes_per_block_group can't end up being zero.

Signed-off-by: Theodore Ts'o <>
Reviewed-by: Andreas Dilger <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: fix in-superblock mount options processing
Theodore Ts'o [Fri, 18 Nov 2016 18:24:26 +0000 (13:24 -0500)]
ext4: fix in-superblock mount options processing

commit 5aee0f8a3f42c94c5012f1673420aee96315925a upstream.

Fix a large number of problems with how we handle mount options in the
superblock.  For one, if the string in the superblock is long enough
that it is not null terminated, we could run off the end of the string
and try to interpret superblocks fields as characters.  It's unlikely
this will cause a security problem, but it could result in an invalid
parse.  Also, parse_options is destructive to the string, so in some
cases if there is a comma-separated string, it would be modified in
the superblock.  (Fortunately it only happens on file systems with a
1k block size.)

Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
6 years agossb: Fix error routine when fallback SPROM fails
Larry Finger [Sat, 5 Nov 2016 19:08:57 +0000 (14:08 -0500)]
ssb: Fix error routine when fallback SPROM fails

commit 8052d7245b6089992343c80b38b14dbbd8354651 upstream.

When there is a CRC error in the SPROM read from the device, the code
attempts to handle a fallback SPROM. When this also fails, the driver
returns zero rather than an error code.

Signed-off-by: Larry Finger <>
Signed-off-by: Kalle Valo <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoscsi: mvsas: fix command_active typo
Arnd Bergmann [Wed, 16 Nov 2016 15:08:34 +0000 (16:08 +0100)]
scsi: mvsas: fix command_active typo

commit af15769ffab13d777e55fdef09d0762bf0c249c4 upstream.

gcc-7 notices that the condition in mvs_94xx_command_active looks

drivers/scsi/mvsas/mv_94xx.c: In function 'mvs_94xx_command_active':
drivers/scsi/mvsas/mv_94xx.c:671:15: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context]

This was introduced when the mv_printk() statement got added, and leads
to the condition being ignored. This is probably harmless.

Changing '&&' to '&' makes the code look reasonable, as we check the
command bit before setting and printing it.

Fixes: a4632aae8b66 ("[SCSI] mvsas: Add new macros and functions")
Signed-off-by: Arnd Bergmann <>
Reviewed-by: Johannes Thumshirn <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
6 years agoIB/mlx4: Put non zero value in max_ah device attribute
Maor Gottlieb [Thu, 10 Nov 2016 09:30:58 +0000 (11:30 +0200)]
IB/mlx4: Put non zero value in max_ah device attribute

commit 731e0415b4af3a133d0316e4dc8ef0ea57dc3fdf upstream.

Use INT_MAX since this is the max value the attribute can hold, though
hardware capability is unlimited.

Fixes: 225c7b1feef1 ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters')
Signed-off-by: Maor Gottlieb <>
Signed-off-by: Daniel Jurgens <>
Reviewed-by: Mark Bloch <>
Reviewed-by: Yuval Shaia <>
Signed-off-by: Leon Romanovsky <>
Signed-off-by: Doug Ledford <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoext4: fix stack memory corruption with 64k block size
Chandan Rajendra [Tue, 15 Nov 2016 02:26:26 +0000 (21:26 -0500)]
ext4: fix stack memory corruption with 64k block size

commit 30a9d7afe70ed6bd9191d3000e2ef1a34fb58493 upstream.

The number of 'counters' elements needed in 'struct sg' is
super_block->s_blocksize_bits + 2. Presently we have 16 'counters'
elements in the array. This is insufficient for block sizes >= 32k. In
such cases the memcpy operation performed in ext4_mb_seq_groups_show()
would cause stack memory corruption.

Fixes: c9de560ded61f
Signed-off-by: Chandan Rajendra <>
Signed-off-by: Theodore Ts'o <>
Reviewed-by: Jan Kara <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: fix mballoc breakage with 64k block size
Chandan Rajendra [Tue, 15 Nov 2016 02:04:37 +0000 (21:04 -0500)]
ext4: fix mballoc breakage with 64k block size

commit 69e43e8cc971a79dd1ee5d4343d8e63f82725123 upstream.

'border' variable is set to a value of 2 times the block size of the
underlying filesystem. With 64k block size, the resulting value won't
fit into a 16-bit variable. Hence this commit changes the data type of
'border' to 'unsigned int'.

Fixes: c9de560ded61f
Signed-off-by: Chandan Rajendra <>
Signed-off-by: Theodore Ts'o <>
Reviewed-by: Andreas Dilger <>
Signed-off-by: Ben Hutchings <>
6 years agousb: xhci-mem: use passed in GFP flags instead of GFP_KERNEL
Dan Carpenter [Thu, 10 Nov 2016 19:33:17 +0000 (22:33 +0300)]
usb: xhci-mem: use passed in GFP flags instead of GFP_KERNEL

commit c95a9f83711bf53faeb4ed9bbb63a3f065613dfb upstream.

We normally use the passed in gfp flags for allocations, it's just these
two which were missed.

Fixes: 22d45f01a836 ("usb/xhci: replace pci_*_consistent() with dma_*_coherent()")
Cc: Mathias Nyman <>
Signed-off-by: Dan Carpenter <>
Acked-by: Sebastian Andrzej Siewior <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agopowerpc/pci/rpadlpar: Fix device reference leaks
Johan Hovold [Tue, 1 Nov 2016 15:26:03 +0000 (16:26 +0100)]
powerpc/pci/rpadlpar: Fix device reference leaks

commit 99e5cde5eae78bef95bfe7c16ccda87fb070149b upstream.

Make sure to drop any device reference taken by vio_find_node() when
adding and removing virtual I/O slots.

Fixes: 5eeb8c63a38f ("[PATCH] PCI Hotplug: rpaphp: Move VIO registration")
Signed-off-by: Johan Hovold <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Ben Hutchings <>
6 years agopowerpc/ibmebus: Fix further device reference leaks
Johan Hovold [Tue, 1 Nov 2016 15:26:01 +0000 (16:26 +0100)]
powerpc/ibmebus: Fix further device reference leaks

commit 815a7141c4d1b11610dccb7fcbb38633759824f2 upstream.

Make sure to drop any reference taken by bus_find_device() when creating
devices during init and driver registration.

Fixes: 55347cc9962f ("[POWERPC] ibmebus: Add device creation and bus probing based on of_device")
Signed-off-by: Johan Hovold <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Ben Hutchings <>
6 years agopowerpc/ibmebus: Fix device reference leaks in sysfs interface
Johan Hovold [Tue, 1 Nov 2016 15:26:00 +0000 (16:26 +0100)]
powerpc/ibmebus: Fix device reference leaks in sysfs interface

commit fe0f3168169f7c34c29b0cf0c489f126a7f29643 upstream.

Make sure to drop any reference taken by bus_find_device() in the sysfs
callbacks that are used to create and destroy devices based on
device-tree entries.

Fixes: 6bccf755ff53 ("[POWERPC] ibmebus: dynamic addition/removal of adapters, some code cleanup")
Signed-off-by: Johan Hovold <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Ben Hutchings <>
6 years agocrypto: caam - fix AEAD givenc descriptors
Alex Porosanu [Wed, 9 Nov 2016 08:46:11 +0000 (10:46 +0200)]
crypto: caam - fix AEAD givenc descriptors

commit d128af17876d79b87edf048303f98b35f6a53dbc upstream.

The AEAD givenc descriptor relies on moving the IV through the
output FIFO and then back to the CTX2 for authentication. The
SEQ FIFO STORE could be scheduled before the data can be
read from OFIFO, especially since the SEQ FIFO LOAD needs
to wait for the SEQ FIFO LOAD SKIP to finish first. The
SKIP takes more time when the input is SG than when it's
a contiguous buffer. If the SEQ FIFO LOAD is not scheduled
before the STORE, the DECO will hang waiting for data
to be available in the OFIFO so it can be transferred to C2.
In order to overcome this, first force transfer of IV to C2
by starting the "cryptlen" transfer first and then starting to
store data from OFIFO to the output buffer.

Fixes: 1acebad3d8db8 ("crypto: caam - faster aead implementation")
Signed-off-by: Alex Porosanu <>
Signed-off-by: Horia Geantă <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: UHCI: report non-PME wakeup signalling for Intel hardware
Alan Stern [Fri, 21 Oct 2016 20:49:07 +0000 (16:49 -0400)]
USB: UHCI: report non-PME wakeup signalling for Intel hardware

commit ccdb6be9ec6580ef69f68949ebe26e0fb58a6fb0 upstream.

The UHCI controllers in Intel chipsets rely on a platform-specific non-PME
mechanism for wakeup signalling.  They can generate wakeup signals even
though they don't support PME.

We need to let the USB core know this so that it will enable runtime
suspend for UHCI controllers.

Signed-off-by: Alan Stern <>
Signed-off-by: Bjorn Helgaas <>
Acked-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoPCI: Check for PME in targeted sleep state
Alan Stern [Fri, 21 Oct 2016 20:45:38 +0000 (16:45 -0400)]
PCI: Check for PME in targeted sleep state

commit 6496ebd7edf446fccf8266a1a70ffcb64252593e upstream.

One some systems, the firmware does not allow certain PCI devices to be put
in deep D-states.  This can cause problems for wakeup signalling, if the
device does not support PME# in the deepest allowed suspend state.  For
example, Pierre reports that on his system, ACPI does not permit his xHCI
host controller to go into D3 during runtime suspend -- but D3 is the only
state in which the controller can generate PME# signals.  As a result, the
controller goes into runtime suspend but never wakes up, so it doesn't work
properly.  USB devices plugged into the controller are never detected.

If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately report
that it cannot do wakeup from runtime suspend.  This patch modifies the
pci_dev_run_wake() routine to add this check.

Reported-by: Pierre de Villemereuil <>
Tested-by: Pierre de Villemereuil <>
Signed-off-by: Alan Stern <>
Signed-off-by: Bjorn Helgaas <>
Acked-by: Rafael J. Wysocki <>
CC: Lukas Wunner <>
Signed-off-by: Ben Hutchings <>
6 years agoxfs: fix up xfs_swap_extent_forks inline extent handling
Eric Sandeen [Tue, 8 Nov 2016 01:55:18 +0000 (12:55 +1100)]
xfs: fix up xfs_swap_extent_forks inline extent handling

commit 4dfce57db6354603641132fac3c887614e3ebe81 upstream.

There have been several reports over the years of NULL pointer
dereferences in xfs_trans_log_inode during xfs_fsr processes,
when the process is doing an fput and tearing down extents
on the temporary inode, something like:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
PID: 29439  TASK: ffff880550584fa0  CPU: 6   COMMAND: "xfs_fsr"
    [exception RIP: xfs_trans_log_inode+0x10]
 #9 [ffff8800a57bbbe0] xfs_bunmapi at ffffffffa037398e [xfs]
#10 [ffff8800a57bbce8] xfs_itruncate_extents at ffffffffa0391b29 [xfs]
#11 [ffff8800a57bbd88] xfs_inactive_truncate at ffffffffa0391d0c [xfs]
#12 [ffff8800a57bbdb8] xfs_inactive at ffffffffa0392508 [xfs]
#13 [ffff8800a57bbdd8] xfs_fs_evict_inode at ffffffffa035907e [xfs]
#14 [ffff8800a57bbe00] evict at ffffffff811e1b67
#15 [ffff8800a57bbe28] iput at ffffffff811e23a5
#16 [ffff8800a57bbe58] dentry_kill at ffffffff811dcfc8
#17 [ffff8800a57bbe88] dput at ffffffff811dd06c
#18 [ffff8800a57bbea8] __fput at ffffffff811c823b
#19 [ffff8800a57bbef0] ____fput at ffffffff811c846e
#20 [ffff8800a57bbf00] task_work_run at ffffffff81093b27
#21 [ffff8800a57bbf30] do_notify_resume at ffffffff81013b0c
#22 [ffff8800a57bbf50] int_signal at ffffffff8161405d

As it turns out, this is because the i_itemp pointer, along
with the d_ops pointer, has been overwritten with zeros
when we tear down the extents during truncate.  When the in-core
inode fork on the temporary inode used by xfs_fsr was originally
set up during the extent swap, we mistakenly looked at di_nextents
to determine whether all extents fit inline, but this misses extents
generated by speculative preallocation; we should be using if_bytes

This mistake corrupts the in-memory inode, and code in
xfs_iext_remove_inline eventually gets bad inputs, causing
it to memmove and memset incorrect ranges; this became apparent
because the two values in ifp->if_u2.if_inline_ext[1] contained
what should have been in d_ops and i_itemp; they were memmoved due
to incorrect array indexing and then the original locations
were zeroed with memset, again due to an array overrun.

Fix this by properly using i_df.if_bytes to determine the number
of extents, not di_nextents.

Thanks to dchinner for looking at this with me and spotting the
root cause.

Signed-off-by: Eric Sandeen <>
Reviewed-by: Brian Foster <>
Signed-off-by: Dave Chinner <>
[bwh: Backported to 3.2: adjust filename, indentation]
Signed-off-by: Ben Hutchings <>
6 years agocris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected
Guenter Roeck [Sun, 30 Oct 2016 16:09:18 +0000 (09:09 -0700)]
cris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected

commit 328cf6927bb72cadefddebbc9a23c793108147a2 upstream.

If CONFIG_ETRAX_AXISFLASHMAP is not configured, the flash rescue image
object file is empty. With recent versions of binutils, this results
in the following build error.

cris-linux-objcopy: error:
the input file 'arch/cris/boot/rescue/rescue.o' has no sections

This is seen, for example, when trying to build cris:allnoconfig
with recently generated toolchains.

Since it does not make sense to build a flash rescue image if there is
no flash, only build it if CONFIG_ETRAX_AXISFLASHMAP is enabled.

Reported-by: kbuild test robot <>
Fixes: 66ab3a74c5ce ("CRIS: Merge machine dependent boot/compressed ..")
Signed-off-by: Guenter Roeck <>
Signed-off-by: Jesper Nilsson <>
Signed-off-by: Ben Hutchings <>
6 years agodrm/gma500: Add compat ioctl
Patrik Jakobsson [Tue, 1 Nov 2016 14:43:15 +0000 (15:43 +0100)]
drm/gma500: Add compat ioctl

commit 0a97c81a9717431e6c57ea845b59c3c345edce67 upstream.

Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels.
It turns out that N2600 and N2800 comes with 64-bit enabled. We
previously assumed there where no such systems out there.

Signed-off-by: Patrik Jakobsson <>
Signed-off-by: Sean Paul <>
[bwh: Backported to 3.2: adjust filename, indentation]
Signed-off-by: Ben Hutchings <>
6 years agousb: gadget: composite: correctly initialize ep->maxpacket
Felipe Balbi [Wed, 28 Sep 2016 07:38:11 +0000 (10:38 +0300)]
usb: gadget: composite: correctly initialize ep->maxpacket

commit e8f29bb719b47a234f33b0af62974d7a9521a52c upstream.

usb_endpoint_maxp() returns wMaxPacketSize in its
raw form. Without taking into consideration that it
also contains other bits reserved for isochronous

This patch fixes one occasion where this is a
problem by making sure that we initialize
ep->maxpacket only with lower 10 bits of the value
returned by usb_endpoint_maxp(). Note that seperate
patches will be necessary to audit all call sites of
usb_endpoint_maxp() and make sure that
usb_endpoint_maxp() only returns lower 10 bits of

Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
6 years agoperf scripting: Avoid leaking the scripting_context variable
Arnaldo Carvalho de Melo [Tue, 25 Oct 2016 20:20:47 +0000 (17:20 -0300)]
perf scripting: Avoid leaking the scripting_context variable

commit cf346d5bd4b9d61656df2f72565c9b354ef3ca0d upstream.

Both register_perl_scripting() and register_python_scripting() allocate
this variable, fix it by checking if it already was.

Cc: Adrian Hunter <>
Cc: David Ahern <>
Cc: Frederic Weisbecker <>
Cc: Jiri Olsa <>
Cc: Namhyung Kim <>
Cc: Tom Zanussi <>
Cc: Wang Nan <>
Fixes: 7e4b21b84c43 ("perf/scripts: Add Python scripting engine")
Signed-off-by: Arnaldo Carvalho de Melo <>
Signed-off-by: Ben Hutchings <>
6 years agoite-cir: initialize use_demodulator before using it
Nicolas Iooss [Sat, 10 Sep 2016 16:59:49 +0000 (13:59 -0300)]
ite-cir: initialize use_demodulator before using it

commit 7ec03e60ef81c19b5d3a46dd070ee966774b860f upstream.

Function ite_set_carrier_params() uses variable use_demodulator after
having initialized it to false in some if branches, but this variable is
never set to true otherwise.

This bug has been found using clang -Wsometimes-uninitialized warning

Fixes: 620a32bba4a2 ("[media] rc: New rc-based ite-cir driver for
several ITE CIRs")

Signed-off-by: Nicolas Iooss <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Ben Hutchings <>
6 years agonet/sched: em_meta: Fix 'meta vlan' to correctly recognize zero VID frames
Shmulik Ladkani [Thu, 20 Oct 2016 21:18:08 +0000 (00:18 +0300)]
net/sched: em_meta: Fix 'meta vlan' to correctly recognize zero VID frames

commit d65f2fa680d6f91438461df54c83a331b3a631c9 upstream.

META_COLLECTOR int_vlan_tag() assumes that if the accel tag (vlan_tci)
is zero, then no vlan accel tag is present.

This is incorrect for zero VID vlan accel packets, making the following
match fail:
  tc filter add ... basic match 'meta(vlan mask 0xfff eq 0)' ...

Apparently 'int_vlan_tag' was implemented prior VLAN_TAG_PRESENT was
introduced in 05423b2 "vlan: allow null VLAN ID to be used"
(and at time introduced, the 'vlan_tx_tag_get' call in em_meta was not

Fix, testing skb_vlan_tag_present instead of testing skb_vlan_tag_get's

Fixes: 05423b2413 ("vlan: allow null VLAN ID to be used")
Fixes: 1a31f2042e ("netsched: Allow meta match on vlan tag on receive")

Signed-off-by: Shmulik Ladkani <>
Cc: Eric Dumazet <>
Cc: Stephen Hemminger <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: s/skb_vlan_tag/vlan_tx_tag/]
Signed-off-by: Ben Hutchings <>
6 years agostaging: iio: ad7606: fix improper setting of oversampling pins
Eva Rachel Retuya [Sat, 8 Oct 2016 16:05:39 +0000 (00:05 +0800)]
staging: iio: ad7606: fix improper setting of oversampling pins

commit b321a38d2407c7e425c54bc09be909a34e49f740 upstream.

The oversampling ratio is controlled using the oversampling pins,
OS [2:0] with OS2 being the MSB control bit, and OS0 the LSB control

The gpio connected to the OS2 pin is not being set correctly, only OS0
and OS1 pins are being set. Fix the typo to allow proper control of the
oversampling pins.

Signed-off-by: Eva Rachel Retuya <>
Fixes: b9618c0 ("staging: IIO: ADC: New driver for AD7606/AD7606-6/AD7606-4")
Acked-by: Lars-Peter Clausen <>
Signed-off-by: Jonathan Cameron <>
Signed-off-by: Ben Hutchings <>
6 years agoLinux 3.2.86 v3.2.86
Ben Hutchings [Sun, 26 Feb 2017 20:01:33 +0000 (20:01 +0000)]
Linux 3.2.86

6 years agotcp: avoid infinite loop in tcp_splice_read()
Eric Dumazet [Fri, 3 Feb 2017 22:59:38 +0000 (14:59 -0800)]
tcp: avoid infinite loop in tcp_splice_read()

commit ccf7abb93af09ad0868ae9033d1ca8108bdaec82 upstream.

Splicing from TCP socket is vulnerable when a packet with URG flag is
received and stored into receive queue.

__tcp_splice_read() returns 0, and sk_wait_data() immediately
returns since there is the problematic skb in queue.

This is a nice way to burn cpu (aka infinite loop) and trigger
soft lockups.

Again, this gem was found by syzkaller tool.

Fixes: 9c55e01c0cc8 ("[TCP]: Splice receive support.")
Signed-off-by: Eric Dumazet <>
Reported-by: Dmitry Vyukov <>
Cc: Willy Tarreau <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agodccp: fix freeing skb too early for IPV6_RECVPKTINFO
Andrey Konovalov [Thu, 16 Feb 2017 16:22:46 +0000 (17:22 +0100)]
dccp: fix freeing skb too early for IPV6_RECVPKTINFO

commit 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 upstream.

In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet
is forcibly freed via __kfree_skb in dccp_rcv_state_process if
dccp_v6_conn_request successfully returns.

However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb
is saved to ireq->pktopts and the ref count for skb is incremented in
dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed
in dccp_rcv_state_process.

Fix by calling consume_skb instead of doing goto discard and therefore
calling __kfree_skb.

Similar fixes for TCP:

fb7e2399ec17f1004c0e0ccfd17439f8759ede01 [TCP]: skb is unexpectedly freed.
0aea76d35c9651d55bbaf746e7914e5f9ae5a25d tcp: SYN packets are now
simply consumed

Signed-off-by: Andrey Konovalov <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: kl5kusb105: fix line-state error handling
Johan Hovold [Tue, 10 Jan 2017 11:05:37 +0000 (12:05 +0100)]
USB: serial: kl5kusb105: fix line-state error handling

commit 146cc8a17a3b4996f6805ee5c080e7101277c410 upstream.

The current implementation failed to detect short transfers when
attempting to read the line state, and also, to make things worse,
logged the content of the uninitialised heap transfer buffer.

Fixes: abf492e7b3ae ("USB: kl5kusb105: fix DMA buffers on stack")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agokvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)
Jim Mattson [Mon, 12 Dec 2016 19:01:37 +0000 (11:01 -0800)]
kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)

commit ef85b67385436ddc1998f45f1d6a210f935b3388 upstream.

When L2 exits to L0 due to "exception or NMI", software exceptions
(#BP and #OF) for which L1 has requested an intercept should be
handled by L1 rather than L0. Previously, only hardware exceptions
were forwarded to L1.

Signed-off-by: Jim Mattson <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoLinux 3.2.85 v3.2.85
Ben Hutchings [Thu, 23 Feb 2017 03:51:07 +0000 (03:51 +0000)]
Linux 3.2.85

6 years agoALSA: pcm : Call kill_fasync() in stream lock
Takashi Iwai [Thu, 14 Apr 2016 16:02:37 +0000 (18:02 +0200)]
ALSA: pcm : Call kill_fasync() in stream lock

commit 3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4 upstream.

Currently kill_fasync() is called outside the stream lock in
snd_pcm_period_elapsed().  This is potentially racy, since the stream
may get released even during the irq handler is running.  Although
snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
guarantee that the irq handler finishes, thus the kill_fasync() call
outside the stream spin lock may be invoked after the substream is
detached, as recently reported by KASAN.

As a quick workaround, move kill_fasync() call inside the stream
lock.  The fasync is rarely used interface, so this shouldn't have a
big impact from the performance POV.

Ideally, we should implement some sync mechanism for the proper finish
of stream and irq handler.  But this oneliner should suffice for most
cases, so far.

Reported-by: Baozeng Ding <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonet: avoid signed overflows for SO_{SND|RCV}BUFFORCE
Eric Dumazet [Fri, 2 Dec 2016 17:44:53 +0000 (09:44 -0800)]
net: avoid signed overflows for SO_{SND|RCV}BUFFORCE

commit b98b0bc8c431e3ceb4b26b0dfc8db509518fb290 upstream.

CAP_NET_ADMIN users should not be allowed to set negative
sk_sndbuf or sk_rcvbuf values, as it can lead to various memory
corruptions, crashes, OOM...

Note that before commit 82981930125a ("net: cleanups in
sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF
and SO_RCVBUF were vulnerable.

This needs to be backported to all known linux kernels.

Again, many thanks to syzkaller team for discovering this gem.

Signed-off-by: Eric Dumazet <>
Reported-by: Andrey Konovalov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agosg_write()/bsg_write() is not fit to be called under KERNEL_DS
Al Viro [Fri, 16 Dec 2016 18:42:06 +0000 (13:42 -0500)]
sg_write()/bsg_write() is not fit to be called under KERNEL_DS

commit a0ac402cfcdc904f9772e1762b3fda112dcc56a0 upstream.

Both damn things interpret userland pointers embedded into the payload;
worse, they are actually traversing those.  Leaving aside the bad
API design, this is very much _not_ safe to call with KERNEL_DS.
Bail out early if that happens.

Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
6 years agosctp: validate chunk len before actually using it
Marcelo Ricardo Leitner [Tue, 25 Oct 2016 16:27:39 +0000 (14:27 -0200)]
sctp: validate chunk len before actually using it

commit bf911e985d6bbaa328c20c3e05f4eb03de11fdd6 upstream.

Andrey Konovalov reported that KASAN detected that SCTP was using a slab
beyond the boundaries. It was caused because when handling out of the
blue packets in function sctp_sf_ootb() it was checking the chunk len
only after already processing the first chunk, validating only for the
2nd and subsequent ones.

The fix is to just move the check upwards so it's also validated for the
1st chunk.

Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Signed-off-by: Marcelo Ricardo Leitner <>
Reviewed-by: Xin Long <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: moved code is slightly different]
Signed-off-by: Ben Hutchings <>
6 years agoFix potential infoleak in older kernels
Linus Torvalds [Tue, 8 Nov 2016 10:17:00 +0000 (11:17 +0100)]
Fix potential infoleak in older kernels

Not upstream as it is not needed there.

So a patch something like this might be a safe way to fix the
potential infoleak in older kernels.

THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles
it probably works. It just initializes the output variable with 0 in
the inline asm description, instead of doing it in the exception

It will generate slightly worse code (a few unnecessary ALU
operations), but it doesn't have any interactions with the exception
handler implementation.

Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agotcp: take care of truncations done by sk_filter()
Eric Dumazet [Thu, 10 Nov 2016 21:12:35 +0000 (13:12 -0800)]
tcp: take care of truncations done by sk_filter()

commit ac6e780070e30e4c35bd395acfe9191e6268bdd3 upstream.

With syzkaller help, Marco Grassi found a bug in TCP stack,
crashing in tcp_collapse()

Root cause is that sk_filter() can truncate the incoming skb,
but TCP stack was not really expecting this to happen.
It probably was expecting a simple DROP or ACCEPT behavior.

We first need to make sure no part of TCP header could be removed.
Then we need to adjust TCP_SKB_CB(skb)->end_seq

Many thanks to syzkaller team and Marco for giving us a reproducer.

Signed-off-by: Eric Dumazet <>
Reported-by: Marco Grassi <>
Reported-by: Vladis Dronov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agodccp: limit sk_filter trim to payload
Willem de Bruijn [Tue, 12 Jul 2016 22:18:57 +0000 (18:18 -0400)]
dccp: limit sk_filter trim to payload

commit 4f0c40d94461cfd23893a17335b2ab78ecb333c8 upstream.

Dccp verifies packet integrity, including length, at initial rcv in
dccp_invalid_packet, later pulls headers in dccp_enqueue_skb.

A call to sk_filter in-between can cause __skb_pull to wrap skb->len.
skb_copy_datagram_msg interprets this as a negative value, so
(correctly) fails with EFAULT. The negative length is reported in
ioctl SIOCINQ or possibly in a DCCP_WARN in dccp_close.

Introduce an sk_receive_skb variant that caps how small a filter
program can trim packets, and call this in dccp with the header
length. Excessively trimmed packets are now processed normally and
queued for reception as 0B payloads.

Fixes: 7c657876b63c ("[DCCP]: Initial implementation")
Signed-off-by: Willem de Bruijn <>
Acked-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agorose: limit sk_filter trim to payload
Willem de Bruijn [Tue, 12 Jul 2016 22:18:56 +0000 (18:18 -0400)]
rose: limit sk_filter trim to payload

commit f4979fcea7fd36d8e2f556abef86f80e0d5af1ba upstream.

Sockets can have a filter program attached that drops or trims
incoming packets based on the filter program return value.

Rose requires data packets to have at least ROSE_MIN_LEN bytes. It
verifies this on arrival in rose_route_frame and unconditionally pulls
the bytes in rose_recvmsg. The filter can trim packets to below this
value in-between, causing pull to fail, leaving the partial header at
the time of skb_copy_datagram_msg.

Place a lower bound on the size to which sk_filter may trim packets
by introducing sk_filter_trim_cap and call this for rose packets.

Signed-off-by: Willem de Bruijn <>
Acked-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonet: Add __sock_queue_rcv_skb()
Ben Hutchings [Thu, 29 Dec 2016 03:06:54 +0000 (03:06 +0000)]
net: Add __sock_queue_rcv_skb()

Extraxcted from commit e6afc8ace6dd5cef5e812f26c72579da8806f5ac
"udp: remove headers from UDP packets before queueing".

Signed-off-by: Ben Hutchings <>
6 years agofbdev: color map copying bounds checking
Kees Cook [Tue, 24 Jan 2017 23:18:24 +0000 (15:18 -0800)]
fbdev: color map copying bounds checking

commit 2dc705a9930b4806250fbf5a76e55266e59389f2 upstream.

Copying color maps to userspace doesn't check the value of to->start,
which will cause kernel heap buffer OOB read due to signedness wraps.


Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kees Cook <>
Reported-by: Peter Pi (@heisecode) of Trend Micro
Cc: Min Chong <>
Cc: Dan Carpenter <>
Cc: Tomi Valkeinen <>
Cc: Bartlomiej Zolnierkiewicz <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoHID: core: prevent out-of-bound readings
Benjamin Tissoires [Tue, 19 Jan 2016 11:34:58 +0000 (12:34 +0100)]
HID: core: prevent out-of-bound readings

commit 50220dead1650609206efe91f0cc116132d59b3f upstream.

Plugging a Logitech DJ receiver with KASAN activated raises a bunch of
out-of-bound readings.

The fields are allocated up to MAX_USAGE, meaning that potentially, we do
not have enough fields to fit the incoming values.
Add checks and silence KASAN.

Signed-off-by: Benjamin Tissoires <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Ben Hutchings <>
6 years agoblock: fix use-after-free in sys_ioprio_get()
Omar Sandoval [Fri, 1 Jul 2016 07:39:35 +0000 (00:39 -0700)]
block: fix use-after-free in sys_ioprio_get()

commit 8ba8682107ee2ca3347354e018865d8e1967c5f4 upstream.

get_task_ioprio() accesses the task->io_context without holding the task
lock and thus can race with exit_io_context(), leading to a
use-after-free. The reproducer below hits this within a few seconds on
my 4-core QEMU VM:

#define _GNU_SOURCE
#include <assert.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <sys/wait.h>

int main(int argc, char **argv)
pid_t pid, child;
long nproc, i;

syscall(SYS_ioprio_set, 1, 0, 0x6000);

nproc = sysconf(_SC_NPROCESSORS_ONLN);

for (i = 0; i < nproc; i++) {
pid = fork();
assert(pid != -1);
if (pid == 0) {
for (;;) {
pid = fork();
assert(pid != -1);
if (pid == 0) {
} else {
child = wait(NULL);
assert(child == pid);

pid = fork();
assert(pid != -1);
if (pid == 0) {
for (;;) {
/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
syscall(SYS_ioprio_get, 2, 0);

for (;;) {
/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
syscall(SYS_ioprio_get, 2, 0);

return 0;

This gets us KASAN dumps like this:

[   35.526914] ==================================================================
[   35.530009] BUG: KASAN: out-of-bounds in get_task_ioprio+0x7b/0x90 at addr ffff880066f34e6c
[   35.530009] Read of size 2 by task ioprio-gpf/363
[   35.530009] =============================================================================
[   35.530009] BUG blkdev_ioc (Not tainted): kasan: bad access detected
[   35.530009] -----------------------------------------------------------------------------

[   35.530009] Disabling lock debugging due to kernel taint
[   35.530009] INFO: Allocated in create_task_io_context+0x2b/0x370 age=0 cpu=0 pid=360
[   35.530009]  ___slab_alloc+0x55d/0x5a0
[   35.530009]  __slab_alloc.isra.20+0x2b/0x40
[   35.530009]  kmem_cache_alloc_node+0x84/0x200
[   35.530009]  create_task_io_context+0x2b/0x370
[   35.530009]  get_task_io_context+0x92/0xb0
[   35.530009]  copy_process.part.8+0x5029/0x5660
[   35.530009]  _do_fork+0x155/0x7e0
[   35.530009]  SyS_clone+0x19/0x20
[   35.530009]  do_syscall_64+0x195/0x3a0
[   35.530009]  return_from_SYSCALL_64+0x0/0x6a
[   35.530009] INFO: Freed in put_io_context+0xe7/0x120 age=0 cpu=0 pid=1060
[   35.530009]  __slab_free+0x27b/0x3d0
[   35.530009]  kmem_cache_free+0x1fb/0x220
[   35.530009]  put_io_context+0xe7/0x120
[   35.530009]  put_io_context_active+0x238/0x380
[   35.530009]  exit_io_context+0x66/0x80
[   35.530009]  do_exit+0x158e/0x2b90
[   35.530009]  do_group_exit+0xe5/0x2b0
[   35.530009]  SyS_exit_group+0x1d/0x20
[   35.530009]  entry_SYSCALL_64_fastpath+0x1a/0xa4
[   35.530009] INFO: Slab 0xffffea00019bcd00 objects=20 used=4 fp=0xffff880066f34ff0 flags=0x1fffe0000004080
[   35.530009] INFO: Object 0xffff880066f34e58 @offset=3672 fp=0x0000000000000001
[   35.530009] ==================================================================

Fix it by grabbing the task lock while we poke at the io_context.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Omar Sandoval <>
Signed-off-by: Jens Axboe <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoperf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race
Peter Zijlstra [Wed, 11 Jan 2017 20:09:50 +0000 (21:09 +0100)]
perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race

commit 321027c1fe77f892f4ea07846aeae08cefbbb290 upstream.

Di Shen reported a race between two concurrent sys_perf_event_open()
calls where both try and move the same pre-existing software group
into a hardware context.

The problem is exactly that described in commit:

  f63a8daa5812 ("perf: Fix event->ctx locking")

... where, while we wait for a ctx->mutex acquisition, the event->ctx
relation can have changed under us.

That very same commit failed to recognise sys_perf_event_context() as an
external access vector to the events and thereby didn't apply the
established locking rules correctly.

So while one sys_perf_event_open() call is stuck waiting on
mutex_lock_double(), the other (which owns said locks) moves the group
about. So by the time the former sys_perf_event_open() acquires the
locks, the context we've acquired is stale (and possibly dead).

Apply the established locking rules as per perf_event_ctx_lock_nested()
to the mutex_lock_double() for the 'move_group' case. This obviously means
we need to validate state after we acquire the locks.

Reported-by: Di Shen (Keen Lab)
Tested-by: John Dias <>
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Alexander Shishkin <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Jiri Olsa <>
Cc: Kees Cook <>
Cc: Linus Torvalds <>
Cc: Min Chong <>
Cc: Peter Zijlstra <>
Cc: Stephane Eranian <>
Cc: Thomas Gleixner <>
Cc: Vince Weaver <>
Fixes: f63a8daa5812 ("perf: Fix event->ctx locking")
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - Use ACCESS_ONCE() instead of READ_ONCE()
 - Test perf_event::group_flags instead of group_caps
 - Add the err_locked cleanup block, which we didn't need before
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoperf: Do not double free
Peter Zijlstra [Wed, 24 Feb 2016 17:45:41 +0000 (18:45 +0100)]
perf: Do not double free

commit 130056275ade730e7a79c110212c8815202773ee upstream.

In case of: err_file: fput(event_file), we'll end up calling
perf_release() which in turn will free the event.

Do not then free the event _again_.

Tested-by: Alexander Shishkin <>
Signed-off-by: Peter Zijlstra (Intel) <>
Reviewed-by: Alexander Shishkin <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Jiri Olsa <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoperf: Fix event->ctx locking
Peter Zijlstra [Fri, 23 Jan 2015 11:24:14 +0000 (12:24 +0100)]
perf: Fix event->ctx locking

commit f63a8daa5812afef4f06c962351687e1ff9ccb2b upstream.

There have been a few reported issues wrt. the lack of locking around
changing event->ctx. This patch tries to address those.

It avoids the whole rwsem thing; and while it appears to work, please
give it some thought in review.

What I did fail at is sensible runtime checks on the use of
event->ctx, the RCU use makes it very hard.

Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Paul E. McKenney <>
Cc: Jiri Olsa <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Linus Torvalds <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - We don't have perf_pmu_migrate_context()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agolockdep: Silence warning if CONFIG_LOCKDEP isn't set
Paul Bolle [Thu, 24 Jan 2013 20:53:17 +0000 (21:53 +0100)]
lockdep: Silence warning if CONFIG_LOCKDEP isn't set

commit 5cd3f5affad2109fd1458aab3f6216f2181e26ea upstream.

Since commit c9a4962881929df7f1ef6e63e1b9da304faca4dd ("nfsd:
make client_lock per net") compiling nfs4state.o without
CONFIG_LOCKDEP set, triggers this GCC warning:

    fs/nfsd/nfs4state.c: In function ‘free_client’:
    fs/nfsd/nfs4state.c:1051:19: warning: unused variable ‘nn’ [-Wunused-variable]

The cause of that warning is that lockdep_assert_held() compiles
away if CONFIG_LOCKDEP is not set. Silence this warning by using
the argument to lockdep_assert_held() as a nop if CONFIG_LOCKDEP
is not set.

Signed-off-by: Paul Bolle <>
Cc: Peter Zijlstra <>
Cc: Stanislav Kinsbursky <>
Cc: J. Bruce Fields <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoperf: Fix perf_event_for_each() to use sibling
Michael Ellerman [Wed, 11 Apr 2012 01:54:13 +0000 (11:54 +1000)]
perf: Fix perf_event_for_each() to use sibling

commit 724b6daa13e100067c30cfc4d1ad06629609dc4e upstream.

In perf_event_for_each() we call a function on an event, and then
iterate over the siblings of the event.

However we don't call the function on the siblings, we call it
repeatedly on the original event - it seems "obvious" that we should
be calling it with sibling as the argument.

It looks like this broke in commit 75f937f24bd9 ("Fix ctx->mutex
vs counter->mutex inversion").

The only effect of the bug is that the PERF_IOC_FLAG_GROUP parameter
to the ioctls doesn't work.

Signed-off-by: Michael Ellerman <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
6 years agotty: Prevent ldisc drivers from re-using stale tty fields
Peter Hurley [Fri, 27 Nov 2015 19:30:21 +0000 (14:30 -0500)]
tty: Prevent ldisc drivers from re-using stale tty fields

commit dd42bf1197144ede075a9d4793123f7689e164bc upstream.

Line discipline drivers may mistakenly misuse ldisc-related fields
when initializing. For example, a failure to initialize tty->receive_room
in the N_GIGASET_M101 line discipline was recently found and fixed [1].
Now, the N_X25 line discipline has been discovered accessing the previous
line discipline's already-freed private data [2].

Harden the ldisc interface against misuse by initializing revelant
tty fields before instancing the new line discipline.

    commit fd98e9419d8d622a4de91f76b306af6aa627aa9c
    Author: Tilman Schmidt <>
    Date:   Tue Jul 14 00:37:13 2015 +0200

    isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[2] Report from Sasha Levin <>
    [  634.336761] ==================================================================
    [  634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0
    [  634.339558] Read of size 4 by task syzkaller_execu/8981
    [  634.340359] =============================================================================
    [  634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected
    [  634.405018] Call Trace:
    [  634.405277] dump_stack (lib/dump_stack.c:52)
    [  634.405775] print_trailer (mm/slub.c:655)
    [  634.406361] object_err (mm/slub.c:662)
    [  634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236)
    [  634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279)
    [  634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1))
    [  634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447)
    [  634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567)
    [  634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879)
    [  634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
    [  634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
    [  634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)

Cc: Tilman Schmidt <>
Cc: Sasha Levin <>
Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoisdn/gigaset: reset tty->receive_room when attaching ser_gigaset
Tilman Schmidt [Mon, 13 Jul 2015 22:37:13 +0000 (00:37 +0200)]
isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

commit fd98e9419d8d622a4de91f76b306af6aa627aa9c upstream.

Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
first merged in kernel release 3.10, caused the following regression
in the Gigaset M101 driver:

Before that commit, when closing the N_TTY line discipline in
preparation to switching to N_GIGASET_M101, receive_room would be
reset to a non-zero value by the call to n_tty_flush_buffer() in
n_tty's close method. With the removal of that call, receive_room
might be left at zero, blocking data reception on the serial line.

The present patch fixes that regression by setting receive_room
to an appropriate value in the ldisc open method.

Fixes: 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc")
Signed-off-by: Tilman Schmidt <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoperf: Fix race in swevent hash
Peter Zijlstra [Tue, 15 Dec 2015 12:49:05 +0000 (13:49 +0100)]
perf: Fix race in swevent hash

commit 12ca6ad2e3a896256f086497a7c7406a547ee373 upstream.

There's a race on CPU unplug where we free the swevent hash array
while it can still have events on. This will result in a
use-after-free which is BAD.

Simply do not free the hash array on unplug. This leaves the thing
around and no use-after-free takes place.

When the last swevent dies, we do a for_each_possible_cpu() iteration
anyway to clean these up, at which time we'll free it, so no leakage
will occur.

Reported-by: Sasha Levin <>
Tested-by: Sasha Levin <>
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Frederic Weisbecker <>
Cc: Jiri Olsa <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Stephane Eranian <>
Cc: Thomas Gleixner <>
Cc: Vince Weaver <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
6 years agosg: Fix double-free when drives detach during SG_IO
Calvin Owens [Fri, 30 Oct 2015 23:57:00 +0000 (16:57 -0700)]
sg: Fix double-free when drives detach during SG_IO

commit f3951a3709ff50990bf3e188c27d346792103432 upstream.

In sg_common_write(), we free the block request and return -ENODEV if
the device is detached in the middle of the SG_IO ioctl().

Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we
end up freeing rq->cmd in the already free rq object, and then free
the object itself out from under the current user.

This ends up corrupting random memory via the list_head on the rq
object. The most common crash trace I saw is this:

  ------------[ cut here ]------------
  kernel BUG at block/blk-core.c:1420!
  Call Trace:
  [<ffffffff81281eab>] blk_put_request+0x5b/0x80
  [<ffffffffa0069e5b>] sg_finish_rem_req+0x6b/0x120 [sg]
  [<ffffffffa006bcb9>] sg_common_write.isra.14+0x459/0x5a0 [sg]
  [<ffffffff8125b328>] ? selinux_file_alloc_security+0x48/0x70
  [<ffffffffa006bf95>] sg_new_write.isra.17+0x195/0x2d0 [sg]
  [<ffffffffa006cef4>] sg_ioctl+0x644/0xdb0 [sg]
  [<ffffffff81170f80>] do_vfs_ioctl+0x90/0x520
  [<ffffffff81258967>] ? file_has_perm+0x97/0xb0
  [<ffffffff811714a1>] SyS_ioctl+0x91/0xb0
  [<ffffffff81602afb>] tracesys+0xdd/0xe2
    RIP [<ffffffff81281e04>] __blk_put_request+0x154/0x1a0

The solution is straightforward: just set srp->rq to NULL in the
failure branch so that sg_finish_rem_req() doesn't attempt to re-free

Additionally, since sg_rq_end_io() will never be called on the object
when this happens, we need to free memory backing ->cmd if it isn't
embedded in the object itself.

KASAN was extremely helpful in finding the root cause of this bug.

Signed-off-by: Calvin Owens <>
Acked-by: Douglas Gilbert <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2:
 - sg_finish_rem_req() would not free srp->rq->cmd so don't do it here either
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomedia: info leak in __media_device_enum_links()
Dan Carpenter [Sat, 13 Apr 2013 09:32:15 +0000 (06:32 -0300)]
media: info leak in __media_device_enum_links()

commit c88e739b1fad662240e99ecbd0bdaac871717987 upstream.

These structs have holes and reserved struct members which aren't
cleared.  I've added a memset() so we don't leak stack information.

Signed-off-by: Dan Carpenter <>
Signed-off-by: Laurent Pinchart <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Ben Hutchings <>
6 years agoARM: dma-mapping: don't allow DMA mappings to be marked executable
Russell King [Wed, 23 Oct 2013 15:14:59 +0000 (16:14 +0100)]
ARM: dma-mapping: don't allow DMA mappings to be marked executable

commit 0ea1ec713f04bdfac343c9702b21cd3a7c711826 upstream.

DMA mapping permissions were being derived from pgprot_kernel directly
without using PAGE_KERNEL.  This causes them to be marked with executable
permission, which is not what we want.  Fix this.

Signed-off-by: Russell King <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonet: cleanups in sock_setsockopt()
Eric Dumazet [Thu, 26 Apr 2012 20:07:59 +0000 (20:07 +0000)]
net: cleanups in sock_setsockopt()

commit 82981930125abfd39d7c8378a9cfdf5e1be2002b upstream.

Use min_t()/max_t() macros, reformat two comments, use !!test_bit() to
match !!sock_flag()

Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoser_gigaset: return -ENOMEM on error instead of success
Dan Carpenter [Wed, 7 Dec 2016 11:22:03 +0000 (14:22 +0300)]
ser_gigaset: return -ENOMEM on error instead of success

commit 93a97c50cbf1c007caf12db5cc23e0d5b9c8473c upstream.

If we can't allocate the resources in gigaset_initdriver() then we
should return -ENOMEM instead of zero.

Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)")
Signed-off-by: Dan Carpenter <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agocan: raw: raw_setsockopt: limit number of can_filter that can be set
Marc Kleine-Budde [Mon, 5 Dec 2016 10:44:23 +0000 (11:44 +0100)]
can: raw: raw_setsockopt: limit number of can_filter that can be set

commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream.

This patch adds a check to limit the number of can_filters that can be
set via setsockopt on CAN_RAW sockets. Otherwise allocations > MAX_ORDER
are not prevented resulting in a warning.


Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Signed-off-by: Marc Kleine-Budde <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agofuse: fix clearing suid, sgid for chown()
Miklos Szeredi [Tue, 6 Dec 2016 15:18:45 +0000 (16:18 +0100)]
fuse: fix clearing suid, sgid for chown()

commit c01638f5d919728f565bf8b5e0a6a159642df0d9 upstream.

Basically, the pjdfstests set the ownership of a file to 06555, and then
chowns it (as root) to a new uid/gid. Prior to commit a09f99eddef4 ("fuse:
fix killing s[ug]id in setattr"), fuse would send down a setattr with both
the uid/gid change and a new mode.  Now, it just sends down the uid/gid

Technically this is NOTABUG, since POSIX doesn't _require_ that we clear
these bits for a privileged process, but Linux (wisely) has done that and I
think we don't want to change that behavior here.

This is caused by the use of should_remove_suid(), which will always return
0 when the process has CAP_FSETID.

In fact we really don't need to be calling should_remove_suid() at all,
since we've already been indicated that we should remove the suid, we just
don't want to use a (very) stale mode for that.

This patch should fix the above as well as simplify the logic.

Reported-by: Jeff Layton <>
Signed-off-by: Miklos Szeredi <>
Fixes: a09f99eddef4 ("fuse: fix killing s[ug]id in setattr")
Reviewed-by: Jeff Layton <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
6 years agonet: ep93xx_eth: Do not crash unloading module
Florian Fainelli [Mon, 5 Dec 2016 03:22:05 +0000 (19:22 -0800)]
net: ep93xx_eth: Do not crash unloading module

commit c823abac17926767fb50175e098f087a6ac684c3 upstream.

When we unload the ep93xx_eth, whether we have opened the network
interface or not, we will either hit a kernel paging request error, or a
simple NULL pointer de-reference because:

- if ep93xx_open has been called, we have created a valid DMA mapping
  for ep->descs, when we call ep93xx_stop, we also call
  ep93xx_free_buffers, ep->descs now has a stale value

- if ep93xx_open has not been called, we have a NULL pointer for
  ep->descs, so performing any operation against that address just won't

Fix this by adding a NULL pointer check for ep->descs which means that
ep93xx_free_buffers() was able to successfully tear down the descriptors
and free the DMA cookie as well.

Fixes: 1d22e05df818 ("[PATCH] Cirrus Logic ep93xx ethernet driver")
Signed-off-by: Florian Fainelli <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agonet: ping: check minimum size on ICMP header length
Kees Cook [Mon, 5 Dec 2016 18:34:38 +0000 (10:34 -0800)]
net: ping: check minimum size on ICMP header length

commit 0eab121ef8750a5c8637d51534d5e9143fb0633f upstream.

Prior to commit c0371da6047a ("put iov_iter into msghdr") in v3.19, there
was no check that the iovec contained enough bytes for an ICMP header,
and the read loop would walk across neighboring stack contents. Since the
iov_iter conversion, bad arguments are noticed, but the returned error is
EFAULT. Returning EINVAL is a clearer error and also solves the problem
prior to v3.19.

This was found using trinity with KASAN on v3.18:

BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr ffffffc071077da0
Read of size 8 by task trinity-c2/9623
page:ffffffbe034b9a08 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x0()
page dumped because: kasan: bad access detected
CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: G    BU         3.18.0-dirty #15
Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
Call trace:
[<ffffffc000209c98>] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90
[<ffffffc000209e54>] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171
[<     inline     >] __dump_stack lib/dump_stack.c:15
[<ffffffc000f18dc4>] dump_stack+0x7c/0xd0 lib/dump_stack.c:50
[<     inline     >] print_address_description mm/kasan/report.c:147
[<     inline     >] kasan_report_error mm/kasan/report.c:236
[<ffffffc000373dcc>] kasan_report+0x380/0x4b8 mm/kasan/report.c:259
[<     inline     >] check_memory_region mm/kasan/kasan.c:264
[<ffffffc00037352c>] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507
[<ffffffc0005b9624>] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15
[<     inline     >] memcpy_from_msg include/linux/skbuff.h:2667
[<ffffffc000ddeba0>] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674
[<ffffffc000dded30>] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714
[<ffffffc000dc91dc>] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749
[<     inline     >] __sock_sendmsg_nosec net/socket.c:624
[<     inline     >] __sock_sendmsg net/socket.c:632
[<ffffffc000cab61c>] sock_sendmsg+0x124/0x164 net/socket.c:643
[<     inline     >] SYSC_sendto net/socket.c:1797
[<ffffffc000cad270>] SyS_sendto+0x178/0x1d8 net/socket.c:1761


Reported-by: Qidan He <>
Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Signed-off-by: Kees Cook <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: only ICMPv4 is supported]
Signed-off-by: Ben Hutchings <>
6 years agotipc: check minimum bearer MTU
Michal Kubeček [Fri, 2 Dec 2016 08:33:41 +0000 (09:33 +0100)]
tipc: check minimum bearer MTU

commit 3de81b758853f0b29c61e246679d20b513c4cfec upstream.

Qian Zhang (张谦) reported a potential socket buffer overflow in
tipc_msg_build() which is also known as CVE-2016-8632: due to
insufficient checks, a buffer overflow can occur if MTU is too short for
even tipc headers. As anyone can set device MTU in a user/net namespace,
this issue can be abused by a regular user.

As agreed in the discussion on Ben Hutchings' original patch, we should
check the MTU at the moment a bearer is attached rather than for each
processed packet. We also need to repeat the check when bearer MTU is
adjusted to new device MTU. UDP case also needs a check to avoid
overflow when calculating bearer MTU.

Fixes: b97bf3fd8f6a ("[TIPC] Initial merge")
Signed-off-by: Michal Kubecek <>
Reported-by: Qian Zhang (张谦) <>
Acked-by: Ying Xue <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Adjust filename, context
 - Duplicate macro definitions in bearer.h to avoid mutual inclusion
 - NETDEV_CHANGEMTU and NETDEV_CHANGEADDR cases in net notifier were combined
 - Drop changes in udp_media.c]
Signed-off-by: Ben Hutchings <>
6 years agopacket: fix race condition in packet_set_ring
Philip Pettersson [Wed, 30 Nov 2016 22:55:36 +0000 (14:55 -0800)]
packet: fix race condition in packet_set_ring

commit 84ac7260236a49c79eede91617700174c2c19b0c upstream.

When packet_set_ring creates a ring buffer it will initialize a
struct timer_list if the packet version is TPACKET_V3. This value
can then be raced by a different thread calling setsockopt to
set the version to TPACKET_V1 before packet_set_ring has finished.

This leads to a use-after-free on a function pointer in the
struct timer_list when the socket is closed as the previously
initialized timer will not be deleted.

The bug is fixed by taking lock_sock(sk) in packet_setsockopt when
changing the packet version while also taking the lock at the start
of packet_set_ring.

Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
Signed-off-by: Philip Pettersson <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agolocking/rtmutex: Prevent dequeue vs. unlock race
Thomas Gleixner [Wed, 30 Nov 2016 21:04:41 +0000 (21:04 +0000)]
locking/rtmutex: Prevent dequeue vs. unlock race

commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream.

David reported a futex/rtmutex state corruption. It's caused by the
following problem:


l->owner = T1 | HAS_WAITERS;

l->owner = T1 | HAS_WAITERS;
signal(->T2) signal(->T3)
  ===> wait list is now empty
  if (wait_list_empty(l)) {
    owner = l->owner & ~HAS_WAITERS;
    l->owner = owner
     ==> l->owner = T1

rt_mutex_unlock(l) fixup_rt_mutex_waiters()
  if (wait_list_empty(l)) {
    owner = l->owner & ~HAS_WAITERS;
cmpxchg(l->owner, T1, NULL)
 ===> Success (l->owner = NULL)
    l->owner = owner
     ==> l->owner = T1

That means the problem is caused by fixup_rt_mutex_waiters() which does the
RMW to clear the waiters bit unconditionally when there are no waiters in
the rtmutexes rbtree.

This can be fatal: A concurrent unlock can release the rtmutex in the
fastpath because the waiters bit is not set. If the cmpxchg() gets in the
middle of the RMW operation then the previous owner, which just unlocked
the rtmutex is set as the owner again when the write takes place after the
successfull cmpxchg().

The solution is rather trivial: verify that the owner member of the rtmutex
has the waiters bit set before clearing it. This does not require a
cmpxchg() or other atomic operations because the waiters bit can only be
set and cleared with the rtmutex wait_lock held. It's also safe against the
fast path unlock attempt. The unlock attempt via cmpxchg() will either see
the bit set and take the slowpath or see the bit cleared and release it
atomically in the fastpath.

It's remarkable that the test program provided by David triggers on ARM64
and MIPS64 really quick, but it refuses to reproduce on x86-64, while the
problem exists there as well. That refusal might explain that this got not
discovered earlier despite the bug existing from day one of the rtmutex
implementation more than 10 years ago.

Thanks to David for meticulously instrumenting the code and providing the
information which allowed to decode this subtle problem.

Reported-by: David Daney <>
Tested-by: David Daney <>
Signed-off-by: Thomas Gleixner <>
Reviewed-by: Steven Rostedt <>
Acked-by: Peter Zijlstra (Intel) <>
Cc: Linus Torvalds <>
Cc: Mark Rutland <>
Cc: Peter Zijlstra <>
Cc: Sebastian Siewior <>
Cc: Will Deacon <>
Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core")
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2:
 - Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()
 - Adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoKVM: x86: drop error recovery in em_jmp_far and em_ret_far
Radim Krčmář [Wed, 23 Nov 2016 20:15:00 +0000 (21:15 +0100)]
KVM: x86: drop error recovery in em_jmp_far and em_ret_far

commit 2117d5398c81554fbf803f5fd1dc55eb78216c0c upstream.

em_jmp_far and em_ret_far assumed that setting IP can only fail in 64
bit mode, but syzkaller proved otherwise (and SDM agrees).
Code segment was restored upon failure, but it was left uninitialized
outside of long mode, which could lead to a leak of host kernel stack.
We could have fixed that by always saving and restoring the CS, but we
take a simpler approach and just break any guest that manages to fail
as the error recovery is error-prone and modern CPUs don't need emulator
for this.

Found by syzkaller:

  WARNING: CPU: 2 PID: 3668 at arch/x86/kvm/emulate.c:2217 em_ret_far+0x428/0x480
  Kernel panic - not syncing: panic_on_warn set ...

  CPU: 2 PID: 3668 Comm: syz-executor Not tainted 4.9.0-rc4+ #49
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
   [...] __dump_stack lib/dump_stack.c:15
   [...] dump_stack+0xb3/0x118 lib/dump_stack.c:51
   [...] panic+0x1b7/0x3a3 kernel/panic.c:179
   [...] __warn+0x1c4/0x1e0 kernel/panic.c:542
   [...] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
   [...] em_ret_far+0x428/0x480 arch/x86/kvm/emulate.c:2217
   [...] em_ret_far_imm+0x17/0x70 arch/x86/kvm/emulate.c:2227
   [...] x86_emulate_insn+0x87a/0x3730 arch/x86/kvm/emulate.c:5294
   [...] x86_emulate_instruction+0x520/0x1ba0 arch/x86/kvm/x86.c:5545
   [...] emulate_instruction arch/x86/include/asm/kvm_host.h:1116
   [...] complete_emulated_io arch/x86/kvm/x86.c:6870
   [...] complete_emulated_mmio+0x4e9/0x710 arch/x86/kvm/x86.c:6934
   [...] kvm_arch_vcpu_ioctl_run+0x3b7a/0x5a90 arch/x86/kvm/x86.c:6978
   [...] kvm_vcpu_ioctl+0x61e/0xdd0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2557
   [...] vfs_ioctl fs/ioctl.c:43
   [...] do_vfs_ioctl+0x18c/0x1040 fs/ioctl.c:679
   [...] SYSC_ioctl fs/ioctl.c:694
   [...] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
   [...] entry_SYSCALL_64_fastpath+0x1f/0xc2

Reported-by: Dmitry Vyukov <>
Fixes: d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far jumps")
Signed-off-by: Radim Krčmář <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoext4: sanity check the block and cluster size at mount time
Theodore Ts'o [Fri, 18 Nov 2016 18:00:24 +0000 (13:00 -0500)]
ext4: sanity check the block and cluster size at mount time

commit 8cdf3372fe8368f56315e66bea9f35053c418093 upstream.

If the block size or cluster size is insane, reject the mount.  This
is important for security reasons (although we shouldn't be just
depending on this check).

Reported-by: Borislav Petkov <>
Reported-by: Nikolay Borisov <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agoKVM: Disable irq while unregistering user notifier
Ignacio Alvarado [Fri, 4 Nov 2016 19:15:55 +0000 (12:15 -0700)]
KVM: Disable irq while unregistering user notifier

commit 1650b4ebc99da4c137bfbfc531be4a2405f951dd upstream.

Function user_notifier_unregister should be called only once for each
registered user notifier.

Function kvm_arch_hardware_disable can be executed from an IPI context
which could cause a race condition with a VCPU returning to user mode
and attempting to unregister the notifier.

Signed-off-by: Ignacio Alvarado <>
Fixes: 18863bdd60f8 ("KVM: x86 shared msr infrastructure")
Reviewed-by: Paolo Bonzini <>
Signed-off-by: Radim Krčmář <>
Signed-off-by: Ben Hutchings <>
6 years agomwifiex: printk() overflow with 32-byte SSIDs
Brian Norris [Wed, 9 Nov 2016 02:28:24 +0000 (18:28 -0800)]
mwifiex: printk() overflow with 32-byte SSIDs

commit fcd2042e8d36cf644bd2d69c26378d17158b17df upstream.

SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
when we print them out.

This can be easily noticed by connecting to a network with a 32-octet

[ 3903.502925] mwifiex_pcie 0000:01:00.0: info: trying to associate to
'0123456789abcdef0123456789abcdef <uninitialized mem>' bssid

Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Brian Norris <>
Acked-by: Amitkumar Karwar <>
Signed-off-by: Kalle Valo <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
6 years agoIB/mlx4: Fix create CQ error flow
Matan Barak [Thu, 10 Nov 2016 09:30:55 +0000 (11:30 +0200)]
IB/mlx4: Fix create CQ error flow

commit 593ff73bcfdc79f79a8a0df55504f75ad3e5d1a9 upstream.

Currently, if ib_copy_to_udata fails, the CQ
won't be deleted from the radix tree and the HW (HW2SW).

Fixes: 225c7b1feef1 ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters')
Signed-off-by: Matan Barak <>
Signed-off-by: Daniel Jurgens <>
Reviewed-by: Mark Bloch <>
Signed-off-by: Leon Romanovsky <>
Signed-off-by: Doug Ledford <>
Signed-off-by: Ben Hutchings <>
6 years agoIB/uverbs: Fix leak of XRC target QPs
Tariq Toukan [Thu, 27 Oct 2016 13:36:26 +0000 (16:36 +0300)]
IB/uverbs: Fix leak of XRC target QPs

commit 5b810a242c28e1d8d64d718cebe75b79d86a0b2d upstream.

The real QP is destroyed in case of the ref count reaches zero, but
for XRC target QPs this call was missed and caused to QP leaks.

Let's call to destroy for all flows.

Fixes: 0e0ec7e0638e ('RDMA/core: Export ib_open_qp() to share XRC...')
Signed-off-by: Tariq Toukan <>
Signed-off-by: Noa Osherovich <>
Signed-off-by: Leon Romanovsky <>
Signed-off-by: Doug Ledford <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: cp210x: add ID for the Zone DPMX
Paul Jakma [Wed, 16 Nov 2016 10:13:49 +0000 (10:13 +0000)]
USB: serial: cp210x: add ID for the Zone DPMX

commit 2ab13292d7a314fa45de0acc808e41aaad31989c upstream.

The BRIM Brothers Zone DPMX is a bicycle powermeter. This ID is for the USB
serial interface in its charging dock for the control pods, via which some
settings for the pods can be modified.

Signed-off-by: Paul Jakma <>
Cc: Barry Redmond <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agomfd: core: Fix device reference leak in mfd_clone_cell
Johan Hovold [Tue, 1 Nov 2016 10:38:18 +0000 (11:38 +0100)]
mfd: core: Fix device reference leak in mfd_clone_cell

commit 722f191080de641f023feaa7d5648caf377844f5 upstream.

Make sure to drop the reference taken by bus_find_device_by_name()
before returning from mfd_clone_cell().

Fixes: a9bbba996302 ("mfd: add platform_device sharing support for mfd")
Signed-off-by: Johan Hovold <>
Signed-off-by: Lee Jones <>
Signed-off-by: Ben Hutchings <>
6 years agoFix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y
Petr Vandrovec [Thu, 10 Nov 2016 21:57:14 +0000 (13:57 -0800)]
Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y

commit 2ce9d2272b98743b911196c49e7af5841381c206 upstream.

Some code (all error handling) submits CDBs that are allocated
on the stack.  This breaks with CB/CBI code that tries to create
URB directly from SCSI command buffer - which happens to be in
vmalloced memory with vmalloced kernel stacks.

Let's make copy of the command in usb_stor_CB_transport.

Signed-off-by: Petr Vandrovec <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agodib0700: fix nec repeat handling
Sean Young [Thu, 10 Nov 2016 16:44:49 +0000 (17:44 +0100)]
dib0700: fix nec repeat handling

commit ba13e98f2cebd55a3744c5ffaa08f9dca73bf521 upstream.

When receiving a nec repeat, ensure the correct scancode is repeated
rather than a random value from the stack.  This removes the need for
the bogus uninitialized_var() and also fixes the warnings:

    drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’:
    drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be used uninitialized in this function

[sean addon: So after writing the patch and submitting it, I've bought the
             hardware on ebay. Without this patch you get random scancodes
             on nec repeats, which the patch indeed fixes.]

Signed-off-by: Sean Young <>
Tested-by: Sean Young <>
Signed-off-by: Arnd Bergmann <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
6 years agocoredump: fix unfreezable coredumping task
Andrey Ryabinin [Thu, 10 Nov 2016 18:46:38 +0000 (10:46 -0800)]
coredump: fix unfreezable coredumping task

commit 70d78fe7c8b640b5acfad56ad341985b3810998a upstream.

It could be not possible to freeze coredumping task when it waits for
'core_state->startup' completion, because threads are frozen in
get_signal() before they got a chance to complete 'core_state->startup'.

Inability to freeze a task during suspend will cause suspend to fail.
Also CRIU uses cgroup freezer during dump operation.  So with an
unfreezable task the CRIU dump will fail because it waits for a
transition from 'FREEZING' to 'FROZEN' state which will never happen.

Use freezer_do_not_count() to tell freezer to ignore coredumping task
while it waits for core_state->startup completion.

Signed-off-by: Andrey Ryabinin <>
Acked-by: Pavel Machek <>
Acked-by: Oleg Nesterov <>
Cc: Alexander Viro <>
Cc: Tejun Heo <>
Cc: "Rafael J. Wysocki" <>
Cc: Michal Hocko <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
6 years agoswapfile: fix memory corruption via malformed swapfile
Jann Horn [Thu, 10 Nov 2016 18:46:19 +0000 (10:46 -0800)]
swapfile: fix memory corruption via malformed swapfile

commit dd111be69114cc867f8e826284559bfbc1c40e37 upstream.

When root activates a swap partition whose header has the wrong
endianness, nr_badpages elements of badpages are swabbed before
nr_badpages has been checked, leading to a buffer overrun of up to 8GB.

This normally is not a security issue because it can only be exploited
by root (more specifically, a process with CAP_SYS_ADMIN or the ability
to modify a swap file/partition), and such a process can already e.g.
modify swapped-out memory of any other userspace process on the system.

Signed-off-by: Jann Horn <>
Acked-by: Kees Cook <>
Acked-by: Jerome Marchand <>
Acked-by: Johannes Weiner <>
Cc: "Kirill A. Shutemov" <>
Cc: Vlastimil Babka <>
Cc: Hugh Dickins <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agortnl: reset calcit fptr in rtnl_unregister()
Mathias Krause [Mon, 7 Nov 2016 22:22:19 +0000 (23:22 +0100)]
rtnl: reset calcit fptr in rtnl_unregister()

commit f567e950bf51290755a2539ff2aaef4c26f735d3 upstream.

To avoid having dangling function pointers left behind, reset calcit in
rtnl_unregister(), too.

This is no issue so far, as only the rtnl core registers a netlink
handler with a calcit hook which won't be unregistered, but may become
one if new code makes use of the calcit hook.

Fixes: c7ac8679bec9 ("rtnetlink: Compute and store minimum ifinfo...")
Cc: Jeff Kirsher <>
Cc: Greg Rose <>
Signed-off-by: Mathias Krause <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoscsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression
Sumit Saxena [Wed, 9 Nov 2016 10:59:42 +0000 (02:59 -0800)]
scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression

commit 5e5ec1759dd663a1d5a2f10930224dd009e500e8 upstream.

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

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 <>
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: Ben Hutchings <>
6 years agommc: mxs: Initialize the spinlock prior to using it
Fabio Estevam [Sat, 5 Nov 2016 19:45:07 +0000 (17:45 -0200)]
mmc: mxs: Initialize the spinlock prior to using it

commit f91346e8b5f46aaf12f1df26e87140584ffd1b3f upstream.

An interrupt may occur right after devm_request_irq() is called and
prior to the spinlock initialization, leading to a kernel oops,
as the interrupt handler uses the spinlock.

In order to prevent this problem, move the spinlock initialization
prior to requesting the interrupts.

Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Fabio Estevam <>
Reviewed-by: Marek Vasut <>
Signed-off-by: Ulf Hansson <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: ftdi_sio: add support for TI CC3200 LaunchPad
Doug Brown [Sat, 5 Nov 2016 04:18:20 +0000 (21:18 -0700)]
USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad

commit 9bfef729a3d11f04d12788d749a3ce6b47645734 upstream.

This patch adds support for the TI CC3200 LaunchPad board, which uses a
custom USB vendor ID and product ID. Channel A is used for JTAG, and
channel B is used for a UART.

Signed-off-by: Doug Brown <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoi2c: core: fix NULL pointer dereference under race condition
Vladimir Zapolskiy [Mon, 31 Oct 2016 19:46:24 +0000 (21:46 +0200)]
i2c: core: fix NULL pointer dereference under race condition

commit 147b36d5b70c083cc76770c47d60b347e8eaf231 upstream.

Race condition between registering an I2C device driver and
deregistering an I2C adapter device which is assumed to manage that
I2C device may lead to a NULL pointer dereference due to the
uninitialized list head of driver clients.

The root cause of the issue is that the I2C bus may know about the
registered device driver and thus it is matched by bus_for_each_drv(),
but the list of clients is not initialized and commonly it is NULL,
because I2C device drivers define struct i2c_driver as static and
clients field is expected to be initialized by I2C core:

  i2c_register_driver()             i2c_del_adapter()
    driver_register()                 ...
      bus_add_driver()                ...
        ...                           bus_for_each_drv(..., __process_removed_adapter)
      ...                               i2c_do_del_adapter()
    ...                                   list_for_each_entry_safe(..., &driver->clients, ...)

To solve the problem it is sufficient to do clients list head
initialization before calling driver_register().

The problem was found while using an I2C device driver with a sluggish
registration routine on a bus provided by a physically detachable I2C
master controller, but practically the oops may be reproduced under
the race between arbitraty I2C device driver registration and managing
I2C bus device removal e.g. by unbinding the latter over sysfs:

% echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  Internal error: Oops: 17 [#1] SMP ARM
  CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
  Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
  task: e5ada400 task.stack: e4936000
  PC is at i2c_do_del_adapter+0x20/0xcc
  LR is at __process_removed_adapter+0x14/0x1c
  Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
  Control: 10c5387d  Table: 35bd004a  DAC: 00000051
  Process sh (pid: 533, stack limit = 0xe4936210)
  Stack: (0xe4937d28 to 0xe4938000)
  [<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c)
  [<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0)
  [<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284)
  [<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
  [<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44)
  [<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c)
  [<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34)
  [<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104)
  [<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34)
  [<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54)
  [<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214)
  [<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120)
  [<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170)
  [<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8)
  [<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)

Signed-off-by: Vladimir Zapolskiy <>
Signed-off-by: Wolfram Sang <>
Signed-off-by: Ben Hutchings <>
6 years agoipv6: dccp: add missing bind_conflict to dccp_ipv6_mapped
Eric Dumazet [Thu, 3 Nov 2016 15:59:46 +0000 (08:59 -0700)]
ipv6: dccp: add missing bind_conflict to dccp_ipv6_mapped

commit 990ff4d84408fc55942ca6644f67e361737b3d8e upstream.

While fuzzing kernel with syzkaller, Andrey reported a nasty crash
in inet6_bind() caused by DCCP lacking a required method.

Fixes: ab1e0a13d7029 ("[SOCK] proto: Add hashinfo member to struct proto")
Signed-off-by: Eric Dumazet <>
Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Cc: Arnaldo Carvalho de Melo <>
Acked-by: Arnaldo Carvalho de Melo <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoHID: usbhid: add ATEN CS962 to list of quirky devices
Oliver Neukum [Thu, 3 Nov 2016 11:31:41 +0000 (12:31 +0100)]
HID: usbhid: add ATEN CS962 to list of quirky devices

commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream.

Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Jiri Kosina <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoHID: usbhid: Add HID_QUIRK_NOGET for Aten DVI KVM switch
Laura Abbott [Tue, 12 May 2015 17:00:00 +0000 (10:00 -0700)]
HID: usbhid: Add HID_QUIRK_NOGET for Aten DVI KVM switch

commit 849eca7b9dae0364e2fbe8afdf0fb610d12c9c8f upstream.

Like other KVM switches, the Aten DVI KVM switch needs a quirk to avoid spewing

[791759.606542] usb 1-5.4: input irq status -75 received
[791759.614537] usb 1-5.4: input irq status -75 received
[791759.622542] usb 1-5.4: input irq status -75 received

Add it.

Signed-off-by: Laura Abbott <>
Signed-off-by: Jiri Kosina <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agofirewire: net: fix fragmented datagram_size off-by-one
Stefan Richter [Sun, 30 Oct 2016 16:32:01 +0000 (17:32 +0100)]
firewire: net: fix fragmented datagram_size off-by-one

commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream.

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 */
            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;
            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.)

Signed-off-by: Stefan Richter <>
Signed-off-by: Ben Hutchings <>
6 years agoparisc: Ensure consistent state when switching to kernel stack at syscall entry
John David Anglin [Sat, 29 Oct 2016 03:00:34 +0000 (23:00 -0400)]
parisc: Ensure consistent state when switching to kernel stack at syscall entry

commit 6ed518328d0189e0fdf1bb7c73290d546143ea66 upstream.

We have one critical section in the syscall entry path in which we switch from
the userspace stack to kernel stack. In the event of an external interrupt, the
interrupt code distinguishes between those two states by analyzing the value of
sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that
the value of sr7 is in sync with the currently enabled stack.

This patch now disables interrupts while executing the critical section.  This
prevents the interrupt handler to possibly see an inconsistent state which in
the worst case can lead to crashes.

Interestingly, in the syscall exit path interrupts were already disabled in the
critical section which switches back to the userspace stack.

Signed-off-by: John David Anglin <>
Signed-off-by: Helge Deller <>
Signed-off-by: Ben Hutchings <>
6 years agoip6_tunnel: Clear IP6CB in ip6tunnel_xmit()
Eli Cooper [Tue, 1 Nov 2016 15:45:12 +0000 (23:45 +0800)]
ip6_tunnel: Clear IP6CB in ip6tunnel_xmit()

commit 23f4ffedb7d751c7e298732ba91ca75d224bc1a6 upstream.

skb->cb may contain data from previous layers. In the observed scenario,
the garbage data were misinterpreted as IP6CB(skb)->frag_max_size, so
that small packets sent through the tunnel are mistakenly fragmented.

This patch unconditionally clears the control buffer in ip6tunnel_xmit(),
which affects ip6_tunnel, ip6_udp_tunnel and ip6_gre. Currently none of
these tunnels set IP6CB(skb)->flags, otherwise it needs to be done earlier.

Signed-off-by: Eli Cooper <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: apply to ip6_tnl_xmit2()]
Signed-off-by: Ben Hutchings <>
6 years agouwb: fix device reference leaks
Johan Hovold [Tue, 1 Nov 2016 11:13:31 +0000 (12:13 +0100)]
uwb: fix device reference leaks

commit d6124b409ca33c100170ffde51cd8dff761454a1 upstream.

This subsystem consistently fails to drop the device reference taken by

Note that some of these lookup functions already take a reference to the
returned data, while others claim no reference is needed (or does not
seem need one).

Fixes: 183b9b592a62 ("uwb: add the UWB stack (core files)")
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Drop change to uwb_rc_class_device_exists()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
6 years agousb: gadget: u_ether: remove interrupt throttling
Felipe Balbi [Tue, 1 Nov 2016 11:20:22 +0000 (13:20 +0200)]
usb: gadget: u_ether: remove interrupt throttling

commit fd9afd3cbe404998d732be6cc798f749597c5114 upstream.

According to Dave Miller "the networking stack has a
hard requirement that all SKBs which are transmitted
must have their completion signalled in a fininte
amount of time. This is because, until the SKB is
freed by the driver, it holds onto socket,
netfilter, and other subsystem resources."

In summary, this means that using TX IRQ throttling
for the networking gadgets is, at least, complex and
we should avoid it for the time being.

Reported-by: Ville Syrjälä <>
Tested-by: Ville Syrjälä <>
Suggested-by: David Miller <>
Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
6 years agocan: bcm: fix warning in bcm_connect/proc_register
Oliver Hartkopp [Mon, 24 Oct 2016 19:11:26 +0000 (21:11 +0200)]
can: bcm: fix warning in bcm_connect/proc_register

commit deb507f91f1adbf64317ad24ac46c56eeccfb754 upstream.

Andrey Konovalov reported an issue with proc_register in bcm.c.
As suggested by Cong Wang this patch adds a lock_sock() protection and
a check for unsuccessful proc_create_data() in bcm_connect().


Reported-by: Andrey Konovalov <>
Suggested-by: Cong Wang <>
Signed-off-by: Oliver Hartkopp <>
Acked-by: Cong Wang <>
Tested-by: Andrey Konovalov <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
6 years agoipv6: Don't use ufo handling on later transformed packets
Jakub Sitnicki [Wed, 26 Oct 2016 09:21:14 +0000 (11:21 +0200)]
ipv6: Don't use ufo handling on later transformed packets

commit f89c56ce710afa65e1b2ead555b52c4807f34ff7 upstream.

Similar to commit c146066ab802 ("ipv4: Don't use ufo handling on later
transformed packets"), don't perform UFO on packets that will be IPsec
transformed. To detect it we rely on the fact that headerlen in
dst_entry is non-zero only for transformation bundles (xfrm_dst

Unwanted segmentation can be observed with a NETIF_F_UFO capable device,
such as a dummy device:

  DEV=dum0 LEN=1493

  ip li add $DEV type dummy
  ip addr add fc00::1/64 dev $DEV nodad
  ip link set $DEV up
  ip xfrm policy add dir out src fc00::1 dst fc00::2 \
     tmpl src fc00::1 dst fc00::2 proto esp spi 1
  ip xfrm state add src fc00::1 dst fc00::2 \
     proto esp spi 1 enc 'aes' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b

  tcpdump -n -nn -i $DEV -t &
  socat /dev/zero,readbytes=$LEN udp6:[fc00::2]:$LEN

tcpdump output before:

  IP6 fc00::1 > fc00::2: frag (0|1448) ESP(spi=0x00000001,seq=0x1), length 1448
  IP6 fc00::1 > fc00::2: frag (1448|48)
  IP6 fc00::1 > fc00::2: ESP(spi=0x00000001,seq=0x2), length 88

... and after:

  IP6 fc00::1 > fc00::2: frag (0|1448) ESP(spi=0x00000001,seq=0x1), length 1448
  IP6 fc00::1 > fc00::2: frag (1448|80)

Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")

Signed-off-by: Jakub Sitnicki <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonet/mlx4_en: Process all completions in RX rings after port goes up
Erez Shitrit [Thu, 27 Oct 2016 13:27:17 +0000 (16:27 +0300)]
net/mlx4_en: Process all completions in RX rings after port goes up

commit 8d59de8f7bb3db296331c665779c653b0c8d13ba upstream.

Currently there is a race between incoming traffic and
initialization flow. HW is able to receive the packets
after INIT_PORT is done and unicast steering is configured.
Before we set priv->port_up NAPI is not scheduled and
receive queues become full. Therefore we never get
new interrupts about the completions.
This issue could happen if running heavy traffic during
bringing port up.
The resolution is to schedule NAPI once port_up is set.
If receive queues were full this will process all cqes
and release them.

Fixes: c27a02cd94d6 ("mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC")
Signed-off-by: Erez Shitrit <>
Signed-off-by: Eugenia Emantayev <>
Signed-off-by: Tariq Toukan <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: mlx4_en_priv::rx_cq is an array of structs not pointers]
Signed-off-by: Ben Hutchings <>
6 years agoubifs: Fix regression in ubifs_readdir()
Richard Weinberger [Fri, 28 Oct 2016 09:49:03 +0000 (11:49 +0200)]
ubifs: Fix regression in ubifs_readdir()

commit a00052a296e54205cf238c75bd98d17d5d02a6db upstream.

Commit c83ed4c9dbb35 ("ubifs: Abort readdir upon error") broke
overlayfs support because the fix exposed an internal error
code to VFS.

Reported-by: Peter Rosin <>
Tested-by: Peter Rosin <>
Reported-by: Ralph Sennhauser <>
Tested-by: Ralph Sennhauser <>
Fixes: c83ed4c9dbb35 ("ubifs: Abort readdir upon error")
Signed-off-by: Richard Weinberger <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoKVM: x86: fix wbinvd_dirty_mask use-after-free
Ido Yariv [Fri, 21 Oct 2016 16:39:57 +0000 (12:39 -0400)]
KVM: x86: fix wbinvd_dirty_mask use-after-free

commit bd768e146624cbec7122ed15dead8daa137d909d upstream.

vcpu->arch.wbinvd_dirty_mask may still be used after freeing it,
corrupting memory. For example, the following call trace may set a bit
in an already freed cpu mask:

Fix this by deferring freeing of wbinvd_dirty_mask.

Signed-off-by: Ido Yariv <>
Reviewed-by: Paolo Bonzini <>
Signed-off-by: Radim Krčmář <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agolib/genalloc.c: start search from start of chunk
Daniel Mentz [Fri, 28 Oct 2016 00:46:59 +0000 (17:46 -0700)]
lib/genalloc.c: start search from start of chunk

commit 62e931fac45b17c2a42549389879411572f75804 upstream.

gen_pool_alloc_algo() iterates over the chunks of a pool trying to find
a contiguous block of memory that satisfies the allocation request.

The shortcut

if (size > atomic_read(&chunk->avail))

makes the loop skip over chunks that do not have enough bytes left to
fulfill the request.  There are two situations, though, where an
allocation might still fail:

(1) The available memory is not contiguous, i.e.  the request cannot
    be fulfilled due to external fragmentation.

(2) A race condition.  Another thread runs the same code concurrently
    and is quicker to grab the available memory.

In those situations, the loop calls pool->algo() to search the entire
chunk, and pool->algo() returns some value that is >= end_bit to
indicate that the search failed.  This return value is then assigned to
start_bit.  The variables start_bit and end_bit describe the range that
should be searched, and this range should be reset for every chunk that
is searched.  Today, the code fails to reset start_bit to 0.  As a
result, prefixes of subsequent chunks are ignored.  Memory allocations
might fail even though there is plenty of room left in these prefixes of
those other chunks.

Fixes: 7f184275aa30 ("lib, Make gen_pool memory allocator lockless")
Signed-off-by: Daniel Mentz <>
Reviewed-by: Mathieu Desnoyers <>
Acked-by: Will Deacon <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonetfilter: nf_conntrack_sip: extend request line validation
Ulrich Weber [Mon, 24 Oct 2016 16:07:23 +0000 (18:07 +0200)]
netfilter: nf_conntrack_sip: extend request line validation

commit 444f901742d054a4cd5ff045871eac5131646cfb upstream.

on SIP requests, so a fragmented TCP SIP packet from an allow header starting with
 Content-Length: 0

will not bet interpreted as an INVITE request. Also Request-URI must start with an alphabetic character.

Confirm with RFC 3261
 Request-Line   =  Method SP Request-URI SP SIP-Version CRLF

Fixes: 30f33e6dee80 ("[NETFILTER]: nf_conntrack_sip: support method specific request/response handling")
Signed-off-by: Ulrich Weber <>
Acked-by: Marco Angaroni <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agovt: clear selection before resizing
Scot Doyle [Thu, 13 Oct 2016 17:12:43 +0000 (12:12 -0500)]
vt: clear selection before resizing

commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 upstream.

When resizing a vt its selection may exceed the new size, resulting in
an invalid memory access [1]. Clear the selection before resizing.


Reported-and-tested-by: Dmitry Vyukov <>
Signed-off-by: Scot Doyle <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agotty: limit terminal size to 4M chars
Dmitry Vyukov [Fri, 14 Oct 2016 13:18:28 +0000 (15:18 +0200)]
tty: limit terminal size to 4M chars

commit 32b2921e6a7461fe63b71217067a6cf4bddb132f upstream.

Size of kmalloc() in vc_do_resize() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Put a reasonable upper bound on terminal size to prevent WARNINGs.

Signed-off-by: Dmitry Vyukov <>
CC: David Rientjes <>
Cc: One Thousand Gnomes <>
Cc: Greg Kroah-Hartman <>
Cc: Jiri Slaby <>
Cc: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agotty: vt, fix bogus division in csi_J
Jiri Slaby [Mon, 3 Oct 2016 09:00:17 +0000 (11:00 +0200)]
tty: vt, fix bogus division in csi_J

commit 42acfc6615f47e465731c263bee0c799edb098f2 upstream.

In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is
divided by 2 inappropriatelly. But scr_memsetw expects size, not
count, because it divides the size by 2 on its own before doing actual

So remove the bogus division.

Signed-off-by: Jiri Slaby <>
Cc: Petr Písař <>
Fixes: f8df13e0a9 (tty: Clean console safely)
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: usb-audio: Add quirk for Syntek STK1160
Marcel Hasler [Wed, 26 Oct 2016 22:42:27 +0000 (00:42 +0200)]
ALSA: usb-audio: Add quirk for Syntek STK1160

commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream.

The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves
the issue reported on the mailing list
( and also fixes
bug 180071 (

Signed-off-by: Marcel Hasler <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoscsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware
Ching Huang [Wed, 19 Oct 2016 09:50:26 +0000 (17:50 +0800)]
scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware

commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f upstream.

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

Ensure that cache flushes are passed to the controller.

[mkp: applied by hand and removed unused vars]

Signed-off-by: Ching Huang <>
Reported-by: Tomas Henzl <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
6 years agoscsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded
Ewan D. Milne [Wed, 26 Oct 2016 15:22:53 +0000 (11:22 -0400)]
scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded

commit 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d upstream.

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

Signed-off-by: Ewan D. Milne <>
Reviewed-by: Laurence Oberman <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agostaging: iio: ad5933: avoid uninitialized variable in error case
Arnd Bergmann [Mon, 24 Oct 2016 15:22:01 +0000 (17:22 +0200)]
staging: iio: ad5933: avoid uninitialized variable in error case

commit 34eee70a7b82b09dbda4cb453e0e21d460dae226 upstream.

The ad5933_i2c_read function returns an error code to indicate
whether it could read data or not. However ad5933_work() ignores
this return code and just accesses the data unconditionally,
which gets detected by gcc as a possible bug:

drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work':
drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized]

This adds minimal error handling so we only evaluate the
data if it was correctly read.

Signed-off-by: Arnd Bergmann <>
Acked-by: Lars-Peter Clausen <>
Signed-off-by: Jonathan Cameron <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>