A way to demonstrate this is with the following situation. This assumes that one has opened DRM and EGL devices.

- create a gbm surface with gbm_surface_create and usage GBM_BO_USE_LINEAR
- create an EGLSurface from the gbm surface with eglCreatePlatformWindowSurfaceEXT
- render something to it using GLES
- get the resulting buffer using gbm_bo_lock_front_buffer
- attach it to the hardware cursor using drmModeSetCursor
- the cursor is not displayed

During these steps the following things happen in the DRM driver:
- when the surface is made current using eglMakeCurrent a new bo is created in NOUVEAU_GBM_DOMAIN_GART (due to GBM_BO_USE_LINEAR)
- the rendering operations get queued (and may be flushed with glFlush(), in my specific case this didn't matter)
- when the bo is attached to the cursor plane, it is moved to NOUVEAU_GBM_DOMAIN_VRAM. If the rendering operations haven't finished at this point, the copied buffer is empty.

Note that since this is a timing issue it might not be reproducible in all situations. 
This was tested on different GPUs (GTX 1080 and GT 445M) with rootston (wlroots example wayland compositor: https://github.com/swaywm/wlroots , git commit b2f56ad4) running weston-terminal (this makes the issue appear more frequently)

Probably the driver should wait for pending rendering operations on the surface before moving it around. Another possibility for the scenario listed above is to let the bo start in VRAM, so no moves are necessary. In order to prevent other setups from breaking this would then only be done if GBM_BO_USE_SCANOUT was set on creation. A workaround is to add glFinish() in the application before calling drmModeSetCursor.

Kernel version: 4.20.6
Mesa version: 18.3.3