RingCentral Linux client freezes entire Qubes desktop

[Elijah-C-G]

Qubes OS version
Qubes 4.0

Affected component(s) or functionality
Dom0 display - the entire desktop

Brief summary
When attempting to share my screen via RingCentral, the desktop locks in to an unresponsive RingCentral window and there is no clear way to regain control.

To Reproduce
Steps to reproduce the behavior:

1. Install the RingCentral Linux client on to an AppVM, and make sure it is running.
2. Have another program running in a window on that same AppVM. (The bug doesn't happen if RingCentral is the only running window on that AppVM.)
3. Start a RingCentral meeting using your account.
4. Attempt to share your screen.

Expected behavior
RingCentral does not render the entire Qubes desktop inoperable (and ideally also shares its screen for the AppVM)

Actual behavior
The Qubes desktop becomes inoperable, and a reboot is required to regain control of the system

Screenshots
If necessary, I can upload a video showing what happens.

[DemiMarie]

Zoom screensharing has similar problems.

One of the problems is that override redirect windows are not handled correctly by QubesOS’s GUI services.

[mfc]

Zoom screensharing has similar problems.

One of the problems is that override redirect windows are not handled correctly by QubesOS’s GUI services.

you can try what is suggested in this qubes-users thread:

The problem with Zoom is probably that it opens a transparent overlay, likely because of annotations. However, Qubes OS does not support transparency. There is a workaround that hides the overlay:

xdotool selectwindow windowunmap

[strugee]

Shouldn't this be a security bug? I thought an untrusted qube wasn't supposed to be able to DoS the dom0 desktop. I somehow managed to trigger this in Zoom this morning by having a Zoom call open and making a Firefox window in the same qube fullscreen. It broke my entire desktop, even after I quit Zoom, and typing anywhere (like in a terminal to kill the VM) did not work, including trusted shortcuts like Alt-Tab. Clicking buttons in the panel didn't work either.

[andrewdavidwong]

Shouldn't this be a security bug? I thought an untrusted qube wasn't supposed to be able to DoS the dom0 desktop. I somehow managed to trigger this in Zoom this morning by having a Zoom call open and making a Firefox window in the same qube fullscreen. It broke my entire desktop, even after I quit Zoom, and typing anywhere (like in a terminal to kill the VM) did not work, including trusted shortcuts like Alt-Tab. Clicking buttons in the panel didn't work either.

That's a tough call. For example, XSAs that are DoS-only aren't considered to affect the security of Qubes OS, and we report them as such in the XSA Tracker. So, I'd defer to @marmarek to say whether this qualifies as a security bug.

[github-actions]

This issue is being closed because:

• This issue is on the "Release 4.0 updates" milestone.
• Qubes OS 4.0 reached EOL (end-of-life) over one year ago.
• There has not been any activity on this issue in over one year.

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment.
(For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)