* [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create @ 2020-02-02 13:21 ` Daniel Vetter 0 siblings, 0 replies; 15+ messages in thread From: Daniel Vetter @ 2020-02-02 13:21 UTC (permalink / raw) To: DRI Development Cc: Rob Clark, Hillf Danton, Daniel Vetter, Intel Graphics Development, stable, Sean Paul, Daniel Vetter, Sam Ravnborg, Dan Carpenter, Emil Velikov There's two references floating around here (for the object reference, not the handle_count reference, that's a different thing): - The temporary reference held by vgem_gem_create, acquired by creating the object and released by calling drm_gem_object_put_unlocked. - The reference held by the object handle, created by drm_gem_handle_create. This one generally outlives the function, except if a 2nd thread races with a GEM_CLOSE ioctl call. So usually everything is correct, except in that race case, where the access to gem_object->size could be looking at freed data already. Which again isn't a real problem (userspace shot its feet off already with the race, we could return garbage), but maybe someone can exploit this as an information leak. Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Hillf Danton <hdanton@sina.com> Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Eric Anholt <eric@anholt.net> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Clark <robdclark@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 5bd60ded3d81..909eba43664a 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, return ERR_CAST(obj); ret = drm_gem_handle_create(file, &obj->base, handle); - drm_gem_object_put_unlocked(&obj->base); - if (ret) + if (ret) { + drm_gem_object_put_unlocked(&obj->base); return ERR_PTR(ret); + } return &obj->base; } @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, args->size = gem_object->size; args->pitch = pitch; - DRM_DEBUG("Created object of size %lld\n", size); + drm_gem_object_put_unlocked(gem_object); + + DRM_DEBUG("Created object of size %llu\n", args->size); return 0; } -- 2.24.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create @ 2020-02-02 13:21 ` Daniel Vetter 0 siblings, 0 replies; 15+ messages in thread From: Daniel Vetter @ 2020-02-02 13:21 UTC (permalink / raw) To: DRI Development Cc: Intel Graphics Development, Daniel Vetter, Dan Carpenter, Hillf Danton, stable, Emil Velikov, Sean Paul, Chris Wilson, Eric Anholt, Sam Ravnborg, Rob Clark, Daniel Vetter There's two references floating around here (for the object reference, not the handle_count reference, that's a different thing): - The temporary reference held by vgem_gem_create, acquired by creating the object and released by calling drm_gem_object_put_unlocked. - The reference held by the object handle, created by drm_gem_handle_create. This one generally outlives the function, except if a 2nd thread races with a GEM_CLOSE ioctl call. So usually everything is correct, except in that race case, where the access to gem_object->size could be looking at freed data already. Which again isn't a real problem (userspace shot its feet off already with the race, we could return garbage), but maybe someone can exploit this as an information leak. Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Hillf Danton <hdanton@sina.com> Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Eric Anholt <eric@anholt.net> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Clark <robdclark@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 5bd60ded3d81..909eba43664a 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, return ERR_CAST(obj); ret = drm_gem_handle_create(file, &obj->base, handle); - drm_gem_object_put_unlocked(&obj->base); - if (ret) + if (ret) { + drm_gem_object_put_unlocked(&obj->base); return ERR_PTR(ret); + } return &obj->base; } @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, args->size = gem_object->size; args->pitch = pitch; - DRM_DEBUG("Created object of size %lld\n", size); + drm_gem_object_put_unlocked(gem_object); + + DRM_DEBUG("Created object of size %llu\n", args->size); return 0; } -- 2.24.1 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [Intel-gfx] [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create @ 2020-02-02 13:21 ` Daniel Vetter 0 siblings, 0 replies; 15+ messages in thread From: Daniel Vetter @ 2020-02-02 13:21 UTC (permalink / raw) To: DRI Development Cc: Rob Clark, Hillf Danton, Daniel Vetter, Intel Graphics Development, stable, Eric Anholt, Sean Paul, Daniel Vetter, Sam Ravnborg, Dan Carpenter, Emil Velikov There's two references floating around here (for the object reference, not the handle_count reference, that's a different thing): - The temporary reference held by vgem_gem_create, acquired by creating the object and released by calling drm_gem_object_put_unlocked. - The reference held by the object handle, created by drm_gem_handle_create. This one generally outlives the function, except if a 2nd thread races with a GEM_CLOSE ioctl call. So usually everything is correct, except in that race case, where the access to gem_object->size could be looking at freed data already. Which again isn't a real problem (userspace shot its feet off already with the race, we could return garbage), but maybe someone can exploit this as an information leak. Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Hillf Danton <hdanton@sina.com> Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Eric Anholt <eric@anholt.net> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Clark <robdclark@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 5bd60ded3d81..909eba43664a 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, return ERR_CAST(obj); ret = drm_gem_handle_create(file, &obj->base, handle); - drm_gem_object_put_unlocked(&obj->base); - if (ret) + if (ret) { + drm_gem_object_put_unlocked(&obj->base); return ERR_PTR(ret); + } return &obj->base; } @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, args->size = gem_object->size; args->pitch = pitch; - DRM_DEBUG("Created object of size %lld\n", size); + drm_gem_object_put_unlocked(gem_object); + + DRM_DEBUG("Created object of size %llu\n", args->size); return 0; } -- 2.24.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/vgem: Close use-after-free race in vgem_gem_create 2020-02-02 13:21 ` [Intel-gfx] " Daniel Vetter (?) (?) @ 2020-02-02 13:38 ` Patchwork -1 siblings, 0 replies; 15+ messages in thread From: Patchwork @ 2020-02-02 13:38 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx == Series Details == Series: drm/vgem: Close use-after-free race in vgem_gem_create URL : https://patchwork.freedesktop.org/series/72873/ State : warning == Summary == $ dim checkpatch origin/drm-tip d0b2cbabe0de drm/vgem: Close use-after-free race in vgem_gem_create -:25: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com' #25: Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com -:63: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>' total: 1 errors, 1 warnings, 0 checks, 22 lines checked _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/vgem: Close use-after-free race in vgem_gem_create 2020-02-02 13:21 ` [Intel-gfx] " Daniel Vetter ` (2 preceding siblings ...) (?) @ 2020-02-02 14:34 ` Patchwork -1 siblings, 0 replies; 15+ messages in thread From: Patchwork @ 2020-02-02 14:34 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx == Series Details == Series: drm/vgem: Close use-after-free race in vgem_gem_create URL : https://patchwork.freedesktop.org/series/72873/ State : success == Summary == CI Bug Log - changes from CI_DRM_7856 -> Patchwork_16379 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/index.html Known issues ------------ Here are the changes found in Patchwork_16379 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][1] -> [FAIL][2] ([fdo#111096] / [i915#323]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html #### Possible fixes #### * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [FAIL][3] ([i915#178]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html * igt@i915_selftest@live_blt: - fi-ivb-3770: [DMESG-FAIL][5] ([i915#725]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/fi-ivb-3770/igt@i915_selftest@live_blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/fi-ivb-3770/igt@i915_selftest@live_blt.html - fi-hsw-4770: [DMESG-FAIL][7] ([i915#553] / [i915#725]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/fi-hsw-4770/igt@i915_selftest@live_blt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/fi-hsw-4770/igt@i915_selftest@live_blt.html * igt@i915_selftest@live_execlists: - fi-icl-y: [DMESG-FAIL][9] ([fdo#108569]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/fi-icl-y/igt@i915_selftest@live_execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/fi-icl-y/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_gem_contexts: - fi-byt-n2820: [DMESG-FAIL][11] ([i915#1052]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html * igt@i915_selftest@live_gtt: - fi-hsw-4770: [TIMEOUT][13] ([fdo#112271]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/fi-hsw-4770/igt@i915_selftest@live_gtt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/fi-hsw-4770/igt@i915_selftest@live_gtt.html #### Warnings #### * igt@gem_exec_parallel@fds: - fi-byt-n2820: [FAIL][15] ([i915#694]) -> [TIMEOUT][16] ([fdo#112271] / [i915#1084]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/fi-byt-n2820/igt@gem_exec_parallel@fds.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/fi-byt-n2820/igt@gem_exec_parallel@fds.html [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052 [i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084 [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553 [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694 [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725 Participating hosts (43 -> 42) ------------------------------ Additional (8): fi-bdw-5557u fi-byt-j1900 fi-bwr-2160 fi-ilk-650 fi-bsw-kefka fi-skl-lmem fi-bsw-nick fi-skl-6600u Missing (9): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-bsw-cyan fi-gdg-551 fi-blb-e6850 fi-byt-clapper fi-bdw-samus fi-kbl-r Build changes ------------- * CI: CI-20190529 -> None * Linux: CI_DRM_7856 -> Patchwork_16379 CI-20190529: 20190529 CI_DRM_7856: a113999b001035a5b6474407b228363c163574a3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5411: 86c6ab8a0b6696bdb2153febd350af7fa02fbb00 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16379: d0b2cbabe0deb86f971d677bf112493016c4ad54 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d0b2cbabe0de drm/vgem: Close use-after-free race in vgem_gem_create == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/index.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create 2020-02-02 13:21 ` [Intel-gfx] " Daniel Vetter (?) @ 2020-02-02 15:39 ` Sam Ravnborg -1 siblings, 0 replies; 15+ messages in thread From: Sam Ravnborg @ 2020-02-02 15:39 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Hillf Danton, Intel Graphics Development, stable, Sean Paul, DRI Development, Daniel Vetter, Dan Carpenter, Emil Velikov Hi Daniel. On Sun, Feb 02, 2020 at 02:21:33PM +0100, Daniel Vetter wrote: > There's two references floating around here (for the object reference, > not the handle_count reference, that's a different thing): > > - The temporary reference held by vgem_gem_create, acquired by > creating the object and released by calling > drm_gem_object_put_unlocked. > > - The reference held by the object handle, created by > drm_gem_handle_create. This one generally outlives the function, > except if a 2nd thread races with a GEM_CLOSE ioctl call. > > So usually everything is correct, except in that race case, where the > access to gem_object->size could be looking at freed data already. > Which again isn't a real problem (userspace shot its feet off already > with the race, we could return garbage), but maybe someone can exploit > this as an information leak. > > Cc: Dan Carpenter <dan.carpenter@oracle.com> > Cc: Hillf Danton <hdanton@sina.com> > Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com ^^ Small typo > Cc: stable@vger.kernel.org > Cc: Emil Velikov <emil.velikov@collabora.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Sean Paul <seanpaul@chromium.org> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Eric Anholt <eric@anholt.net> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Rob Clark <robdclark@chromium.org> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index 5bd60ded3d81..909eba43664a 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > return ERR_CAST(obj); > > ret = drm_gem_handle_create(file, &obj->base, handle); > - drm_gem_object_put_unlocked(&obj->base); > - if (ret) > + if (ret) { > + drm_gem_object_put_unlocked(&obj->base); > return ERR_PTR(ret); > + } > > return &obj->base; > } > @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > args->size = gem_object->size; > args->pitch = pitch; > > - DRM_DEBUG("Created object of size %lld\n", size); > + drm_gem_object_put_unlocked(gem_object); > + > + DRM_DEBUG("Created object of size %llu\n", args->size); > > return 0; > } > -- > 2.24.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create @ 2020-02-02 15:39 ` Sam Ravnborg 0 siblings, 0 replies; 15+ messages in thread From: Sam Ravnborg @ 2020-02-02 15:39 UTC (permalink / raw) To: Daniel Vetter Cc: DRI Development, Rob Clark, Hillf Danton, Intel Graphics Development, stable, Sean Paul, Daniel Vetter, Dan Carpenter, Emil Velikov Hi Daniel. On Sun, Feb 02, 2020 at 02:21:33PM +0100, Daniel Vetter wrote: > There's two references floating around here (for the object reference, > not the handle_count reference, that's a different thing): > > - The temporary reference held by vgem_gem_create, acquired by > creating the object and released by calling > drm_gem_object_put_unlocked. > > - The reference held by the object handle, created by > drm_gem_handle_create. This one generally outlives the function, > except if a 2nd thread races with a GEM_CLOSE ioctl call. > > So usually everything is correct, except in that race case, where the > access to gem_object->size could be looking at freed data already. > Which again isn't a real problem (userspace shot its feet off already > with the race, we could return garbage), but maybe someone can exploit > this as an information leak. > > Cc: Dan Carpenter <dan.carpenter@oracle.com> > Cc: Hillf Danton <hdanton@sina.com> > Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com ^^ Small typo > Cc: stable@vger.kernel.org > Cc: Emil Velikov <emil.velikov@collabora.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Sean Paul <seanpaul@chromium.org> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Eric Anholt <eric@anholt.net> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Rob Clark <robdclark@chromium.org> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index 5bd60ded3d81..909eba43664a 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > return ERR_CAST(obj); > > ret = drm_gem_handle_create(file, &obj->base, handle); > - drm_gem_object_put_unlocked(&obj->base); > - if (ret) > + if (ret) { > + drm_gem_object_put_unlocked(&obj->base); > return ERR_PTR(ret); > + } > > return &obj->base; > } > @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > args->size = gem_object->size; > args->pitch = pitch; > > - DRM_DEBUG("Created object of size %lld\n", size); > + drm_gem_object_put_unlocked(gem_object); > + > + DRM_DEBUG("Created object of size %llu\n", args->size); > > return 0; > } > -- > 2.24.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create @ 2020-02-02 15:39 ` Sam Ravnborg 0 siblings, 0 replies; 15+ messages in thread From: Sam Ravnborg @ 2020-02-02 15:39 UTC (permalink / raw) To: Daniel Vetter Cc: Rob Clark, Hillf Danton, Intel Graphics Development, stable, Sean Paul, DRI Development, Daniel Vetter, Dan Carpenter, Emil Velikov Hi Daniel. On Sun, Feb 02, 2020 at 02:21:33PM +0100, Daniel Vetter wrote: > There's two references floating around here (for the object reference, > not the handle_count reference, that's a different thing): > > - The temporary reference held by vgem_gem_create, acquired by > creating the object and released by calling > drm_gem_object_put_unlocked. > > - The reference held by the object handle, created by > drm_gem_handle_create. This one generally outlives the function, > except if a 2nd thread races with a GEM_CLOSE ioctl call. > > So usually everything is correct, except in that race case, where the > access to gem_object->size could be looking at freed data already. > Which again isn't a real problem (userspace shot its feet off already > with the race, we could return garbage), but maybe someone can exploit > this as an information leak. > > Cc: Dan Carpenter <dan.carpenter@oracle.com> > Cc: Hillf Danton <hdanton@sina.com> > Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com ^^ Small typo > Cc: stable@vger.kernel.org > Cc: Emil Velikov <emil.velikov@collabora.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Sean Paul <seanpaul@chromium.org> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Eric Anholt <eric@anholt.net> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Rob Clark <robdclark@chromium.org> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index 5bd60ded3d81..909eba43664a 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > return ERR_CAST(obj); > > ret = drm_gem_handle_create(file, &obj->base, handle); > - drm_gem_object_put_unlocked(&obj->base); > - if (ret) > + if (ret) { > + drm_gem_object_put_unlocked(&obj->base); > return ERR_PTR(ret); > + } > > return &obj->base; > } > @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > args->size = gem_object->size; > args->pitch = pitch; > > - DRM_DEBUG("Created object of size %lld\n", size); > + drm_gem_object_put_unlocked(gem_object); > + > + DRM_DEBUG("Created object of size %llu\n", args->size); > > return 0; > } > -- > 2.24.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create 2020-02-02 13:21 ` [Intel-gfx] " Daniel Vetter (?) @ 2020-02-02 17:37 ` Chris Wilson -1 siblings, 0 replies; 15+ messages in thread From: Chris Wilson @ 2020-02-02 17:37 UTC (permalink / raw) To: DRI Development, Daniel Vetter Cc: Rob Clark, Hillf Danton, Daniel Vetter, Intel Graphics Development, stable, Sean Paul, Daniel Vetter, Sam Ravnborg, Dan Carpenter, Emil Velikov Quoting Daniel Vetter (2020-02-02 13:21:33) > There's two references floating around here (for the object reference, > not the handle_count reference, that's a different thing): > > - The temporary reference held by vgem_gem_create, acquired by > creating the object and released by calling > drm_gem_object_put_unlocked. > > - The reference held by the object handle, created by > drm_gem_handle_create. This one generally outlives the function, > except if a 2nd thread races with a GEM_CLOSE ioctl call. > > So usually everything is correct, except in that race case, where the > access to gem_object->size could be looking at freed data already. > Which again isn't a real problem (userspace shot its feet off already > with the race, we could return garbage), but maybe someone can exploit > this as an information leak. > > Cc: Dan Carpenter <dan.carpenter@oracle.com> > Cc: Hillf Danton <hdanton@sina.com> > Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com > Cc: stable@vger.kernel.org > Cc: Emil Velikov <emil.velikov@collabora.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Sean Paul <seanpaul@chromium.org> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Eric Anholt <eric@anholt.net> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Rob Clark <robdclark@chromium.org> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index 5bd60ded3d81..909eba43664a 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > return ERR_CAST(obj); > > ret = drm_gem_handle_create(file, &obj->base, handle); > - drm_gem_object_put_unlocked(&obj->base); > - if (ret) > + if (ret) { > + drm_gem_object_put_unlocked(&obj->base); > return ERR_PTR(ret); > + } > > return &obj->base; > } > @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > args->size = gem_object->size; > args->pitch = pitch; > > - DRM_DEBUG("Created object of size %lld\n", size); > + drm_gem_object_put_unlocked(gem_object); > + > + DRM_DEBUG("Created object of size %llu\n", args->size); I was thinking we either should return size from vgem_gem_create (the strategy we took in i915) or simply remove the vgem_gem_create() as that doesn't improve readability. -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, - struct drm_file *file, - unsigned int *handle, - unsigned long size) +static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, + struct drm_mode_create_dumb *args) { struct drm_vgem_gem_object *obj; - int ret; + u64 pitch, size; + u32 handle; + + pitch = args->width * DIV_ROUND_UP(args->bpp, 8); + size = mul_u32_u32(args->height, pitch); + if (size == 0 || pitch < args->width) + return -EINVAL; obj = __vgem_gem_create(dev, size); if (IS_ERR(obj)) - return ERR_CAST(obj); + return PTR_ERR(obj); + + size = obj->base.size; - ret = drm_gem_handle_create(file, &obj->base, handle); + ret = drm_gem_handle_create(file, &obj->base, &handle); drm_gem_object_put_unlocked(&obj->base); if (ret) return ERR_PTR(ret); - return &obj->base; -} - -static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, - struct drm_mode_create_dumb *args) -{ - struct drm_gem_object *gem_object; - u64 pitch, size; - - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); - size = args->height * pitch; - if (size == 0) - return -EINVAL; - - gem_object = vgem_gem_create(dev, file, &args->handle, size); - if (IS_ERR(gem_object)) - return PTR_ERR(gem_object); - - args->size = gem_object->size; + args->size = size; args->pitch = pitch; + args->handle = handle; At the end of the day, it makes no difference, Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create @ 2020-02-02 17:37 ` Chris Wilson 0 siblings, 0 replies; 15+ messages in thread From: Chris Wilson @ 2020-02-02 17:37 UTC (permalink / raw) To: DRI Development, Daniel Vetter Cc: Intel Graphics Development, Daniel Vetter, Dan Carpenter, Hillf Danton, stable, Emil Velikov, Sean Paul, Eric Anholt, Sam Ravnborg, Rob Clark, Daniel Vetter Quoting Daniel Vetter (2020-02-02 13:21:33) > There's two references floating around here (for the object reference, > not the handle_count reference, that's a different thing): > > - The temporary reference held by vgem_gem_create, acquired by > creating the object and released by calling > drm_gem_object_put_unlocked. > > - The reference held by the object handle, created by > drm_gem_handle_create. This one generally outlives the function, > except if a 2nd thread races with a GEM_CLOSE ioctl call. > > So usually everything is correct, except in that race case, where the > access to gem_object->size could be looking at freed data already. > Which again isn't a real problem (userspace shot its feet off already > with the race, we could return garbage), but maybe someone can exploit > this as an information leak. > > Cc: Dan Carpenter <dan.carpenter@oracle.com> > Cc: Hillf Danton <hdanton@sina.com> > Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com > Cc: stable@vger.kernel.org > Cc: Emil Velikov <emil.velikov@collabora.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Sean Paul <seanpaul@chromium.org> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Eric Anholt <eric@anholt.net> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Rob Clark <robdclark@chromium.org> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index 5bd60ded3d81..909eba43664a 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > return ERR_CAST(obj); > > ret = drm_gem_handle_create(file, &obj->base, handle); > - drm_gem_object_put_unlocked(&obj->base); > - if (ret) > + if (ret) { > + drm_gem_object_put_unlocked(&obj->base); > return ERR_PTR(ret); > + } > > return &obj->base; > } > @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > args->size = gem_object->size; > args->pitch = pitch; > > - DRM_DEBUG("Created object of size %lld\n", size); > + drm_gem_object_put_unlocked(gem_object); > + > + DRM_DEBUG("Created object of size %llu\n", args->size); I was thinking we either should return size from vgem_gem_create (the strategy we took in i915) or simply remove the vgem_gem_create() as that doesn't improve readability. -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, - struct drm_file *file, - unsigned int *handle, - unsigned long size) +static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, + struct drm_mode_create_dumb *args) { struct drm_vgem_gem_object *obj; - int ret; + u64 pitch, size; + u32 handle; + + pitch = args->width * DIV_ROUND_UP(args->bpp, 8); + size = mul_u32_u32(args->height, pitch); + if (size == 0 || pitch < args->width) + return -EINVAL; obj = __vgem_gem_create(dev, size); if (IS_ERR(obj)) - return ERR_CAST(obj); + return PTR_ERR(obj); + + size = obj->base.size; - ret = drm_gem_handle_create(file, &obj->base, handle); + ret = drm_gem_handle_create(file, &obj->base, &handle); drm_gem_object_put_unlocked(&obj->base); if (ret) return ERR_PTR(ret); - return &obj->base; -} - -static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, - struct drm_mode_create_dumb *args) -{ - struct drm_gem_object *gem_object; - u64 pitch, size; - - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); - size = args->height * pitch; - if (size == 0) - return -EINVAL; - - gem_object = vgem_gem_create(dev, file, &args->handle, size); - if (IS_ERR(gem_object)) - return PTR_ERR(gem_object); - - args->size = gem_object->size; + args->size = size; args->pitch = pitch; + args->handle = handle; At the end of the day, it makes no difference, Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create @ 2020-02-02 17:37 ` Chris Wilson 0 siblings, 0 replies; 15+ messages in thread From: Chris Wilson @ 2020-02-02 17:37 UTC (permalink / raw) To: DRI Development, Daniel Vetter Cc: Rob Clark, Hillf Danton, Daniel Vetter, Intel Graphics Development, stable, Eric Anholt, Sean Paul, Daniel Vetter, Sam Ravnborg, Dan Carpenter, Emil Velikov Quoting Daniel Vetter (2020-02-02 13:21:33) > There's two references floating around here (for the object reference, > not the handle_count reference, that's a different thing): > > - The temporary reference held by vgem_gem_create, acquired by > creating the object and released by calling > drm_gem_object_put_unlocked. > > - The reference held by the object handle, created by > drm_gem_handle_create. This one generally outlives the function, > except if a 2nd thread races with a GEM_CLOSE ioctl call. > > So usually everything is correct, except in that race case, where the > access to gem_object->size could be looking at freed data already. > Which again isn't a real problem (userspace shot its feet off already > with the race, we could return garbage), but maybe someone can exploit > this as an information leak. > > Cc: Dan Carpenter <dan.carpenter@oracle.com> > Cc: Hillf Danton <hdanton@sina.com> > Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com > Cc: stable@vger.kernel.org > Cc: Emil Velikov <emil.velikov@collabora.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Sean Paul <seanpaul@chromium.org> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Eric Anholt <eric@anholt.net> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Rob Clark <robdclark@chromium.org> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > --- > drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index 5bd60ded3d81..909eba43664a 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > return ERR_CAST(obj); > > ret = drm_gem_handle_create(file, &obj->base, handle); > - drm_gem_object_put_unlocked(&obj->base); > - if (ret) > + if (ret) { > + drm_gem_object_put_unlocked(&obj->base); > return ERR_PTR(ret); > + } > > return &obj->base; > } > @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > args->size = gem_object->size; > args->pitch = pitch; > > - DRM_DEBUG("Created object of size %lld\n", size); > + drm_gem_object_put_unlocked(gem_object); > + > + DRM_DEBUG("Created object of size %llu\n", args->size); I was thinking we either should return size from vgem_gem_create (the strategy we took in i915) or simply remove the vgem_gem_create() as that doesn't improve readability. -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, - struct drm_file *file, - unsigned int *handle, - unsigned long size) +static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, + struct drm_mode_create_dumb *args) { struct drm_vgem_gem_object *obj; - int ret; + u64 pitch, size; + u32 handle; + + pitch = args->width * DIV_ROUND_UP(args->bpp, 8); + size = mul_u32_u32(args->height, pitch); + if (size == 0 || pitch < args->width) + return -EINVAL; obj = __vgem_gem_create(dev, size); if (IS_ERR(obj)) - return ERR_CAST(obj); + return PTR_ERR(obj); + + size = obj->base.size; - ret = drm_gem_handle_create(file, &obj->base, handle); + ret = drm_gem_handle_create(file, &obj->base, &handle); drm_gem_object_put_unlocked(&obj->base); if (ret) return ERR_PTR(ret); - return &obj->base; -} - -static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, - struct drm_mode_create_dumb *args) -{ - struct drm_gem_object *gem_object; - u64 pitch, size; - - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); - size = args->height * pitch; - if (size == 0) - return -EINVAL; - - gem_object = vgem_gem_create(dev, file, &args->handle, size); - if (IS_ERR(gem_object)) - return PTR_ERR(gem_object); - - args->size = gem_object->size; + args->size = size; args->pitch = pitch; + args->handle = handle; At the end of the day, it makes no difference, Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create 2020-02-02 17:37 ` [Intel-gfx] " Chris Wilson (?) @ 2020-02-06 18:05 ` Daniel Vetter -1 siblings, 0 replies; 15+ messages in thread From: Daniel Vetter @ 2020-02-06 18:05 UTC (permalink / raw) To: Chris Wilson Cc: Rob Clark, Hillf Danton, Daniel Vetter, Intel Graphics Development, stable, Sean Paul, DRI Development, Daniel Vetter, Sam Ravnborg, Dan Carpenter, Emil Velikov On Sun, Feb 02, 2020 at 05:37:31PM +0000, Chris Wilson wrote: > Quoting Daniel Vetter (2020-02-02 13:21:33) > > There's two references floating around here (for the object reference, > > not the handle_count reference, that's a different thing): > > > > - The temporary reference held by vgem_gem_create, acquired by > > creating the object and released by calling > > drm_gem_object_put_unlocked. > > > > - The reference held by the object handle, created by > > drm_gem_handle_create. This one generally outlives the function, > > except if a 2nd thread races with a GEM_CLOSE ioctl call. > > > > So usually everything is correct, except in that race case, where the > > access to gem_object->size could be looking at freed data already. > > Which again isn't a real problem (userspace shot its feet off already > > with the race, we could return garbage), but maybe someone can exploit > > this as an information leak. > > > > Cc: Dan Carpenter <dan.carpenter@oracle.com> > > Cc: Hillf Danton <hdanton@sina.com> > > Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com > > Cc: stable@vger.kernel.org > > Cc: Emil Velikov <emil.velikov@collabora.com> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > > Cc: Sean Paul <seanpaul@chromium.org> > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Eric Anholt <eric@anholt.net> > > Cc: Sam Ravnborg <sam@ravnborg.org> > > Cc: Rob Clark <robdclark@chromium.org> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > > index 5bd60ded3d81..909eba43664a 100644 > > --- a/drivers/gpu/drm/vgem/vgem_drv.c > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > > @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > > return ERR_CAST(obj); > > > > ret = drm_gem_handle_create(file, &obj->base, handle); > > - drm_gem_object_put_unlocked(&obj->base); > > - if (ret) > > + if (ret) { > > + drm_gem_object_put_unlocked(&obj->base); > > return ERR_PTR(ret); > > + } > > > > return &obj->base; > > } > > @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > > args->size = gem_object->size; > > args->pitch = pitch; > > > > - DRM_DEBUG("Created object of size %lld\n", size); > > + drm_gem_object_put_unlocked(gem_object); > > + > > + DRM_DEBUG("Created object of size %llu\n", args->size); > > I was thinking we either should return size from vgem_gem_create (the > strategy we took in i915) or simply remove the vgem_gem_create() as that > doesn't improve readability. > > -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > - struct drm_file *file, > - unsigned int *handle, > - unsigned long size) > +static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > + struct drm_mode_create_dumb *args) > { > struct drm_vgem_gem_object *obj; > - int ret; > + u64 pitch, size; > + u32 handle; > + > + pitch = args->width * DIV_ROUND_UP(args->bpp, 8); > + size = mul_u32_u32(args->height, pitch); > + if (size == 0 || pitch < args->width) > + return -EINVAL; > > obj = __vgem_gem_create(dev, size); > if (IS_ERR(obj)) > - return ERR_CAST(obj); > + return PTR_ERR(obj); > + > + size = obj->base.size; > > - ret = drm_gem_handle_create(file, &obj->base, handle); > + ret = drm_gem_handle_create(file, &obj->base, &handle); > drm_gem_object_put_unlocked(&obj->base); > if (ret) > return ERR_PTR(ret); > > - return &obj->base; > -} > - > -static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > - struct drm_mode_create_dumb *args) > -{ > - struct drm_gem_object *gem_object; > - u64 pitch, size; > - > - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); > - size = args->height * pitch; > - if (size == 0) > - return -EINVAL; > - > - gem_object = vgem_gem_create(dev, file, &args->handle, size); > - if (IS_ERR(gem_object)) > - return PTR_ERR(gem_object); > - > - args->size = gem_object->size; > + args->size = size; > args->pitch = pitch; > + args->handle = handle; > > > At the end of the day, it makes no difference, Yeah there's room for more polish, but didn't want to do that in the cc: stable patch. > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Thanks for your review, finally applied to drm-misc-next-fixes now that CI has blessed me with its attention for a bit! -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create @ 2020-02-06 18:05 ` Daniel Vetter 0 siblings, 0 replies; 15+ messages in thread From: Daniel Vetter @ 2020-02-06 18:05 UTC (permalink / raw) To: Chris Wilson Cc: DRI Development, Daniel Vetter, Intel Graphics Development, Dan Carpenter, Hillf Danton, stable, Emil Velikov, Sean Paul, Eric Anholt, Sam Ravnborg, Rob Clark, Daniel Vetter On Sun, Feb 02, 2020 at 05:37:31PM +0000, Chris Wilson wrote: > Quoting Daniel Vetter (2020-02-02 13:21:33) > > There's two references floating around here (for the object reference, > > not the handle_count reference, that's a different thing): > > > > - The temporary reference held by vgem_gem_create, acquired by > > creating the object and released by calling > > drm_gem_object_put_unlocked. > > > > - The reference held by the object handle, created by > > drm_gem_handle_create. This one generally outlives the function, > > except if a 2nd thread races with a GEM_CLOSE ioctl call. > > > > So usually everything is correct, except in that race case, where the > > access to gem_object->size could be looking at freed data already. > > Which again isn't a real problem (userspace shot its feet off already > > with the race, we could return garbage), but maybe someone can exploit > > this as an information leak. > > > > Cc: Dan Carpenter <dan.carpenter@oracle.com> > > Cc: Hillf Danton <hdanton@sina.com> > > Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com > > Cc: stable@vger.kernel.org > > Cc: Emil Velikov <emil.velikov@collabora.com> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > > Cc: Sean Paul <seanpaul@chromium.org> > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Eric Anholt <eric@anholt.net> > > Cc: Sam Ravnborg <sam@ravnborg.org> > > Cc: Rob Clark <robdclark@chromium.org> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > > index 5bd60ded3d81..909eba43664a 100644 > > --- a/drivers/gpu/drm/vgem/vgem_drv.c > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > > @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > > return ERR_CAST(obj); > > > > ret = drm_gem_handle_create(file, &obj->base, handle); > > - drm_gem_object_put_unlocked(&obj->base); > > - if (ret) > > + if (ret) { > > + drm_gem_object_put_unlocked(&obj->base); > > return ERR_PTR(ret); > > + } > > > > return &obj->base; > > } > > @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > > args->size = gem_object->size; > > args->pitch = pitch; > > > > - DRM_DEBUG("Created object of size %lld\n", size); > > + drm_gem_object_put_unlocked(gem_object); > > + > > + DRM_DEBUG("Created object of size %llu\n", args->size); > > I was thinking we either should return size from vgem_gem_create (the > strategy we took in i915) or simply remove the vgem_gem_create() as that > doesn't improve readability. > > -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > - struct drm_file *file, > - unsigned int *handle, > - unsigned long size) > +static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > + struct drm_mode_create_dumb *args) > { > struct drm_vgem_gem_object *obj; > - int ret; > + u64 pitch, size; > + u32 handle; > + > + pitch = args->width * DIV_ROUND_UP(args->bpp, 8); > + size = mul_u32_u32(args->height, pitch); > + if (size == 0 || pitch < args->width) > + return -EINVAL; > > obj = __vgem_gem_create(dev, size); > if (IS_ERR(obj)) > - return ERR_CAST(obj); > + return PTR_ERR(obj); > + > + size = obj->base.size; > > - ret = drm_gem_handle_create(file, &obj->base, handle); > + ret = drm_gem_handle_create(file, &obj->base, &handle); > drm_gem_object_put_unlocked(&obj->base); > if (ret) > return ERR_PTR(ret); > > - return &obj->base; > -} > - > -static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > - struct drm_mode_create_dumb *args) > -{ > - struct drm_gem_object *gem_object; > - u64 pitch, size; > - > - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); > - size = args->height * pitch; > - if (size == 0) > - return -EINVAL; > - > - gem_object = vgem_gem_create(dev, file, &args->handle, size); > - if (IS_ERR(gem_object)) > - return PTR_ERR(gem_object); > - > - args->size = gem_object->size; > + args->size = size; > args->pitch = pitch; > + args->handle = handle; > > > At the end of the day, it makes no difference, Yeah there's room for more polish, but didn't want to do that in the cc: stable patch. > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Thanks for your review, finally applied to drm-misc-next-fixes now that CI has blessed me with its attention for a bit! -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create @ 2020-02-06 18:05 ` Daniel Vetter 0 siblings, 0 replies; 15+ messages in thread From: Daniel Vetter @ 2020-02-06 18:05 UTC (permalink / raw) To: Chris Wilson Cc: Rob Clark, Hillf Danton, Daniel Vetter, Intel Graphics Development, stable, Eric Anholt, Sean Paul, DRI Development, Daniel Vetter, Sam Ravnborg, Dan Carpenter, Emil Velikov On Sun, Feb 02, 2020 at 05:37:31PM +0000, Chris Wilson wrote: > Quoting Daniel Vetter (2020-02-02 13:21:33) > > There's two references floating around here (for the object reference, > > not the handle_count reference, that's a different thing): > > > > - The temporary reference held by vgem_gem_create, acquired by > > creating the object and released by calling > > drm_gem_object_put_unlocked. > > > > - The reference held by the object handle, created by > > drm_gem_handle_create. This one generally outlives the function, > > except if a 2nd thread races with a GEM_CLOSE ioctl call. > > > > So usually everything is correct, except in that race case, where the > > access to gem_object->size could be looking at freed data already. > > Which again isn't a real problem (userspace shot its feet off already > > with the race, we could return garbage), but maybe someone can exploit > > this as an information leak. > > > > Cc: Dan Carpenter <dan.carpenter@oracle.com> > > Cc: Hillf Danton <hdanton@sina.com> > > Cc: Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com > > Cc: stable@vger.kernel.org > > Cc: Emil Velikov <emil.velikov@collabora.com> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > > Cc: Sean Paul <seanpaul@chromium.org> > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Eric Anholt <eric@anholt.net> > > Cc: Sam Ravnborg <sam@ravnborg.org> > > Cc: Rob Clark <robdclark@chromium.org> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > --- > > drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > > index 5bd60ded3d81..909eba43664a 100644 > > --- a/drivers/gpu/drm/vgem/vgem_drv.c > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > > @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > > return ERR_CAST(obj); > > > > ret = drm_gem_handle_create(file, &obj->base, handle); > > - drm_gem_object_put_unlocked(&obj->base); > > - if (ret) > > + if (ret) { > > + drm_gem_object_put_unlocked(&obj->base); > > return ERR_PTR(ret); > > + } > > > > return &obj->base; > > } > > @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > > args->size = gem_object->size; > > args->pitch = pitch; > > > > - DRM_DEBUG("Created object of size %lld\n", size); > > + drm_gem_object_put_unlocked(gem_object); > > + > > + DRM_DEBUG("Created object of size %llu\n", args->size); > > I was thinking we either should return size from vgem_gem_create (the > strategy we took in i915) or simply remove the vgem_gem_create() as that > doesn't improve readability. > > -static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, > - struct drm_file *file, > - unsigned int *handle, > - unsigned long size) > +static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > + struct drm_mode_create_dumb *args) > { > struct drm_vgem_gem_object *obj; > - int ret; > + u64 pitch, size; > + u32 handle; > + > + pitch = args->width * DIV_ROUND_UP(args->bpp, 8); > + size = mul_u32_u32(args->height, pitch); > + if (size == 0 || pitch < args->width) > + return -EINVAL; > > obj = __vgem_gem_create(dev, size); > if (IS_ERR(obj)) > - return ERR_CAST(obj); > + return PTR_ERR(obj); > + > + size = obj->base.size; > > - ret = drm_gem_handle_create(file, &obj->base, handle); > + ret = drm_gem_handle_create(file, &obj->base, &handle); > drm_gem_object_put_unlocked(&obj->base); > if (ret) > return ERR_PTR(ret); > > - return &obj->base; > -} > - > -static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, > - struct drm_mode_create_dumb *args) > -{ > - struct drm_gem_object *gem_object; > - u64 pitch, size; > - > - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); > - size = args->height * pitch; > - if (size == 0) > - return -EINVAL; > - > - gem_object = vgem_gem_create(dev, file, &args->handle, size); > - if (IS_ERR(gem_object)) > - return PTR_ERR(gem_object); > - > - args->size = gem_object->size; > + args->size = size; > args->pitch = pitch; > + args->handle = handle; > > > At the end of the day, it makes no difference, Yeah there's room for more polish, but didn't want to do that in the cc: stable patch. > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Thanks for your review, finally applied to drm-misc-next-fixes now that CI has blessed me with its attention for a bit! -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/vgem: Close use-after-free race in vgem_gem_create 2020-02-02 13:21 ` [Intel-gfx] " Daniel Vetter ` (5 preceding siblings ...) (?) @ 2020-02-05 8:15 ` Patchwork -1 siblings, 0 replies; 15+ messages in thread From: Patchwork @ 2020-02-05 8:15 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx == Series Details == Series: drm/vgem: Close use-after-free race in vgem_gem_create URL : https://patchwork.freedesktop.org/series/72873/ State : success == Summary == CI Bug Log - changes from CI_DRM_7856_full -> Patchwork_16379_full ==================================================== Summary ------- **SUCCESS** No regressions found. Known issues ------------ Here are the changes found in Patchwork_16379_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@drm_import_export@import-close-race-prime: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([i915#472]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-tglb1/igt@drm_import_export@import-close-race-prime.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-tglb6/igt@drm_import_export@import-close-race-prime.html * igt@gem_busy@extended-parallel-vcs1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb2/igt@gem_busy@extended-parallel-vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb8/igt@gem_busy@extended-parallel-vcs1.html * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +6 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-kbl2/igt@gem_ctx_isolation@rcs0-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-kbl7/igt@gem_ctx_isolation@rcs0-s3.html * igt@gem_exec_schedule@pi-userfault-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb6/igt@gem_exec_schedule@pi-userfault-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb1/igt@gem_exec_schedule@pi-userfault-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb7/igt@gem_exec_schedule@preempt-other-chain-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb2/igt@gem_exec_schedule@preempt-other-chain-bsd.html * igt@gem_partial_pwrite_pread@write-snoop: - shard-hsw: [PASS][11] -> [FAIL][12] ([i915#694]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-hsw8/igt@gem_partial_pwrite_pread@write-snoop.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-hsw1/igt@gem_partial_pwrite_pread@write-snoop.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][13] -> [TIMEOUT][14] ([i915#716]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-skl7/igt@gen9_exec_parse@allowed-single.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-skl5/igt@gen9_exec_parse@allowed-single.html * igt@i915_pm_rpm@gem-mmap-cpu: - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#189]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb7/igt@i915_pm_rpm@gem-mmap-cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb2/igt@i915_pm_rpm@gem-mmap-cpu.html * igt@i915_selftest@live_blt: - shard-hsw: [PASS][17] -> [DMESG-FAIL][18] ([i915#725]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-hsw1/igt@i915_selftest@live_blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-hsw6/igt@i915_selftest@live_blt.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-apl2/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb6/igt@kms_psr@psr2_cursor_plane_move.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][27] -> [SKIP][28] ([fdo#109276]) +17 similar issues [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb2/igt@prime_busy@hang-bsd2.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb7/igt@prime_busy@hang-bsd2.html #### Possible fixes #### * igt@gem_busy@busy-vcs1: - shard-iclb: [SKIP][29] ([fdo#112080]) -> [PASS][30] +15 similar issues [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb6/igt@gem_busy@busy-vcs1.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb1/igt@gem_busy@busy-vcs1.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [SKIP][31] ([fdo#110841]) -> [PASS][32] [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb2/igt@gem_ctx_shared@exec-single-timeline-bsd.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb8/igt@gem_ctx_shared@exec-single-timeline-bsd.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [SKIP][33] ([fdo#112146]) -> [PASS][34] +1 similar issue [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb1/igt@gem_exec_schedule@in-order-bsd.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb6/igt@gem_exec_schedule@in-order-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [SKIP][35] ([fdo#109276]) -> [PASS][36] +19 similar issues [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb8/igt@gem_exec_schedule@preempt-queue-bsd1.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb4/igt@gem_exec_schedule@preempt-queue-bsd1.html * igt@gem_tiled_blits@normal: - shard-hsw: [FAIL][37] ([i915#818]) -> [PASS][38] [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-hsw5/igt@gem_tiled_blits@normal.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-hsw6/igt@gem_tiled_blits@normal.html * igt@kms_color@pipe-b-ctm-negative: - shard-skl: [DMESG-WARN][39] ([i915#109]) -> [PASS][40] +1 similar issue [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-skl4/igt@kms_color@pipe-b-ctm-negative.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-skl3/igt@kms_color@pipe-b-ctm-negative.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [FAIL][41] ([i915#72]) -> [PASS][42] [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-glk2/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-glk2/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [DMESG-WARN][43] ([i915#180]) -> [PASS][44] [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-apl8/igt@kms_flip@flip-vs-suspend-interruptible.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible.html * igt@kms_flip@plain-flip-ts-check-interruptible: - shard-skl: [FAIL][45] ([i915#34]) -> [PASS][46] [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-skl4/igt@kms_flip@plain-flip-ts-check-interruptible.html [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-skl8/igt@kms_flip@plain-flip-ts-check-interruptible.html * igt@kms_flip_tiling@flip-x-tiled: - shard-glk: [FAIL][47] ([fdo#108145] / [i915#699]) -> [PASS][48] [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-glk5/igt@kms_flip_tiling@flip-x-tiled.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-glk8/igt@kms_flip_tiling@flip-x-tiled.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-skl: [INCOMPLETE][49] ([i915#69]) -> [PASS][50] [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-skl8/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-skl10/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [SKIP][51] ([fdo#109441]) -> [PASS][52] +3 similar issues [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb7/igt@kms_psr@psr2_sprite_mmap_gtt.html [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [DMESG-WARN][53] ([i915#180]) -> [PASS][54] +5 similar issues [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-kbl2/igt@kms_vblank@pipe-a-ts-continuation-suspend.html [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-kbl7/igt@kms_vblank@pipe-a-ts-continuation-suspend.html #### Warnings #### * igt@gem_ctx_isolation@vcs1-nonpriv-switch: - shard-iclb: [SKIP][55] ([fdo#112080]) -> [FAIL][56] ([IGT#28]) [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-iclb7/igt@gem_ctx_isolation@vcs1-nonpriv-switch.html [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv-switch.html * igt@gem_tiled_blits@interruptible: - shard-hsw: [FAIL][57] ([i915#694]) -> [FAIL][58] ([i915#818]) [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7856/shard-hsw6/igt@gem_tiled_blits@interruptible.html [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/shard-hsw5/igt@gem_tiled_blits@interruptible.html [IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28 [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441 [fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841 [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080 [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146 [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109 [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180 [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265 [i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34 [i915#472]: https://gitlab.freedesktop.org/drm/intel/issues/472 [i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677 [i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69 [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694 [i915#699]: https://gitlab.freedesktop.org/drm/intel/issues/699 [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716 [i915#72]: https://gitlab.freedesktop.org/drm/intel/issues/72 [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725 [i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818 Participating hosts (10 -> 10) ------------------------------ No changes in participating hosts Build changes ------------- * CI: CI-20190529 -> None * Linux: CI_DRM_7856 -> Patchwork_16379 CI-20190529: 20190529 CI_DRM_7856: a113999b001035a5b6474407b228363c163574a3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5411: 86c6ab8a0b6696bdb2153febd350af7fa02fbb00 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16379: d0b2cbabe0deb86f971d677bf112493016c4ad54 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16379/index.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-02-06 18:06 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-02-02 13:21 [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create Daniel Vetter 2020-02-02 13:21 ` Daniel Vetter 2020-02-02 13:21 ` [Intel-gfx] " Daniel Vetter 2020-02-02 13:38 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork 2020-02-02 14:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2020-02-02 15:39 ` [PATCH] " Sam Ravnborg 2020-02-02 15:39 ` Sam Ravnborg 2020-02-02 15:39 ` [Intel-gfx] " Sam Ravnborg 2020-02-02 17:37 ` Chris Wilson 2020-02-02 17:37 ` Chris Wilson 2020-02-02 17:37 ` [Intel-gfx] " Chris Wilson 2020-02-06 18:05 ` Daniel Vetter 2020-02-06 18:05 ` Daniel Vetter 2020-02-06 18:05 ` [Intel-gfx] " Daniel Vetter 2020-02-05 8:15 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.