linux-stable.git, branch v4.9.19

Linux 4.9.19

2017-03-30T07:41:57+00:00

crypto: algif_hash - avoid zero-sized array

2017-03-30T07:41:28+00:00

commit 6207119444595d287b1e9e83a2066c17209698f3 upstream.

With this reproducer:
  struct sockaddr_alg alg = {
          .salg_family = 0x26,
          .salg_type = "hash",
          .salg_feat = 0xf,
          .salg_mask = 0x5,
          .salg_name = "digest_null",
  };
  int sock, sock2;

  sock = socket(AF_ALG, SOCK_SEQPACKET, 0);
  bind(sock, (struct sockaddr *)&alg, sizeof(alg));
  sock2 = accept(sock, NULL, NULL);
  setsockopt(sock, SOL_ALG, ALG_SET_KEY, "\x9b\xca", 2);
  accept(sock2, NULL, NULL);

==== 8< ======== 8< ======== 8< ======== 8< ====

one can immediatelly see an UBSAN warning:
UBSAN: Undefined behaviour in crypto/algif_hash.c:187:7
variable length array bound value 0 <= 0
CPU: 0 PID: 15949 Comm: syz-executor Tainted: G            E      4.4.30-0-default #1
...
Call Trace:
...
 [] ? __ubsan_handle_vla_bound_not_positive+0x13d/0x188
 [] ? __ubsan_handle_out_of_bounds+0x1bc/0x1bc
 [] ? hash_accept+0x5bd/0x7d0 [algif_hash]
 [] ? hash_accept_nokey+0x3f/0x51 [algif_hash]
 [] ? hash_accept_parent_nokey+0x4a0/0x4a0 [algif_hash]
 [] ? SyS_accept+0x2b/0x40

It is a correct warning, as hash state is propagated to accept as zero,
but creating a zero-length variable array is not allowed in C.

Fix this as proposed by Herbert -- do "?: 1" on that site. No sizeof or
similar happens in the code there, so we just allocate one byte even
though we do not use the array.

Signed-off-by: Jiri Slaby 
Cc: Herbert Xu 
Cc: "David S. Miller"  (maintainer:CRYPTO API)
Reported-by: Sasha Levin 
Signed-off-by: Herbert Xu 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

fbcon: Fix vc attr at deinit

2017-03-30T07:41:28+00:00

commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream.

fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust
the vc attrs dynamically when vc_hi_font_mask is changed at
fbcon_init().  When the vc_hi_font_mask is set, it remaps the attrs in
the existing console buffer with one bit shift up (for 9 bits), while
it remaps with one bit shift down (for 8 bits) when the value is
cleared.  It works fine as long as the font gets updated after fbcon
was initialized.

However, we hit a bizarre problem when the console is switched to
another fb driver (typically from vesafb or efifb to drmfb).  At
switching to the new fb driver, we temporarily rebind the console to
the dummy console, then rebind to the new driver.  During the
switching, we leave the modified attrs as is.  Thus, the new fbcon
takes over the old buffer as if it were to contain 8 bits chars
(although the attrs are still shifted for 9 bits), and effectively
this results in the yellow color texts instead of the original white
color, as found in the bugzilla entry below.

An easy fix for this is to re-adjust the attrs before leaving the
fbcon at con_deinit callback.  Since the code to adjust the attrs is
already present in the current fbcon code, in this patch, we simply
factor out the relevant code, and call it from fbcon_deinit().

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619
Signed-off-by: Takashi Iwai 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

drm: reference count event->completion

2017-03-30T07:41:28+00:00

commit 24835e442f289813aa568d142a755672a740503c upstream.

When writing the generic nonblocking commit code I assumed that
through clever lifetime management I can assure that the completion
(stored in drm_crtc_commit) only gets freed after it is completed. And
that worked.

I also wanted to make nonblocking helpers resilient against driver
bugs, by having timeouts everywhere. And that worked too.

Unfortunately taking boths things together results in oopses :( Well,
at least sometimes: What seems to happen is that the drm event hangs
around forever stuck in limbo land. The nonblocking helpers eventually
time out, move on and release it. Now the bug I tested all this
against is drivers that just entirely fail to deliver the vblank
events like they should, and in those cases the event is simply
leaked. But what seems to happen, at least sometimes, on i915 is that
the event is set up correctly, but somohow the vblank fails to fire in
time. Which means the event isn't leaked, it's still there waiting for
eventually a vblank to fire. That tends to happen when re-enabling the
pipe, and then the trap springs and the kernel oopses.

The correct fix here is simply to refcount the crtc commit to make
sure that the event sticks around even for drivers which only
sometimes fail to deliver vblanks for some arbitrary reasons. Since
crtc commits are already refcounted that's easy to do.

References: https://bugs.freedesktop.org/show_bug.cgi?id=96781
Cc: Jim Rees 
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Jani Nikula 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20161221102331.31033-1-daniel.vetter@ffwll.ch
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

nl80211: fix dumpit error path RTNL deadlocks

2017-03-30T07:41:28+00:00

commit ea90e0dc8cecba6359b481e24d9c37160f6f524f upstream.

Sowmini pointed out Dmitry's RTNL deadlock report to me, and it turns out
to be perfectly accurate - there are various error paths that miss unlock
of the RTNL.

To fix those, change the locking a bit to not be conditional in all those
nl80211_prepare_*_dump() functions, but make those require the RTNL to
start with, and fix the buggy error paths. This also let me use sparse
(by appropriately overriding the rtnl_lock/rtnl_unlock functions) to
validate the changes.

Reported-by: Sowmini Varadhan 
Reported-by: Dmitry Vyukov 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

drm/bridge: analogix dp: Fix runtime PM state on driver bind

2017-03-30T07:41:28+00:00

commit f0a8b49c03d22a511a601dc54b2a3425a41e35fa upstream.

Analogix_dp_bind() can be called from component framework, which doesn't
guarantee proper runtime PM state of the device during bind operation,
so ensure that device is runtime active before doing any register access.
This ensures that the power domain, to which DP module belongs, is turned
on. While at it, also fix the unbalanced call to phy_power_on() in
analogix_dp_bind() function.

This patch solves the following kernel oops on Samsung Exynos5250 Snow
board:

Unhandled fault: imprecise external abort (0x406) at 0x00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: : 406 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 75 Comm: kworker/0:2 Not tainted 4.9.0 #1046
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
task: ee272300 task.stack: ee312000
PC is at analogix_dp_enable_sw_function+0x18/0x2c
LR is at analogix_dp_init_dp+0x2c/0x50
...
[] (analogix_dp_enable_sw_function) from [] (analogix_dp_init_dp+0x2c/0x50)
[] (analogix_dp_init_dp) from [] (analogix_dp_bind+0x184/0x42c)
[] (analogix_dp_bind) from [] (component_bind_all+0xf0/0x218)
[] (component_bind_all) from [] (exynos_drm_load+0x134/0x200)
[] (exynos_drm_load) from [] (drm_dev_register+0xa0/0xd0)
[] (drm_dev_register) from [] (drm_platform_init+0x58/0xb0)
[] (drm_platform_init) from [] (try_to_bring_up_master+0x14c/0x188)
[] (try_to_bring_up_master) from [] (component_add+0x88/0x138)
[] (component_add) from [] (platform_drv_probe+0x50/0xb0)
[] (platform_drv_probe) from [] (driver_probe_device+0x1f0/0x2a8)
[] (driver_probe_device) from [] (bus_for_each_drv+0x44/0x8c)
[] (bus_for_each_drv) from [] (__device_attach+0x9c/0x100)
[] (__device_attach) from [] (bus_probe_device+0x84/0x8c)
[] (bus_probe_device) from [] (deferred_probe_work_func+0x60/0x8c)
[] (deferred_probe_work_func) from [] (process_one_work+0x120/0x318)
[] (process_one_work) from [] (process_scheduled_works+0x28/0x38)
[] (process_scheduled_works) from [] (worker_thread+0x204/0x4ac)
[] (worker_thread) from [] (kthread+0xd8/0xf4)
[] (kthread) from [] (ret_from_fork+0x14/0x3c)
Code: e59035f0 e5935018 f57ff04f e3c55001 (f57ff04e)
---[ end trace 3d1d0d87796de344 ]---

Reviewed-by: Sean Paul 
Signed-off-by: Marek Szyprowski 
Signed-off-by: Archit Taneja 
Link: http://patchwork.freedesktop.org/patch/msgid/1483091866-1088-1-git-send-email-m.szyprowski@samsung.com
Cc: Javier Martinez Canillas 
Signed-off-by: Greg Kroah-Hartman

device-dax: fix pmd/pte fault fallback handling

2017-03-30T07:41:27+00:00

commit 0134ed4fb9e78672ee9f7b18007114404c81e63f upstream.

Jeff Moyer reports:

    With a device dax alignment of 4KB or 2MB, I get sigbus when running
    the attached fio job file for the current kernel (4.11.0-rc1+).  If
    I specify an alignment of 1GB, it works.

    I turned on debug output, and saw that it was failing in the huge
    fault code.

     dax dax1.0: dax_open
     dax dax1.0: dax_mmap
     dax dax1.0: dax_dev_huge_fault: fio: write (0x7f08f0a00000 -
     dax dax1.0: __dax_dev_pud_fault: phys_to_pgoff(0xffffffffcf60
     dax dax1.0: dax_release

    fio config for reproduce:
    [global]
    ioengine=dev-dax
    direct=0
    filename=/dev/dax0.0
    bs=2m

    [write]
    rw=write

    [read]
    stonewall
    rw=read

The driver fails to fallback when taking a fault that is larger than
the device alignment, or handling a larger fault when a smaller
mapping is already established. While we could support larger
mappings for a device with a smaller alignment, that change is
too large for the immediate fix. The simplest change is to force
fallback until the fault size matches the alignment.

Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Cc: 
Reported-by: Jeff Moyer 
Signed-off-by: Dave Jiang 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

libceph: don't set weight to IN when OSD is destroyed

2017-03-30T07:41:27+00:00

commit b581a5854eee4b7851dedb0f8c2ceb54fb902c06 upstream.

Since ceph.git commit 4e28f9e63644 ("osd/OSDMap: clear osd_info,
osd_xinfo on osd deletion"), weight is set to IN when OSD is deleted.
This changes the result of applying an incremental for clients, not
just OSDs.  Because CRUSH computations are obviously affected,
pre-4e28f9e63644 servers disagree with post-4e28f9e63644 clients on
object placement, resulting in misdirected requests.

Mirrors ceph.git commit a6009d1039a55e2c77f431662b3d6cc5a8e8e63f.

Fixes: 930c53286977 ("libceph: apply new_state before new_up_client on incrementals")
Link: http://tracker.ceph.com/issues/19122
Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Don't leak memory when a channel is rescinded

2017-03-30T07:41:27+00:00

commit 5e030d5ce9d99a899b648413139ff65bab12b038 upstream.

When we close a channel that has been rescinded, we will leak memory since
vmbus_teardown_gpadl() returns an error. Fix this so that we can properly
cleanup the memory allocated to the ring buffers.

Fixes: ccb61f8a99e6 ("Drivers: hv: vmbus: Fix a rescind handling bug")

Signed-off-by: K. Y. Srinivasan 
Cc: Dexuan Cui 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Don't leak channel ids

2017-03-30T07:41:27+00:00

commit 9a5476020a5f06a0fc6f17097efc80275d2f03cd upstream.

If we cannot allocate memory for the channel, free the relid
associated with the channel.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman