Bug 11080

Occasionally we have seen corruption of all of a Gtk-based X client's images when it connects across ssh.  Images are replaced by image data that clearly comes from another client connected to the server.

It appears that the client and server are attempting to send image data via the MIT-SHM shared memory extension, even though the two are on different machines.

When the problem occurred I did some checks.  The X client was mapping a SysV shared memory segment:

betamax:~$ grep SYSV /proc/17565/maps
b550b000-b556b000 rw-s 00000000 00:08 425985     /SYSV00000000 (deleted)

Normally, no SysV segments are mapped.  Furthermore, the "nattch" parameter was 1 (no server had also mapped the segment).  For correctly-working X clients, nattch=2.

betamax:~$ ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 425985     conductor 600        393216     1          dest

Listing shared memory segments on the machine running the X server reveals that the server happens to have a shared memory segment with the same ID (shmid=425985):

tonytheprawn:~$ ipcs -m
------ Shared Memory Segments --------
key        shmid   owner    perms bytes  nattch status
0x00000000 393216  mseaborn 600   393216 2      dest
0x00000000 425985  mseaborn 600   393216 2      dest
... 

It appears that the X server and client do not check to see whether they are really on the same machine.  The client sends the server a memory segment ID.  If the server fails to map the segment, it fails silently and the two fall back to the remote case.  However in this case, the server is succeeding accidentally and is seeing an unrelated process's image data.

This is not surprising considering that the connection is proxied by ssh:  both the server and client believe they are connected to a local process via a Unix domain socket.

I can see two ways to fix this:

 * Add more checks to the client or server to check that they are on the same machine.  May involve adding parameters to the MIT-SHM X requests.
 * Provide a way for ssh to switch off the MIT-SHM extension on the connections it sets up.  Also requires some sort of protocol extension.

This may not be worth fixing.

There may be some security issues here.  Maybe an X client can use this to read unrelated processes' SysV shared memory segments on the X server's machine?