This is a result from a private communication and review request from the
replay-sorcery author Joshua 'Pip' Minter. In upstream version 0.6.0 that is
already released the former setuid-root binary approach has been replaced (or
enriched) by a systemd service replay-sorcery-kms that runs as root and
operates a UNIX domain socket.

The idea is that the kms system service opens any DRI devices via the ffmpeg
library and passes back the open file descriptors to clients of the UNIX
domain socket.

The 0.6.0 upstream code has the following issues:

a) The socket is placed into /tmp/replace-sorcery/device.sock. The socket,
  however, belongs in /run, ideally setup via systemd service directives, so
  that systemd already passes in the ready socket file descriptor.
b) /tmp/replay-sorcery is a predictable path in a world writable
  directory, i.e. any other user in the system can precreate it
  and thus take control of the directory and its contents. For example by
  removing the intended device.sock and creating a different socket
  there, clients in the system will then communicate with other
  parties than intended.
c) The service calls the `kmsChmod()` function for both /tmp/replay-sorcery
  and /tmp/replay-sorcery/device.sock. This function performs a `chmod(path,
  0777)`. Thus a local attacker can stage symlink attacks in both
  locations. The attack via /tmp/replay-sorcery is thwarted by the Linux
  kernel's symlink protection. The attack via the socket filename is
  not, because /tmp/replay-sorcery will not have a sticky bit set. So
  the attacker only has to win a race condition between the kms service
  binding the socket and performing the chown(). This allows for a
  pretty easy full local root exploit achievable every time when the kms
  service is starting up.
d) During receiption of the RSServiceDeviceInfo data from the client, the
  (size_t => 64-bit on x86_64) deviceLength parameter has no upper limit i.e.
  clients can cause DoS by causing large memory allocations, both in terms of
  memory and CPU time.
e) Before accepting arbitrary client connections the service should make sure
  that the client is somehow authorized to access the local display. E.g. by
  it being a member of a special "replay-sorcery" group, or by it owning a
  local active graphical session (systemd helpers exist to check for this I
  guess, or using polkit for authentication right away).

The combined issues a), b) and c) are serious enough for a CVE assignment, and
Mitre assigned the CVE present in the bug summary for it.