Currently, when the session creation fails, the event queue is leaked.
To fix this issue, add an API to flush the queue, when the session is
stopped and free the event queue in dispose().

Currently, the monitor layout update source is leaked, when the session
creation fails.
This GSource, however, must be destroyed, when the session is stopped
and not later.

To handle both the success and fail case, add a helper method, where
the existing session sources are cleared, when the session stops or
when it is disposed.

Malicious remote desktop clients can send invalid file lists containing
illegal filenames, such as filenames containing the '/' character.
In such case, gnome-remote-desktop currently dereferences a NULL
pointer, which would lead to a crash.

While such malicious remote desktop clients are not known, still add
handling for such situation by discarding the file list, when such
situation is detected.

When clearing a GFX surface, the graphics pipeline currently first
clears its members, which are, if they exist, the render surface and
the frame controller, and then deletes the GFX surface itself.
This has currently the effect, that when the client sends a frame
acknowledgement for a frame, that was rendered on a GFX surface, that
is about to be cleared, that the respective frame controller is used,
while it is in the process of being deleted leading to a crash, where a
NULL pointer is dereferenced.
The reason for this situation is that for each surface, a surface
context is created, which also contains a pointer to the GFX surface.
This is necessary to be able to map frame ids to surfaces at any time,
even when the respective surface is already deleted.
When clearing a surface, it is first removed from the surface table,
while the GFX mutex is locked, and then actually deleted, where the GFX
mutex has to be unlocked first, to not lock it again.
In this process of unlocking the GFX mutex and locking it again a frame
acknowledgement can happen, and in this situation, the frame controller
might be in the process of deletion, leading to a NULL pointer
dereference, where the frame controller or one of its members is being
looked up.

To fix this issue, simply delete the GFX surface first. This also
clears the pointer to the GFX surface in the surface context.
The other members of the GFX surface can afterwards be cleared without
any problems.

https://errors.ubuntu.com/problem/ecf34bd0b58c72cf2d1f03ba4222b71cc62e0d83

Recently, it was discovered, that WinPR events are handled in
unexpected manners on a few systems.
In this case here, a Bandwidth Measure Stop PDU can be sent before it
is meant to be sent.
This results into an unexpected state of the bandwidth measurement
state machine, as the bandwidth measure stop was meant to be queued
before it is actually stopped.
Since there are currently no places, where a Bandwidth Measure Stop PDU
is sent directly, disallow unqueued bandwidth measure stops.

Fixes: https://errors.ubuntu.com/problem/98a015184483b3876c1a63cfb0191c51ab2df6e5

libsecret apparently does not set an error, if the credentials to
delete were not found.
So, also check whether an error was set before assuming that the
failure of the operation.

Fixes: https://errors.ubuntu.com/problem/5fb98359975eaf2962d46e9073776e3807a9d63c

The DRM format modifier should only be used, when it is not invalid.
The current checks currently do not correctly check for this.
Instead, the existence of the modifiers array in the DmaBuf struct is
always checked, which is always true.

So, fix this by replacing this tautology with an actual modifier check.

In case someone reads the documentation, the connection between the
documentation and the implementation would be clearer.

When a client suspends the frame acknowledgement, the Unacknowledged
Frames ADM element MUST be cleared ([MS-RDPEGFX] 3.2.5.13).
In gnome-remote-desktop, this also involves iterating through all GFX
surfaces, getting their frame controller, and clear their frame logs.
In some circumstances however, a GFX surface might have a different
render surface due to encoder constraints.
These render surfaces don't have their own frame controller.
If a client suspends the frame acknowledgement and a separate render
surface is present, gnome-remote-desktop crashes, as the suspend
handling currently assumes, that all GFX surfaces have a frame
controller, but this is not the case.

Fix this situation by checking for the existence of the frame
controller first, before trying to clear its frame log.

Fixes: cc790574
Fixes: https://errors.ubuntu.com/problem/ecf34bd0b58c72cf2d1f03ba4222b71cc62e0d83

A couple were missing newlines, and one said RDP but was about VNC.


(cherry picked from commit 4192a2fd)

Upstream version 42.4