linux-kernel - Re: [PATCH 0/1] Input: evdev - fix wrong timestamp after SYN

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: <CABDcavYkGAGA5CVsMZGE9g_HLTvE3kAM25Uu8h6ccqerLp5oWQ@mail.gmail.com>
Date: Mon, 24 Feb 2025 17:19:23 +0100
From: Guillermo Rodriguez Garcia <guille.rodriguez@...il.com>
To: linux-kernel@...r.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>, linux-input@...r.kernel.org
Subject: Re: [PATCH 0/1] Input: evdev - fix wrong timestamp after SYN_DROPPED

Hi all,

Any comments on the patch below?

Thank you,

Guillermo Rodriguez Garcia
guille.rodriguez@...il.com

El lun, 2 dic 2024 a las 13:34, Guillermo Rodríguez
(<guille.rodriguez@...il.com>) escribió:
>
> Hi all,
>
> We are seeing an issue with gpio_keys where the first event after
> a SYN_DROPPED has the same timestamp as the SYN_DROPPED event itself.
> After some investigation it looks like this is an issue with evdev
> and not specific to gpio_keys.
>
> The issue was originally introduced in commit 3b51c44 ("Input: allow
> drivers specify timestamp for input events").
>
> This commit introduced input_set_timestamp and input_get_timestamp.
> The latter (despite the name) actually generates and stores a timestamp
> in dev->timestamp if the driver did not set one itself. This timestamp
> needs to be reset when events are flushed; otherwise the next event
> will use a stale timestamp. A partial fix was implemented in 4370b23
> ("Input: reset device timestamp on sync"), but this does not cover the
> case of SYN_DROPPED.
>
> If a SYN_DROPPED is generated (currently only done by evdev), the
> following happens:
>
> - evdev calls input_get_timestamp to generate a timestamp for the
>   SYN_DROPPED event.
> - input_get_timestamp generates a timestamp and stores it in
>   dev->timestamp
> - When the next real event is reported (in evdev_events), evdev
>   calls input_get_timestamp, which uses the timestamp already
>   stored in dev->timestamp, which corresponds to the SYN_DROPPED event
>
> How to fix:
>
> - When a SYN_DROPPED is generated, after calling input_get_timestamp,
>   the timestamp stored in dev->timestamp should be reset (same as is
>   currently done in input_handle_event). The attached patch does that.
>
> (Perhaps the underlying problem is that it is not expected that a
> function called input_get_timestamp will have side effects. The
> commit history of input.c shows that this has actually caused a
> few issues since 3b51c44.)
>
>
> Guillermo Rodríguez (1):
>   Input: evdev - fix wrong timestamp after SYN_DROPPED event
>
>  drivers/input/evdev.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
>
> base-commit: e70140ba0d2b1a30467d4af6bcfe761327b9ec95
> 2.25.1
>