4 years agoLinux 4.3.6 v4.3.6
Greg Kroah-Hartman [Fri, 19 Feb 2016 22:35:24 +0000 (14:35 -0800)]
Linux 4.3.6

4 years agoHID: multitouch: fix input mode switching on some Elan panels
Benjamin Tissoires [Tue, 1 Dec 2015 11:41:38 +0000 (12:41 +0100)]
HID: multitouch: fix input mode switching on some Elan panels

commit 73e7d63efb4d774883a338997943bfa59e127085 upstream.

as reported by

This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature
reports on demand for Win8 devices") as the origin of the problem but this
commit actually masked 2 firmware bugs that are annihilating each other:

The report descriptor declares two features in reports 3 and 5:

0x05, 0x0d,                    // Usage Page (Digitizers)             318
0x09, 0x0e,                    // Usage (Device Configuration)        320
0xa1, 0x01,                    // Collection (Application)            322
0x85, 0x03,                    //  Report ID (3)                      324
0x09, 0x22,                    //  Usage (Finger)                     326
0xa1, 0x00,                    //  Collection (Physical)              328
0x09, 0x52,                    //   Usage (Inputmode)                 330
0x15, 0x00,                    //   Logical Minimum (0)               332
0x25, 0x0a,                    //   Logical Maximum (10)              334
0x75, 0x08,                    //   Report Size (8)                   336
0x95, 0x02,                    //   Report Count (2)                  338
0xb1, 0x02,                    //   Feature (Data,Var,Abs)            340
0xc0,                          //  End Collection                     342
0x09, 0x22,                    //  Usage (Finger)                     343
0xa1, 0x00,                    //  Collection (Physical)              345
0x85, 0x05,                    //   Report ID (5)                     347
0x09, 0x57,                    //   Usage (Surface Switch)            349
0x09, 0x58,                    //   Usage (Button Switch)             351
0x15, 0x00,                    //   Logical Minimum (0)               353
0x75, 0x01,                    //   Report Size (1)                   355
0x95, 0x02,                    //   Report Count (2)                  357
0x25, 0x03,                    //   Logical Maximum (3)               359
0xb1, 0x02,                    //   Feature (Data,Var,Abs)            361
0x95, 0x0e,                    //   Report Count (14)                 363
0xb1, 0x03,                    //   Feature (Cnst,Var,Abs)            365
0xc0,                          //  End Collection                     367

The report ID 3 presents 2 input mode features, while only the first one
is handled by the device. Given that we did not checked if one was
previously assigned, we were dealing with the ignored featured and we
should never have been able to switch this panel into the multitouch mode.

However, the firmware presents an other bugs which allowed 6d4f5440
to counteract the faulty report descriptor. When we request the values
of the feature 5, the firmware answers "03 03 00". The fields are correct
but the report id is wrong. Before 6d4f5440, we retrieved all the features
and injected them in the system. So when we called report 5, we injected
in the system the report 3 with the values "03 00".
Setting the second input mode to 03 in this report changed it to "03 03"
and the touchpad switched to the mt mode. We could have set anything
in the second field because the actual value (the first 03 in this report)
was given by the query of report ID 5.

To sum up: 2 bugs in the firmware were hiding that we were accessing the
wrong feature.

Signed-off-by: Benjamin Tissoires <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agomm, vmstat: fix wrong WQ sleep when memory reclaim doesn't make any progress
Tetsuo Handa [Fri, 5 Feb 2016 23:36:30 +0000 (15:36 -0800)]
mm, vmstat: fix wrong WQ sleep when memory reclaim doesn't make any progress

commit 564e81a57f9788b1475127012e0fd44e9049e342 upstream.

Jan Stancek has reported that system occasionally hanging after "oom01"
testcase from LTP triggers OOM.  Guessing from a result that there is a
kworker thread doing memory allocation and the values between "Node 0
Normal free:" and "Node 0 Normal:" differs when hanging, vmstat is not
up-to-date for some reason.

According to commit 373ccbe59270 ("mm, vmstat: allow WQ concurrency to
discover memory reclaim doesn't make any progress"), it meant to force
the kworker thread to take a short sleep, but it by error used
schedule_timeout(1).  We missed that schedule_timeout() in state
TASK_RUNNING doesn't do anything.

Fix it by using schedule_timeout_uninterruptible(1) which forces the
kworker thread to take a short sleep in order to make sure that vmstat
is up-to-date.

Fixes: 373ccbe59270 ("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress")
Signed-off-by: Tetsuo Handa <>
Reported-by: Jan Stancek <>
Acked-by: Michal Hocko <>
Cc: Tejun Heo <>
Cc: Cristopher Lameter <>
Cc: Joonsoo Kim <>
Cc: Arkadiusz Miskiewicz <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
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/pipe.c: return error code rather than 0 in pipe_write()
Eric Biggers [Sat, 17 Oct 2015 21:26:09 +0000 (16:26 -0500)]
fs/pipe.c: return error code rather than 0 in pipe_write()

commit 6ae08069939f17422835448acae76bda8d96b16a upstream.

pipe_write() would return 0 if it failed to merge the beginning of the
data to write with the last, partially filled pipe buffer.  It should
return an error code instead.  Userspace programs could be confused by
write() returning 0 when called with a nonzero 'count'.

The EFAULT error case was a regression from f0d1bec9d5 ("new helper:
copy_page_from_iter()"), while the ops->confirm() error case was a much
older bug.

Test program:

#include <assert.h>
#include <errno.h>
#include <unistd.h>

int main(void)
int fd[2];
char data[1] = {0};

assert(0 == pipe(fd));
assert(1 == write(fd[1], data, 1));

/* prior to this patch, write() returned 0 here  */
assert(-1 == write(fd[1], NULL, 1));
assert(errno == EFAULT);

Signed-off-by: Eric Biggers <>
Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agozsmalloc: fix migrate_zspage-zs_free race condition
Junil Lee [Wed, 20 Jan 2016 22:58:18 +0000 (14:58 -0800)]
zsmalloc: fix migrate_zspage-zs_free race condition

commit c102f07ca0b04f2cb49cfc161c83f6239d17f491 upstream.

record_obj() in migrate_zspage() does not preserve handle's
HANDLE_PIN_BIT, set by find_aloced_obj()->trypin_tag(), and implicitly
(accidentally) un-pins the handle, while migrate_zspage() still performs
an explicit unpin_tag() on the that handle.  This additional explicit
unpin_tag() introduces a race condition with zs_free(), which can pin
that handle by this time, so the handle becomes un-pinned.

Schematically, it goes like this:

  CPU0                                        CPU1
        set HANDLE_PIN_BIT                    zs_free()
  obj_malloc() -- new object, no tag
  record_obj() -- remove HANDLE_PIN_BIT           set HANDLE_PIN_BIT
  unpin_tag()  -- remove zs_free's HANDLE_PIN_BIT

The race condition may result in a NULL pointer dereference:

  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  CPU: 0 PID: 19001 Comm: CookieMonsterCl Tainted:
  PC is at get_zspage_mapping+0x0/0x24
  LR is at obj_free.isra.22+0x64/0x128
  Call trace:

This patch keeps the lock bit in migration path and update value

Signed-off-by: Junil Lee <>
Signed-off-by: Minchan Kim <>
Acked-by: Vlastimil Babka <>
Cc: Sergey Senozhatsky <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agozram: don't call idr_remove() from zram_remove()
Jerome Marchand [Sat, 16 Jan 2016 00:54:48 +0000 (16:54 -0800)]
zram: don't call idr_remove() from zram_remove()

commit 17ec4cd985780a7e30aa45bb8f272237c12502a4 upstream.

The use of idr_remove() is forbidden in the callback functions of
idr_for_each().  It is therefore unsafe to call idr_remove in

This patch moves the call to idr_remove() from zram_remove() to
hot_remove_store().  In the detroy_devices() path, idrs are removed by
idr_destroy().  This solves an use-after-free detected by KASan.

[ fix coding stype, per Sergey]
Signed-off-by: Jerome Marchand <>
Acked-by: Sergey Senozhatsky <>
Cc: Minchan Kim <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agozram: try vmalloc() after kmalloc()
Kyeongdon Kim [Thu, 14 Jan 2016 23:22:29 +0000 (15:22 -0800)]
zram: try vmalloc() after kmalloc()

commit d913897abace843bba20249f3190167f7895e9c3 upstream.

When we're using LZ4 multi compression streams for zram swap, we found
out page allocation failure message in system running test.  That was
not only once, but a few(2 - 5 times per test).  Also, some failure
cases were continually occurring to try allocation order 3.

In order to make parallel compression private data, we should call
kzalloc() with order 2/3 in runtime(lzo/lz4).  But if there is no order
2/3 size memory to allocate in that time, page allocation fails.  This
patch makes to use vmalloc() as fallback of kmalloc(), this prevents
page alloc failure warning.

After using this, we never found warning message in running test, also
It could reduce process startup latency about 60-120ms in each case.

For reference a call trace :

    Binder_1: page allocation failure: order:3, mode:0x10c0d0
    CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20
    Call trace:
    DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
         0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB

[ change vmalloc gfp and adding comment about gfp]
[ tweak comments and styles]
Signed-off-by: Kyeongdon Kim <>
Signed-off-by: Minchan Kim <>
Acked-by: Sergey Senozhatsky <>
Sergey Senozhatsky <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agozram/zcomp: use GFP_NOIO to allocate streams
Sergey Senozhatsky [Thu, 14 Jan 2016 23:22:26 +0000 (15:22 -0800)]
zram/zcomp: use GFP_NOIO to allocate streams

commit 3d5fe03a3ea013060ebba2a811aeb0f23f56aefa upstream.

We can end up allocating a new compression stream with GFP_KERNEL from
within the IO path, which may result is nested (recursive) IO
operations.  That can introduce problems if the IO path in question is a
reclaimer, holding some locks that will deadlock nested IOs.

Allocate streams and working memory using GFP_NOIO flag, forbidding
recursive IO and FS operations.

An example:

  inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
  git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes:
   (jbd2_handle){+.+.?.}, at:  start_this_handle+0x4ca/0x555
  {IN-RECLAIM_FS-W} state was registered at:
  irq event stamp: 138297
  hardirqs last  enabled at (138297):  debug_check_no_locks_freed+0x113/0x12f
  hardirqs last disabled at (138296):  debug_check_no_locks_freed+0x33/0x12f
  softirqs last  enabled at (137818):  __do_softirq+0x2d3/0x3e9
  softirqs last disabled at (137813):  irq_exit+0x41/0x95

               other info that might help us debug this:
   Possible unsafe locking scenario:

                *** DEADLOCK ***
  5 locks held by git/20158:
   #0:  (sb_writers#7){.+.+.+}, at: [<ffffffff81155411>] mnt_want_write+0x24/0x4b
   #1:  (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [<ffffffff81145087>] lock_rename+0xd9/0xe3
   #2:  (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [<ffffffff8114f8e2>] lock_two_nondirectories+0x3f/0x6b
   #3:  (&sb->s_type->i_mutex_key#11/4){+.+.+.}, at: [<ffffffff8114f909>] lock_two_nondirectories+0x66/0x6b
   #4:  (jbd2_handle){+.+.?.}, at: [<ffffffff811e31db>] start_this_handle+0x4ca/0x555

               stack backtrace:
  CPU: 2 PID: 20158 Comm: git Not tainted 4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211
  Call Trace:
    zcomp_strm_alloc+0x25/0x73 [zram]
    zcomp_strm_multi_find+0xe7/0x173 [zram]
    zcomp_strm_find+0xc/0xe [zram]
    zram_bvec_rw+0x2ca/0x7e0 [zram]
    zram_make_request+0x1fa/0x301 [zram]
    ? mark_held_locks+0x5f/0x76

[ add stable mark]
Signed-off-by: Sergey Senozhatsky <>
Acked-by: Minchan Kim <>
Cc: Kyeongdon Kim <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/nouveau/pmu: do not assume a PMU is present
Alexandre Courbot [Thu, 3 Sep 2015 08:39:52 +0000 (17:39 +0900)]
drm/nouveau/pmu: do not assume a PMU is present

commit 579b7c58215329803ce184704463de09f0f310ac upstream.

Some devices may not have a PMU. Avoid a NULL pointer dereference in
such cases by checking whether the pointer given to nvkm_pmu_pgob() is

Signed-off-by: Alexandre Courbot <>
Signed-off-by: Ben Skeggs <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoHID: multitouch: Fetch feature reports on demand for Win8 devices
Mika Westerberg [Wed, 7 Oct 2015 12:33:43 +0000 (15:33 +0300)]
HID: multitouch: Fetch feature reports on demand for Win8 devices

commit 6d4f5440a3a2bb2e9d0d582bbf98234e9e9bb095 upstream.

Some newer Intel Skylake based Dell laptops with Win8 precision touchpad
fail when initial feature reports are fetched from it. Below is an example
output with some additional debug included:

 i2c_hid i2c-DLL0704:01: Fetching the HID descriptor
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00
 i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ...
 i2c_hid i2c-DLL0704:01: i2c_hid_get_report
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00
 i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05
 i2c_hid i2c-DLL0704:01: report id 13
 i2c_hid i2c-DLL0704:01: i2c_hid_get_report
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00
 i2c_hid i2c-DLL0704:01: failed to retrieve report from device.
 i2c_hid i2c-DLL0704:01: report id 7
 i2c_hid i2c-DLL0704:01: i2c_hid_get_report
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00
 i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ...
 i2c_hid i2c-DLL0704:01: report id 4
 i2c_hid i2c-DLL0704:01: i2c_hid_get_report
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00

We manage to fetch few reports but then the touchpad dies:

 i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
 i2c_hid i2c-DLL0704:01: failed to retrieve report from device.

it eventually pulls the whole I2C bus low:

 i2c_designware i2c_designware.1: controller timed out
 i2c_hid i2c-DLL0704:01: failed to set a report to device.

Fix this by preventing initial feature report retrieval for Win8 devices.
Instead we fetch reports as needed in mt_feature_mapping(). This prevents
fetching reports which might cause problems with the device in question.

Suggested-by: Benjamin Tissoires <>
Signed-off-by: Mika Westerberg <>
Reviewed-by: Benjamin Tissoires <>
Tested-by: Seth Forshee <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agortlwifi: rtl8821ae: Fix lockups on boot
Larry Finger [Tue, 10 Nov 2015 16:46:11 +0000 (10:46 -0600)]
rtlwifi: rtl8821ae: Fix lockups on boot

commit eeec5d0ef7ee54a75e09e861c3cc44177b8752c7 upstream.

In commit 54328e64047a5 ("rtlwifi: rtl8821ae: Fix system lockups on boot"),
an attempt was made to fix a regression introduced in commit 1277fa2ab2f9
("rtlwifi: Remove the clear interrupt routine from all drivers").
Unfortunately, there were logic errors in that patch that prevented
affected boxes from booting even after that patch was applied.

The actual cause of the original problem is unknown as none of the
developers have systems that are affected.

Fixes: 54328e64047a ("rtlwifi: rtl8821ae: Fix system lockups on boot")
Signed-off-by: Larry Finger <>
Signed-off-by: Kalle Valo <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoFS-Cache: Add missing initialization of ret in cachefiles_write_page()
Geert Uytterhoeven [Thu, 12 Nov 2015 11:46:23 +0000 (11:46 +0000)]
FS-Cache: Add missing initialization of ret in cachefiles_write_page()

commit cf89752645e47d86ba8a4157f4b121fcb33434c5 upstream.

fs/cachefiles/rdwr.c: In function ‘cachefiles_write_page’:
fs/cachefiles/rdwr.c:882: warning: ‘ret’ may be used uninitialized in
this function

If the jump to label "error" is taken, "ret" will indeed be
uninitialized, and random stack data may be printed by the debug code.

Fixes: 102f4d900c9c8f5e ("FS-Cache: Handle a write to the page immediately beyond the EOF marker")
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: David Howells <>
Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoFS-Cache: Handle a write to the page immediately beyond the EOF marker
David Howells [Wed, 4 Nov 2015 15:20:42 +0000 (15:20 +0000)]
FS-Cache: Handle a write to the page immediately beyond the EOF marker

commit 102f4d900c9c8f5ed89ae4746d493fe3ebd7ba64 upstream.

Handle a write being requested to the page immediately beyond the EOF
marker on a cache object.  Currently this gets an assertion failure in
CacheFiles because the EOF marker is used there to encode information about
a partial page at the EOF - which could lead to an unknown blank spot in
the file if we extend the file over it.

The problem is actually in fscache where we check the index of the page
being written against store_limit.  store_limit is set to the number of
pages that we're allowed to store by fscache_set_store_limit() - which
means it's one more than the index of the last page we're allowed to store.
The problem is that we permit writing to a page with an index _equal_ to
the store limit - when we should reject that case.

Whilst we're at it, change the triggered assertion in CacheFiles to just
return -ENOBUFS instead.

The assertion failure looks something like this:

CacheFiles: Assertion failed
1000 < 7b1 is false
------------[ cut here ]------------
kernel BUG at fs/cachefiles/rdwr.c:962!
RIP: 0010:[<ffffffffa02c9e83>]  [<ffffffffa02c9e83>] cachefiles_write_page+0x273/0x2d0 [cachefiles]

Signed-off-by: David Howells <>
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: marvell/cesa - fix test in mv_cesa_dev_dma_init()
Boris BREZILLON [Fri, 5 Feb 2016 16:45:48 +0000 (17:45 +0100)]
crypto: marvell/cesa - fix test in mv_cesa_dev_dma_init()

commit 8a3978ad55fb4c0564d285fb2f6cdee2313fce01 upstream.

We are checking twice if dma->cache_pool is not NULL but are never testing
dma->padding_pool value.

Signed-off-by: Boris Brezillon <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_skcipher - Do not set MAY_BACKLOG on the async path
Herbert Xu [Wed, 3 Feb 2016 13:39:27 +0000 (21:39 +0800)]
crypto: algif_skcipher - Do not set MAY_BACKLOG on the async path

commit dad41997063723eaf5f77bc2015606a5a9bce320 upstream.

The async path cannot use MAY_BACKLOG because it is not meant to
block, which is what MAY_BACKLOG does.  On the other hand, both
the sync and async paths can make use of MAY_SLEEP.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_skcipher - Do not dereference ctx without socket lock
Herbert Xu [Wed, 3 Feb 2016 13:39:26 +0000 (21:39 +0800)]
crypto: algif_skcipher - Do not dereference ctx without socket lock

commit 6454c2b83f719057069777132b13949e4c6b6350 upstream.

Any access to non-constant bits of the private context must be
done under the socket lock, in particular, this includes ctx->req.

This patch moves such accesses under the lock, and fetches the
tfm from the parent socket which is guaranteed to be constant,
rather than from ctx->req.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_skcipher - Do not assume that req is unchanged
Herbert Xu [Wed, 3 Feb 2016 13:39:24 +0000 (21:39 +0800)]
crypto: algif_skcipher - Do not assume that req is unchanged

commit ec69bbfb9902c32a5c1492f2b1b8ad032a66d724 upstream.

The async path in algif_skcipher assumes that the crypto completion
function will be called with the original request.  This is not
necessarily the case.  In fact there is no need for this anyway
since we already embed information into the request with struct

This patch adds a pointer to that struct and then passes it as
the data to the callback function.

Signed-off-by: Herbert Xu <>
Tested-by: Tadeusz Struk <>
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 agocrypto: shash - Fix has_key setting
Herbert Xu [Tue, 26 Jan 2016 16:16:37 +0000 (00:16 +0800)]
crypto: shash - Fix has_key setting

commit 00420a65fa2beb3206090ead86942484df2275f3 upstream.

The has_key logic is wrong for shash algorithms as they always
have a setkey function.  So we should instead be testing against

Fixes: a5596d633278 ("crypto: hash - Add crypto_ahash_has_setkey")
Reported-by: Stephan Mueller <>
Signed-off-by: Herbert Xu <>
Tested-by: Stephan Mueller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: chacha20-ssse3 - Align stack pointer to 64 bytes
Eli Cooper [Thu, 21 Jan 2016 16:24:08 +0000 (00:24 +0800)]
crypto: chacha20-ssse3 - Align stack pointer to 64 bytes

commit cbe09bd51bf23b42c3a94c5fb6815e1397c5fc3f upstream.

This aligns the stack pointer in chacha20_4block_xor_ssse3 to 64 bytes.
Fixes general protection faults and potential kernel panics.

Signed-off-by: Eli Cooper <>
Acked-by: Martin Willi <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: caam - make write transactions bufferable on PPC platforms
Horia Geant? [Tue, 12 Jan 2016 15:59:29 +0000 (17:59 +0200)]
crypto: caam - make write transactions bufferable on PPC platforms

commit e7a7104e432c0db8469ca3568daf4f1d1afe3e73 upstream.

Previous change (see "Fixes" tag) to the MCFGR register
clears AWCACHE[0] ("bufferable" AXI3 attribute) (which is "1" at POR).

This makes all writes non-bufferable, causing a ~ 5% performance drop
for PPC-based platforms.

Rework previous change such that MCFGR[AWCACHE]=4'b0011
(bufferable + cacheable) for all platforms.
Note: For ARM-based platforms, AWCACHE[0] is ignored
by the interconnect IP.

Fixes: f10967495144 ("crypto: caam - fix snooping for write transactions")
Signed-off-by: Horia Geant? <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_skcipher - sendmsg SG marking is off by one
Herbert Xu [Tue, 19 Jan 2016 13:23:57 +0000 (21:23 +0800)]
crypto: algif_skcipher - sendmsg SG marking is off by one

commit 202736d99b7f29279db9da61587f11a08a04a9c6 upstream.

We mark the end of the SG list in sendmsg and sendpage and unmark
it on the next send call.  Unfortunately the unmarking in sendmsg
is off-by-one, leading to an SG list that is too short.

Fixes: 0f477b655a52 ("crypto: algif - Mark sgl end at the end of data")
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_skcipher - Load TX SG list after waiting
Herbert Xu [Mon, 18 Jan 2016 10:46:10 +0000 (18:46 +0800)]
crypto: algif_skcipher - Load TX SG list after waiting

commit 4f0414e54e4d1893c6f08260693f8ef84c929293 upstream.

We need to load the TX SG list in sendmsg(2) after waiting for
incoming data, not before.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Herbert Xu <>
Tested-by: Dmitry Vyukov <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: crc32c - Fix crc32c soft dependency
Jean Delvare [Mon, 18 Jan 2016 16:06:05 +0000 (17:06 +0100)]
crypto: crc32c - Fix crc32c soft dependency

commit fd7f6727102a1ccf6b4c1dfcc631f9b546526b26 upstream.

I don't think it makes sense for a module to have a soft dependency
on itself. This seems quite cyclic by nature and I can't see what
purpose it could serve.

OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty
much assumes that some incarnation of the "crc32c" hash algorithm has
been loaded. Therefore it makes sense to have the soft dependency
there (as crc-t10dif does.)

Cc: Tim Chen <>
Cc: "David S. Miller" <>
Signed-off-by: Jean Delvare <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_skcipher - Fix race condition in skcipher_check_key
Herbert Xu [Fri, 15 Jan 2016 14:02:20 +0000 (22:02 +0800)]
crypto: algif_skcipher - Fix race condition in skcipher_check_key

commit 1822793a523e5d5730b19cc21160ff1717421bc8 upstream.

We need to lock the child socket in skcipher_check_key as otherwise
two simultaneous calls can cause the parent socket to be freed.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_hash - Fix race condition in hash_check_key
Herbert Xu [Fri, 15 Jan 2016 14:01:08 +0000 (22:01 +0800)]
crypto: algif_hash - Fix race condition in hash_check_key

commit ad46d7e33219218605ea619e32553daf4f346b9f upstream.

We need to lock the child socket in hash_check_key as otherwise
two simultaneous calls can cause the parent socket to be freed.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: af_alg - Forbid bind(2) when nokey child sockets are present
Herbert Xu [Wed, 13 Jan 2016 07:03:32 +0000 (15:03 +0800)]
crypto: af_alg - Forbid bind(2) when nokey child sockets are present

commit a6a48c565f6f112c6983e2a02b1602189ed6e26e upstream.

This patch forbids the calling of bind(2) when there are child
sockets created by accept(2) in existence, even if they are created
on the nokey path.

This is needed as those child sockets have references to the tfm
object which bind(2) will destroy.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_skcipher - Remove custom release parent function
Herbert Xu [Wed, 13 Jan 2016 07:01:06 +0000 (15:01 +0800)]
crypto: algif_skcipher - Remove custom release parent function

commit d7b65aee1e7b4c87922b0232eaba56a8a143a4a0 upstream.

This patch removes the custom release parent function as the
generic af_alg_release_parent now works for nokey sockets too.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_hash - Remove custom release parent function
Herbert Xu [Wed, 13 Jan 2016 07:00:36 +0000 (15:00 +0800)]
crypto: algif_hash - Remove custom release parent function

commit f1d84af1835846a5a2b827382c5848faf2bb0e75 upstream.

This patch removes the custom release parent function as the
generic af_alg_release_parent now works for nokey sockets too.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path
Herbert Xu [Wed, 13 Jan 2016 06:59:03 +0000 (14:59 +0800)]
crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path

commit 6a935170a980024dd29199e9dbb5c4da4767a1b9 upstream.

This patch allows af_alg_release_parent to be called even for
nokey sockets.

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: algif_skcipher - Add key check exception for cipher_null
Herbert Xu [Mon, 11 Jan 2016 13:29:41 +0000 (21:29 +0800)]
crypto: algif_skcipher - Add key check exception for cipher_null

commit 6e8d8ecf438792ecf7a3207488fb4eebc4edb040 upstream.

This patch adds an exception to the key check so that cipher_null
users may continue to use algif_skcipher without setting a key.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: skcipher - Add crypto_skcipher_has_setkey
Herbert Xu [Mon, 11 Jan 2016 13:26:50 +0000 (21:26 +0800)]
crypto: skcipher - Add crypto_skcipher_has_setkey

commit a1383cd86a062fc798899ab20f0ec2116cce39cb upstream.

This patch adds a way for skcipher users to determine whether a key
is required by a transform.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_hash - Require setkey before accept(2)
Herbert Xu [Fri, 8 Jan 2016 13:31:04 +0000 (21:31 +0800)]
crypto: algif_hash - Require setkey before accept(2)

commit 6de62f15b581f920ade22d758f4c338311c2f0d4 upstream.

Hash implementations that require a key may crash if you use
them without setting a key.  This patch adds the necessary checks
so that if you do attempt to use them without a key that we return
-ENOKEY instead of proceeding.

This patch also adds a compatibility path to support old applications
that do acept(2) before setkey.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: hash - Add crypto_ahash_has_setkey
Herbert Xu [Fri, 8 Jan 2016 13:28:26 +0000 (21:28 +0800)]
crypto: hash - Add crypto_ahash_has_setkey

commit a5596d6332787fd383b3b5427b41f94254430827 upstream.

This patch adds a way for ahash users to determine whether a key
is required by a crypto_ahash transform.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: algif_skcipher - Add nokey compatibility path
Herbert Xu [Mon, 4 Jan 2016 04:36:12 +0000 (13:36 +0900)]
crypto: algif_skcipher - Add nokey compatibility path

commit a0fa2d037129a9849918a92d91b79ed6c7bd2818 upstream.

This patch adds a compatibility path to support old applications
that do acept(2) before setkey.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: af_alg - Add nokey compatibility path
Herbert Xu [Mon, 4 Jan 2016 04:35:18 +0000 (13:35 +0900)]
crypto: af_alg - Add nokey compatibility path

commit 37766586c965d63758ad542325a96d5384f4a8c9 upstream.

This patch adds a compatibility path to support old applications
that do acept(2) before setkey.

Signed-off-by: Herbert Xu <>
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 agocrypto: algif_skcipher - Require setkey before accept(2)
Herbert Xu [Fri, 25 Dec 2015 07:40:05 +0000 (15:40 +0800)]
crypto: algif_skcipher - Require setkey before accept(2)

commit dd504589577d8e8e70f51f997ad487a4cb6c026f upstream.

Some cipher implementations will crash if you try to use them
without calling setkey first.  This patch adds a check so that
the accept(2) call will fail with -ENOKEY if setkey hasn't been
done on the socket yet.

Reported-by: Dmitry Vyukov <>
Signed-off-by: Herbert Xu <>
Tested-by: Dmitry Vyukov <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agosched: Fix crash in sched_init_numa()
Raghavendra K T [Fri, 15 Jan 2016 19:01:23 +0000 (00:31 +0530)]
sched: Fix crash in sched_init_numa()

commit 9c03ee147193645be4c186d3688232fa438c57c7 upstream.

The following PowerPC commit:

  c118baf80256 ("arch/powerpc/mm/numa.c: do not allocate bootmem memory for non existing nodes")

avoids allocating bootmem memory for non existent nodes.

But when DEBUG_PER_CPU_MAPS=y is enabled, my powerNV system failed to boot
because in sched_init_numa(), cpumask_or() operation was done on
unallocated nodes.

Fix that by making cpumask_or() operation only on existing nodes.

[ Tested with and w/o DEBUG_PER_CPU_MAPS=y on x86 and PowerPC. ]

Reported-by: Jan Stancek <>
Tested-by: Jan Stancek <>
Signed-off-by: Raghavendra K T <>
Cc: <>
Cc: <>
Cc: <>
Cc: <>
Cc: <>
Cc: <>
Cc: <>
Cc: <>
Cc: <>
Cc: <>
Cc: <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoext4: fix an endianness bug in ext4_encrypted_follow_link()
Al Viro [Thu, 26 Nov 2015 20:20:50 +0000 (15:20 -0500)]
ext4: fix an endianness bug in ext4_encrypted_follow_link()

commit 5a1c7f47da9b32d0671e776b0f388095b7f91e2e upstream.

applying le32_to_cpu() to 16bit value is a bad idea...

Signed-off-by: Al Viro <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoext4: fix an endianness bug in ext4_encrypted_zeroout()
Al Viro [Thu, 26 Nov 2015 20:20:19 +0000 (15:20 -0500)]
ext4: fix an endianness bug in ext4_encrypted_zeroout()

commit e2c9e0b28e146c9a3bce21408f3c02e24ac7ac31 upstream.

ex->ee_block is not host-endian (note that accesses of other fields
of *ex right next to that line go through the helpers that do proper
conversion from little-endian to host-endian; it might make sense
to add similar for ->ee_block to avoid reintroducing that kind of

Signed-off-by: Al Viro <>
Signed-off-by: Theodore Ts'o <>
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 agoext2, ext4: warn when mounting with dax enabled
Dan Williams [Tue, 29 Sep 2015 19:48:11 +0000 (15:48 -0400)]
ext2, ext4: warn when mounting with dax enabled

commit ef83b6e8f40bb24b92ad73b5889732346e54a793 upstream.

Similar to XFS warn when mounting DAX while it is still considered under
development.  Also, aspects of the DAX implementation, for example
synchronization against multiple faults and faults causing block
allocation, depend on the correct implementation in the filesystem.  The
maturity of a given DAX implementation is filesystem specific.

Cc: "Theodore Ts'o" <>
Cc: Matthew Wilcox <>
Cc: Kirill A. Shutemov <>
Reported-by: Dave Chinner <>
Acked-by: Jan Kara <>
Signed-off-by: Dan Williams <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocrypto: fix test vector for rsa
Tadeusz Struk [Thu, 14 Jan 2016 04:57:40 +0000 (20:57 -0800)]
crypto: fix test vector for rsa

After the fix to the asn1_decoder in commit: 0d62e9dd
"ASN.1: Fix non-match detection failure on data overrun"
the rsa algorithm is failing to register in 4.3 stable kernels with
error: "alg: rsa: test failed on vector 4, err=-74"

This happens because the asn1 definition for the rsa key that has been
added in 4.2 defined all 3 components of the key as non-optional, as
the asn1_decoder before the fix was working fine for both the private
and public keys.

This patch adds the missing (fake) component to one key vector to allow
the algorithm to successfully register and be used with a valid private
keys later. This is only to make the asn1_decoder successfully parse the
key and the fake component is never used in the test as the vector is
marked as public key.

This patch applies only to 4.3 kernels as the 4.2 version of asn1_decoder
works fine with the asn1 definition.
4.4 is also ok because the akcipher interface has been changed, and
the set_key function has been split into set_public_key and set_priv_key
and there are two separate asn1 definitions for the two key formats
with all the required components correctly defined (commit 22287b0).

Signed-off-by: Tadeusz Struk <>
Acked-by: Herbert Xu <>
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 agoarm64: mm: use correct mapping granularity under DEBUG_RODATA
Ard Biesheuvel [Mon, 16 Nov 2015 10:18:14 +0000 (11:18 +0100)]
arm64: mm: use correct mapping granularity under DEBUG_RODATA

commit 4fee9f364b9b99f76732f2a6fd6df679a237fa74 upstream.

When booting a 64k pages kernel that is built with CONFIG_DEBUG_RODATA
and resides at an offset that is not a multiple of 512 MB, the rounding
that occurs in __map_memblock() and fixup_executable() results in
incorrect regions being mapped.

The following snippet from /sys/kernel/debug/kernel_page_tables shows
how, when the kernel is loaded 2 MB above the base of DRAM at 0x40000000,
the first 2 MB of memory (which may be inaccessible from non-secure EL1
or just reserved by the firmware) is inadvertently mapped into the end of
the module region.

  ---[ Modules start ]---
  0xfffffdffffe00000-0xfffffe0000000000     2M RW NX ... UXN MEM/NORMAL
  ---[ Modules end ]---
  ---[ Kernel Mapping ]---
  0xfffffe0000000000-0xfffffe0000090000   576K RW NX ... UXN MEM/NORMAL
  0xfffffe0000090000-0xfffffe0000200000  1472K ro x  ... UXN MEM/NORMAL
  0xfffffe0000200000-0xfffffe0000800000     6M ro x  ... UXN MEM/NORMAL
  0xfffffe0000800000-0xfffffe0000810000    64K ro x  ... UXN MEM/NORMAL
  0xfffffe0000810000-0xfffffe0000a00000  1984K RW NX ... UXN MEM/NORMAL
  0xfffffe0000a00000-0xfffffe00ffe00000  4084M RW NX ... UXN MEM/NORMAL

The same issue is likely to occur on 16k pages kernels whose load
address is not a multiple of 32 MB (i.e., SECTION_SIZE). So round to

Fixes: da141706aea5 ("arm64: add better page protections to arm64")
Signed-off-by: Ard Biesheuvel <>
Acked-by: Mark Rutland <>
Acked-by: Laura Abbott <>
Signed-off-by: Catalin Marinas <>
[ard.biesheuvel: add #define of SWAPPER_BLOCK_SIZE for -stable version]
Signed-off-by: Ard Biesheuvel <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoiommu/io-pgtable-arm: Ensure we free the final level on teardown
Will Deacon [Tue, 15 Dec 2015 16:08:12 +0000 (16:08 +0000)]
iommu/io-pgtable-arm: Ensure we free the final level on teardown

commit 12c2ab09571e8aae3a87da2a4a452632a5fac1e5 upstream.

When tearing down page tables, we return early for the final level
since we know that we won't have any table pointers to follow.
Unfortunately, this also means that we forget to free the final level,
so we end up leaking memory.

Fix the issue by always freeing the current level, but just don't bother
to iterate over the ptes if we're at the final level.

Reported-by: Zhang Bo <>
Signed-off-by: Will Deacon <>
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: Retry failed reopen if tty teardown in-progress
Peter Hurley [Sun, 10 Jan 2016 05:13:45 +0000 (21:13 -0800)]
tty: Retry failed reopen if tty teardown in-progress

commit 7f22f6c935cda600660e623a411fe380015d28d9 upstream.

A small window exists where a tty reopen will observe the tty
just prior to imminent teardown (tty->count == 0); in this case, open()
returns EIO to userspace.

Instead, retry the open after checking for signals and yielding;
this interruptible retry loop allows teardown to commence and initialize
a new tty on retry. Never retry the BSD master pty reopen; there is no
guarantee the pty pair teardown is imminent since the slave file
descriptors may remain open indefinitely.

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 agon_tty: Fix unsafe reference to "other" ldisc
Peter Hurley [Mon, 11 Jan 2016 06:40:56 +0000 (22:40 -0800)]
n_tty: Fix unsafe reference to "other" ldisc

commit 6d27a63caad3f13e96cf065d2d96828c2006be6b upstream.

Although n_tty_check_unthrottle() has a valid ldisc reference (since
the tty core gets the ldisc ref in tty_read() before calling the line
discipline read() method), it does not have a valid ldisc reference to
the "other" pty of a pty pair. Since getting an ldisc reference for
tty->link essentially open-codes tty_wakeup(), just replace with the
equivalent tty_wakeup().

Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agon_tty: Fix poll() after buffer-limited eof push read
Peter Hurley [Fri, 27 Nov 2015 18:59:20 +0000 (13:59 -0500)]
n_tty: Fix poll() after buffer-limited eof push read

commit ac8f3bf8832a405cc6e4dccb1d26d5cb2994d234 upstream.

commit 40d5e0905a03 ("n_tty: Fix EOF push handling") fixed EOF push
for reads. However, that approach still allows a condition mismatch
between poll() and read(), where poll() returns POLLIN but read()
blocks. This state can happen when a previous read() returned because
the user buffer was full and the next character was an EOF not at the
beginning of the line. While the next read() will properly identify
the condition and advance the read buffer tail without improperly
indicating an EOF file condition (ie., read() will not mistakenly
return 0), poll() will mistakenly indicate POLLIN.

Although a possible solution would be to peek at the input buffer
in n_tty_poll(), the better solution in this patch is to eat the
EOF during the previous read() (ie., fix the problem by eliminating
the condition).

The current canon line buffer copy limits the scan for next end-of-line
to the smaller of either,
   a. the remaining user buffer size
   b. completed lines in the input buffer
When the remaining user buffer size is exactly one less than the
end-of-line marked by EOF push, the EOF is not scanned nor skipped
but left for subsequent reads. In the example below, the scan
index 'eol' has stopped at the EOF because it is past the scan
limit of 5 (not because it has found the next set bit in read_flags)

   user buffer [*nr = 5]    _ _ _ _ _

   read_flags               0 0 0 0 0   1
   input buffer             h e l l o [EOF]
                            ^           ^
                           /           /
                         tail        eol

   result: found = 0, tail += 5, *nr += 5

Instead, allow the scan to peek ahead 1 byte (while still limiting the
scan to completed lines in the input buffer). For the example above,

   result: found = 1, tail += 6, *nr += 5

Because the scan limit is now bumped +1 byte, when the scan is
completed, the tail advance and the user buffer copy limit is
re-clamped to *nr when EOF is _not_ found.

Fixes: 40d5e0905a03 ("n_tty: Fix EOF push handling")
Signed-off-by: Peter Hurley <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agousb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms
Lu Baolu [Tue, 26 Jan 2016 15:50:08 +0000 (17:50 +0200)]
usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms

commit ccc04afb72cddbdf7c0e1c17e92886405a71b754 upstream.

Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well.

Signed-off-by: Lu Baolu <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agousb: xhci: handle both SSIC ports in PME stuck quirk
Lu Baolu [Tue, 26 Jan 2016 15:50:05 +0000 (17:50 +0200)]
usb: xhci: handle both SSIC ports in PME stuck quirk

commit fa89537783cb442263fa5a14df6c7693eaf32f11 upstream.

Commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI")
adds a workaround for a limitation of PME storm caused by SSIC port in
some Intel SoCs. This commit only handled one SSIC port, while there
are actually two SSIC ports in the chips. This patch handles both SSIC
ports. Without this fix, users still see PME storm.

Signed-off-by: Zhuang Jin Can <>
Signed-off-by: Lu Baolu <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agousb: phy: msm: fix error handling in probe.
Srinivas Kandagatla [Wed, 13 Jan 2016 09:13:10 +0000 (09:13 +0000)]
usb: phy: msm: fix error handling in probe.

commit a38a08dfaaab978dced63aa9cad45f0f62e23a66 upstream.

This driver registers for extcon events as part of its probe, but
never unregisters them in case of error in the probe path.

There were multiple issues noticed due to this missing error handling.
One of them is random crashes if the regulators are not ready yet by the
time probe is invoked.

Ivan's previous attempt [1] to fix this issue, did not really address
all the failure cases like regualtor/get_irq failures.


Without this patch the kernel would carsh with log:
Unable to handle kernel paging request at virtual address 17d78410
pgd = ffffffc001a5c000
[17d78410] *pgd=00000000b6806003, *pud=00000000b6806003, *pmd=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.4.0+ #48
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Workqueue: deferwq deferred_probe_work_func
task: ffffffc03686e900 ti: ffffffc0368b0000 task.ti: ffffffc0368b0000
PC is at raw_notifier_chain_register+0x1c/0x44
LR is at extcon_register_notifier+0x88/0xc8
pc : [<ffffffc0000da43c>] lr : [<ffffffc000606298>] pstate: 80000085
sp : ffffffc0368b3a70
x29: ffffffc0368b3a70 x28: ffffffc03680c310
x27: ffffffc035518000 x26: ffffffc035518000
x25: ffffffc03bfa20e0 x24: ffffffc035580a18
x23: 0000000000000000 x22: ffffffc035518458
x21: ffffffc0355e9a60 x20: ffffffc035518000
x19: 0000000000000000 x18: 0000000000000028
x17: 0000000000000003 x16: ffffffc0018153c8
x15: 0000000000000001 x14: ffffffc03686f0f8
x13: ffffffc03686f0f8 x12: 0000000000000003
x11: 0000000000000001 x10: 0000000000000001
x9 : ffffffc03686f0f8 x8 : 0000e3872014c1a1
x7 : 0000000000000028 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000
x3 : 00000000354fb170 x2 : 0000000017d78400
x1 : ffffffc0355e9a60 x0 : ffffffc0354fb268

Fixes:  591fc116f330 ("usb: phy: msm: Use extcon framework for VBUS and ID detection")
Signed-off-by: Srinivas Kandagatla <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agousb: cdc-acm: send zero packet for intel 7260 modem
Lu Baolu [Wed, 6 Jan 2016 07:10:04 +0000 (15:10 +0800)]
usb: cdc-acm: send zero packet for intel 7260 modem

commit ffdb1e369a73b380fce95b05f8498d92c43842b4 upstream.

For Intel 7260 modem, it is needed for host side to send zero
packet if the BULK OUT size is equal to USB endpoint max packet
length. Otherwise, modem side may still wait for more data and
cannot give response to host side.

Signed-off-by: Konrad Leszczynski <>
Signed-off-by: Lu Baolu <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agousb: cdc-acm: handle unlinked urb in acm read callback
Lu Baolu [Wed, 30 Dec 2015 04:59:08 +0000 (12:59 +0800)]
usb: cdc-acm: handle unlinked urb in acm read callback

commit 19454462acb1bdef80542061bdc9b410e4ed1ff6 upstream.

In current acm driver, the bulk-in callback function ignores the
URBs unlinked in usb core.

This causes unexpected data loss in some cases. For example,
runtime suspend entry will unlinked all urbs and set urb->status
to -ENOENT even those urbs might have data not processed yet.
Hence, data loss occurs.

This patch lets bulk-in callback function handle unlinked urbs
to avoid data loss.

Signed-off-by: Tang Jian Qiang <>
Signed-off-by: Lu Baolu <>
Acked-by: Oliver Neukum <>
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 agoASoC: rt5645: fix the shift bit of IN1 boost
Bard Liao [Thu, 21 Jan 2016 05:13:40 +0000 (13:13 +0800)]
ASoC: rt5645: fix the shift bit of IN1 boost

commit b28785fa9cede0d4f47310ca0dd2a4e1d50478b5 upstream.

The shift bit of IN1 boost gain control is 12.

Signed-off-by: Bard Liao <>
Signed-off-by: Mark Brown <>
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 bad dereference of jack object
Takashi Iwai [Tue, 9 Feb 2016 09:23:52 +0000 (10:23 +0100)]
ALSA: hda - Fix bad dereference of jack object

commit 2ebab40eb74a0225d5dfba72bfae317dd948fa2d upstream.

The hda_jack_tbl entries are managed by snd_array for allowing
multiple jacks.  It's good per se, but the problem is that struct
hda_jack_callback keeps the hda_jack_tbl pointer.  Since snd_array
doesn't preserve each pointer at resizing the array, we can't keep the
original pointer but have to deduce the pointer at each time via
snd_array_entry() instead.  Actually, this resulted in the deference
to the wrong pointer on codecs that have many pins such as CS4208.

This patch replaces the pointer to the NID value as the search key.
As an unexpected good side effect, this even simplifies the code, as
only NID is needed in most cases.

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 agoRevert "ALSA: hda - Fix noise on Gigabyte Z170X mobo"
Takashi Iwai [Fri, 5 Feb 2016 19:12:24 +0000 (20:12 +0100)]
Revert "ALSA: hda - Fix noise on Gigabyte Z170X mobo"

commit 6c361d10e0eb859233c71954abcd20d2d8700587 upstream.

This reverts commit 0c25ad80408e95e0a4fbaf0056950206e95f726f.

The original commit disabled the aamixer path due to the noise
problem, but it turned out that some mobo with the same PCI SSID
doesn't suffer from the issue, and the disabled function (analog
loopback) is still demanded by users.

Since the recent commit [e7fdd52779a6: ALSA: hda - Implement loopback
control switch for Realtek and other codecs], we have the dynamic
mixer switch to enable/disable the aamix path, and we don't have to
disable the path statically any longer.  So, let's revert the
disablement, so that only the user suffering from the noise problem
can turn off the aamix on the fly.

Reported-by: <>
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 race at concurrent reads
Takashi Iwai [Mon, 8 Feb 2016 16:26:58 +0000 (17:26 +0100)]
ALSA: timer: Fix race at concurrent reads

commit 4dff5c7b7093b19c19d3a100f8a3ad87cb7cd9e7 upstream.

snd_timer_user_read() has a potential race among parallel reads, as
qhead and qused are updated outside the critical section due to
copy_to_user() calls.  Move them into the critical section, and also
sanitize the relevant code a bit.

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: rawmidi: Make snd_rawmidi_transmit() race-free
Takashi Iwai [Sun, 31 Jan 2016 10:57:41 +0000 (11:57 +0100)]
ALSA: rawmidi: Make snd_rawmidi_transmit() race-free

commit 06ab30034ed9c200a570ab13c017bde248ddb2a6 upstream.

A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by
syzkaller fuzzer:
  WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [<ffffffff84f80bd5>] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
 [<ffffffff84fdb3c1>] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [<ffffffff84f87ed9>] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
 [<ffffffff84f89fd3>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
 [<ffffffff817b0323>] __vfs_write+0x113/0x480 fs/read_write.c:528
 [<ffffffff817b1db7>] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [<ffffffff817b50a1>] SyS_write+0x111/0x220 fs/read_write.c:616
 [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

Also a similar warning is found but in another path:
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff82be2c0d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [<ffffffff81355139>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [<ffffffff81355369>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [<ffffffff8527e69a>] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
 [<ffffffff8527e851>] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
 [<ffffffff852d9046>] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [<ffffffff85285a0b>] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
 [<ffffffff85287b73>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
 [<ffffffff817ba5f3>] __vfs_write+0x113/0x480 fs/read_write.c:528
 [<ffffffff817bc087>] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [<ffffffff817bf371>] SyS_write+0x111/0x220 fs/read_write.c:616
 [<ffffffff86660276>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

In the former case, the reason is that virmidi has an open code
calling snd_rawmidi_transmit_ack() with the value calculated outside
the spinlock.   We may use snd_rawmidi_transmit() in a loop just for
consuming the input data, but even there, there is a race between
snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack().

Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and
snd_rawmidi_tranmit_ack() separately without protection, so they are
racy as well.

The patch tries to address these issues by the following ways:
- Introduce the unlocked versions of snd_rawmidi_transmit_peek() and
  snd_rawmidi_transmit_ack() to be called inside the explicit lock.
- Rewrite snd_rawmidi_transmit() to be race-free (the former case).
- Make the split calls (the latter case) protected in the rawmidi spin

Reported-by: Dmitry Vyukov <>
Tested-by: Dmitry Vyukov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: seq: Degrade the error message for too many opens
Takashi Iwai [Mon, 25 Jan 2016 10:24:56 +0000 (11:24 +0100)]
ALSA: seq: Degrade the error message for too many opens

commit da10816e3d923565b470fec78a674baba794ed33 upstream.

ALSA OSS sequencer spews a kernel error message ("ALSA: seq_oss: too
many applications") when user-space tries to open more than the
limit.  This means that it can easily fill the log buffer.

Since it's merely a normal error, it's safe to suppress it via
pr_debug() instead.

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: bebob: Use a signed return type for get_formation_index
Lucas Tanure [Mon, 25 Jan 2016 21:30:23 +0000 (19:30 -0200)]
ALSA: bebob: Use a signed return type for get_formation_index

commit 07905298e4d5777eb58516cdc242f7ac1ca387a2 upstream.

The return type "unsigned int" was used by the get_formation_index function
despite of the aspect that it will eventually return a negative error code.
So, change to signed int and get index by reference in the parameters.

Done with the help of Coccinelle.

[Fix the missing braces suggested by Julia Lawall -- tiwai]

Signed-off-by: Lucas Tanure <>
Reviewed-by: Takashi Sakamoto <>
Tested-by: Takashi Sakamoto <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>