seatd-launch could use a user-specified socket path instead of the
internally generated socket path, and would unlink the socket path
before use to guard against collision with leftover sockets. This
meant that a caller could freely control what file path would be
unlinked and replaced with a user-owned seatd socket for the duration
of the session.
If seatd-launch had the SUID bit set, this could be used by a
malicious user to remove files with the privileges of the owner of
seatd-launch, which is likely root, and replace it with a user-owned
domain socket.
This does not directly allow retrieving the contents of existing
files, and the user-owned socket file is at the current time not
believed to be directly useful for further exploitation.