Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shadow sessions inside nxagent sessions fail #6

Closed
sunweaver opened this issue Mar 18, 2015 · 0 comments
Closed

shadow sessions inside nxagent sessions fail #6

sunweaver opened this issue Mar 18, 2015 · 0 comments
Labels
Milestone

Comments

@sunweaver
Copy link
Member

We just tried to run cascaded sessions with one of them being a desktop sharing session:

(a) from client (host-A) launch X2Go session to a remote server (server-B)
(b) from X2Go session on server-B launch a remote desktop sharing session with :0 on remote
host-C

Result: a black nxagent window appears (inside the X2Go Session on server-B) that accepts mouse and keyboard input (which both arrive on host-C via desktop sharing). If I manage to move a window via the desktop sharing session, the black nxagent window does some screen updates, but no full view of the remotely shared desktop appears.

sunweaver added a commit to sunweaver/nx-libs that referenced this issue Apr 28, 2015
sunweaver added a commit to sunweaver/nx-libs that referenced this issue Apr 28, 2015
@sunweaver sunweaver added the bug label May 16, 2015
@sunweaver sunweaver added this to the 3.6.0.x milestone May 16, 2015
uli42 added a commit to uli42/nx-libs that referenced this issue Jun 19, 2019
If compiled with -fsanitize=address this showed up when running startlxde:

==11551==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d000018fbc at pc 0x7f270a9ed57b bp 0x7fff30ef3050 sp 0x7fff30ef2800
READ of size 204 at 0x60d000018fbc thread T0
    #0 0x7f270a9ed57a  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
    #1 0x559dafcd5c93 in FindGlyphRef ../../render/glyph.c:179
    #2 0x559dafcd705d in AddGlyph /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXglyph.c:71
    #3 0x559dafccc0ff in ProcRenderAddGlyphs ../../mi/../render/render.c:1186
    ArcticaProject#4 0x559dafcbd5a5 in ProcRenderDispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXrender.c:1689
    ArcticaProject#5 0x559dafcbc4ea in Dispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:476
    ArcticaProject#6 0x559dafc4e9b0 in main /work/nx-libs/nx-X11/programs/Xserver/dix/main.c:353
    ArcticaProject#7 0x7f2708e1d09a in __libc_start_main ../csu/libc-start.c:308
    ArcticaProject#8 0x559dafc4f5d9 in _start (/work/nx-libs/nx-X11/programs/Xserver/nxagent+0x6e5d9)

0x60d000018fbc is located 0 bytes to the right of 140-byte region [0x60d000018f30,0x60d000018fbc)
allocated by thread T0 here:
    #0 0x7f270aa1e330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x559dafcd646c in AllocateGlyph ../../render/glyph.c:348

This happens when two glyphs are compared via memcmp and the smaller
one happens to be identical to the beginning of the bigger one.

Newer render implementations use a sha1 hash instead of memcmp so this
patch will (hopefully) be obsolete once render gets updated.
uli42 added a commit to uli42/nx-libs that referenced this issue Jun 21, 2019
If compiled with -fsanitize=address this showed up when running startlxde:

==11551==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d000018fbc at pc 0x7f270a9ed57b bp 0x7fff30ef3050 sp 0x7fff30ef2800
READ of size 204 at 0x60d000018fbc thread T0
    #0 0x7f270a9ed57a  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
    #1 0x559dafcd5c93 in FindGlyphRef ../../render/glyph.c:179
    #2 0x559dafcd705d in AddGlyph /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXglyph.c:71
    #3 0x559dafccc0ff in ProcRenderAddGlyphs ../../mi/../render/render.c:1186
    ArcticaProject#4 0x559dafcbd5a5 in ProcRenderDispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXrender.c:1689
    ArcticaProject#5 0x559dafcbc4ea in Dispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:476
    ArcticaProject#6 0x559dafc4e9b0 in main /work/nx-libs/nx-X11/programs/Xserver/dix/main.c:353
    ArcticaProject#7 0x7f2708e1d09a in __libc_start_main ../csu/libc-start.c:308
    ArcticaProject#8 0x559dafc4f5d9 in _start (/work/nx-libs/nx-X11/programs/Xserver/nxagent+0x6e5d9)

0x60d000018fbc is located 0 bytes to the right of 140-byte region [0x60d000018f30,0x60d000018fbc)
allocated by thread T0 here:
    #0 0x7f270aa1e330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x559dafcd646c in AllocateGlyph ../../render/glyph.c:348

This happens when two glyphs are compared via memcmp and the smaller
one happens to be identical to the beginning of the bigger one.

Newer render implementations use a sha1 hash instead of memcmp so this
patch will (hopefully) be obsolete once render gets updated.
sunweaver pushed a commit to uli42/nx-libs that referenced this issue Jun 22, 2019
If compiled with -fsanitize=address this showed up when running startlxde:

==11551==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d000018fbc at pc 0x7f270a9ed57b bp 0x7fff30ef3050 sp 0x7fff30ef2800
READ of size 204 at 0x60d000018fbc thread T0
    #0 0x7f270a9ed57a  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
    #1 0x559dafcd5c93 in FindGlyphRef ../../render/glyph.c:179
    #2 0x559dafcd705d in AddGlyph /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXglyph.c:71
    #3 0x559dafccc0ff in ProcRenderAddGlyphs ../../mi/../render/render.c:1186
    ArcticaProject#4 0x559dafcbd5a5 in ProcRenderDispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXrender.c:1689
    ArcticaProject#5 0x559dafcbc4ea in Dispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:476
    ArcticaProject#6 0x559dafc4e9b0 in main /work/nx-libs/nx-X11/programs/Xserver/dix/main.c:353
    ArcticaProject#7 0x7f2708e1d09a in __libc_start_main ../csu/libc-start.c:308
    ArcticaProject#8 0x559dafc4f5d9 in _start (/work/nx-libs/nx-X11/programs/Xserver/nxagent+0x6e5d9)

0x60d000018fbc is located 0 bytes to the right of 140-byte region [0x60d000018f30,0x60d000018fbc)
allocated by thread T0 here:
    #0 0x7f270aa1e330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x559dafcd646c in AllocateGlyph ../../render/glyph.c:348

This happens when two glyphs are compared via memcmp and the smaller
one happens to be identical to the beginning of the bigger one.

Newer render implementations use a sha1 hash instead of memcmp so this
patch will (hopefully) be obsolete once render gets updated.
uli42 added a commit to uli42/nx-libs that referenced this issue Oct 2, 2020
In compext Atom has the size of XlibAtom. Therefore calling functions
of Compext.c requires to use/pass XlibAtom. Same for Window/XlibWindow.

==15438==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffcdc0 at pc 0x5555556a81b5 bp 0x7fffffffcd10 sp 0x7fffffffcd08
WRITE of size 8 at 0x7fffffffcdc0 thread T0
    #0 0x5555556a81b4 in NXGetCollectedProperty nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124
    #1 0x5555557d0488 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1202
    #2 0x555555723340 in nxagentHandleCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3923
    #3 0x55555571d4db in nxagentHandleProxyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3007
    ArcticaProject#4 0x55555571bb92 in nxagentHandleClientMessageEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:2595
    ArcticaProject#5 0x555555717dfc in nxagentDispatchEvents nx-X11/programs/Xserver/hw/nxagent/Events.c:1827
    ArcticaProject#6 0x555555750813 in nxagentBlockHandler nx-X11/programs/Xserver/hw/nxagent/Handlers.c:437
    ArcticaProject#7 0x5555556c1b5d in BlockHandler nx-X11/programs/Xserver/dix/dixutils.c:403
    ArcticaProject#8 0x5555556d47ff in WaitForSomething nx-X11/programs/Xserver/os/WaitFor.c:232
    ArcticaProject#9 0x555555665b22 in Dispatch nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:365
    ArcticaProject#10 0x5555555ed760 in main nx-X11/programs/Xserver/dix/main.c:350
    ArcticaProject#11 0x7ffff604909a in __libc_start_main ../csu/libc-start.c:308
    ArcticaProject#12 0x5555555edc09 in _start (nx-X11/programs/Xserver/nxagent+0x99c09)

Address 0x7fffffffcdc0 is located in stack of thread T0 at offset 32 in frame
    #0 0x5555557d0324 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1190

  This frame has 5 object(s):
    [32, 36) 'atomReturnType' <== Memory access at offset 32 partially overflows this variable
    [96, 100) 'resultFormat'
    [160, 168) 'ulReturnItems'
    [224, 232) 'ulReturnBytesLeft'
    [288, 296) 'pszReturnData'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124 in NXGetCollectedProperty
...
sunweaver pushed a commit to uli42/nx-libs that referenced this issue Oct 17, 2020
In compext Atom has the size of XlibAtom. Therefore calling functions
of Compext.c requires to use/pass XlibAtom. Same for Window/XlibWindow.

==15438==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffcdc0 at pc 0x5555556a81b5 bp 0x7fffffffcd10 sp 0x7fffffffcd08
WRITE of size 8 at 0x7fffffffcdc0 thread T0
    #0 0x5555556a81b4 in NXGetCollectedProperty nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124
    #1 0x5555557d0488 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1202
    #2 0x555555723340 in nxagentHandleCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3923
    #3 0x55555571d4db in nxagentHandleProxyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3007
    ArcticaProject#4 0x55555571bb92 in nxagentHandleClientMessageEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:2595
    ArcticaProject#5 0x555555717dfc in nxagentDispatchEvents nx-X11/programs/Xserver/hw/nxagent/Events.c:1827
    ArcticaProject#6 0x555555750813 in nxagentBlockHandler nx-X11/programs/Xserver/hw/nxagent/Handlers.c:437
    ArcticaProject#7 0x5555556c1b5d in BlockHandler nx-X11/programs/Xserver/dix/dixutils.c:403
    ArcticaProject#8 0x5555556d47ff in WaitForSomething nx-X11/programs/Xserver/os/WaitFor.c:232
    ArcticaProject#9 0x555555665b22 in Dispatch nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:365
    ArcticaProject#10 0x5555555ed760 in main nx-X11/programs/Xserver/dix/main.c:350
    ArcticaProject#11 0x7ffff604909a in __libc_start_main ../csu/libc-start.c:308
    ArcticaProject#12 0x5555555edc09 in _start (nx-X11/programs/Xserver/nxagent+0x99c09)

Address 0x7fffffffcdc0 is located in stack of thread T0 at offset 32 in frame
    #0 0x5555557d0324 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1190

  This frame has 5 object(s):
    [32, 36) 'atomReturnType' <== Memory access at offset 32 partially overflows this variable
    [96, 100) 'resultFormat'
    [160, 168) 'ulReturnItems'
    [224, 232) 'ulReturnBytesLeft'
    [288, 296) 'pszReturnData'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124 in NXGetCollectedProperty
...
uli42 added a commit to uli42/nx-libs that referenced this issue Oct 18, 2020
 Direct leak of 3 byte(s) in 1 object(s) allocated from:
 #0 0xb79e85d4 in __interceptor_malloc (/lib/i386-linux-gnu/libasan.so.5+0xeb5d4)
 #1 0xb770b635 in copystring /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:96
 #2 0xb770ba56 in _X11TransConnectDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:229
 #3 0xb776b4fd in XOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/OpenDis.c:215
 ArcticaProject#4 0x63e2fd in nxagentInternalOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:608
 ArcticaProject#5 0x63fa03 in nxagentOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:1140
 ArcticaProject#6 0x694b5a in InitOutput /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Init.c:305
 ArcticaProject#7 0x5f7b11 in main /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/dix/main.c:278
 ArcticaProject#8 0xb6f04b40 in __libc_start_main ../csu/libc-start.c:308

I have not investigated the exact location where an XFree() was missing but added multiple
Xfree() calls whereever appropriate.

Fixes ArcticaProject#951
sunweaver pushed a commit to uli42/nx-libs that referenced this issue Nov 3, 2020
 Direct leak of 3 byte(s) in 1 object(s) allocated from:
 #0 0xb79e85d4 in __interceptor_malloc (/lib/i386-linux-gnu/libasan.so.5+0xeb5d4)
 #1 0xb770b635 in copystring /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:96
 #2 0xb770ba56 in _X11TransConnectDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:229
 #3 0xb776b4fd in XOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/OpenDis.c:215
 ArcticaProject#4 0x63e2fd in nxagentInternalOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:608
 ArcticaProject#5 0x63fa03 in nxagentOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:1140
 ArcticaProject#6 0x694b5a in InitOutput /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Init.c:305
 ArcticaProject#7 0x5f7b11 in main /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/dix/main.c:278
 ArcticaProject#8 0xb6f04b40 in __libc_start_main ../csu/libc-start.c:308

I have not investigated the exact location where an XFree() was missing but added multiple
Xfree() calls whereever appropriate.

Fixes ArcticaProject#951
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant