Skip to content

fb: properly wrap/unwrap CloseScreen

Peter Hutterer requested to merge whot/xserver:wip/cve-2023-5574 into master

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

CVE-2023-5574, ZDI-CAN-21213

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.

Likewise, 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.

Merge request reports