4 years agoLinux 3.14.61 v3.14.61
Greg Kroah-Hartman [Wed, 17 Feb 2016 20:34:50 +0000 (12:34 -0800)]
Linux 3.14.61

4 years agobinfmt_elf: Don't clobber passed executable's file header
Maciej W. Rozycki [Mon, 26 Oct 2015 15:48:19 +0000 (15:48 +0000)]
binfmt_elf: Don't clobber passed executable's file header

commit b582ef5c53040c5feef4c96a8f9585b6831e2441 upstream.

Do not clobber the buffer space passed from `search_binary_handler' and
originally preloaded by `prepare_binprm' with the executable's file
header by overwriting it with its interpreter's file header.  Instead
keep the buffer space intact and directly use the data structure locally
allocated for the interpreter's file header, fixing a bug introduced in
2.1.14 with loadable module support ( commit beb11695
[Import of Linux/MIPS 2.1.14], predating repo's history).
Adjust the amount of data read from the interpreter's file accordingly.

This was not an issue before loadable module support, because back then
`load_elf_binary' was executed only once for a given ELF executable,
whether the function succeeded or failed.

With loadable module support supported and enabled, upon a failure of
`load_elf_binary' -- which may for example be caused by architecture
code rejecting an executable due to a missing hardware feature requested
in the file header -- a module load is attempted and then the function
reexecuted by `search_binary_handler'.  With the executable's file
header replaced with its interpreter's file header the executable can
then be erroneously accepted in this subsequent attempt.

Signed-off-by: Maciej W. Rozycki <>
Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoFS-Cache: Don't override netfs's primary_index if registering failed
Kinglong Mee [Wed, 4 Nov 2015 15:20:24 +0000 (15:20 +0000)]
FS-Cache: Don't override netfs's primary_index if registering failed

commit b130ed5998e62879a66bad08931a2b5e832da95c upstream.

Only override netfs->primary_index when registering success.

Signed-off-by: Kinglong Mee <>
Signed-off-by: David Howells <>
Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoFS-Cache: Increase reference of parent after registering, netfs success
Kinglong Mee [Wed, 4 Nov 2015 15:20:15 +0000 (15:20 +0000)]
FS-Cache: Increase reference of parent after registering, netfs success

commit 86108c2e34a26e4bec3c6ddb23390bf8cedcf391 upstream.

If netfs exist, fscache should not increase the reference of parent's
usage and n_children, otherwise, never be decreased.

v2: thanks David's suggest,
 move increasing reference of parent if success
 use kmem_cache_free() freeing primary_index directly

v3: don't move "netfs->primary_index->parent = &fscache_fsdef_index;"

Signed-off-by: Kinglong Mee <>
Signed-off-by: David Howells <>
Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: user - lock crypto_alg_list on alg dump
Mathias Krause [Mon, 1 Feb 2016 13:27:30 +0000 (14:27 +0100)]
crypto: user - lock crypto_alg_list on alg dump

commit 63e41ebc6630f39422d87f8a4bade1e793f37a01 upstream.

We miss to take the crypto_alg_sem semaphore when traversing the
crypto_alg_list for CRYPTO_MSG_GETALG dumps. This allows a race with
crypto_unregister_alg() removing algorithms from the list while we're
still traversing it, thereby leading to a use-after-free as show below:

[ 3482.071639] general protection fault: 0000 [#1] SMP
[ 3482.075639] Modules linked in: aes_x86_64 glue_helper lrw ablk_helper cryptd gf128mul ipv6 pcspkr serio_raw virtio_net microcode virtio_pci virtio_ring virtio sr_mod cdrom [last unloaded: aesni_intel]
[ 3482.075639] CPU: 1 PID: 11065 Comm: crconf Not tainted 4.3.4-grsec+ #126
[ 3482.075639] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 3482.075639] task: ffff88001cd41a40 ti: ffff88001cd422c8 task.ti: ffff88001cd422c8
[ 3482.075639] RIP: 0010:[<ffffffff93722bd3>]  [<ffffffff93722bd3>] strncpy+0x13/0x30
[ 3482.075639] RSP: 0018:ffff88001f713b60  EFLAGS: 00010202
[ 3482.075639] RAX: ffff88001f6c4430 RBX: ffff88001f6c43a0 RCX: ffff88001f6c4430
[ 3482.075639] RDX: 0000000000000040 RSI: fefefefefefeff16 RDI: ffff88001f6c4430
[ 3482.075639] RBP: ffff88001f713b60 R08: ffff88001f6c4470 R09: ffff88001f6c4480
[ 3482.075639] R10: 0000000000000002 R11: 0000000000000246 R12: ffff88001ce2aa28
[ 3482.075639] R13: ffff880000093700 R14: ffff88001f5e4bf8 R15: 0000000000003b20
[ 3482.075639] FS:  0000033826fa2700(0000) GS:ffff88001e900000(0000) knlGS:0000000000000000
[ 3482.075639] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3482.075639] CR2: ffffffffff600400 CR3: 00000000139ec000 CR4: 00000000001606f0
[ 3482.075639] Stack:
[ 3482.075639]  ffff88001f713bd8 ffffffff936ccd00 ffff88001e5c4200 ffff880000093700
[ 3482.075639]  ffff88001f713bd0 ffffffff938ef4bf 0000000000000000 0000000000003b20
[ 3482.075639]  ffff88001f5e4bf8 ffff88001f5e4848 0000000000000000 0000000000003b20
[ 3482.075639] Call Trace:
[ 3482.075639]  [<ffffffff936ccd00>] crypto_report_alg+0xc0/0x3e0
[ 3482.075639]  [<ffffffff938ef4bf>] ? __alloc_skb+0x16f/0x300
[ 3482.075639]  [<ffffffff936cd08a>] crypto_dump_report+0x6a/0x90
[ 3482.075639]  [<ffffffff93935707>] netlink_dump+0x147/0x2e0
[ 3482.075639]  [<ffffffff93935f99>] __netlink_dump_start+0x159/0x190
[ 3482.075639]  [<ffffffff936ccb13>] crypto_user_rcv_msg+0xc3/0x130
[ 3482.075639]  [<ffffffff936cd020>] ? crypto_report_alg+0x3e0/0x3e0
[ 3482.075639]  [<ffffffff936cc4b0>] ? alg_test_crc32c+0x120/0x120
[ 3482.075639]  [<ffffffff93933145>] ? __netlink_lookup+0xd5/0x120
[ 3482.075639]  [<ffffffff936cca50>] ? crypto_add_alg+0x1d0/0x1d0
[ 3482.075639]  [<ffffffff93938141>] netlink_rcv_skb+0xe1/0x130
[ 3482.075639]  [<ffffffff936cc4f8>] crypto_netlink_rcv+0x28/0x40
[ 3482.075639]  [<ffffffff939375a8>] netlink_unicast+0x108/0x180
[ 3482.075639]  [<ffffffff93937c21>] netlink_sendmsg+0x541/0x770
[ 3482.075639]  [<ffffffff938e31e1>] sock_sendmsg+0x21/0x40
[ 3482.075639]  [<ffffffff938e4763>] SyS_sendto+0xf3/0x130
[ 3482.075639]  [<ffffffff93444203>] ? bad_area_nosemaphore+0x13/0x20
[ 3482.075639]  [<ffffffff93444470>] ? __do_page_fault+0x80/0x3a0
[ 3482.075639]  [<ffffffff939d80cb>] entry_SYSCALL_64_fastpath+0x12/0x6e
[ 3482.075639] Code: 88 4a ff 75 ed 5d 48 0f ba 2c 24 3f c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 85 d2 48 89 f8 48 89 f9 4c 8d 04 17 48 89 e5 74 15 <0f> b6 16 80 fa 01 88 11 48 83 de ff 48 83 c1 01 4c 39 c1 75 eb
[ 3482.075639] RIP  [<ffffffff93722bd3>] strncpy+0x13/0x30

To trigger the race run the following loops simultaneously for a while:
  $ while : ; do modprobe aesni-intel; rmmod aesni-intel; done
  $ while : ; do crconf show all > /dev/null; done

Fix the race by taking the crypto_alg_sem read lock, thereby preventing
crypto_unregister_alg() from modifying the algorithm list during the

This bug has been detected by the PaX memory sanitize feature.

Signed-off-by: Mathias Krause <>
Cc: Steffen Klassert <>
Cc: PaX Team <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoEVM: Use crypto_memneq() for digest comparisons
Ryan Ware [Thu, 11 Feb 2016 23:58:44 +0000 (15:58 -0800)]
EVM: Use crypto_memneq() for digest comparisons

commit 613317bd212c585c20796c10afe5daaa95d4b0a1 upstream.

This patch fixes vulnerability CVE-2016-2085.  The problem exists
because the vm_verify_hmac() function includes a use of memcmp().
Unfortunately, this allows timing side channel attacks; specifically
a MAC forgery complexity drop from 2^128 to 2^12.  This patch changes
the memcmp() to the cryptographically safe crypto_memneq().

Reported-by: Xiaofei Rex Guo <>
Signed-off-by: Ryan Ware <>
Signed-off-by: Mimi Zohar <>
Signed-off-by: James Morris <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_hash - wait for crypto_ahash_init() to complete
Wang, Rui Y [Wed, 27 Jan 2016 09:08:37 +0000 (17:08 +0800)]
crypto: algif_hash - wait for crypto_ahash_init() to complete

commit fe09786178f9df713a4b2dd6b93c0a722346bf5e upstream.

hash_sendmsg/sendpage() need to wait for the completion
of crypto_ahash_init() otherwise it can cause panic.

Signed-off-by: Rui Wang <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoahci: Intel DNV device IDs SATA
Alexandra Yates [Fri, 5 Feb 2016 23:27:49 +0000 (15:27 -0800)]
ahci: Intel DNV device IDs SATA

commit 342decff2b846b46fa61eb5ee40986fab79a9a32 upstream.

Adding Intel codename DNV platform device IDs for SATA.

Signed-off-by: Alexandra Yates <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agolibata: disable forced PORTS_IMPL for >= AHCI 1.3
Tejun Heo [Fri, 15 Jan 2016 20:13:05 +0000 (15:13 -0500)]
libata: disable forced PORTS_IMPL for >= AHCI 1.3

commit 566d1827df2ef0cbe921d3d6946ac3007b1a6938 upstream.

Some early controllers incorrectly reported zero ports in PORTS_IMPL
register and the ahci driver fabricates PORTS_IMPL from the number of
ports in those cases.  This hasn't mattered but with the new nvme
controllers there are cases where zero PORTS_IMPL is valid and should
be honored.

Disable the workaround for >= AHCI 1.3.

Signed-off-by: Tejun Heo <>
Reported-by: Andy Lutomirski <>
Cc: Sergei Shtylyov <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoAHCI: Fix softreset failed issue of Port Multiplier
Xiangliang Yu [Thu, 26 Nov 2015 12:27:02 +0000 (20:27 +0800)]
AHCI: Fix softreset failed issue of Port Multiplier

commit 023113d24ef9e1d2b44cb2446872b17e2b01d8b1 upstream.

Current code doesn't update port value of Port Multiplier(PM) when
sending FIS of softreset to device, command will fail if FBS is

There are two ways to fix the issue: the first is to disable FBS
before sending softreset command to PM device and the second is
to update port value of PM when sending command.

For the first way, i can't find any related rule in AHCI Spec. The
second way can avoid disabling FBS and has better performance.

Signed-off-by: Xiangliang Yu <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: af_alg - Fix socket double-free when accept fails
Herbert Xu [Wed, 30 Dec 2015 12:24:17 +0000 (20:24 +0800)]
crypto: af_alg - Fix socket double-free when accept fails

commit a383292c86663bbc31ac62cc0c04fc77504636a6 upstream.

When we fail an accept(2) call we will end up freeing the socket
twice, once due to the direct sk_free call and once again through

This patch fixes this by removing the sk_free call.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: af_alg - Disallow bind/setkey/... after accept(2)
Herbert Xu [Wed, 30 Dec 2015 03:47:53 +0000 (11:47 +0800)]
crypto: af_alg - Disallow bind/setkey/... after accept(2)

commit c840ac6af3f8713a71b4d2363419145760bd6044 upstream.

Each af_alg parent socket obtained by socket(2) corresponds to a
tfm object once bind(2) has succeeded.  An accept(2) call on that
parent socket creates a context which then uses the tfm object.

Therefore as long as any child sockets created by accept(2) exist
the parent socket must not be modified or freed.

This patch guarantees this by using locks and a reference count
on the parent socket.  Any attempt to modify the parent socket will
fail with EBUSY.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoext4: Fix handling of extended tv_sec
David Turner [Tue, 24 Nov 2015 19:34:37 +0000 (14:34 -0500)]
ext4: Fix handling of extended tv_sec

commit a4dad1ae24f850410c4e60f22823cba1289b8d52 upstream.

In ext4, the bottom two bits of {a,c,m}time_extra are used to extend
the {a,c,m}time fields, deferring the year 2038 problem to the year

When decoding these extended fields, for times whose bottom 32 bits
would represent a negative number, sign extension causes the 64-bit
extended timestamp to be negative as well, which is not what's
intended.  This patch corrects that issue, so that the only negative
{a,c,m}times are those between 1901 and 1970 (as per 32-bit signed

Some older kernels might have written pre-1970 dates with 1,1 in the
extra bits.  This patch treats those incorrectly-encoded dates as
pre-1970, instead of post-2311, until kernel 4.20 is released.
Hopefully by then e2fsck will have fixed up the bad data.

Also add a comment explaining the encoding of ext4's extra {a,c,m}time

Signed-off-by: David Turner <>
Signed-off-by: Theodore Ts'o <>
Reported-by: Mark Harris <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxhci: fix usb2 resume timing and races.
Mathias Nyman [Fri, 11 Dec 2015 12:38:06 +0000 (14:38 +0200)]
xhci: fix usb2 resume timing and races.

commit f69115fdbc1ac0718e7d19ad3caa3da2ecfe1c96 upstream.

According to USB 2 specs ports need to signal resume for at least 20ms,
in practice even longer, before moving to U0 state.
Both host and devices can initiate resume.

On device initiated resume, a port status interrupt with the port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.

On host initiated resume, current code sets the port to resume state,
sleep 20ms, and finally sets the port to U0 state. This should also
be changed to work in a similar way as the device initiated resume, with
timestamp tagging, but that is not yet tested and will be a separate
fix later.

There are a few issues with this approach

1. A host initiated resume will also generate a resume event. The event
   handler will find the port in resume state, believe it's a device
   initiated resume, and act accordingly.

2. A port status request might cut the resume signalling short if a
   get_port_status request is handled during the host resume signalling.
   The port will be found in resume state. The timestamp is not set leading
   to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
   get_port_status will proceed with moving the port to U0.

3. If an error, or anything else happens to the port during device
   initiated resume signalling it will leave all the device resume
   parameters hanging uncleared, preventing further suspend, returning
   -EBUSY, and cause the pm thread to busyloop trying to enter suspend.

Fix this by using the existing resuming_ports bitfield to indicate that
resume signalling timing is taken care of.
Check if the resume_done[port] is set before using it for timestamp
comparison, and also clear out any resume signalling related variables
if port is not in U0 or Resume state

This issue was discovered when a PM thread busylooped, trying to runtime
suspend the xhci USB 2 roothub on a Dell XPS

Reported-by: Daniel J Blueman <>
Tested-by: Daniel J Blueman <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agotty: Fix unsafe ldisc reference via ioctl(TIOCGETD)
Peter Hurley [Mon, 11 Jan 2016 06:40:55 +0000 (22:40 -0800)]
tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)

commit 5c17c861a357e9458001f021a7afa7aab9937439 upstream.

ioctl(TIOCGETD) retrieves the line discipline id directly from the
ldisc because the line discipline id (c_line) in termios is untrustworthy;
userspace may have set termios via ioctl(TCSETS*) without actually
changing the line discipline via ioctl(TIOCSETD).

However, directly accessing the current ldisc via tty->ldisc is
unsafe; the ldisc ptr dereferenced may be stale if the line discipline
is changing via ioctl(TIOCSETD) or hangup.

Wait for the line discipline reference (just like read() or write())
to retrieve the "current" line discipline id.

Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agotty: Fix GPF in flush_to_ldisc()
Peter Hurley [Fri, 27 Nov 2015 19:25:08 +0000 (14:25 -0500)]
tty: Fix GPF in flush_to_ldisc()

commit 9ce119f318ba1a07c29149301f1544b6c4bea52a upstream.

A line discipline which does not define a receive_buf() method can
can cause a GPF if data is ever received [1]. Oddly, this was known
to the author of n_tracesink in 2011, but never fixed.

[1] GPF report
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<          (null)>]           (null)
    PGD 3752d067 PUD 37a7b067 PMD 0
    Oops: 0010 [#1] SMP KASAN
    Modules linked in:
    CPU: 2 PID: 148 Comm: kworker/u10:2 Not tainted 4.4.0-rc2+ #51
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Workqueue: events_unbound flush_to_ldisc
    task: ffff88006da94440 ti: ffff88006db60000 task.ti: ffff88006db60000
    RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
    RSP: 0018:ffff88006db67b50  EFLAGS: 00010246
    RAX: 0000000000000102 RBX: ffff88003ab32f88 RCX: 0000000000000102
    RDX: 0000000000000000 RSI: ffff88003ab330a6 RDI: ffff88003aabd388
    RBP: ffff88006db67c48 R08: ffff88003ab32f9c R09: ffff88003ab31fb0
    R10: ffff88003ab32fa8 R11: 0000000000000000 R12: dffffc0000000000
    R13: ffff88006db67c20 R14: ffffffff863df820 R15: ffff88003ab31fb8
    FS:  0000000000000000(0000) GS:ffff88006dc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000000 CR3: 0000000037938000 CR4: 00000000000006e0
     ffffffff829f46f1 ffff88006da94bf8 ffff88006da94bf8 0000000000000000
     ffff88003ab31fb0 ffff88003aabd438 ffff88003ab31ff8 ffff88006430fd90
     ffff88003ab32f9c ffffed0007557a87 1ffff1000db6cf78 ffff88003ab32078
    Call Trace:
     [<ffffffff8127cf91>] process_one_work+0x8f1/0x17a0 kernel/workqueue.c:2030
     [<ffffffff8127df14>] worker_thread+0xd4/0x1180 kernel/workqueue.c:2162
     [<ffffffff8128faaf>] kthread+0x1cf/0x270 drivers/block/aoe/aoecmd.c:1302
     [<ffffffff852a7c2f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:468
    Code:  Bad RIP value.
    RIP  [<          (null)>]           (null)
     RSP <ffff88006db67b50>
    CR2: 0000000000000000
    ---[ end trace a587f8947e54d6ea ]---

Reported-by: Dmitry Vyukov <>
Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: option: fix Cinterion AHxx enumeration
John Ernberg [Mon, 25 Jan 2016 12:27:17 +0000 (12:27 +0000)]
USB: option: fix Cinterion AHxx enumeration

commit 4152b387da81617c80cb2946b2d56e3958906b3e upstream.

In certain kernel configurations where the cdc_ether and option drivers
are compiled as modules there can occur a race condition in enumeration.
This causes the option driver to enumerate the ethernet(wwan) interface
as usb-serial interfaces.

usb-devices output for the modem:
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1e2d ProdID=0055 Rev=00.00
S:  Manufacturer=Cinterion
S:  Product=AHx
C:  #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=10mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
I:  If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether

Signed-off-by: John Ernberg <>
Fixes: 1941138e1c02 ("USB: added support for Cinterion's products...")
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: serial: option: Adding support for Telit LE922
Daniele Palmas [Tue, 12 Jan 2016 16:22:06 +0000 (17:22 +0100)]
USB: serial: option: Adding support for Telit LE922

commit ff4e2494dc17b173468e1713fdf6237fd8578bc7 upstream.

This patch adds support for two PIDs of LE922.

Signed-off-by: Daniele Palmas <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: cp210x: add ID for IAI USB to RS485 adaptor
Peter Dedecker [Fri, 8 Jan 2016 11:34:41 +0000 (12:34 +0100)]
USB: cp210x: add ID for IAI USB to RS485 adaptor

commit f487c54ddd544e1c9172cd510954f697b77b76e3 upstream.

Added the USB serial console device ID for IAI Corp. RCB-CV-USB
USB to RS485 adaptor.

Signed-off-by: Peter Dedecker <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: serial: ftdi_sio: add support for Yaesu SCU-18 cable
Greg Kroah-Hartman [Wed, 20 Jan 2016 07:43:13 +0000 (23:43 -0800)]
USB: serial: ftdi_sio: add support for Yaesu SCU-18 cable

commit e03cdf22a2727c60307be6a729233edab3bfda9c upstream.

Harald Linden reports that the ftdi_sio driver works properly for the
Yaesu SCU-18 cable if the device ids are added to the driver.  So let's
add them.

Reported-by: Harald Linden <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agousb: hub: do not clear BOS field during reset device
Du, Changbin [Mon, 18 Jan 2016 13:02:42 +0000 (21:02 +0800)]
usb: hub: do not clear BOS field during reset device

commit d8f00cd685f5c8e0def8593e520a7fef12c22407 upstream.

In function usb_reset_and_verify_device, the old BOS descriptor may
still be used before allocating a new one. (usb_unlocked_disable_lpm
function uses it under the situation that it fails to disable lpm.)
So we cannot set the udev->bos to NULL before that, just keep what it
was. It will be overwrite when allocating a new one.

Crash log:
BUG: unable to handle kernel NULL pointer dereference at
IP: [<ffffffff8171f98d>] usb_enable_link_state+0x2d/0x2f0
Call Trace:
[<ffffffff8171ed5b>] ? usb_set_lpm_timeout+0x12b/0x140
[<ffffffff8171fcd1>] usb_enable_lpm+0x81/0xa0
[<ffffffff8171fdd8>] usb_disable_lpm+0xa8/0xc0
[<ffffffff8171fe1c>] usb_unlocked_disable_lpm+0x2c/0x50
[<ffffffff81723933>] usb_reset_and_verify_device+0xc3/0x710
[<ffffffff8172c4ed>] ? usb_sg_wait+0x13d/0x190
[<ffffffff81724743>] usb_reset_device+0x133/0x280
[<ffffffff8179ccd1>] usb_stor_port_reset+0x61/0x70
[<ffffffff8179cd68>] usb_stor_invoke_transport+0x88/0x520

Signed-off-by: Du, Changbin <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: visor: fix null-deref at probe
Johan Hovold [Tue, 12 Jan 2016 11:05:20 +0000 (12:05 +0100)]
USB: visor: fix null-deref at probe

commit cac9b50b0d75a1d50d6c056ff65c005f3224c8e0 upstream.

Fix null-pointer dereference at probe should a (malicious) Treo device
lack the expected endpoints.

Specifically, the Treo port-setup hack was dereferencing the bulk-in and
interrupt-in urbs without first making sure they had been allocated by

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: serial: visor: fix crash on detecting device without write_urbs
Vladis Dronov [Tue, 12 Jan 2016 14:10:50 +0000 (15:10 +0100)]
USB: serial: visor: fix crash on detecting device without write_urbs

commit cb3232138e37129e88240a98a1d2aba2187ff57c upstream.

The visor driver crashes in clie_5_attach() when a specially crafted USB
device without bulk-out endpoint is detected. This fix adds a check that
the device has proper configuration expected by the driver.

Reported-by: Ralf Spenneberg <>
Signed-off-by: Vladis Dronov <>
Fixes: cfb8da8f69b8 ("USB: visor: fix initialisation of UX50/TH55 devices")
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agosaa7134-alsa: Only frees registered sound cards
Mauro Carvalho Chehab [Thu, 4 Feb 2016 17:59:43 +0000 (15:59 -0200)]
saa7134-alsa: Only frees registered sound cards

commit ac75fe5d8fe4a0bf063be18fb29684405279e79e upstream.

That prevents this bug:
[ 2382.269496] BUG: unable to handle kernel NULL pointer dereference at 0000000000000540
[ 2382.270013] IP: [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
[ 2382.270013] PGD 0
[ 2382.270013] Oops: 0002 [#1] SMP
[ 2382.270013] Modules linked in: saa7134_alsa(-) tda1004x saa7134_dvb videobuf2_dvb dvb_core tda827x tda8290 tuner saa7134 tveeprom videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc tun bridge stp llc ebtables ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack it87 hwmon_vid snd_hda_codec_idt snd_hda_codec_generic iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq pcspkr i2c_i801 snd_seq_device snd_pcm snd_timer lpc_ich snd mfd_core soundcore binfmt_misc i915 video i2c_algo_bit drm_kms_helper drm r8169 ata_generic serio_raw pata_acpi mii i2c_core [last unloaded: videobuf2_memops]
[ 2382.270013] CPU: 0 PID: 4899 Comm: rmmod Not tainted 4.5.0-rc1+ #4
[ 2382.270013] Hardware name: PCCHIPS P17G/P17G, BIOS 080012  05/14/2008
[ 2382.270013] task: ffff880039c38000 ti: ffff88003c764000 task.ti: ffff88003c764000
[ 2382.270013] RIP: 0010:[<ffffffffa01fe616>]  [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
[ 2382.270013] RSP: 0018:ffff88003c767ea0  EFLAGS: 00010286
[ 2382.270013] RAX: ffff88003c767eb8 RBX: 0000000000000000 RCX: 0000000000006260
[ 2382.270013] RDX: ffffffffa020a060 RSI: ffffffffa0206de1 RDI: ffff88003c767eb0
[ 2382.270013] RBP: ffff88003c767ed8 R08: 0000000000019960 R09: ffffffff811a5412
[ 2382.270013] R10: ffffea0000d7c200 R11: 0000000000000000 R12: ffff88003c767ea8
[ 2382.270013] R13: 00007ffe760617f7 R14: 0000000000000000 R15: 0000557625d7f1e0
[ 2382.270013] FS:  00007f80bb1c0700(0000) GS:ffff88003f400000(0000) knlGS:0000000000000000
[ 2382.270013] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 2382.270013] CR2: 0000000000000540 CR3: 000000003c00f000 CR4: 00000000000006f0
[ 2382.270013] Stack:
[ 2382.270013]  000000003c767ed8 ffffffff00000000 ffff880000000000 ffff88003c767eb8
[ 2382.270013]  ffff88003c767eb8 ffffffffa049a890 00007ffe76060060 ffff88003c767ef0
[ 2382.270013]  ffffffffa049889d ffffffffa049a500 ffff88003c767f48 ffffffff8111079c
[ 2382.270013] Call Trace:
[ 2382.270013]  [<ffffffffa049889d>] saa7134_alsa_exit+0x1d/0x780 [saa7134_alsa]
[ 2382.270013]  [<ffffffff8111079c>] SyS_delete_module+0x19c/0x1f0
[ 2382.270013]  [<ffffffff8170fc2e>] entry_SYSCALL_64_fastpath+0x12/0x71
[ 2382.270013] Code: 20 a0 48 c7 c6 e1 6d 20 a0 48 89 e5 41 54 53 4c 8d 65 d0 48 89 fb 48 83 ec 28 c7 45 d0 00 00 00 00 49 8d 7c 24 08 e8 7a 55 ed e0 <4c> 89 a3 40 05 00 00 48 89 df e8 eb fd ff ff 85 c0 75 1a 48 8d
[ 2382.270013] RIP  [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
[ 2382.270013]  RSP <ffff88003c767ea0>
[ 2382.270013] CR2: 0000000000000540

Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: dummy: Implement timer backend switching more safely
Takashi Iwai [Tue, 2 Feb 2016 14:27:36 +0000 (15:27 +0100)]
ALSA: dummy: Implement timer backend switching more safely

commit ddce57a6f0a2d8d1bfacfa77f06043bc760403c2 upstream.

Currently the selected timer backend is referred at any moment from
the running PCM callbacks.  When the backend is switched, it's
possible to lead to inconsistency from the running backend.  This was
pointed by syzkaller fuzzer, and the commit [7ee96216c31a: ALSA:
dummy: Disable switching timer backend via sysfs] disabled the dynamic
switching for avoiding the crash.

This patch improves the handling of timer backend switching.  It keeps
the reference to the selected backend during the whole operation of an
opened stream so that it won't be changed by other streams.

Together with this change, the hrtimer parameter is reenabled as
writable now.

NOTE: this patch also turned out to fix the still remaining race.
Namely, ops was still replaced dynamically at dummy_pcm_open:

  static int dummy_pcm_open(struct snd_pcm_substream *substream)
          dummy->timer_ops = &dummy_systimer_ops;
          if (hrtimer)
                  dummy->timer_ops = &dummy_hrtimer_ops;

Since dummy->timer_ops is common among all streams, and when the
replacement happens during accesses of other streams, it may lead to a
crash.  This was actually triggered by syzkaller fuzzer and KASAN.

This patch rewrites the code not to use the ops shared by all streams
any longer, too.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: hda - Fix speaker output from VAIO AiO machines
Takashi Iwai [Sun, 7 Feb 2016 08:38:26 +0000 (09:38 +0100)]
ALSA: hda - Fix speaker output from VAIO AiO machines

commit c44d9b1181cf34e0860c72cc8a00e0c47417aac0 upstream.

Some Sony VAIO AiO models (VGC-JS4EF and VGC-JS25G, both with PCI SSID
104d:9044) need the same quirk to make the speaker working properly.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: hda - Fix static checker warning in patch_hdmi.c
David Henningsson [Fri, 5 Feb 2016 08:05:41 +0000 (09:05 +0100)]
ALSA: hda - Fix static checker warning in patch_hdmi.c

commit 360a8245680053619205a3ae10e6bfe624a5da1d upstream.

The static checker warning is:

sound/pci/hda/patch_hdmi.c:460 hdmi_eld_ctl_get()
error: __memcpy() 'eld->eld_buffer' too small (256 vs 512)

I have a hard time figuring out if this can ever cause an information leak
(I don't think so), but nonetheless it does not hurt to increase the
robustness of the code.

Fixes: 68e03de98507 ('ALSA: hda - hdmi: Do not expose eld data when eld is invalid')
Reported-by: Dan Carpenter <>
Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: hda - Add fixup for Mac Mini 7,1 model
Takashi Iwai [Wed, 3 Feb 2016 11:32:51 +0000 (12:32 +0100)]
ALSA: hda - Add fixup for Mac Mini 7,1 model

commit 2154cc0e2d4ae15132d005d17e473327c70c9a06 upstream.

Mac Mini 7,1 model with CS4208 codec reports the headphone jack
detection wrongly in an inverted way.  Moreover, the advertised pins
for the audio input and SPDIF output have actually no jack detection.

This patch addresses these issues.  The inv_jack_detect flag is set
for fixing the headphone jack detection, and the pin configs for audio
input and SPDIF output are marked as non-detectable.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: timer: Fix race between stop and interrupt
Takashi Iwai [Tue, 9 Feb 2016 11:02:32 +0000 (12:02 +0100)]
ALSA: timer: Fix race between stop and interrupt

commit ed8b1d6d2c741ab26d60d499d7fbb7ac801f0f51 upstream.

A slave timer element also unlinks at snd_timer_stop() but it takes
only slave_active_lock.  When a slave is assigned to a master,
however, this may become a race against the master's interrupt
handling, eventually resulting in a list corruption.  The actual bug
could be seen with a syzkaller fuzzer test case in BugLink below.

As a fix, we need to take timeri->timer->lock when timer isn't NULL,
i.e. assigned to a master, while the assignment to a master itself is
protected by slave_active_lock.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: timer: Fix wrong instance passed to slave callbacks
Takashi Iwai [Mon, 8 Feb 2016 16:36:25 +0000 (17:36 +0100)]
ALSA: timer: Fix wrong instance passed to slave callbacks

commit 117159f0b9d392fb433a7871426fad50317f06f7 upstream.

In snd_timer_notify1(), the wrong timer instance was passed for slave
ccallback function.  This leads to the access to the wrong data when
an incompatible master is handled (e.g. the master is the sequencer
timer and the slave is a user timer), as spotted by syzkaller fuzzer.

This patch fixes that wrong assignment.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: timer: Fix link corruption due to double start or stop
Takashi Iwai [Sat, 30 Jan 2016 22:09:08 +0000 (23:09 +0100)]
ALSA: timer: Fix link corruption due to double start or stop

commit f784beb75ce82f4136f8a0960d3ee872f7109e09 upstream.

Although ALSA timer code got hardening for races, it still causes
use-after-free error.  This is however rather a corrupted linked list,
not actually the concurrent accesses.  Namely, when timer start is
triggered twice, list_add_tail() is called twice, too.  This ends
up with the link corruption and triggers KASAN error.

The simplest fix would be replacing list_add_tail() with
list_move_tail(), but fundamentally it's the problem that we don't
check the double start/stop correctly.  So, the right fix here is to
add the proper checks to snd_timer_start() and snd_timer_stop() (and
their variants).

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: timer: Fix leftover link at closing
Takashi Iwai [Thu, 4 Feb 2016 16:06:13 +0000 (17:06 +0100)]
ALSA: timer: Fix leftover link at closing

commit 094fd3be87b0f102589e2d5c3fa5d06b7e20496d upstream.

In ALSA timer core, the active timer instance is managed in
active_list linked list.  Each element is added / removed dynamically
at timer start, stop and in timer interrupt.  The problem is that
snd_timer_interrupt() has a thinko and leaves the element in
active_list when it's the last opened element.  This eventually leads
to list corruption or use-after-free error.

This hasn't been revealed because we used to delete the list forcibly
in snd_timer_stop() in the past.  However, the recent fix avoids the
double-stop behavior (in commit [f784beb75ce8: ALSA: timer: Fix link
corruption due to double start or stop]), and this leak hits reality.

This patch fixes the link management in snd_timer_interrupt().  Now it
simply unlinks no matter which stream is.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: timer: Code cleanup
Takashi Iwai [Thu, 14 Jan 2016 16:01:46 +0000 (17:01 +0100)]
ALSA: timer: Code cleanup

commit c3b1681375dc6e71d89a3ae00cc3ce9e775a8917 upstream.

This is a minor code cleanup without any functional changes:
- Kill keep_flag argument from _snd_timer_stop(), as all callers pass
  only it false.
- Remove redundant NULL check in _snd_timer_stop().

Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: seq: Fix lockdep warnings due to double mutex locks
Takashi Iwai [Wed, 3 Feb 2016 07:32:44 +0000 (08:32 +0100)]
ALSA: seq: Fix lockdep warnings due to double mutex locks

commit 7f0973e973cd74aa40747c9d38844560cd184ee8 upstream.

The port subscription code uses double mutex locks for source and
destination ports, and this may become racy once when wrongly set up.
It leads to lockdep warning splat, typically triggered by fuzzer like
syzkaller, although the actual deadlock hasn't been seen, so far.

This patch simplifies the handling by reducing to two single locks, so
that no lockdep warning will be trigger any longer.

By splitting to two actions, a still-in-progress element shall be
added in one list while handling another.  For ignoring this element,
a new check is added in deliver_to_subscribers().

Along with it, the code to add/remove the subscribers list element was
cleaned up and refactored.

Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: seq: Fix race at closing in virmidi driver
Takashi Iwai [Mon, 1 Feb 2016 11:06:42 +0000 (12:06 +0100)]
ALSA: seq: Fix race at closing in virmidi driver

commit 2d1b5c08366acd46c35a2e9aba5d650cb5bf5c19 upstream.

The virmidi driver has an open race at closing its assigned rawmidi
device, and this may lead to use-after-free in

Plug the hole by properly protecting the linked list deletion and
calling in the right order in snd_virmidi_input_close().

Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: seq: Fix yet another races among ALSA timer accesses
Takashi Iwai [Sat, 30 Jan 2016 22:30:25 +0000 (23:30 +0100)]
ALSA: seq: Fix yet another races among ALSA timer accesses

commit 2cdc7b636d55cbcf42e1e6c8accd85e62d3e9ae8 upstream.

ALSA sequencer may open/close and control ALSA timer instance
dynamically either via sequencer events or direct ioctls.  These are
done mostly asynchronously, and it may call still some timer action
like snd_timer_start() while another is calling snd_timer_close().
Since the instance gets removed by snd_timer_close(), it may lead to
a use-after-free.

This patch tries to address such a race by protecting each
snd_timer_*() call via the existing spinlock and also by avoiding the
access to timer during close call.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoASoC: dpcm: fix the BE state on hw_free
Vinod Koul [Mon, 1 Feb 2016 16:56:40 +0000 (22:26 +0530)]
ASoC: dpcm: fix the BE state on hw_free

commit 5e82d2be6ee53275c72e964507518d7964c82753 upstream.

While performing hw_free, DPCM checks the BE state but leaves out
the suspend state. The suspend state needs to be checked as well,
as we might be suspended and then usermode closes rather than
resuming the audio stream.

This was found by a stress testing of system with playback in
loop and killed after few seconds running in background and second
script running suspend-resume test in loop

Signed-off-by: Vinod Koul <>
Acked-by: Liam Girdwood <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: pcm: Fix potential deadlock in OSS emulation
Takashi Iwai [Sun, 31 Jan 2016 09:32:37 +0000 (10:32 +0100)]
ALSA: pcm: Fix potential deadlock in OSS emulation

commit b248371628aad599a48540962f6b85a21a8a0c3f upstream.

There are potential deadlocks in PCM OSS emulation code while
accessing read/write and mmap concurrently.  This comes from the
infamous mmap_sem usage in copy_from/to_user().  Namely,

   snd_pcm_oss_write() ->
     &runtime->oss.params_lock ->
        copy_to_user() ->
  mmap() ->
    &mm->mmap_sem ->
      snd_pcm_oss_mmap() ->

Since we can't avoid taking params_lock from mmap code path, use
trylock variant and aborts with -EAGAIN as a workaround of this AB/BA

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: rawmidi: Fix race at copying & updating the position
Takashi Iwai [Wed, 3 Feb 2016 13:41:22 +0000 (14:41 +0100)]
ALSA: rawmidi: Fix race at copying & updating the position

commit 81f577542af15640cbcb6ef68baa4caa610cbbfc upstream.

The rawmidi read and write functions manage runtime stream status
such as runtime->appl_ptr and runtime->avail.  These point where to
copy the new data and how many bytes have been copied (or to be
read).  The problem is that rawmidi read/write call copy_from_user()
or copy_to_user(), and the runtime spinlock is temporarily unlocked
and relocked while copying user-space.  Since the current code
advances and updates the runtime status after the spin unlock/relock,
the copy and the update may be asynchronous, and eventually
runtime->avail might go to a negative value when many concurrent
accesses are done.  This may lead to memory corruption in the end.

For fixing this race, in this patch, the status update code is
performed in the same lock before the temporary unlock.  Also, the
spinlock is now taken more widely in snd_rawmidi_kernel_read1() for
protecting more properly during the whole operation.

Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check
Takashi Iwai [Mon, 1 Feb 2016 11:04:55 +0000 (12:04 +0100)]
ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check

commit cc85f7a634cfaf9f0713c6aa06d08817424db37a upstream.

NULL user-space buffer can be passed even in a normal path, thus it's
not good to spew a kernel warning with stack trace at each time.
Just drop snd_BUG_ON() macro usage there.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: seq: Fix incorrect sanity check at snd_seq_oss_synth_cleanup()
Takashi Iwai [Mon, 25 Jan 2016 10:01:47 +0000 (11:01 +0100)]
ALSA: seq: Fix incorrect sanity check at snd_seq_oss_synth_cleanup()

commit 599151336638d57b98d92338aa59c048e3a3e97d upstream.

ALSA sequencer OSS emulation code has a sanity check for currently
opened devices, but there is a thinko there, eventually it spews
warnings and skips the operation wrongly like:
  WARNING: CPU: 1 PID: 7573 at sound/core/seq/oss/seq_oss_synth.c:311

Fix this off-by-one error.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: dummy: Disable switching timer backend via sysfs
Takashi Iwai [Thu, 28 Jan 2016 06:54:16 +0000 (07:54 +0100)]
ALSA: dummy: Disable switching timer backend via sysfs

commit 7ee96216c31aabe1eb42fb91ff50dae9fcd014b2 upstream.

ALSA dummy driver can switch the timer backend between system timer
and hrtimer via its hrtimer module option.  This can be also switched
dynamically via sysfs, but it may lead to a memory corruption when
switching is done while a PCM stream is running; the stream instance
for the newly switched timer method tries to access the memory that
was allocated by another timer method although the sizes differ.

As the simplest fix, this patch just disables the switch via sysfs by
dropping the writable bit.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: compress: Disable GET_CODEC_CAPS ioctl for some architectures
Takashi Iwai [Mon, 25 Jan 2016 12:59:21 +0000 (13:59 +0100)]
ALSA: compress: Disable GET_CODEC_CAPS ioctl for some architectures

commit 462b3f161beb62eeb290f4ec52f5ead29a2f8ac7 upstream.

Some architectures like PowerPC can handle the maximum struct size in
an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by
SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit.  This
problem was revealed recently by a powerpc change, as it's now treated
as a fatal build error.

This patch is a stop-gap for that: for architectures with less than 14
bit ioctl struct size, get rid of the handling of the relevant ioctl.
We should provide an alternative equivalent ioctl code later, but for
now just paper over it.  Luckily, the compress API hasn't been used on
such architectures, so the impact must be effectively zero.

Reviewed-by: Mark Brown <>
Acked-by: Sudip Mukherjee <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: usb-audio: avoid freeing umidi object twice
Andrey Konovalov [Sat, 13 Feb 2016 08:08:06 +0000 (11:08 +0300)]
ALSA: usb-audio: avoid freeing umidi object twice

commit 07d86ca93db7e5cdf4743564d98292042ec21af7 upstream.

The 'umidi' object will be free'd on the error path by snd_usbmidi_free()
when tearing down the rawmidi interface. So we shouldn't try to free it
in snd_usbmidi_create() after having registered the rawmidi interface.

Found by KASAN.

Signed-off-by: Andrey Konovalov <>
Acked-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: usb-audio: Fix TEAC UD-501/UD-503/NT-503 usb delay
Guillaume Fougnies [Mon, 25 Jan 2016 23:28:27 +0000 (00:28 +0100)]
ALSA: usb-audio: Fix TEAC UD-501/UD-503/NT-503 usb delay

commit 5a4ff9ec8d6edd2ab1cfe8ce6a080d6e57cbea9a upstream.

TEAC UD-501/UD-503/NT-503 fail to switch properly between different
rate/format. Similar to 'Playback Design', this patch corrects the
invalid clock source error for TEAC products and avoids complete
freeze of the usb interface of 503 series.

Signed-off-by: Guillaume Fougnies <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agofix sysvfs symlinks
Al Viro [Tue, 24 Nov 2015 02:11:08 +0000 (21:11 -0500)]
fix sysvfs symlinks

commit 0ebf7f10d67a70e120f365018f1c5fce9ddc567d upstream.

The thing got broken back in 2002 - sysvfs does *not* have inline
symlinks; even short ones have bodies stored in the first block
of file.  sysv_symlink() handles that correctly; unfortunately,
attempting to look an existing symlink up will end up confusing
them for inline symlinks, and interpret the block number containing
the body as the body itself.

Nobody has noticed until now, which says something about the level
of testing sysvfs gets ;-/

Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agomedia: vb2 dma-contig: Fully cache synchronise buffers in prepare and finish
Tiffany Lin [Thu, 24 Sep 2015 09:02:36 +0000 (06:02 -0300)]
media: vb2 dma-contig: Fully cache synchronise buffers in prepare and finish

commit d9a985883fa32453d099d6293188c11d75cef1fa upstream.

In videobuf2 dma-contig memory type the prepare and finish ops, instead of
passing the number of entries in the original scatterlist as the "nents"
parameter to dma_sync_sg_for_device() and dma_sync_sg_for_cpu(), the value
returned by dma_map_sg() was used. Albeit this has been suggested in
comments of some implementations (which have since been corrected), this
is wrong.

Fixes: 199d101efdba ("v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator")

Signed-off-by: Tiffany Lin <>
Signed-off-by: Sakari Ailus <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agov4l2-compat-ioctl32: fix alignment for ARM64
Andrzej Hajda [Mon, 31 Aug 2015 11:56:15 +0000 (08:56 -0300)]
v4l2-compat-ioctl32: fix alignment for ARM64

commit 655e9780ab913a3a06d4a164d55e3b755524186d upstream.

Alignment/padding rules on AMD64 and ARM64 differs. To allow properly match
compatible ioctls on ARM64 kernels without breaking AMD64 some fields
should be aligned using compat_s64 type and in one case struct should be

Signed-off-by: Andrzej Hajda <>
[ use compat_u64 instead of compat_s64 in v4l2_input32]
Signed-off-by: Hans Verkuil <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Mauro Carvalho Chehab <>
4 years agoparisc: Fix __ARCH_SI_PREAMBLE_SIZE
Helge Deller [Sun, 10 Jan 2016 08:30:42 +0000 (09:30 +0100)]

commit e60fc5aa608eb38b47ba4ee058f306f739eb70a0 upstream.

On a 64bit kernel build the compiler aligns the _sifields union in the
struct siginfo_t on a 64bit address. The __ARCH_SI_PREAMBLE_SIZE define
compensates for this alignment and thus fixes the wait testcase of the
strace package.

The symptoms of a wrong __ARCH_SI_PREAMBLE_SIZE value is that
_sigchld.si_stime variable is missed to be copied and thus after a
copy_siginfo() will have uninitialized values.

Signed-off-by: Helge Deller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoparisc: Fix syscall restarts
Helge Deller [Mon, 21 Dec 2015 09:03:30 +0000 (10:03 +0100)]
parisc: Fix syscall restarts

commit 71a71fb5374a23be36a91981b5614590b9e722c3 upstream.

On parisc syscalls which are interrupted by signals sometimes failed to
restart and instead returned -ENOSYS which in the worst case lead to
userspace crashes.
A similiar problem existed on MIPS and was fixed by commit e967ef02
("MIPS: Fix restart of indirect syscalls").

On parisc the current syscall restart code assumes that all syscall
callers load the syscall number in the delay slot of the ble
instruction. That's how it is e.g. done in the unistd.h header file:
ble 0x100(%sr2, %r0)
ldi #syscall_nr, %r20
Because of that assumption the current code never restored %r20 before
returning to userspace.

This assumption is at least not true for code which uses the glibc
syscall() function, which instead uses this syntax:
ble 0x100(%sr2, %r0)
copy regX, %r20
where regX depend on how the compiler optimizes the code and register

This patch fixes this problem by adding code to analyze how the syscall
number is loaded in the delay branch and - if needed - copy the syscall
number to regX prior returning to userspace for the syscall restart.

Signed-off-by: Helge Deller <>
Cc: Mathieu Desnoyers <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoparisc: Drop unused MADV_xxxK_PAGES flags from asm/mman.h
Helge Deller [Sun, 22 Nov 2015 11:14:14 +0000 (12:14 +0100)]
parisc: Drop unused MADV_xxxK_PAGES flags from asm/mman.h

commit dcbf0d299c00ed4f82ea8d6e359ad88a5182f9b8 upstream.

Drop the MADV_xxK_PAGES flags, which were never used and were from a proposed
API which was never integrated into the generic Linux kernel code.

Signed-off-by: Helge Deller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agofix calculation of meta_bg descriptor backups
Andy Leiserson [Sun, 18 Oct 2015 04:36:29 +0000 (00:36 -0400)]
fix calculation of meta_bg descriptor backups

commit 904dad4742d211b7a8910e92695c0fa957483836 upstream.

"group" is the group where the backup will be placed, and is
initialized to zero in the declaration. This meant that backups for
meta_bg descriptors were erroneously written to the backup block group
descriptors in groups 1 and (desc_per_block-1).

Reproduction information:
  mke2fs -Fq -t ext4 -b 1024 -O ^resize_inode /tmp/foo.img 16G
  truncate -s 24G /tmp/foo.img
  losetup /dev/loop0 /tmp/foo.img
  mount /dev/loop0 /mnt
  resize2fs /dev/loop0
  umount /dev/loop0
  dd if=/dev/zero of=/dev/loop0 bs=1024 count=2
  e2fsck -fy /dev/loop0
  losetup -d /dev/loop0

Signed-off-by: Andy Leiserson <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agojbd2: Fix unreclaimed pages after truncate in data=journal mode
Jan Kara [Tue, 24 Nov 2015 20:34:35 +0000 (15:34 -0500)]
jbd2: Fix unreclaimed pages after truncate in data=journal mode

commit bc23f0c8d7ccd8d924c4e70ce311288cb3e61ea8 upstream.

Ted and Namjae have reported that truncated pages don't get timely
reclaimed after being truncated in data=journal mode. The following test
triggers the issue easily:

for (i = 0; i < 1000; i++) {
pwrite(fd, buf, 1024*1024, 0);
ftruncate(fd, 0);

The reason is that journal_unmap_buffer() finds that truncated buffers
are not journalled (jh->b_transaction == NULL), they are part of
checkpoint list of a transaction (jh->b_cp_transaction != NULL) and have
been already written out (!buffer_dirty(bh)). We clean such buffers but
we leave them in the checkpoint list. Since checkpoint transaction holds
a reference to the journal head, these buffers cannot be released until
the checkpoint transaction is cleaned up. And at that point we don't
call release_buffer_page() anymore so pages detached from mapping are
lingering in the system waiting for reclaim to find them and free them.

Fix the problem by removing buffers from transaction checkpoint lists
when journal_unmap_buffer() finds out they don't have to be there

Reported-and-tested-by: Namjae Jeon <>
Fixes: de1b794130b130e77ffa975bb58cb843744f9ae5
Signed-off-by: Jan Kara <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agotracing: Fix setting of start_index in find_next()
Qiu Peiyang [Thu, 31 Dec 2015 05:11:28 +0000 (13:11 +0800)]
tracing: Fix setting of start_index in find_next()

commit f36d1be2930ede0a1947686e1126ffda5d5ee1bb upstream.

When we do cat /sys/kernel/debug/tracing/printk_formats, we hit kernel
panic at t_show.

general protection fault: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 2957 Comm: sh Tainted: G W  O 3.14.55-x86_64-01062-gd4acdc7 #2
RIP: 0010:[<ffffffff811375b2>]
 [<ffffffff811375b2>] t_show+0x22/0xe0
RSP: 0000:ffff88002b4ebe80  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
RDX: 0000000000000004 RSI: ffffffff81fd26a6 RDI: ffff880032f9f7b1
RBP: ffff88002b4ebe98 R08: 0000000000001000 R09: 000000000000ffec
R10: 0000000000000000 R11: 000000000000000f R12: ffff880004d9b6c0
R13: 7365725f6d706400 R14: ffff880004d9b6c0 R15: ffffffff82020570
FS:  0000000000000000(0000) GS:ffff88003aa00000(0063) knlGS:00000000f776bc40
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000f6c02ff0 CR3: 000000002c2b3000 CR4: 00000000001007f0
Call Trace:
 [<ffffffff811dc076>] seq_read+0x2f6/0x3e0
 [<ffffffff811b749b>] vfs_read+0x9b/0x160
 [<ffffffff811b7f69>] SyS_read+0x49/0xb0
 [<ffffffff81a3a4b9>] ia32_do_call+0x13/0x13
 ---[ end trace 5bd9eb630614861e ]---
Kernel panic - not syncing: Fatal exception

When the first time find_next calls find_next_mod_format, it should
iterate the trace_bprintk_fmt_list to find the first print format of
the module. However in current code, start_index is smaller than *pos
at first, and code will not iterate the list. Latter container_of will
get the wrong address with former v, which will cause mod_fmt be a
meaningless object and so is the returned mod_fmt->fmt.

This patch will fix it by correcting the start_index. After fixed,
when the first time calls find_next_mod_format, start_index will be
equal to *pos, and code will iterate the trace_bprintk_fmt_list to
get the right module printk format, so is the returned mod_fmt->fmt.

Fixes: 102c9323c35a8 "tracing: Add __tracepoint_string() to export string pointers"
Signed-off-by: Qiu Peiyang <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoPCI: Fix minimum allocation address overwrite
Christoph Biedl [Wed, 23 Dec 2015 15:51:57 +0000 (16:51 +0100)]
PCI: Fix minimum allocation address overwrite

commit 3460baa620685c20f5ee19afb6d99d26150c382c upstream.

Commit 36e097a8a297 ("PCI: Split out bridge window override of minimum
allocation address") claimed to do no functional changes but unfortunately
did: The "min" variable is altered.  At least the AVM A1 PCMCIA adapter was
no longer detected, breaking ISDN operation.

Use a local copy of "min" to restore the previous behaviour.

[bhelgaas: avoid gcc "?:" extension for portability and readability]
Fixes: 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address")
Signed-off-by: Christoph Biedl <>
Signed-off-by: Bjorn Helgaas <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agomtd: mtdpart: fix add_mtd_partitions error path
Boris BREZILLON [Thu, 30 Jul 2015 10:18:03 +0000 (12:18 +0200)]
mtd: mtdpart: fix add_mtd_partitions error path

commit e5bae86797141e4a95e42d825f737cb36d7b8c37 upstream.

If we fail to allocate a partition structure in the middle of the partition
creation process, the already allocated partitions are never removed, which
means they are still present in the partition list and their resources are
never freed.

Signed-off-by: Boris Brezillon <>
Signed-off-by: Brian Norris <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agovTPM: fix memory allocation flag for rtce buffer at kernel boot
Hon Ching \(Vicky\) Lo [Thu, 8 Oct 2015 00:11:51 +0000 (20:11 -0400)]
vTPM: fix memory allocation flag for rtce buffer at kernel boot

commit 60ecd86c4d985750efa0ea3d8610972b09951715 upstream.

At ibm vtpm initialzation, tpm_ibmvtpm_probe() registers its interrupt
handler, ibmvtpm_interrupt, which calls ibmvtpm_crq_process to allocate
memory for rtce buffer.  The current code uses 'GFP_KERNEL' as the
type of kernel memory allocation, which resulted a warning at
kernel/lockdep.c.  This patch uses 'GFP_ATOMIC' instead so that the
allocation is high-priority and does not sleep.

Signed-off-by: Hon Ching(Vicky) Lo <>
Signed-off-by: Peter Huewe <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agowlcore/wl12xx: spi: fix NULL pointer dereference (Oops)
Uri Mashiach [Thu, 24 Dec 2015 14:05:00 +0000 (16:05 +0200)]
wlcore/wl12xx: spi: fix NULL pointer dereference (Oops)

commit e47301b06d5a65678690f04c2248fd181db1e59a upstream.

Fix the below Oops when trying to modprobe wlcore_spi.
The oops occurs because the wl1271_power_{off,on}()
function doesn't check the power() function pointer.

[   23.401447] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
[   23.409954] pgd = c0004000
[   23.412922] [00000000] *pgd=00000000
[   23.416693] Internal error: Oops: 80000007 [#1] SMP ARM
[   23.422168] Modules linked in: wl12xx wlcore mac80211 cfg80211
musb_dsps musb_hdrc usbcore usb_common snd_soc_simple_card evdev joydev
omap_rng wlcore_spi snd_soc_tlv320aic23_i2c rng_core snd_soc_tlv320aic23
c_can_platform c_can can_dev snd_soc_davinci_mcasp snd_soc_edma
snd_soc_omap omap_wdt musb_am335x cpufreq_dt thermal_sys hwmon
[   23.453253] CPU: 0 PID: 36 Comm: kworker/0:2 Not tainted
4.2.0-00002-g951efee-dirty #233
[   23.461720] Hardware name: Generic AM33XX (Flattened Device Tree)
[   23.468123] Workqueue: events request_firmware_work_func
[   23.473690] task: de32efc0 ti: de4ee000 task.ti: de4ee000
[   23.479341] PC is at 0x0
[   23.482112] LR is at wl12xx_set_power_on+0x28/0x124 [wlcore]
[   23.488074] pc : [<00000000>]    lr : [<bf2581f0>]    psr: 60000013
[   23.488074] sp : de4efe50  ip : 00000002  fp : 00000000
[   23.500162] r10: de7cdd00  r9 : dc848800  r8 : bf27af00
[   23.505663] r7 : bf27a1a8  r6 : dcbd8a80  r5 : dce0e2e0  r4 :
[   23.512536] r3 : 00000000  r2 : 00000000  r1 : 00000001  r0 :
[   23.519412] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
[   23.527109] Control: 10c5387d  Table: 9cb78019  DAC: 00000015
[   23.533160] Process kworker/0:2 (pid: 36, stack limit = 0xde4ee218)
[   23.539760] Stack: (0xde4efe50 to 0xde4f0000)


[   23.665030] [<bf2581f0>] (wl12xx_set_power_on [wlcore]) from
[<bf25f7ac>] (wlcore_nvs_cb+0x118/0xa4c [wlcore])
[   23.675604] [<bf25f7ac>] (wlcore_nvs_cb [wlcore]) from [<c04387ec>]
[   23.685784] [<c04387ec>] (request_firmware_work_func) from
[<c0058e2c>] (process_one_work+0x1b4/0x4b4)
[   23.695591] [<c0058e2c>] (process_one_work) from [<c0059168>]
[   23.704124] [<c0059168>] (worker_thread) from [<c005ee68>]
[   23.711747] [<c005ee68>] (kthread) from [<c000f598>]
[   23.719357] Code: bad PC value
[   23.722760] ---[ end trace 981be8510db9b3a9 ]---

Prevent oops by validationg power() pointer value before
calling the function.

Signed-off-by: Uri Mashiach <>
Acked-by: Igor Grinberg <>
Signed-off-by: Kalle Valo <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agowlcore/wl12xx: spi: fix oops on firmware load
Uri Mashiach [Thu, 10 Dec 2015 13:12:56 +0000 (15:12 +0200)]
wlcore/wl12xx: spi: fix oops on firmware load

commit 9b2761cb72dc41e1948c8a5512b4efd384eda130 upstream.

The maximum chunks used by the function is
The original commands array had space for
When the last chunk is used (len > 4 * WSPI_MAX_CHUNK_SIZE), the last
command is stored outside the bounds of the commands array.

Oops 5 (page fault) is generated during current wl1271 firmware load

root@debian-armhf:~# ifconfig wlan0 up
[  294.312399] Unable to handle kernel paging request at virtual address
[  294.320173] pgd = de528000
[  294.323028] [00203fc4] *pgd=00000000
[  294.326916] Internal error: Oops: 5 [#1] SMP ARM
[  294.331789] Modules linked in: bnep rfcomm bluetooth ipv6 arc4 wl12xx
wlcore mac80211 musb_dsps cfg80211 musb_hdrc usbcore usb_common
wlcore_spi omap_rng rng_core musb_am335x omap_wdt cpufreq_dt thermal_sys
[  294.351838] CPU: 0 PID: 1827 Comm: ifconfig Not tainted
4.2.0-00002-g3e9ad27-dirty #78
[  294.360154] Hardware name: Generic AM33XX (Flattened Device Tree)
[  294.366557] task: dc9d6d40 ti: de550000 task.ti: de550000
[  294.372236] PC is at __spi_validate+0xa8/0x2ac
[  294.376902] LR is at __spi_sync+0x78/0x210
[  294.381200] pc : [<c049c760>]    lr : [<c049ebe0>]    psr: 60000013
[  294.381200] sp : de551998  ip : de5519d8  fp : 00200000
[  294.393242] r10: de551c8c  r9 : de5519d8  r8 : de3a9000
[  294.398730] r7 : de3a9258  r6 : de3a9400  r5 : de551a48  r4 :
[  294.405577] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 :
[  294.412420] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment user
[  294.419918] Control: 10c5387d  Table: 9e528019  DAC: 00000015
[  294.425954] Process ifconfig (pid: 1827, stack limit = 0xde550218)
[  294.432437] Stack: (0xde551998 to 0xde552000)


[  294.883613] [<c049c760>] (__spi_validate) from [<c049ebe0>]
[  294.891670] [<c049ebe0>] (__spi_sync) from [<bf036598>]
(wl12xx_spi_raw_write+0xfc/0x148 [wlcore_spi])
[  294.901661] [<bf036598>] (wl12xx_spi_raw_write [wlcore_spi]) from
[<bf21c694>] (wlcore_boot_upload_firmware+0x1ec/0x458 [wlcore])
[  294.914038] [<bf21c694>] (wlcore_boot_upload_firmware [wlcore]) from
[<bf24532c>] (wl12xx_boot+0xc10/0xfac [wl12xx])
[  294.925161] [<bf24532c>] (wl12xx_boot [wl12xx]) from [<bf20d5cc>]
(wl1271_op_add_interface+0x5b0/0x910 [wlcore])
[  294.936364] [<bf20d5cc>] (wl1271_op_add_interface [wlcore]) from
[<bf15c4ac>] (ieee80211_do_open+0x44c/0xf7c [mac80211])
[  294.947963] [<bf15c4ac>] (ieee80211_do_open [mac80211]) from
[<c0537978>] (__dev_open+0xa8/0x110)
[  294.957307] [<c0537978>] (__dev_open) from [<c0537bf8>]
[  294.965713] [<c0537bf8>] (__dev_change_flags) from [<c0537cd0>]
[  294.974576] [<c0537cd0>] (dev_change_flags) from [<c05a55a0>]
[  294.983191] [<c05a55a0>] (devinet_ioctl) from [<c0517040>]
[  294.991244] [<c0517040>] (sock_ioctl) from [<c017d378>]
[  294.999208] [<c017d378>] (do_vfs_ioctl) from [<c017d674>]
[  295.006880] [<c017d674>] (SyS_ioctl) from [<c000f4c0>]
[  295.014835] Code: e1550004 e2444034 0a00007d e5953018 (e5942008)
[  295.021544] ---[ end trace 66ed188198f4e24e ]---

Signed-off-by: Uri Mashiach <>
Acked-by: Igor Grinberg <>
Signed-off-by: Kalle Valo <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agospi: fix parent-device reference leak
Johan Hovold [Mon, 14 Dec 2015 15:16:19 +0000 (16:16 +0100)]
spi: fix parent-device reference leak

commit 157f38f993919b648187ba341bfb05d0e91ad2f6 upstream.

Fix parent-device reference leak due to SPI-core taking an unnecessary
reference to the parent when allocating the master structure, a
reference that was never released.

Note that driver core takes its own reference to the parent when the
master device is registered.

Fixes: 49dce689ad4e ("spi doesn't need class_device")
Signed-off-by: Johan Hovold <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agospi: ti-qspi: Fix data corruption seen on r/w stress test
Vignesh R [Mon, 12 Oct 2015 07:52:02 +0000 (13:22 +0530)]
spi: ti-qspi: Fix data corruption seen on r/w stress test

commit bc27a53928981662079aa243915b443370294a03 upstream.

Writing invalid command to QSPI_SPI_CMD_REG will terminate current
transfer and de-assert the chip select. This has to be done before
calling spi_finalize_current_message(). Because
spi_finalize_current_message() will mark the end of current message
transfer and schedule the next transfer. If the chipselect is not
de-asserted before calling spi_finalize_current_message() then the next
transfer will overlap with the previous transfer leading to data
__spi_pump_message() can be called either from kthread worker context or
directly from the calling process's context. It is possible that these
two calls can race against each other. But race is serialized by
checking whether master->cur_msg == NULL (pointer to msg being handled
by transfer_one() at present). The master->cur_msg is set to NULL when
spi_finalize_current_message() is called on that message, which means
calling spi_finalize_current_message() allows __spi_sync() to pump next
message in calling process context.
Now if spi-ti-qspi calls spi_finalize_current_message() before we
terminate transfer at hardware side, if __spi_pump_message() is called
from process context then the successive transactions can overlap.

Fix this by moving writing invalid command to QSPI_SPI_CMD_REG to
before calling spi_finalize_current_message() call.

Signed-off-by: Vignesh R <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agospi: atmel: Fix DMA-setup for transfers with more than 8 bits per word
David Mosberger-Tang [Tue, 20 Oct 2015 12:26:47 +0000 (14:26 +0200)]
spi: atmel: Fix DMA-setup for transfers with more than 8 bits per word

commit 06515f83908d038d9e12ffa3dcca27a1b67f2de0 upstream.

The DMA-slave configuration depends on the whether <= 8 or > 8 bits
are transferred per word, so we need to call
atmel_spi_dma_slave_config() with the correct value.

Signed-off-by: David Mosberger <>
Signed-off-by: Nicolas Ferre <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoRevert "dm mpath: fix stalls when handling invalid ioctls"
Mauricio Faria de Oliveira [Thu, 29 Oct 2015 12:24:23 +0000 (10:24 -0200)]
Revert "dm mpath: fix stalls when handling invalid ioctls"

commit 47796938c46b943d157ac8a6f9ed4e3b98b83cf4 upstream.

This reverts commit a1989b330093578ea5470bea0a00f940c444c466.

That commit introduced a regression at least for the case of the SG_IO ioctl()
running without CAP_SYS_RAWIO capability (e.g., unprivileged users) when there
are no active paths: the ioctl() fails with the ENOTTY errno immediately rather
than blocking due to queue_if_no_path until a path becomes active, for example.

That case happens to be exercised by QEMU KVM guests with 'scsi-block' devices
(qemu "-device scsi-block" [1], libvirt "<disk type='block' device='lun'>" [2])
from multipath devices; which leads to SCSI/filesystem errors in such a guest.

More general scenarios can hit that regression too. The following demonstration
employs a SG_IO ioctl() with a standard SCSI INQUIRY command for this objective
(some output & user changes omitted for brevity and comments added for clarity).

Reverting that commit restores normal operation (queueing) in failing scenarios;
tested on linux-next (next-20151022).

1) Test-case is based on sg_simple0 [3] (just SG_IO; remove SG_GET_VERSION_NUM)

    $ cat sg_simple0.c
    ... see [3] ...
    $ sed '/SG_GET_VERSION_NUM/,/}/d' sg_simple0.c > sgio_inquiry.c
    $ gcc sgio_inquiry.c -o sgio_inquiry

2) The ioctl() works fine with active paths present.

    # multipath -l 85ag56
    85ag56 (...) dm-19 IBM     ,2145
    size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw
    |-+- policy='service-time 0' prio=0 status=active
    | |- 8:0:11:0  sdz  65:144  active undef running
    | `- 9:0:9:0   sdbf 67:144  active undef running
    `-+- policy='service-time 0' prio=0 status=enabled
      |- 8:0:12:0  sdae 65:224  active undef running
      `- 9:0:12:0  sdbo 68:32   active undef running

    $ ./sgio_inquiry /dev/mapper/85ag56
    Some of the INQUIRY command's response:
        IBM       2145              0000
    INQUIRY duration=0 millisecs, resid=0

3) The ioctl() fails with ENOTTY errno with _no_ active paths present,
   for unprivileged users (rather than blocking due to queue_if_no_path).

    # for path in $(multipath -l 85ag56 | grep -o 'sd[a-z]\+'); \
          do multipathd -k"fail path $path"; done

    # multipath -l 85ag56
    85ag56 (...) dm-19 IBM     ,2145
    size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw
    |-+- policy='service-time 0' prio=0 status=enabled
    | |- 8:0:11:0  sdz  65:144  failed undef running
    | `- 9:0:9:0   sdbf 67:144  failed undef running
    `-+- policy='service-time 0' prio=0 status=enabled
      |- 8:0:12:0  sdae 65:224  failed undef running
      `- 9:0:12:0  sdbo 68:32   failed undef running

    $ ./sgio_inquiry /dev/mapper/85ag56
    sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device

4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285);
   it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl().

    $ dmesg
    [] device-mapper: multipath: Failing path 65:144.
    [] device-mapper: multipath: Failing path 67:144.
    [] device-mapper: multipath: Failing path 65:224.
    [] device-mapper: multipath: Failing path 68:32.
    [] sgio_inquiry: sending ioctl 2285 to a partition!

5) The ioctl() only works if the SYS_CAP_RAWIO capability is present
   (then queueing happens -- in this example, queue_if_no_path is set);
   this is due to a conditional check in scsi_verify_blk_ioctl().

    # capsh --drop=cap_sys_rawio -- -c './sgio_inquiry /dev/mapper/85ag56'
    sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device

    # ./sgio_inquiry /dev/mapper/85ag56 &
    [1] 72830

    # cat /proc/72830/stack
    [<c00000171c0df700>] 0xc00000171c0df700
    [<c000000000015934>] __switch_to+0x204/0x350
    [<c000000000152d4c>] msleep+0x5c/0x80
    [<c00000000077dfb0>] dm_blk_ioctl+0x70/0x170
    [<c000000000487c40>] blkdev_ioctl+0x2b0/0x9b0
    [<c0000000003128e4>] block_ioctl+0x64/0xd0
    [<c0000000002dd3b0>] do_vfs_ioctl+0x490/0x780
    [<c0000000002dd774>] SyS_ioctl+0xd4/0xf0
    [<c000000000009358>] system_call+0x38/0xd0

6) This is the function call chain exercised in this analysis:

SYSCALL_DEFINE3(ioctl, <...>) @ fs/ioctl.c
    -> do_vfs_ioctl()
        -> vfs_ioctl()
            error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
                -> dm_blk_ioctl() @ drivers/md/dm.c
                    -> multipath_ioctl() @ drivers/md/dm-mpath.c
                        (bdev = NULL, due to no active paths)
                        if (!bdev || <...>) {
                            int err = scsi_verify_blk_ioctl(NULL, cmd);
                            if (err)
                                r = err;
                            -> scsi_verify_blk_ioctl() @ block/scsi_ioctl.c
                                if (bd && bd == bd->bd_contains) // not taken (bd = NULL)
                                    return 0;
                                if (capable(CAP_SYS_RAWIO)) // not taken (unprivileged user)
                                    return 0;
                                           "%s: sending ioctl %x to a partition!\n" <...>);

                                return -ENOIOCTLCMD;
                        return r ? : <...>
            if (error == -ENOIOCTLCMD)
                error = -ENOTTY;
                return error;

[2] (see 'disk' -> 'device')
[3] (Revision 1.2, 2002-05-03)

Signed-off-by: Mauricio Faria de Oliveira <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agosh64: fix __NR_fgetxattr
Dmitry V. Levin [Fri, 11 Dec 2015 21:41:06 +0000 (13:41 -0800)]
sh64: fix __NR_fgetxattr

commit 2d33fa1059da4c8e816627a688d950b613ec0474 upstream.

According to arch/sh/kernel/syscalls_64.S and common sense, __NR_fgetxattr
has to be defined to 259, but it doesn't.  Instead, it's defined to 269,
which is of course used by another syscall, __NR_sched_setaffinity in this

This bug was found by strace test suite.

Signed-off-by: Dmitry V. Levin <>
Acked-by: Geert Uytterhoeven <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup
xuejiufei [Fri, 5 Feb 2016 23:36:47 +0000 (15:36 -0800)]
ocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup

commit c95a51807b730e4681e2ecbdfd669ca52601959e upstream.

When recovery master down, dlm_do_local_recovery_cleanup() only remove
the $RECOVERY lock owned by dead node, but do not clear the refmap bit.
Which will make umount thread falling in dead loop migrating $RECOVERY
to the dead node.

Signed-off-by: xuejiufei <>
Reviewed-by: Joseph Qi <>
Cc: Mark Fasheh <>
Cc: Joel Becker <>
Cc: Junxiao Bi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoocfs2/dlm: ignore cleaning the migration mle that is inuse
xuejiufei [Thu, 14 Jan 2016 23:17:38 +0000 (15:17 -0800)]
ocfs2/dlm: ignore cleaning the migration mle that is inuse

commit bef5502de074b6f6fa647b94b73155d675694420 upstream.

We have found that migration source will trigger a BUG that the refcount
of mle is already zero before put when the target is down during
migration.  The situation is as follows:

  <<<<<< Now the refcount of the mle is 2.
  dlm_send_one_lockres and wait for the target to become the
  new master.
  <<<<<< o2hb detect the target down and clean the migration
  mle. Now the refcount is 1.

dlm_migrate_lockres woken, and put the mle twice when found the target
goes down which trigger the BUG with the following message:

  "ERROR: bad mle: ".

Signed-off-by: Jiufei Xue <>
Reviewed-by: Joseph Qi <>
Cc: Mark Fasheh <>
Cc: Joel Becker <>
Cc: Junxiao Bi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoocfs2: fix SGID not inherited issue
Junxiao Bi [Fri, 11 Dec 2015 21:41:03 +0000 (13:41 -0800)]
ocfs2: fix SGID not inherited issue

commit 854ee2e944b4daf795e32562a7d2f9e90ab5a6a8 upstream.

Commit 8f1eb48758aa ("ocfs2: fix umask ignored issue") introduced an
issue, SGID of sub dir was not inherited from its parents dir.  It is
because SGID is set into "inode->i_mode" in ocfs2_get_init_inode(), but
is overwritten by "mode" which don't have SGID set later.

Fixes: 8f1eb48758aa ("ocfs2: fix umask ignored issue")
Signed-off-by: Junxiao Bi <>
Cc: Mark Fasheh <>
Cc: Joel Becker <>
Acked-by: Srinivas Eeda <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agokernel/signal.c: unexport sigsuspend()
Richard Weinberger [Fri, 20 Nov 2015 23:57:21 +0000 (15:57 -0800)]
kernel/signal.c: unexport sigsuspend()

commit 9d8a765211335cfdad464b90fb19f546af5706ae upstream.

sigsuspend() is nowhere used except in signal.c itself, so we can mark it
static do not pollute the global namespace.

But this patch is more than a boring cleanup patch, it fixes a real issue
on UserModeLinux.  UML has a special console driver to display ttys using
xterm, or other terminal emulators, on the host side.  Vegard reported
that sometimes UML is unable to spawn a xterm and he's facing the
following warning:

  WARNING: CPU: 0 PID: 908 at include/linux/thread_info.h:128 sigsuspend+0xab/0xc0()

It turned out that this warning makes absolutely no sense as the UML
xterm code calls sigsuspend() on the host side, at least it tries.  But
as the kernel itself offers a sigsuspend() symbol the linker choose this
one instead of the glibc wrapper.  Interestingly this code used to work
since ever but always blocked signals on the wrong side.  Some recent
kernel change made the WARN_ON() trigger and uncovered the bug.

It is a wonderful example of how much works by chance on computers. :-)

Fixes: 68f3f16d9ad0f1 ("new helper: sigsuspend()")
Signed-off-by: Richard Weinberger <>
Reported-by: Vegard Nossum <>
Tested-by: Vegard Nossum <>
Acked-by: Oleg Nesterov <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agofat: fix fake_offset handling on error path
OGAWA Hirofumi [Fri, 20 Nov 2015 23:57:15 +0000 (15:57 -0800)]
fat: fix fake_offset handling on error path

commit 928a477102c4fc6739883415b66987207e3502f4 upstream.

For the root directory, .  and ..  are faked (using dir_emit_dots()) and
ctx->pos is reset from 2 to 0.

A corrupted root directory could cause fat_get_entry() to fail, but
->iterate() (fat_readdir()) reports progress to the VFS (with ctx->pos
rewound to 0), so any following calls to ->iterate() continue to return
the same entries again and again.

The result is that userspace will never see the end of the directory,
causing e.g.  'ls' to hang in a getdents() loop.

[ cleanup and make sure to correct fake_offset]
Reported-by: Vegard Nossum <>
Tested-by: Vegard Nossum <>
Signed-off-by: Richard Weinberger <>
Signed-off-by: OGAWA Hirofumi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoremoteproc: avoid stack overflow in debugfs file
Arnd Bergmann [Fri, 20 Nov 2015 17:26:07 +0000 (18:26 +0100)]
remoteproc: avoid stack overflow in debugfs file

commit 92792e48e2ae6051af30468a87994b5432da2f06 upstream.

Recent gcc versions warn about reading from a negative offset of
an on-stack array:

drivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write':
drivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]' may be used uninitialized in this function [-Wmaybe-uninitialized]

I don't see anything in sys_write() that prevents us from
being called with a zero 'count' argument, so we should
add an extra check in rproc_recovery_write() to prevent the
access and avoid the warning.

Signed-off-by: Arnd Bergmann <>
Fixes: 2e37abb89a2e ("remoteproc: create a 'recovery' debugfs entry")
Signed-off-by: Ohad Ben-Cohen <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoproc: actually make proc_fd_permission() thread-friendly
Oleg Nesterov [Sat, 7 Nov 2015 00:30:06 +0000 (16:30 -0800)]
proc: actually make proc_fd_permission() thread-friendly

commit 54708d2858e79a2bdda10bf8a20c80eb96c20613 upstream.

The commit 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly")
fixed the access to /proc/self/fd from sub-threads, but introduced another
problem: a sub-thread can't access /proc/<tid>/fd/ or /proc/thread-self/fd
if generic_permission() fails.

Change proc_fd_permission() to check same_thread_group(pid_task(), current).

Fixes: 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly")
Reported-by: "Jin, Yihua" <>
Signed-off-by: Oleg Nesterov <>
Cc: "Eric W. Biederman" <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoHID: usbhid: fix recursive deadlock
Ioan-Adrian Ratiu [Fri, 20 Nov 2015 20:19:02 +0000 (22:19 +0200)]
HID: usbhid: fix recursive deadlock

commit e470127e9606b1fa151c4184243e61296d1e0c0f upstream.

The critical section protected by usbhid->lock in hid_ctrl() is too
big and because of this it causes a recursive deadlock. "Too big" means
the case statement and the call to hid_input_report() do not need to be
protected by the spinlock (no URB operations are done inside them).

The deadlock happens because in certain rare cases drivers try to grab
the lock while handling the ctrl irq which grabs the lock before them
as described above. For example newer wacom tablets like 056a:033c try
to reschedule proximity reads from wacom_intuos_schedule_prox_event()
calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
which tries to grab the usbhid lock already held by hid_ctrl().

There are two ways to get out of this deadlock:
    1. Make the drivers work "around" the ctrl critical region, in the
    wacom case for ex. by delaying the scheduling of the proximity read
    request itself to a workqueue.
    2. Shrink the critical region so the usbhid lock protects only the
    instructions which modify usbhid state, calling hid_input_report()
    with the spinlock unlocked, allowing the device driver to grab the
    lock first, finish and then grab the lock afterwards in hid_ctrl().

This patch implements the 2nd solution.

Signed-off-by: Ioan-Adrian Ratiu <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Jason Gerecke <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrivers/base/memory.c: prohibit offlining of memory blocks with missing sections
Seth Jennings [Fri, 11 Dec 2015 21:40:57 +0000 (13:40 -0800)]
drivers/base/memory.c: prohibit offlining of memory blocks with missing sections

commit 26bbe7ef6d5cdc7ec08cba6d433fca4060f258f3 upstream.

Commit bdee237c0343 ("x86: mm: Use 2GB memory block size on large-memory
x86-64 systems") and 982792c782ef ("x86, mm: probe memory block size for
generic x86 64bit") introduced large block sizes for x86.  This made it
possible to have multiple sections per memory block where previously,
there was a only every one section per block.

Since blocks consist of contiguous ranges of section, there can be holes
in the blocks where sections are not present.  If one attempts to
offline such a block, a crash occurs since the code is not designed to
deal with this.

This patch is a quick fix to gaurd against the crash by not allowing
blocks with non-present sections to be offlined.


Signed-off-by: Seth Jennings <>
Reported-by: Andrew Banman <>
Cc: Daniel J Blueman <>
Cc: Yinghai Lu <>
Cc: Greg KH <>
Cc: Russ Anderson <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodm btree: fix leak of bufio-backed block in btree_split_sibling error path
Mike Snitzer [Mon, 23 Nov 2015 21:24:45 +0000 (16:24 -0500)]
dm btree: fix leak of bufio-backed block in btree_split_sibling error path

commit 30ce6e1cc5a0f781d60227e9096c86e188d2c2bd upstream.

The block allocated at the start of btree_split_sibling() is never
released if later insert_at() fails.

Fix this by releasing the previously allocated bufio block using

Reported-by: Mikulas Patocka <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_hash - Only export and import on sockets with data
Herbert Xu [Sun, 1 Nov 2015 09:11:19 +0000 (17:11 +0800)]
crypto: algif_hash - Only export and import on sockets with data

commit 4afa5f9617927453ac04b24b584f6c718dfb4f45 upstream.

The hash_accept call fails to work on sockets that have not received
any data.  For some algorithm implementations it may cause crashes.

This patch fixes this by ensuring that we only export and import on
sockets that have received data.

Reported-by: Harsh Jain <>
Signed-off-by: Herbert Xu <>
Tested-by: Stephan Mueller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agorecordmcount: Fix endianness handling bug for nop_mcount
libin [Tue, 3 Nov 2015 00:58:47 +0000 (08:58 +0800)]
recordmcount: Fix endianness handling bug for nop_mcount

commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream.

In nop_mcount, shdr->sh_offset and welp->r_offset should handle
endianness properly, otherwise it will trigger Segmentation fault
if the recordmcount main and file.o have different endianness.

Signed-off-by: Li Bin <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxhci: fix placement of call to usb_disabled()
Greg Kroah-Hartman [Sun, 31 Jan 2016 19:11:58 +0000 (11:11 -0800)]
xhci: fix placement of call to usb_disabled()

In the backport of 1eaf35e4dd592c59041bc1ed3248c46326da1f5f, the call to
usb_disabled() was too late, after we had already done some allocation.
Move that call to the top of the function instead, making the logic
match what is intended and is in the original patch.

Reported-by: Luis Henriques <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoLinux 3.14.60 v3.14.60
Greg Kroah-Hartman [Fri, 29 Jan 2016 06:00:38 +0000 (22:00 -0800)]
Linux 3.14.60

4 years agoarm64: restore bogomips information in /proc/cpuinfo
Yang Shi [Wed, 18 Nov 2015 18:48:55 +0000 (10:48 -0800)]
arm64: restore bogomips information in /proc/cpuinfo

commit 92e788b749862ebe9920360513a718e5dd4da7a9 upstream.

As previously reported, some userspace applications depend on bogomips
showed by /proc/cpuinfo. Although there is much less legacy impact on
aarch64 than arm, it does break libvirt.

This patch reverts commit 326b16db9f69 ("arm64: delay: don't bother
reporting bogomips in /proc/cpuinfo"), but with some tweak due to
context change and without the pr_info().

Fixes: 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo")
Signed-off-by: Yang Shi <>
Acked-by: Will Deacon <>
Cc: <> # 3.12+
Signed-off-by: Catalin Marinas <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agomn10300: Select CONFIG_HAVE_UID16 to fix build failure
Guenter Roeck [Sat, 28 Nov 2015 16:52:04 +0000 (08:52 -0800)]
mn10300: Select CONFIG_HAVE_UID16 to fix build failure

commit c86576ea114a9a881cf7328dc7181052070ca311 upstream.

mn10300 builds fail with

fs/stat.c: In function 'cp_old_stat':
fs/stat.c:163:2: error: 'old_uid_t' undeclared

ipc/util.c: In function 'ipc64_perm_to_ipc_perm':
ipc/util.c:540:2: error: 'old_uid_t' undeclared

Select CONFIG_HAVE_UID16 and remove local definition of CONFIG_UID16
to fix the problem.

Fixes: fbc416ff8618 ("arm64: fix building without CONFIG_UID16")
Cc: Arnd Bergmann <>
Acked-by: Arnd Bergmann <>
Acked-by: Acked-by: David Howells <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoopenrisc: fix CONFIG_UID16 setting
Andrew Morton [Fri, 17 Jul 2015 23:23:28 +0000 (16:23 -0700)]
openrisc: fix CONFIG_UID16 setting

commit 04ea1e91f85615318ea91ce8ab50cb6a01ee4005 upstream.


  kernel/uid16.c: In function 'SYSC_setgroups16':
  kernel/uid16.c:184:2: error: implicit declaration of function 'groups_alloc'
  kernel/uid16.c:184:13: warning: assignment makes pointer from integer without a cast

openrisc shouldn't be setting CONFIG_UID16 when CONFIG_MULTIUSER=n.

Fixes: 2813893f8b197a1 ("kernel: conditionally support non-root users, groups and capabilities")
Reported-by: Fengguang Wu <>
Cc: Iulia Manda <>
Cc: Josh Triplett <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoHID: core: Avoid uninitialized buffer access
Richard Purdie [Fri, 18 Sep 2015 23:31:33 +0000 (16:31 -0700)]
HID: core: Avoid uninitialized buffer access

commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.

hid_connect adds various strings to the buffer but they're all
conditional. You can find circumstances where nothing would be written
to it but the kernel will still print the supposedly empty buffer with
printk. This leads to corruption on the console/in the logs.

Ensure buf is initialized to an empty string.

Signed-off-by: Richard Purdie <>
[dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
Cc: Jiri Kosina <>
Signed-off-by: Darren Hart <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoparisc iommu: fix panic due to trying to allocate too large region
Mikulas Patocka [Mon, 30 Nov 2015 19:47:46 +0000 (14:47 -0500)]
parisc iommu: fix panic due to trying to allocate too large region

commit e46e31a3696ae2d66f32c207df3969613726e636 upstream.

When using the Promise TX2+ SATA controller on PA-RISC, the system often
crashes with kernel panic, for example just writing data with the dd
utility will make it crash.

Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources

CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
 [<000000004021497c>] show_stack+0x14/0x20
 [<0000000040410bf0>] dump_stack+0x88/0x100
 [<000000004023978c>] panic+0x124/0x360
 [<0000000040452c18>] sba_alloc_range+0x698/0x6a0
 [<0000000040453150>] sba_map_sg+0x260/0x5b8
 [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata]
 [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata]
 [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata]
 [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130
 [<000000004049da34>] scsi_request_fn+0x6e4/0x970
 [<00000000403e95a8>] __blk_run_queue+0x40/0x60
 [<00000000403e9d8c>] blk_run_queue+0x3c/0x68
 [<000000004049a534>] scsi_run_queue+0x2a4/0x360
 [<000000004049be68>] scsi_end_request+0x1a8/0x238
 [<000000004049de84>] scsi_io_completion+0xfc/0x688
 [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0

The cause of the crash is not exhaustion of the IOMMU space, there is
plenty of free pages. The function sba_alloc_range is called with size
0x11000, thus the pages_needed variable is 0x11. The function
sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
0x10 (because dma_get_seg_boundary(dev) returns 0xffff).

The function sba_search_bitmap attempts to allocate 17 pages that must not
cross 16-page boundary - it can't satisfy this requirement
(iommu_is_span_boundary always returns true) and fails even if there are
many free entries in the IOMMU space.

How did it happen that we try to allocate 17 pages that don't cross
16-page boundary? The cause is in the function iommu_coalesce_chunks. This
function tries to coalesce adjacent entries in the scatterlist. The
function does several checks if it may coalesce one entry with the next,
one of those checks is this:

if (startsg->length + dma_len > max_seg_size)

When it finishes coalescing adjacent entries, it allocates the mapping:

sg_dma_len(contig_sg) = dma_len;
dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
sg_dma_address(contig_sg) =
| (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT)
| dma_offset;

It is possible that (startsg->length + dma_len > max_seg_size) is false
(we are just near the 0x10000 max_seg_size boundary), so the funcion
decides to coalesce this entry with the next entry. When the coalescing
succeeds, the function performs
dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
to allocate 17 pages for a device that must not cross 16-page boundary.

To fix the bug, we must make sure that dma_len after addition of
dma_offset and alignment doesn't cross the segment boundary. I.e. change
if (startsg->length + dma_len > max_seg_size)
if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size)

This patch makes this change (it precalculates max_seg_boundary at the
beginning of the function iommu_coalesce_chunks). I also added a check
that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
not needed for Promise TX2+ SATA, but it may be needed for other devices
that have dma_get_seg_boundary lower than dma_get_max_seg_size).

Signed-off-by: Mikulas Patocka <>
Signed-off-by: Helge Deller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoarm64: mm: ensure that the zero page is visible to the page table walker
Will Deacon [Thu, 10 Dec 2015 16:05:36 +0000 (16:05 +0000)]
arm64: mm: ensure that the zero page is visible to the page table walker

commit 32d6397805d00573ce1fa55f408ce2bca15b0ad3 upstream.

In paging_init, we allocate the zero page, memset it to zero and then
point TTBR0 to it in order to avoid speculative fetches through the
identity mapping.

In order to guarantee that the freshly zeroed page is indeed visible to
the page table walker, we need to execute a dsb instruction prior to
writing the TTBR.

Signed-off-by: Will Deacon <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoarm64: Clear out any singlestep state on a ptrace detach operation
John Blackwood [Mon, 7 Dec 2015 11:50:34 +0000 (11:50 +0000)]
arm64: Clear out any singlestep state on a ptrace detach operation

commit 5db4fd8c52810bd9740c1240ebf89223b171aa70 upstream.

Make sure to clear out any ptrace singlestep state when a ptrace(2)
PTRACE_DETACH call is made on arm64 systems.

Otherwise, the previously ptraced task will die off with a SIGTRAP
signal if the debugger just previously singlestepped the ptraced task.

Signed-off-by: John Blackwood <>
[will: added comment to justify why this is in the arch code]
Signed-off-by: Will Deacon <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoarm64: fix building without CONFIG_UID16
Arnd Bergmann [Fri, 20 Nov 2015 11:12:21 +0000 (12:12 +0100)]
arm64: fix building without CONFIG_UID16

commit fbc416ff86183e2203cdf975e2881d7c164b0271 upstream.

As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16
disabled currently fails because the system call table still needs to
reference the individual function entry points that are provided by
kernel/sys_ni.c in this case, and the declarations are hidden inside
of #ifdef CONFIG_UID16:

arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function)
 __SYSCALL(__NR_lchown, sys_lchown16)

I believe this problem only exists on ARM64, because older architectures
tend to not need declarations when their system call table is built
in assembly code, while newer architectures tend to not need UID16
support. ARM64 only uses these system calls for compatibility with
32-bit ARM binaries.

This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is
set unconditionally on ARM64 with CONFIG_COMPAT, so we see the
declarations whenever we need them, but otherwise the behavior is

Fixes: af1839eb4bd4 ("Kconfig: clean up the long arch list for the UID16 config option")
Signed-off-by: Arnd Bergmann <>
Acked-by: Will Deacon <>
Signed-off-by: Catalin Marinas <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoarm64: KVM: Fix AArch32 to AArch64 register mapping
Marc Zyngier [Mon, 16 Nov 2015 10:28:17 +0000 (10:28 +0000)]
arm64: KVM: Fix AArch32 to AArch64 register mapping

commit c0f0963464c24e034b858441205455bf2a5d93ad upstream.

When running a 32bit guest under a 64bit hypervisor, the ARMv8
architecture defines a mapping of the 32bit registers in the 64bit
space. This includes banked registers that are being demultiplexed
over the 64bit ones.

On exceptions caused by an operation involving a 32bit register, the
HW exposes the register number in the ESR_EL2 register. It was so
far understood that SW had to distinguish between AArch32 and AArch64
accesses (based on the current AArch32 mode and register number).

It turns out that I misinterpreted the ARM ARM, and the clue is in
D1.20.1: "For some exceptions, the exception syndrome given in the
ESR_ELx identifies one or more register numbers from the issued
instruction that generated the exception. Where the exception is
taken from an Exception level using AArch32 these register numbers
give the AArch64 view of the register."

Which means that the HW is already giving us the translated version,
and that we shouldn't try to interpret it at all (for example, doing
an MMIO operation from the IRQ mode using the LR register leads to
very unexpected behaviours).

The fix is thus not to perform a call to vcpu_reg32() at all from
vcpu_reg(), and use whatever register number is supplied directly.
The only case we need to find out about the mapping is when we
actively generate a register access, which only occurs when injecting
a fault in a guest.

Reviewed-by: Robin Murphy <>
Signed-off-by: Marc Zyngier <>
Signed-off-by: Christoffer Dall <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoscripts/ support data in text section on powerpc
Ulrich Weigand [Tue, 12 Jan 2016 12:14:22 +0000 (23:14 +1100)]
scripts/ support data in text section on powerpc

commit 2e50c4bef77511b42cc226865d6bc568fa7f8769 upstream.

If a text section starts out with a data blob before the first
function start label, disassembly parsing doing in
gets confused on powerpc, leading to creation of corrupted module

This was not a problem so far since the compiler would never create
such text sections.  However, this has changed with a recent change
in GCC 6 to support distances of > 2GB between a function and its
assoicated TOC in the ELFv2 ABI, exposing this problem.

There is already code in to handle such data blobs
on the sparc64 platform.  This patch uses the same method to handle
those on powerpc as well.

Acked-by: Steven Rostedt <>
Signed-off-by: Ulrich Weigand <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agopowerpc: Make {cmp}xchg* and their atomic_ versions fully ordered
Boqun Feng [Mon, 2 Nov 2015 01:30:32 +0000 (09:30 +0800)]
powerpc: Make {cmp}xchg* and their atomic_ versions fully ordered

commit 81d7a3294de7e9828310bbf986a67246b13fa01e upstream.

According to memory-barriers.txt, xchg*, cmpxchg* and their atomic_
versions all need to be fully ordered, however they are now just
RELEASE+ACQUIRE, which are not fully ordered.

__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics")

This patch depends on patch "powerpc: Make value-returning atomics fully
ordered" for PPC_ATOMIC_ENTRY_BARRIER definition.

Signed-off-by: Boqun Feng <>
Reviewed-by: Paul E. McKenney <>
Acked-by: Peter Zijlstra (Intel) <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agopowerpc: Make value-returning atomics fully ordered
Boqun Feng [Mon, 2 Nov 2015 01:30:31 +0000 (09:30 +0800)]
powerpc: Make value-returning atomics fully ordered

commit 49e9cf3f0c04bf76ffa59242254110309554861d upstream.

According to memory-barriers.txt:

> Any atomic operation that modifies some state in memory and returns
> information about the state (old or new) implies an SMP-conditional
> general memory barrier (smp_mb()) on each side of the actual
> operation ...

Which mean these operations should be fully ordered. However on PPC,
PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation,
which is currently "lwsync" if SMP=y. The leading "lwsync" can not
guarantee fully ordered atomics, according to Paul Mckenney:

To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
the fully-ordered semantics.

This also makes futex atomics fully ordered, which can avoid possible
memory ordering problems if userspace code relies on futex system call
for fully ordered semantics.

Fixes: b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics")
Signed-off-by: Boqun Feng <>
Reviewed-by: Paul E. McKenney <>
Acked-by: Peter Zijlstra (Intel) <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agopowerpc/tm: Check for already reclaimed tasks
Michael Neuling [Thu, 19 Nov 2015 04:44:45 +0000 (15:44 +1100)]
powerpc/tm: Check for already reclaimed tasks

commit 7f821fc9c77a9b01fe7b1d6e72717b33d8d64142 upstream.

Currently we can hit a scenario where we'll tm_reclaim() twice.  This
results in a TM bad thing exception because the second reclaim occurs
when not in suspend mode.

The scenario in which this can happen is the following.  We attempt to
deliver a signal to userspace.  To do this we need obtain the stack
pointer to write the signal context.  To get this stack pointer we
must tm_reclaim() in case we need to use the checkpointed stack
pointer (see get_tm_stackpointer()).  Normally we'd then return
directly to userspace to deliver the signal without going through

Unfortunatley, if at this point we get an error (such as a bad
userspace stack pointer), we need to exit the process.  The exit will
result in a __switch_to().  __switch_to() will attempt to save the
process state which results in another tm_reclaim().  This
tm_reclaim() now causes a TM Bad Thing exception as this state has
already been saved and the processor is no longer in TM suspend mode.

This patch checks the state of the MSR to ensure we are TM suspended
before we attempt the tm_reclaim().  If we've already saved the state
away, we should no longer be in TM suspend mode.  This has the
additional advantage of checking for a potential TM Bad Thing

Found using syscall fuzzer.

Fixes: fb09692e71f1 ("powerpc: Add reclaim and recheckpoint functions for context switching transactional memory processes")
Signed-off-by: Michael Neuling <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agopowerpc/tm: Block signal return setting invalid MSR state
Michael Neuling [Thu, 19 Nov 2015 04:44:44 +0000 (15:44 +1100)]
powerpc/tm: Block signal return setting invalid MSR state

commit d2b9d2a5ad5ef04ff978c9923d19730cb05efd55 upstream.

Currently we allow both the MSR T and S bits to be set by userspace on
a signal return.  Unfortunately this is a reserved configuration and
will cause a TM Bad Thing exception if attempted (via rfid).

This patch checks for this case in both the 32 and 64 bit signals
code.  If both T and S are set, we mark the context as invalid.

Found using a syscall fuzzer.

Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context")
Signed-off-by: Michael Neuling <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoteam: Replace rcu_read_lock with a mutex in team_vlan_rx_kill_vid
Ido Schimmel [Mon, 18 Jan 2016 15:30:22 +0000 (17:30 +0200)]
team: Replace rcu_read_lock with a mutex in team_vlan_rx_kill_vid

[ Upstream commit 60a6531bfe49555581ccd65f66a350cc5693fcde ]

We can't be within an RCU read-side critical section when deleting
VLANs, as underlying drivers might sleep during the hardware operation.
Therefore, replace the RCU critical section with a mutex. This is
consistent with team_vlan_rx_add_vid.

Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
Acked-by: Jiri Pirko <>
Signed-off-by: Ido Schimmel <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoppp, slip: Validate VJ compression slot parameters completely
Ben Hutchings [Sun, 1 Nov 2015 16:22:53 +0000 (16:22 +0000)]
ppp, slip: Validate VJ compression slot parameters completely

[ Upstream commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae ]

Currently slhc_init() treats out-of-range values of rslots and tslots
as equivalent to 0, except that if tslots is too large it will
dereference a null pointer (CVE-2015-7799).

Add a range-check at the top of the function and make it return an
ERR_PTR() on error instead of NULL.  Change the callers accordingly.

Compile-tested only.

Reported-by: 郭永刚 <>
Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoisdn_ppp: Add checks for allocation failure in isdn_ppp_open()
Ben Hutchings [Sun, 1 Nov 2015 16:21:24 +0000 (16:21 +0000)]
isdn_ppp: Add checks for allocation failure in isdn_ppp_open()

[ Upstream commit 0baa57d8dc32db78369d8b5176ef56c5e2e18ab3 ]

Compile-tested only.

Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoipv6: update skb->csum when CE mark is propagated
Eric Dumazet [Fri, 15 Jan 2016 12:56:56 +0000 (04:56 -0800)]
ipv6: update skb->csum when CE mark is propagated

[ Upstream commit 34ae6a1aa0540f0f781dd265366036355fdc8930 ]

When a tunnel decapsulates the outer header, it has to comply
with RFC 6080 and eventually propagate CE mark into inner header.

It turns out IP6_ECN_set_ce() does not correctly update skb->csum
for CHECKSUM_COMPLETE packets, triggering infamous "hw csum failure"
messages and stack traces.

Signed-off-by: Eric Dumazet <>
Acked-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agophonet: properly unshare skbs in phonet_rcv()
Eric Dumazet [Tue, 12 Jan 2016 16:58:00 +0000 (08:58 -0800)]
phonet: properly unshare skbs in phonet_rcv()

[ Upstream commit 7aaed57c5c2890634cfadf725173c7c68ea4cb4f ]

Ivaylo Dimitrov reported a regression caused by commit 7866a621043f
("dev: add per net_device packet type chains").

skb->dev becomes NULL and we crash in __netif_receive_skb_core().

Before above commit, different kind of bugs or corruptions could happen
without major crash.

But the root cause is that phonet_rcv() can queue skb without checking
if skb is shared or not.

Many thanks to Ivaylo Dimitrov for his help, diagnosis and tests.

Reported-by: Ivaylo Dimitrov <>
Tested-by: Ivaylo Dimitrov <>
Signed-off-by: Eric Dumazet <>
Cc: Remi Denis-Courmont <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agobonding: Prevent IPv6 link local address on enslaved devices
Karl Heiss [Mon, 11 Jan 2016 13:28:43 +0000 (08:28 -0500)]
bonding: Prevent IPv6 link local address on enslaved devices

[ Upstream commit 03d84a5f83a67e692af00a3d3901e7820e3e84d5 ]

Commit 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
undoes the fix provided by commit c2edacf80e15 ("bonding / ipv6: no addrconf
for slaves separately from master") by effectively setting the slave flag
after the slave has been opened.  If the slave comes up quickly enough, it
will go through the IPv6 addrconf before the slave flag has been set and
will get a link local IPv6 address.

In order to ensure that addrconf knows to ignore the slave devices on state
change, set IFF_SLAVE before dev_open() during bonding enslavement.

Fixes: 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
Signed-off-by: Karl Heiss <>
Signed-off-by: Jay Vosburgh <>
Reviewed-by: Jarod Wilson <>
Signed-off-by: Andy Gospodarek <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agotcp_yeah: don't set ssthresh below 2
Neal Cardwell [Mon, 11 Jan 2016 18:42:43 +0000 (13:42 -0500)]
tcp_yeah: don't set ssthresh below 2

[ Upstream commit 83d15e70c4d8909d722c0d64747d8fb42e38a48f ]

For tcp_yeah, use an ssthresh floor of 2, the same floor used by Reno
and CUBIC, per RFC 5681 (equation 4).

tcp_yeah_ssthresh() was sometimes returning a 0 or negative ssthresh
value if the intended reduction is as big or bigger than the current
cwnd. Congestion control modules should never return a zero or
negative ssthresh. A zero ssthresh generally results in a zero cwnd,
causing the connection to stall. A negative ssthresh value will be
interpreted as a u32 and will set a target cwnd for PRR near 4

Oleksandr Natalenko reported that a system using tcp_yeah with ECN
could see a warning about a prior_cwnd of 0 in
tcp_cwnd_reduction(). Testing verified that this was due to
tcp_yeah_ssthresh() misbehaving in this way.

Reported-by: Oleksandr Natalenko <>
Signed-off-by: Neal Cardwell <>
Signed-off-by: Yuchung Cheng <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agonet: sctp: prevent writes to cookie_hmac_alg from accessing invalid memory
Sasha Levin [Thu, 7 Jan 2016 19:52:43 +0000 (14:52 -0500)]
net: sctp: prevent writes to cookie_hmac_alg from accessing invalid memory

[ Upstream commit 320f1a4a175e7cd5d3f006f92b4d4d3e2cbb7bb5 ]

proc_dostring() needs an initialized destination string, while the one
provided in proc_sctp_do_hmac_alg() contains stack garbage.

Thus, writing to cookie_hmac_alg would strlen() that garbage and end up
accessing invalid memory.

Fixes: 3c68198e7 ("sctp: Make hmac algorithm selection for cookie generation dynamic")
Signed-off-by: Sasha Levin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>