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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141109203459.GB37384@dtor-ws>
Date:	Sun, 9 Nov 2014 12:34:59 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Pali Rohár <pali.rohar@...il.com>
Cc:	Hans de Goede <hdegoede@...hat.com>,
	Yunkang Tang <yunkang.tang@...alps.com>,
	Tommy Will <tommywill2011@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/4] input: alps: For protocol V3, do not process data
 when last packet's bit7 is set

On Sun, Nov 09, 2014 at 12:22:51PM +0100, Pali Rohár wrote:
> On Sunday 09 November 2014 08:50:39 Dmitry Torokhov wrote:
> > Hi Pali,
> > 
> > On Sun, Nov 02, 2014 at 12:25:09AM +0100, Pali Rohár wrote:
> > > Sometimes on Dell Latitude laptops psmouse/alps driver
> > > receive invalid ALPS protocol V3 packets with bit7 set in
> > > last byte. More often it can be reproduced on Dell Latitude
> > > E6440 or E7440 with closed lid and pushing cover above
> > > touchpad.
> > > 
> > > If bit7 in last packet byte is set then it is not valid ALPS
> > > packet. I was told that ALPS devices never send these
> > > packets. It is not know yet who send those packets, it
> > > could be Dell EC, bug in BIOS and also bug in touchpad
> > > firmware...
> > > 
> > > With this patch alps driver does not process those invalid
> > > packets and drops it with PSMOUSE_FULL_PACKET so psmouse
> > > driver does not enter to out of sync state.
> > > 
> > > This patch fix problem when psmouse driver still resetting
> > > ALPS device when laptop lid is closed because of receiving
> > > invalid packets in out of sync state.
> > > 
> > > Signed-off-by: Pali Rohár <pali.rohar@...il.com>
> > > Tested-by: Pali Rohár <pali.rohar@...il.com>
> > > Cc: stable@...r.kernel.org
> > > ---
> > > 
> > >  drivers/input/mouse/alps.c |   10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/input/mouse/alps.c
> > > b/drivers/input/mouse/alps.c index 7c47e97..e802d28 100644
> > > --- a/drivers/input/mouse/alps.c
> > > +++ b/drivers/input/mouse/alps.c
> > > @@ -1181,6 +1181,16 @@ static psmouse_ret_t
> > > alps_process_byte(struct psmouse *psmouse)
> > > 
> > >  		return PSMOUSE_BAD_DATA;
> > >  	
> > >  	}
> > > 
> > > +	if (priv->proto_version == ALPS_PROTO_V3 &&
> > > psmouse->pktcnt == psmouse->pktsize) { +		// For protocol
> > > V3, do not process data when last packet's bit7 is set
> > > +		if (psmouse->packet[psmouse->pktcnt - 1] & 0x80) {
> > > +			psmouse_dbg(psmouse, "v3 discard packet[%i] = 
> %x\n",
> > > +				    psmouse->pktcnt - 1,
> > > +				    psmouse->packet[psmouse->pktcnt - 1]);
> > > +			return PSMOUSE_FULL_PACKET;
> > > +		}
> > > +	}
> > 
> > I wanted to apply it, but I would like some more data. Could
> > you please send me the dmesg with i8042.debug wit this patch
> > in place?
> > 
> > Thanks!
> 
> See attachment. It contains debug log from both i8042.debug=1 and 
> psmouse.ko with applied all 4 patches.

Thank you Pali.

OK, so it looks like the problematic byte is the last one and we should
be resynching right away. With your other patch increasing number of bad
packets before issuing resync this special handling is no longer needed,
right?

Thanks.

-- 
Dmitry
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ