fbCloseScreen assumes that it overrides miCloseScreen (which just calls FreePixmap(screen->devPrivates)) and emulates that instead of wrapping it.
This is a wrong assumption, we may have ShmCloseScreen in the mix too, resulting in leaks (see below). Fix this by properly setting up the CloseScreen wrapper.
This means we no longer need the manual DestroyPixmap call in vfbCloseScreen, reverting d348ab06
This vulnerability was discovered by: Sri working with Trend Micro Zero Day Initiative
This has a few knock-on side-effects, in particular: much of the
CloseScreen and even
DestroyPixmap code never used to be called because of the shortcut taken by fb. So there's some untested code in there, e.g. xorg/driver/xf86-video-qxl#17.
dix: always initialize pScreen->CloseScreen is necessary for Xwayland because that one initialized RandR first and that code is not designed to be the last one in the chain during unwrapping (it does not check for NULL).
Since the CVE-2023-5574 can only be triggered on Xvfb but those side-effects apply to all DDXs it may be safer for some users to live with the Xvfb issue until these patches have seen widespread testing.