linux-stable.git/drivers/gpu, branch v4.14.166

drm/i915: Fix use-after-free when destroying GEM context

2020-01-17T18:45:43+00:00

This patch is a simplified fix to address a use-after-free in 4.14.x and
4.19.x stable kernels. The flaw is already fixed upstream, starting in
5.2, by commit 7dc40713618c ("drm/i915: Introduce a mutex for
file_priv->context_idr") as part of a more complex patch series that
isn't appropriate for backporting to stable kernels.

Expand mutex coverage, while destroying the GEM context, to include the
GEM context lookup step. This fixes a use-after-free detected by KASAN:

 ==================================================================
 BUG: KASAN: use-after-free in i915_ppgtt_close+0x2ca/0x2f0
 Write of size 1 at addr ffff8881368a8368 by task i915-poc/3124

 CPU: 0 PID: 3124 Comm: i915-poc Not tainted 4.14.164 #1
 Hardware name: HP HP Elite x2 1012 G1 /80FC, BIOS N85 Ver. 01.20 04/05/2017
 Call Trace:
  dump_stack+0xcd/0x12e
  ? _atomic_dec_and_lock+0x1b2/0x1b2
  ? i915_ppgtt_close+0x2ca/0x2f0
  ? printk+0x8f/0xab
  ? show_regs_print_info+0x53/0x53
  ? i915_ppgtt_close+0x2ca/0x2f0
  print_address_description+0x65/0x270
  ? i915_ppgtt_close+0x2ca/0x2f0
  kasan_report+0x251/0x340
  i915_ppgtt_close+0x2ca/0x2f0
  ? __radix_tree_insert+0x3f0/0x3f0
  ? i915_ppgtt_init_hw+0x7c0/0x7c0
  context_close+0x42e/0x680
  ? i915_gem_context_release+0x230/0x230
  ? kasan_kmalloc+0xa0/0xd0
  ? radix_tree_delete_item+0x1d4/0x250
  ? radix_tree_lookup+0x10/0x10
  ? inet_recvmsg+0x4b0/0x4b0
  ? kasan_slab_free+0x88/0xc0
  i915_gem_context_destroy_ioctl+0x236/0x300
  ? i915_gem_context_create_ioctl+0x360/0x360
  ? drm_dev_printk+0x1d0/0x1d0
  ? memcpy+0x34/0x50
  ? i915_gem_context_create_ioctl+0x360/0x360
  drm_ioctl_kernel+0x1b0/0x2b0
  ? drm_ioctl_permit+0x2a0/0x2a0
  ? avc_ss_reset+0xd0/0xd0
  drm_ioctl+0x6fe/0xa20
  ? i915_gem_context_create_ioctl+0x360/0x360
  ? drm_getstats+0x20/0x20
  ? put_unused_fd+0x260/0x260
  do_vfs_ioctl+0x189/0x12d0
  ? ioctl_preallocate+0x280/0x280
  ? selinux_file_ioctl+0x3a7/0x680
  ? selinux_bprm_set_creds+0xe30/0xe30
  ? security_file_ioctl+0x69/0xa0
  ? selinux_bprm_set_creds+0xe30/0xe30
  SyS_ioctl+0x6f/0x80
  ? __sys_sendmmsg+0x4a0/0x4a0
  ? do_vfs_ioctl+0x12d0/0x12d0
  do_syscall_64+0x214/0x5f0
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x25/0x60
  ? __switch_to_asm+0x31/0x60
  ? syscall_return_slowpath+0x2c0/0x2c0
  ? copy_overflow+0x20/0x20
  ? __switch_to_asm+0x25/0x60
  ? syscall_return_via_sysret+0x2a/0x7a
  ? prepare_exit_to_usermode+0x200/0x200
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x25/0x60
  ? __switch_to_asm+0x25/0x60
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x25/0x60
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x25/0x60
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
 RIP: 0033:0x7f7fda5115d7
 RSP: 002b:00007f7eec317ec8 EFLAGS: 00000286 ORIG_RAX: 0000000000000010
 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7fda5115d7
 RDX: 000055b306db9188 RSI: 000000004008646e RDI: 0000000000000003
 RBP: 00007f7eec317ef0 R08: 00007f7eec318700 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000286 R12: 00007f7eec317fc0
 R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffd8007ade0

 Allocated by task 2898:
  save_stack+0x32/0xb0
  kasan_kmalloc+0xa0/0xd0
  kmem_cache_alloc_trace+0x5e/0x180
  i915_ppgtt_create+0xab/0x2510
  i915_gem_create_context+0x981/0xf90
  i915_gem_context_create_ioctl+0x1d7/0x360
  drm_ioctl_kernel+0x1b0/0x2b0
  drm_ioctl+0x6fe/0xa20
  do_vfs_ioctl+0x189/0x12d0
  SyS_ioctl+0x6f/0x80
  do_syscall_64+0x214/0x5f0
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

 Freed by task 104:
  save_stack+0x32/0xb0
  kasan_slab_free+0x72/0xc0
  kfree+0x88/0x190
  i915_ppgtt_release+0x24e/0x460
  i915_gem_context_free+0x90/0x480
  contexts_free_worker+0x54/0x80
  process_one_work+0x876/0x14e0
  worker_thread+0x1b8/0xfd0
  kthread+0x2f8/0x3c0
  ret_from_fork+0x35/0x40

 The buggy address belongs to the object at ffff8881368a8000
  which belongs to the cache kmalloc-8192 of size 8192
 The buggy address is located 872 bytes inside of
  8192-byte region [ffff8881368a8000, ffff8881368aa000)
 The buggy address belongs to the page:
 page:ffffea0004da2a00 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
 flags: 0x200000000008100(slab|head)
 raw: 0200000000008100 0000000000000000 0000000000000000 0000000100030003
 raw: dead000000000100 dead000000000200 ffff88822a002280 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff8881368a8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8881368a8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 >ffff8881368a8300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                           ^
  ffff8881368a8380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8881368a8400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ==================================================================

Fixes: 1acfc104cdf8 ("drm/i915: Enable rcu-only context lookups")
Reported-by: 罗权 
Cc: Chris Wilson 
Cc: Jon Bloomfield 
Cc: stable@vger.kernel.org # 4.14.x
Cc: stable@vger.kernel.org # 4.19.x
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

drm/i915/gen9: Clear residual context state on context switch

2020-01-14T19:05:49+00:00

commit bc8a76a152c5f9ef3b48104154a65a68a8b76946 upstream.

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

Intel GPU Hardware prior to Gen11 does not clear EU state
during a context switch. This can result in information
leakage between contexts.

For Gen8 and Gen9, hardware provides a mechanism for
fast cleardown of the EU state, by issuing a PIPE_CONTROL
with bit 27 set. We can use this in a context batch buffer
to explicitly cleardown the state on every context switch.

As this workaround is already in place for gen8, we can borrow
the code verbatim for Gen9.

Signed-off-by: Mika Kuoppala 
Signed-off-by: Akeem G Abodunrin 
Cc: Kumar Valsan Prathap 
Cc: Chris Wilson 
Cc: Balestrieri Francesco 
Cc: Bloomfield Jon 
Cc: Dutt Sudeep 
Signed-off-by: Greg Kroah-Hartman

drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

2020-01-14T19:05:44+00:00

commit c4e4fccc5d52d881afaac11d3353265ef4eccb8b upstream.

[Why]
According to DP spec, it should shift left 4 digits for NO_STOP_BIT
in REMOTE_I2C_READ message. Not 5 digits.

In current code, NO_STOP_BIT is always set to zero which means I2C
master is always generating a I2C stop at the end of each I2C write
transaction while handling REMOTE_I2C_READ sideband message. This issue
might have the generated I2C signal not meeting the requirement. Take
random read in I2C for instance, I2C master should generate a repeat
start to start to read data after writing the read address. This issue
will cause the I2C master to generate a stop-start rather than a
re-start which is not expected in I2C random read.

[How]
Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
drm_dp_encode_sideband_req().

Changes since v1:(https://patchwork.kernel.org/patch/11312667/)
* Add more descriptions in commit and cc to stable

Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
Reviewed-by: Harry Wentland 
Signed-off-by: Wayne Lin 
Cc: stable@vger.kernel.org
Signed-off-by: Lyude Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20200103055001.10287-1-Wayne.Lin@amd.com
Signed-off-by: Greg Kroah-Hartman

drm/fb-helper: Round up bits_per_pixel if possible

2020-01-14T19:05:44+00:00

commit f30e27779d3031a092c2a177b7fb76adccc45241 upstream.

When userspace requests a video mode parameter value that is not
supported, frame buffer device drivers should round it up to a supported
value, if possible, instead of just rejecting it.  This allows
applications to quickly scan for supported video modes.

Currently this rule is not followed for the number of bits per pixel,
causing e.g. "fbset -depth N" to fail, if N is smaller than the current
number of bits per pixel.

Fix this by returning an error only if bits per pixel is too large, and
setting it to the current value otherwise.

See also Documentation/fb/framebuffer.rst, Section 2 (Programmer's View
of /dev/fb*").

Fixes: 865afb11949e5bf4 ("drm/fb-helper: reject any changes to the fbdev")
Cc: stable@vger.kernel.org
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20191230132734.4538-1-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman

drm/mst: Fix MST sideband up-reply failure handling

2020-01-09T09:17:58+00:00

[ Upstream commit d8fd3722207f154b53c80eee2cf4977c3fc25a92 ]

Fix the breakage resulting in the stacktrace below, due to tx queue
being full when trying to send an up-reply. txmsg->seqno is -1 in this
case leading to a corruption of the mstb object by

	txmsg->dst->tx_slots[txmsg->seqno] = NULL;

in process_single_up_tx_qlock().

[  +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]] set_hdr_from_dst_qlock: failed to find slot
[  +0,000015] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]] failed to send msg in q -11
[  +0,000939] BUG: kernel NULL pointer dereference, address: 00000000000005a0
[  +0,006982] #PF: supervisor write access in kernel mode
[  +0,005223] #PF: error_code(0x0002) - not-present page
[  +0,005135] PGD 0 P4D 0
[  +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
[  +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted: G     U            5.2.0-rc1+ #410
[  +0,008433] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428 04/26/2019
[  +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
[  +0,005676] RIP: 0010:queue_work_on+0x19/0x70
[  +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00  48 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
[  +0,018750] RSP: 0018:ffffc900007dfc50 EFLAGS: 00010006
[  +0,005222] RAX: 0000000000000046 RBX: 00000000000005a0 RCX: 0000000000000001
[  +0,007133] RDX: 000000000001b608 RSI: 0000000000000000 RDI: ffffffff82121972
[  +0,007129] RBP: 0000000000000202 R08: 0000000000000000 R09: 0000000000000001
[  +0,007129] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88847bfa5096
[  +0,007131] R13: 0000000000000010 R14: ffff88849c08f3f8 R15: 0000000000000000
[  +0,007128] FS:  0000000000000000(0000) GS:ffff88849dc80000(0000) knlGS:0000000000000000
[  +0,008083] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0,005749] CR2: 00000000000005a0 CR3: 0000000005210006 CR4: 0000000000760ee0
[  +0,007128] PKRU: 55555554
[  +0,002722] Call Trace:
[  +0,002458]  drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
[  +0,006197]  ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[  +0,005764]  drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[  +0,005623]  ? intel_dp_hpd_pulse+0x205/0x370 [i915]
[  +0,005018]  intel_dp_hpd_pulse+0x205/0x370 [i915]
[  +0,004836]  i915_digport_work_func+0xbb/0x140 [i915]
[  +0,005108]  process_one_work+0x245/0x610
[  +0,004027]  worker_thread+0x37/0x380
[  +0,003684]  ? process_one_work+0x610/0x610
[  +0,004184]  kthread+0x119/0x130
[  +0,003240]  ? kthread_park+0x80/0x80
[  +0,003668]  ret_from_fork+0x24/0x50

Cc: Lyude Paul 
Cc: Dave Airlie 
Signed-off-by: Imre Deak 
Reviewed-by: Lyude Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20190523212433.9058-1-imre.deak@intel.com
Signed-off-by: Sasha Levin

drm/sun4i: hdmi: Remove duplicate cleanup calls

2020-01-09T09:17:54+00:00

commit 57177d214ee0816c4436c23d6c933ccb32c571f1 upstream.

When the HDMI unbinds drm_connector_cleanup() and drm_encoder_cleanup()
are called. This also happens when the connector and the encoder are
destroyed. This double call triggers a NULL pointer exception.

The patch fixes this by removing the cleanup calls in the unbind
function.

Cc: 
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Stefan Mavrodiev 
Signed-off-by: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20191217124632.20820-1-stefan@olimex.com
Signed-off-by: Greg Kroah-Hartman

drm: limit to INT_MAX in create_blob ioctl

2020-01-09T09:17:53+00:00

[ Upstream commit 5bf8bec3f4ce044a223c40cbce92590d938f0e9c ]

The hardened usercpy code is too paranoid ever since commit 6a30afa8c1fb
("uaccess: disallow > INT_MAX copy sizes")

Code itself should have been fine as-is.

Link: http://lkml.kernel.org/r/20191106164755.31478-1-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter 
Reported-by: syzbot+fb77e97ebf0612ee6914@syzkaller.appspotmail.com
Fixes: 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes")
Cc: Kees Cook 
Cc: Alexander Viro 
Cc: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

drm/nouveau: Move the declaration of struct nouveau_conn_atom up a bit

2020-01-09T09:17:51+00:00

[ Upstream commit 37a68eab4cd92b507c9e8afd760fdc18e4fecac6 ]

Place the declaration of struct nouveau_conn_atom above that of
struct nouveau_connector. This commit makes no changes to the moved
block what so ever, it just moves it up a bit.

This is a preparation patch to fix some issues with connector handling
on pre nv50 displays (which do not use atomic modesetting).

Signed-off-by: Hans de Goede 
Reviewed-by: Lyude Paul 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin

drm/amdgpu: fix potential double drop fence reference

2019-12-31T11:37:30+00:00

[ Upstream commit 946ab8db6953535a3a88c957db8328beacdfed9d ]

The object fence is not set to NULL after its reference is dropped. As a
result, its reference may be dropped again if error occurs after that,
which may lead to a use after free bug. To avoid the issue, fence is
explicitly set to NULL after dropping its reference.

Acked-by: Christian König 
Signed-off-by: Pan Bian 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

gpu: host1x: Allocate gather copy for host1x

2019-12-31T11:37:17+00:00

[ Upstream commit b78e70c04c149299bd210759d7c7af7c86b89ca8 ]

Currently when the gather buffers are copied, they are copied to a
buffer that is allocated for the host1x client that wants to execute the
command streams in the buffers. However, the gather buffers will be read
by the host1x device, which causes SMMU faults if the DMA API is backed
by an IOMMU.

Fix this by allocating the gather buffer copy for the host1x device,
which makes sure that it will be mapped into the host1x's IOVA space if
the DMA API is backed by an IOMMU.

Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin