Description of problem: When trying to connect to a vncserver, remote or local, vncviewer throws a popup with "Invalid display size". However ssh-ing into localhost, then running vncviewer succeeds. Version-Release number of selected component (if applicable): tigervnc-1.10.1-1.mga7.src.rpm How reproducible: Always, tigervnc-1.9.0-3 did not have this problem. Steps to Reproduce: 1. sudo urpmi tigervnc tigervnc-server 2. vncserver :6 (and enter a nice password) 3. vncviewer :6 -passwd ~/.vnc/passwd 4. experience deep disappointment. As stated above, ssh-ing to localhost or ssh-ing into a remote host and starting vncviewer succeeds presuming X forwarding is enabled. Furthermore, ssh-ing into a remote host and tunneling the vnc port back also fails if initiating a vncviewer to the tunneled port also fails (which is what most folks do with VNC). If possible, I would like to be added to vnc testing since I live my life though vncviewers.
tigervnc has no registered or consistent maintainer, so assigning this globally. ========================================== (In reply to Alan Richter from comment #0) > If possible, I would like to be added to vnc testing since I live my life > though vncviewers. This would be invaluable, since this product is difficult to test. It is not possible to be a 'registered tester' for a particular package (registered maintainer, yes); but if you join Mageia QA: https://wiki.mageia.org/en/QA_Team https://wiki.mageia.org/en/QA_Team_portal https://wiki.mageia.org/en/QA_process_for_validating_updates Their 'in-tray' is: http://mageia.madb.org/tools/updates You could keep an eye on that, and jump on any tigervnc update to test. But of course they are very rare. Hopefully, you would be tempted to test other things... the team is hard pressed. The main procedure for update testing is well defined. The QA mailList is good for asking questions. You could try the weekly IRC meetings too. -------------------- Alternatively, log into Bugzilla https://bugs.mageia.org/ periodically, and use the quick search box at the top "tigervnc" which will show any bugs open for it. Go to it/them. Then (after logging in) add yourself to the CC List [edit], and you will see all posts, and when the update gets pushed to QA for testing.
CC: (none) => lewyssmithAssignee: bugsquad => pkg-bugs
Thanks Lewis, I don't think I've got enough time to become a maintainer but I do like keeping an eye on updates_testing and will be more active in testing packages while they're there, presuming I have something to offer. I'll see what I can come up with in tigervnc viewer to help resolve this issue.
I think I've found the problem, it's a patch for CVE-2014-8240 which was causing the "Invalid display size". I respectfully submit my diff file for tigervnc.spec and can vouch that this has resolved this problem. --- tigervnc.spec 2019-12-22 00:50:41.000000000 -0700 +++ tigervnc.spec.fixed 2020-01-22 20:01:15.443838295 -0700 @@ -1,6 +1,6 @@ Name: tigervnc Version: 1.10.1 -Release: %mkrel 1 +Release: %mkrel 2 Summary: Viewer for the VNC remote display system Group: Networking/Remote access License: GPLv2+ @@ -17,7 +17,7 @@ # copied from debian Patch29: tigervnc-1.7.0-CVE-2014-8241.patch -Patch30: tigervnc-1.8.0-CVE-2014-8240.patch +# Patch30: tigervnc-1.8.0-CVE-2014-8240.patch # This is tigervnc-%%{version}/unix/xserver120.patch rebased on the latest xorg Patch100: tigervnc-xserver120.patch @@ -165,7 +165,7 @@ %patch14 -p1 -b .xstartup %patch29 -p1 -b .CVE-2014-8241 -%patch30 -p1 -b .CVE-2014-8240 +#%patch30 -p1 -b .CVE-2014-8240 %build
(In reply to Alan Richter from comment #3) > I think I've found the problem, it's a patch for CVE-2014-8240 which was > causing the "Invalid display size". This goes right back to bug 17190 (2015-11). How can it be that the problem has survived all that time? > I respectfully submit my diff file for tigervnc.spec and can vouch that this > has resolved this problem. Thank you for your research & this learned contribution. Re-assigning to Stig who did the Update to version 1.10.1.
Assignee: pkg-bugs => smelrorCC: lewyssmith => (none)
The security patch isn't the actual cause of the issue. For some reason, the height and width parameters for the PlatformPixelBuffer base class constructor have both been changed to 0. These values are retrieved by the PlatformPixelBuffer::setupShm method and cause the display size check from the patch to fail. Without the patch, setupShm will try to create a shared memory segment of size zero. Assuming that this will be rejected (haven't tested), the PlatformPixelBuffer constructor will fall back to using standard XImage. This would work, but without the benefit of using shared memory. If the zeroing of the height and width parameters for the PlatformPixelBuffer constructor is necessary, the Surface object is still constructed with the correct values and the Surface class has (identically named) methods for retrieving these. Retrieving height and width from Surface instead of from PlatformPixelBuffer should allow the use of shared memory pixel buffer without removing the security patch.
CC: (none) => gm2.asp
Not sure what is wrong, but I've confirmed that replacing /usb/bin/vncviewer with the version downloaded from https://bintray.com/tigervnc/stable/download_file?file_path=tigervnc-1.10.1.x86_64.tar.gz fixes the problem. While the existing mageia verison works ok for connecting to an existing X display, it cannot create a new one as is needed for xen.
CC: (none) => davidwhodgins
(In reply to Dave Hodgins from comment #6) > Not sure what is wrong, but I've confirmed that replacing > /usb/bin/vncviewer with the version downloaded from > https://bintray.com/tigervnc/stable/download_file?file_path=tigervnc-1.10.1. > x86_64.tar.gz > fixes the problem. > > While the existing mageia verison works ok for connecting to an existing > X display, it cannot create a new one as is needed for xen. The one in the tarball doesn't have patch tigervnc-1.8.0-CVE-2014-8240.patch applied and thus it works fine. I patch 2014-8240 even still necessary? I patched a vulnerability in version 1.8 but seems to break 1.10. Wouldn't the boffins who maintain tigervnc have patched that issue between V1.8 and V1.10? The fact remains that tigervnc-viewer is broken at its current level for Mageia 7.1.
As I tried to explain above, the security patch is only a problem because of a bug affecting the values used for width and height in the PlatformPixelBuffer::setupShm method. This bug also prevents use of a shared memory XImage. The following changes on the github Master branch should fix this bug: https://github.com/TigerVNC/tigervnc/commit/0f1ded057dbf875e69a0d72418d95610db8fa6a3 With this fix, the security patch won't do any harm. Whether it is still needed is another matter.
I started looking into the problems with tigervnc-1.10.1-1.mga7.src.rpm then discovered that it won't even build any more: make[2]: Entering directory '/tmp/rpmbuild/BUILD/tigervnc-1.10.1/unix/xserver/hw/vnc' CXXLD Xvnc /usr/bin/ld: ../../os/.libs/libos.a(inputthread.o): in function `InputThreadDoWork': /home/arichter/rpmbuild/BUILD/tigervnc-1.10.1/unix/xserver/os/inputthread.c:321: undefined reference to `ddxInputThreadInit' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:849: Xvnc] Error 1 make[2]: Leaving directory '/tmp/rpmbuild/BUILD/tigervnc-1.10.1/unix/xserver/hw/vnc' make[1]: *** [Makefile:627: all-recursive] Error 1 make: *** [Makefile:972: all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.RybP5j (%build) So I started looking for a way to patch this issue and discovered that tigervnc-1.10.1/unix/xserver/hw/vnc and tigervnc-1.10.1/unix/xserver/os are empty so there wasn't anything to patch. The appearance of formerly non-existent is somewhat new to me so if someone could refer me to the correct man page that explains this phenomenon I'd be most appreciative. In the meantime the latest tigervnc in git does build but patch 14 and patch 30 need to be removed.
Looks like the %prep stage was not successfully executed. This stage includes a recursive copy of /usr/share/x11-server-source/* to unix/xserver
And in case you have not already found it yourself, this looks like a resolved debian bug-report for the same linking failure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951938
From what I can see, nor Fedora, nor Opensuse, nor Gentoo, nor ArchLinux, nor Openmandriva uses these two patches (CVE-2014-8240 and CVE-2014-8241)
CC: (none) => geiger.david68210
Seems these two patches was for release less than 1.4.2
So two minor/cosmetic issues combine to a major issue. 1- Superfluous code added by tigervnc-1.8.0-CVE-2014-8240.patch (less than 10 lines) gets executed on establishment of a VNC session. 2- Bug in transfer of height and width parameters leads to not using a (performance improving) shared memory pixel buffer when possible.
*** Bug 26419 has been marked as a duplicate of this bug. ***
CC: (none) => mrambo
Debian still does have these CVE patches with 1.10.1.
Can someone file a new bug upstream at https://github.com/TigerVNC/tigervnc/issues, please? to see what is going wrong tigervnc or libvncserver or tigervnc security patches.
(In reply to Alan Richter from comment #9) > I started looking into the problems with tigervnc-1.10.1-1.mga7.src.rpm then > discovered that it won't even build any more: > > make[2]: Entering directory > '/tmp/rpmbuild/BUILD/tigervnc-1.10.1/unix/xserver/hw/vnc' > CXXLD Xvnc > /usr/bin/ld: ../../os/.libs/libos.a(inputthread.o): in function > `InputThreadDoWork': > /home/arichter/rpmbuild/BUILD/tigervnc-1.10.1/unix/xserver/os/inputthread.c: > 321: undefined reference to `ddxInputThreadInit' > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile:849: Xvnc] Error 1 > make[2]: Leaving directory > '/tmp/rpmbuild/BUILD/tigervnc-1.10.1/unix/xserver/hw/vnc' > make[1]: *** [Makefile:627: all-recursive] Error 1 > make: *** [Makefile:972: all-recursive] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.RybP5j (%build) > To get 1.10.1 to build on my Mageia 7 I had to add the following patch which fixed the ddxInputThreadInit problem for me. https://github.com/NixOS/nixpkgs/issues/78627 I was curious whether it would exhibit the problem without those old patches. After getting it to build without them I found that it no longer exhibits the problem described in this bug and #26419. Don't know whether I asked well, but I have tried asking upstream as requested. https://github.com/TigerVNC/tigervnc/issues/993
If there is any doubt whether the security patch is still needed, why not fix the release 1.10.1 code bug that makes the patch code fail (Comment 8) and leave the patch in for now?
(In reply to Arne Spiegelhauer from comment #19) > If there is any doubt whether the security patch is still needed, why not > fix the release 1.10.1 code bug that makes the patch code fail (Comment 8) > and leave the patch in for now? I agree with Arne. Tested again with the patch referenced in comment #8 added and the security patches left as they are and found that this also fixes the problem that I experienced here and in bug #26419. The security patches can be removed later if upstream says they are no longer needed. Patched package uploaded for Mageia 7. Advisory: ======================== Updated tigervnc package fixes bugs: * added a patch to fix a bug where the tigervnc client crashes with "Invalid display size" under certain circumstances (mga #26118). * added a patch to fix building on Mageia 7 with xorg-server 1.20.7. References: https://bugs.mageia.org/show_bug.cgi?id=26118 ======================== Updated packages in core/updates_testing: ======================== tigervnc-1.10.1-1.1.mga7 tigervnc-java-1.10.1-1.1.mga7 tigervnc-server-1.10.1-1.1.mga7 tigervnc-server-module-1.10.1-1.1.mga7 from tigervnc-1.10.1-1.1.mga7.src.rpm I tested these changes locally before submitting to the build system. Both of my machines were upgraded with packages containing these fixes. I found that the changes fixed the problem described in this bug and the duplicate 26419.
Assignee: smelror => qa-bugs
Installed and tested without issues. Tested local server to local client and remove server to local client connections. No "Invalid display size", no other issues and no "deep disappointment". ;-) System: Mageia 7, x86_64, Plasma DE, LXQt DE, Intel CPU, nVidia GPU using nvidia340 proprietary driver. $ uname -a Linux marte 5.5.15-desktop-3.mga7 #1 SMP Sat Apr 4 19:06:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep tigervnc | sort tigervnc-1.10.1-1.1.mga7 tigervnc-server-1.10.1-1.1.mga7 tigervnc-server-module-1.10.1-1.1.mga7 ############################ $ vncserver -fg New 'localhost:1 (pclx)' desktop is localhost:1 Starting applications specified in /home/pclx/.vnc/xstartup Log file is /home/pclx/.vnc/localhost:1.log ############################ $ vncviewer localhost:1 Visualizador TigerVNC 64 bits v1.10.1 Compilado em: 2020-04-11 13:58 Copyright (C) 1999-2019 Equipe TigerVNC e muitos outros (veja README.rst) Veja https://www.tigervnc.org para informação sobre o TigerVNC. Sat Apr 11 16:03:26 2020 DecodeManager: Detected 4 CPU core(s) DecodeManager: Creating 4 decoder thread(s) CConn: Conectado ao host localhost porta 5901 CConnection: Server supports RFB protocol version 3.8 CConnection: Using RFB protocol version 3.8 CConnection: Choosing security type VeNCrypt(19) CVeNCrypt: Choosing security type TLSVnc (258) Sat Apr 11 16:03:29 2020 DesktopWindow: Ajustando tamanho de janela para evitar solicitação de tela cheia acidental CConn: Usando formato de pixel depth 24 (32bpp) little-endian rgb888 CConnection: Enabling continuous updates
CC: (none) => mageia
My checks on tigervnc-1.10.1-1.1.mga7.src.rpm: Does it build from source rpm? Yes Do vncservers start correctly? Yes Does vncviewer work correctly when connecting to a remote system (ie. vncviewer remotehost:3 ? Yes Does vncviewer work correclty when connecting through a tunnelled connection (ie. vncviewer :3 when "ssh -L5903:localhost:5903 remotehost" is used)? Yes Does connecting to a Linux vncserver work correctly with a windows tiger vncviewer? Yes. Does this seem to fix all the problems? Yes My list is by no means comprehensive but this version solves all the problems I've had with tigervnc.
@ Mike Rambo : Don't forget to do this change for Cauldron too!
Pushed patched 1.10.1-3 for Cauldron. Build and tested locally prior to submitting.
Based on Comment 21 and Comment 22, I'd say this deserves an OK, and a validation. Advisory in Comment 21.
Whiteboard: (none) => MGA7-64-OKKeywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2020-0093.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
*** Bug 26485 has been marked as a duplicate of this bug. ***
CC: (none) => sylvain.hemonet
Per upstream re: the security patches. "As for the patches, my view is that these are not needed as they do not prevent any security issues in current versions of TigerVNC. So my advice is dropping them." https://github.com/TigerVNC/tigervnc/issues/993 I don't know what Mageia procedure would be with this - whether to drop and rebuild now or try to remember later.
I guess a bug to that effect is the answer. Coffee is good, coffee is fine....