user/sven/linux.git/drivers/gpu, branch v4.4.228

drm/msm: Fix possible null dereference on failure of get_pages()

2020-06-03T06:12:16Z

commit 3976626ea3d2011f8fd3f3a47070a8b792018253 upstream. Commit 62e3a3e342af changed get_pages() to initialise msm_gem_object::pages before trying to initialise msm_gem_object::sgt, so that put_pages() would properly clean up pages in the failure case. However, this means that put_pages() now needs to check that msm_gem_object::sgt is not null before trying to clean it up, and this check was only applied to part of the cleanup code. Move it all into the conditional block. (Strictly speaking we don't need to make the kfree() conditional, but since we can't avoid checking for null ourselves we may as well do so.) Fixes: 62e3a3e342af ("drm/msm: fix leak in failed get_pages") Signed-off-by: Ben Hutchings Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

drm/fb-helper: Use proper plane mask for fb cleanup

2020-06-03T06:12:14Z

commit 7118fd9bd975a9f3093239d4c0f4e15356b57fab upstream. pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the legacy FB fields (plane->fb and plane->old_fb). However it was building the plane mask to pass to this function incorrectly (the bitwise OR was using plane indices rather than plane masks). The end result was that sometimes the legacy pointers would become out of sync with the atomic pointers. If another operation tried to re-set the same FB onto the plane, we might end up with the pointers back in sync, but improper reference counts, which would eventually lead to system crashes when we accessed a pointer to a prematurely-destroyed FB. The cause here was a very subtle bug introduced in commit: commit 07d3bad6c1210bd21e85d084807ef4ee4ac43a78 Author: Maarten Lankhorst Date: Wed Nov 11 11:29:11 2015 +0100 drm/core: Fix old_fb handling in pan_display_atomic. I found the crashes were most easily reproduced (on i915 at least) by starting X and then VT switching to a VT that wasn't running a console instance...the sequence of vt/fbcon entries that happen in that case trigger a reference count mismatch and crash the system. Cc: Maarten Lankhorst Cc: Daniel Vetter Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93313 Signed-off-by: Matt Roper Signed-off-by: Daniel Vetter Signed-off-by: Xuebing Chen Signed-off-by: Greg Kroah-Hartman

drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()

2020-05-20T06:11:45Z

[ Upstream commit 5b5703dbafae74adfbe298a56a81694172caf5e6 ] v2: removed TODO reminder Signed-off-by: Vasily Averin Link: http://patchwork.freedesktop.org/patch/msgid/a4e0ae09-a73c-1c62-04ef-3f990d41bea9@virtuozzo.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin

drm/qxl: qxl_release leak in qxl_draw_dirty_fb()

2020-05-10T08:25:38Z

commit 85e9b88af1e6164f19ec71381efd5e2bcfc17620 upstream. ret should be changed to release allocated struct qxl_release Cc: stable@vger.kernel.org Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations") Signed-off-by: Vasily Averin Link: http://patchwork.freedesktop.org/patch/msgid/22cfd55f-07c8-95d0-a2f7-191b7153c3d4@virtuozzo.com Signed-off-by: Gerd Hoffmann Signed-off-by: Vasily Averin Signed-off-by: Greg Kroah-Hartman

drm/qxl: qxl_release use after free

2020-05-10T08:25:38Z

commit 933db73351d359f74b14f4af095808260aff11f9 upstream. qxl_release should not be accesses after qxl_push_*_ring_release() calls: userspace driver can process submitted command quickly, move qxl_release into release_ring, generate interrupt and trigger garbage collector. It can lead to crashes in qxl driver or trigger memory corruption in some kmalloc-192 slab object Gerd Hoffmann proposes to swap the qxl_release_fence_buffer_objects() + qxl_push_{cursor,command}_ring_release() calls to close that race window. cc: stable@vger.kernel.org Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)") Signed-off-by: Vasily Averin Link: http://patchwork.freedesktop.org/patch/msgid/fa17b338-66ae-f299-68fe-8d32419d9071@virtuozzo.com Signed-off-by: Gerd Hoffmann Signed-off-by: Vasily Averin Signed-off-by: Greg Kroah-Hartman

drm/qxl: qxl_release leak in qxl_hw_surface_alloc()

2020-05-05T17:13:21Z

commit a65aa9c3676ffccb21361d52fcfedd5b5ff387d7 upstream. Cc: stable@vger.kernel.org Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations") Signed-off-by: Vasily Averin Link: http://patchwork.freedesktop.org/patch/msgid/2e5a13ae-9ab2-5401-aa4d-03d5f5593423@virtuozzo.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman

drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

2020-04-24T05:57:21Z

commit 22a07038c0eaf4d1315a493ce66dcd255accba19 upstream. The Parfait (version 2.1.0) static code analysis tool found the following NULL pointer derefernce problem. - drivers/gpu/drm/drm_dp_mst_topology.c The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt() could result in a NULL pointer being returned to port->mstb due to a failure to allocate memory for port->mstb. Signed-off-by: Joe Moriarty Reviewed-by: Steven Sistare Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-3-joe.moriarty@oracle.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman

drm/dp_mst: Fix clearing payload state on topology disable

2020-04-24T05:57:17Z

[ Upstream commit 8732fe46b20c951493bfc4dba0ad08efdf41de81 ] The issues caused by: commit 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr") Prompted me to take a closer look at how we clear the payload state in general when disabling the topology, and it turns out there's actually two subtle issues here. The first is that we're not grabbing &mgr.payload_lock when clearing the payloads in drm_dp_mst_topology_mgr_set_mst(). Seeing as the canonical lock order is &mgr.payload_lock -> &mgr.lock (because we always want &mgr.lock to be the inner-most lock so topology validation always works), this makes perfect sense. It also means that -technically- there could be racing between someone calling drm_dp_mst_topology_mgr_set_mst() to disable the topology, along with a modeset occurring that's modifying the payload state at the same time. The second is the more obvious issue that Wayne Lin discovered, that we're not clearing proposed_payloads when disabling the topology. I actually can't see any obvious places where the racing caused by the first issue would break something, and it could be that some of our higher-level locks already prevent this by happenstance, but better safe then sorry. So, let's make it so that drm_dp_mst_topology_mgr_set_mst() first grabs &mgr.payload_lock followed by &mgr.lock so that we never race when modifying the payload state. Then, we also clear proposed_payloads to fix the original issue of enabling a new topology with a dirty payload state. This doesn't clear any of the drm_dp_vcpi structures, but those are getting destroyed along with the ports anyway. Changes since v1: * Use sizeof(mgr->payloads[0])/sizeof(mgr->proposed_vcpis[0]) instead - vsyrjala Cc: Sean Paul Cc: Wayne Lin Cc: Ville Syrjälä Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Lyude Paul Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200122194321.14953-1-lyude@redhat.com Signed-off-by: Sasha Levin

drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read()

2020-04-13T08:31:35Z

commit a4c30a4861c54af78c4eb8b7855524c1a96d9f80 upstream. When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the result is wrong due to a missing idx increment. This was never noticed since DP_REMOTE_DPCD_READ is currently not used, but if you enable it, then it is all wrong. Signed-off-by: Hans Verkuil Reviewed-by: Lyude Paul Acked-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/e72ddac2-1dc0-100a-d816-9ac98ac009dd@xs4all.nl Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman

drm/bochs: downgrade pci_request_region failure from error to warning

2020-04-13T08:31:25Z

[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ] Shutdown of firmware framebuffer has a bunch of problems. Because of this the framebuffer region might still be reserved even after drm_fb_helper_remove_conflicting_pci_framebuffers() returned. Don't consider pci_request_region() failure for the framebuffer region as fatal error to workaround this issue. Reported-by: Marek Marczykowski-Górecki Signed-off-by: Gerd Hoffmann Acked-by: Sam Ravnborg Link: http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kraxel@redhat.com Signed-off-by: Sasha Levin