linux-kernel - Re: Fix sudden warps in mousedev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 25 Mar 2007 11:19:30 -0700
From:	Pete Zaitcev <zaitcev@...hat.com>
To:	Dmitry Torokhov <dtor@...ightbb.com>
Cc:	linux-kernel@...r.kernel.org, linux-input@...ey.karlin.mff.cuni.cz,
	zaitcev@...hat.com
Subject: Re: Fix sudden warps in mousedev

On Sun, 25 Mar 2007 01:34:02 -0400, Dmitry Torokhov <dtor@...ightbb.com> wrote:

> > +                * Without this, a touchpad may report an unchanged position,
> > +                * then a sync. The input_event() eats the position report, but
> > +                * lets the sync through. We increment pkt_count and leave 
> > +                * a stale position in the ring. If a future reference to fx(2)
> > +                * hits the stale position, a large dx is reported, and the
> > +                * pointer warps across the screen.
> > +                */
> > +               dev = mousedev->handle.dev;
> > +               fx(0) = dev->abs[ABS_X];
> > +               fy(0) = dev->abs[ABS_Y];
> 
> I do not like input hanlders poking into input devices... Can't we just
> reset pkt_count at the beginning of the touch to get rid of stale data?

The pkt_count is zero at the moment of assignment above.

Please look at the included trace again:

> > Event: time 1174703243.305535, type 1 (Key), code 330 (Touch), value 1
> >           <---- touch!=0 now, we're on
> > Event: time 1174703243.305538, type 3 (Absolute), code 24 (Pressure), value 31
> > Event: time 1174703243.305541, -------------- Report Sync ------------
> >           <---- We increment the pkt_count, leaving value of 3687 in old_y
> > Event: time 1174703243.342452, type 3 (Absolute), code 0 (X), value 4747
> > Event: time 1174703243.342455, type 3 (Absolute), code 1 (Y), value 1988
> >           <----- Later to be fy(1), not used for warping purposes :-)
> > Event: time 1174703243.342459, -------------- Report Sync ------------
> > Event: time 1174703243.356225, type 3 (Absolute), code 0 (X), value 4749
> > Event: time 1174703243.356237, type 3 (Absolute), code 1 (Y), value 1987
> >           <----- warp here, by the difference of 3687 and 1987, plus
> >                  some small frac_dy value. Easily jumps half the screen.
> > Event: time 1174703243.356246, -------------- Report Sync ------------

The assignment happens at .305535. The pkt_count is zero, and fy(0) contains
stale data (ovewritten by the assignment). The touchpad reports a position
next with input_report_abs(). If the position were different, we'd receive
an event between .305535 and .305538 and it would be stored in fy(0).

However, if position is the same, as in this case, input_report eats it.
At .305541 we increment pkt_count. The fy(0) location becomes fy(1) at
this point. Without the assignment it contains the stale position.

I can explore alternatives, but for now using dev->abs[] seems to be most
expedient.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/