Invalid root-pixmap properties are not handled safely by the compositor

Summary

root_tile() reads _XROOTPMAP_ID and ESETROOT_PMAP_ID to create a repeating X Render Picture for the desktop background. Several failure cases are not handled safely:

  • Xlib returns format-32 property data as an array of longs, including on LP64, but the current code copies only four bytes into an otherwise uninitialized Pixmap;
  • a property value of Pixmap None is accepted;
  • a nonzero advertised pixmap can disappear before XRenderCreatePicture() processes it, producing BadDrawable;
  • the cached rootTile Picture is not released when the compositor is unmanaged.

The first three cases should select the existing solid-black fallback rather than attempting to use an invalid XID. The cached Picture should follow the same compositor lifecycle as the other root and buffer Pictures.

Reproduction and evidence

A small isolated Xlib/XRender probe on LP64 and a private Xvfb display exercised the same property and Picture-creation contract:

  1. A valid format-32 PIXMAP value round-tripped through the Xlib long-sized representation and created a repeating Picture.
  2. Pixmap None required the black fallback.
  3. A destroyed nonzero Pixmap produced trapped BadDrawable and required the fallback.
  4. Malformed and absent properties selected the fallback.
  5. A destroyed Window produced trapped BadWindow and selected the fallback.

A standalone probe mirroring the proposed selection logic passed all six cases. A live diagnostic capture also observed _XROOTPMAP_ID advertised with XID 0, so the None path is not merely theoretical.

Expected result

Xfwm should read the complete Xlib format-32 item, validate the property and Pixmap value, synchronously trap errors from the property and Picture requests, and use the black fallback whenever no valid Picture can be created. It should free and reset rootTile when compositing is disabled.

Related history

Those reports are useful background, but the available evidence does not prove that root_tile() caused either one, so this issue does not claim to close them.