Input to TTYs goes to X after returning

[Michael Rooney]

Binary package hint: xkeyboard-config

After using to a TTY and returning to X, some or all of the input performed in the TTY gets sent to X. This is especially bad as newlines are sent as well, so a user with an IM/IRC entry focused, or any other form, will have data sent from their TTY session to everyone watching, potentially including login passwords.

Additionally, both in Compiz and Metacity, if the cursor was over a window before the TTY switch, returning to X puts that window in "Move" mode (normally triggered by holding Alt+LeftClick on a window), and seems to requires escaping from this mode before the input appears.

Case 1:
1. Put your cursor over a non-maximized window.
2. Press Ctrl+Alt+F1 to go to TTY1.
3. Log-in.
4. Press Alt+F7 to return.

What happens:
1. The window is in "Move" mode, so mouse movement moves the window. You must click to get out of this mode.
2. The help will be invoked of whatever application handled it, presumably because you pressed F1 to use TTY1.

What should happen:
You should be return to X in the state you left it, and no input involved in going to/from, or using the TTY, should later make it to X

Case 2:
1. Open a text editor.
2. Press Ctrl+Alt+F2 to go to TTY2
3. Type your username and press enter.
4. Press Alt+F7 to return.

What happens:
After clicking or otherwise exiting from "move" mode, the username is echoed in the text editor.

What should happen:
See first case.

After Case 2, try going back to TTY2 and typing your password (or a fake password, for safety), and returning. A section of the end of your password is sent to X after returning.

[Waleed Hamra (w-hamra1987)]

I have a similar situation where input i type in TTY1 gets sent to X!
1)open any window with an input field, and the cursor ready to receive input
2)press ctrl-alt-f1
3)put username and password
4) return to X by alt-f7
5) back to TTY1, using ctrl-alt-f1
6)type anything and hit enter
7)ctrl-alt-f7
8) the text got written to the input field of the windows opened!

Kubuntu Intrepid Ibex i386
KDE 4.1.1

[Kees Cook (kees)]

doesn't seem to be tied to compiz (I run metacity and can confirm it). My steps:

0) open a gnome-terminal and leave it focused
1) ctrl-alt-f1
2) type "abcdefghijklmnopqrstuvwyz" (without hitting enter)
3) return to X with alt-f7
4) observe nothing
5) touch mouse and...
6) suddenly observe "uvwxyz" entered into gnome-terminal, and alt-f7 (window move) triggers

[Bryce Harrington (bryce)]

I've not been able to reproduce this exactly, on either of two laptops. Could you attach your /var/log/Xorg.0.log and the output of 'lspci -vvnn'?

[Kees Cook (kees)]

Does not appear to be related to getty nor specific to tty1 (I can reproduce on any tty, e.g. tty8, tty9).

[C de-Avillez (hggdh2)]

for me results vary: for example, I folowed Kees' steps, and my terminator pane got reduced from full-screen to a ridiculously smal pane, and on the move...

Other times I can see part of what I did in the TTYs echoed.

Metacity only, no Compiz.

[Waleed Hamra (w-hamra1987)]

Also note that the leaked characters only show up when i move the mouse, and then everything i pressed in TTY gets to X, whether characters or function keys!
here's my xorg log

[Bryce Harrington (bryce)]

I can reproduce using kees' steps in comment #2.

If I run this inside X:

xev | sed -n 's/^.*keycode *\([0-9]\+\) *\(.*\), .*$/keycode \1 = \2/p'

then follow those steps, hitting 'bbbbbbbbb' on the console, when returning to X I see:

$ xev | sed -n 's/^.*keycode *\([0-9]\+\) *\(.*\), .*$/keycode \1 = \2/p'
keycode 36 = (keysym 0xff0d, Return)
keycode 37 = (keysym 0xffe3, Control_L)
keycode 64 = (keysym 0xffe9, Alt_L)
keycode 67 = (keysym 0x1008fe01, XF86_Switch_VT_1)
keycode 67 = (keysym 0x1008fe01, XF86_Switch_VT_1)
keycode 67 = (keysym 0x1008fe01, XF86_Switch_VT_1)
[repeated a lot, maybe 100 times]
keycode 67 = (keysym 0x1008fe01, XF86_Switch_VT_1)
keycode 37 = (keysym 0xffe3, Control_L)
keycode 64 = (keysym 0xffe9, Alt_L)
keycode 67 = (keysym 0xffbe, F1)

then after moving the mouse slightly, I see this printed:

keycode 56 = (keysym 0x62, b)
keycode 56 = (keysym 0x62, b)
keycode 56 = (keysym 0x62, b)
keycode 56 = (keysym 0x62, b)
keycode 56 = (keysym 0x62, b)
keycode 56 = (keysym 0x62, b)
keycode 56 = (keysym 0x62, b)
keycode 56 = (keysym 0x62, b)
keycode 56 = (keysym 0x62, b)
keycode 56 = (keysym 0x62, b)
keycode 37 = (keysym 0xffe3, Control_L)
keycode 64 = (keysym 0xffe9, Alt_L)
keycode 73 = (keysym 0x1008fe07, XF86_Switch_VT_7)
keycode 64 = (keysym 0xffe9, Alt_L)
keycode 37 = (keysym 0xffe3, Control_L)

[Jamie Strandboge (jdstrand)]

I was able to reproduce this on a non-compiz desktop with both 2.6.25-5-generic and 2.6.27-4-generic.

[Jamie Strandboge (jdstrand)]

I meant 2.6.26-5-generic and 2.6.27-4-generic.

[Brian Murray (brian-murray)]

I was able to recreate this with 2.6.26-5-generic and 2.6.24-19-generic on an Intrepid system.

[Bryce Harrington (bryce)]

I was also able to reproduce it on 2.6.26-5-generic.

[Bryce Harrington (bryce)]

So probably not a kernel issue; at the same time I'm unsure that it's an xkeyboard-config issue either...

[Bryce Harrington (bryce)]

jcristau reports being able to reproduce on debian

<jcristau> bryce: i get some 'fun' stuff on vt switch, but it seems to be mostly the alt-f7 release, not other stuff i type on the console
<jcristau> xev sees a keyrelease for XF86_Switch_VT_1, then keyrelease for control, alt, and f7
 hrm.
<jcristau> bryce: actually it looks like i can reproduce

[Bryce Harrington (bryce)]

Turns out this is indeed an evdev issue.

Kees - Xorg ignores setting the keyboard driver in xorg.conf and forces it to evdev, thus explaining your ability to reproduce it even with "kbd" specified in xorg.conf.

Despite people not reproducing it on hardy, it may still be a bug present there - we didn't ship evdev by default on hardy, so probably few are using it. But if you set your keyboard driver to "evdev" in xorg.conf on hardy, you may be able to test if this bug is occurring there.

In any case, the attached patch from whot and mjg59 should hopefully solve it.

[Bryce Harrington (bryce)]

Here are debs with the above patch included:

http://bryceharrington.org/ubuntu/evdev/xserver-xorg-input-evdev_2.0.99+git20080912-0ubuntu2_amd64.deb
http://bryceharrington.org/ubuntu/evdev/xserver-xorg-input-evdev_2.0.99+git20080912-0ubuntu2_i386.deb

[Bryce Harrington (bryce)]

Standby, those debs didn't actually have the patch included properly.

[Bryce Harrington (bryce)]

Okay, fixed debs posted. Same links.

http://bryceharrington.org/ubuntu/evdev/xserver-xorg-input-evdev_2.0.99+git20080912-0ubuntu2_amd64.deb
http://bryceharrington.org/ubuntu/evdev/xserver-xorg-input-evdev_2.0.99+git20080912-0ubuntu2_i386.deb

[Bryce Harrington (bryce)]

Thanks to all that confirmed the fix. Too late for beta, but is uploaded and should go out asap after beta-freeze is ended.

[Brian Murray (brian-murray)]

The deb posted resolved the bug for me.

[C de-Avillez (hggdh2)]

I also cannot reproduce it with the deb.

[Bryce Harrington (bryce)]

xserver-xorg-input-evdev (1:2.0.99+git20080912-0ubuntu2) intrepid; urgency=low

  * 101_evdev-close-fd.patch: Fix issue where keystrokes on tty can "leak"
    into the X session after vt switch, due to an fd still being open.
    (LP: #276887)

 -- Bryce Harrington <email address hidden> Fri, 03 Oct 2008 13:52:36 -0700

Also was fixed upstream so when we sync -evdev next, we can drop our patch.

[Timo Aaltonen (tjaalton)]

was not a bug in xkeyboard-config.