linux-kernel - Re: [PATCH] Input: Do not add SYN_REPORT in between a single packet data

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: <CADYu308R82BnOm-N6-w4=WSEJOwwOdwW_OgVg+WD_GeOtdysug@mail.gmail.com>
Date:	Wed, 30 Mar 2016 22:46:24 +0530
From:	Aniroop Mathur <aniroop.mathur@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Henrik Rydberg <rydberg@...math.org>
Cc:	Aniroop Mathur <a.mathur@...sung.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Input: Do not add SYN_REPORT in between a single packet data

Hello Mr. Henrik,

So do you have any further comments on this patch please?
It is pending for more than 20 days. It would be really appreciating
if you could help out to conclude it as soon as possible.

Regards,
Aniroop Mathur

On Thu, Mar 24, 2016 at 1:05 AM, Aniroop Mathur
<aniroop.mathur@...il.com> wrote:
> Hello Mr. Torokhov / Mr. Henry,
>
> On Wed, Mar 16, 2016 at 11:54 PM, Aniroop Mathur
> <aniroop.mathur@...il.com> wrote:
>> Hello Mr. Torokhov,
>>
>> Could you kindly help to update about this patch?
>>
>
> So is this patch concluded? Are you applying it?
>
> Thanks,
> Aniroop Mathur
>
>> Thank you,
>> Aniroop Mathur
>>
>>
>> On Fri, Mar 11, 2016 at 12:26 AM, Aniroop Mathur
>> <aniroop.mathur@...il.com> wrote:
>>> Hi Henrik,
>>>
>>> On Thu, Mar 10, 2016 at 7:15 PM, Henrik Rydberg <rydberg@...math.org> wrote:
>>>> Hi Dmitry,
>>>>
>>>>>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>>>>>> index 8806059..262ef77 100644
>>>>>> --- a/drivers/input/input.c
>>>>>> +++ b/drivers/input/input.c
>>>>>> @@ -401,8 +401,7 @@ static void input_handle_event(struct input_dev *dev,
>>>>>>                 if (dev->num_vals >= 2)
>>>>>>                         input_pass_values(dev, dev->vals, dev->num_vals);
>>>>>>                 dev->num_vals = 0;
>>>>>> -       } else if (dev->num_vals >= dev->max_vals - 2) {
>>>>>> -               dev->vals[dev->num_vals++] = input_value_sync;
>>>>>> +       } else if (dev->num_vals >= dev->max_vals - 1) {
>>>>>>                 input_pass_values(dev, dev->vals, dev->num_vals);
>>>>>>                 dev->num_vals = 0;
>>>>>>         }
>>>>>
>>>>> This makes sense to me. Henrik?
>>>>
>>>> I went through the commits that made these changes, and I cannot see any strong
>>>> reason to keep it. However, this code path only triggers if no SYN events are
>>>> seen, as in a driver that fails to emit them and consequently fills up the
>>>> buffer. In other words, this change would only affect a device that is already,
>>>> to some degree, broken.
>>>>
>>>> So, the question to Aniroop is: do you see this problem in practise, and in that
>>>> case, for what driver?
>>>>
>>>
>>> Nope. So far I have not dealt with any such driver.
>>> I made this change because it is breaking protocol of SYN_REPORT event code.
>>>
>>> Further from the code, I could deduce that max_vals is just an estimation of
>>> packet_size and it does not guarantee that packet_size is same as max_vals.
>>> So real packet_size can be more than max_vals value and hence we could not
>>> insert SYN_REPORT until packet ends really.
>>> Further, if we consider that there exists a driver or will exist in future
>>> which sets capability of x event code according to which max_value comes out to
>>> y and the real packet size is z i.e. driver wants to send same event codes
>>> again in the same packet, so input event reader would be expecting SYN_REPORT
>>> after z events but due to current code SYN_REPORT will get inserted
>>> automatically after y events, which is a wrong behaviour.
>>>
>>> Thanks,
>>> Aniroop Mathur
>>>
>>>> Henrik
>>>>