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: <542E719A.8030509@redhat.com>
Date:	Fri, 03 Oct 2014 11:51:22 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Pali Rohár <pali.rohar@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Yunkang Tang <yunkang.tang@...alps.com>,
	Tommy Will <tommywill2011@...il.com>
CC:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] input: alps: For protocol V3, do not process data
 when last packet's bit7 is set

Hi,

On 10/03/2014 11:43 AM, Pali Rohár wrote:
> Sometimes laptops with closed lid receive invalid ALPS protocol V3 packets with
> last bit7 set.
> 
> This happens on Dell Latitude laptops and it looks like it is BIOS bug. Probably
> EC does not correctly split keyboard and touchpad PS/2 data and when laptop lid
> is closed it adds 0xFF packet into touchpad PS/2 data.
> 
> When last packet's bit7 is set it is invalid ALPS packet. So Do not process it
> and drop it with PSMOUSE_FULL_PACKET.
> 
> After testing it looks like this patch fixed problem with reseting mouse (after
> series of invalid packets) when laptop lid is closed on Dell Latitude machines.
> 
> Signed-off-by: Pali Rohár <pali.rohar@...il.com>
> Tested-by: Pali Rohár <pali.rohar@...il.com>
> ---
>  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 1bd5aa1..b1f44d4 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -1179,6 +1179,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 wonder if this should not be PSMOUSE_BAD_DATA as a return value ? I realize that
with the 3th patch in place, that will cause an immediate reset, but if your theory is
right that this ff gets inserted from the keyboard ps/2 stream, then we actually want
a full reset as otherwise we will be out of sync then.

>  	/* Bytes 2 - pktsize should have 0 in the highest bit */
>  	if ((priv->proto_version < ALPS_PROTO_V5) &&
>  	    psmouse->pktcnt >= 2 && psmouse->pktcnt <= psmouse->pktsize &&
> 

Regards,

Hans
--
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