linux-kernel - Re: [PATCH] media: input: Convert timers to use timer

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] [day] [month] [year] [list]

Date:   Tue, 24 Oct 2017 07:33:20 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Oliver Endriss <o.endriss@....de>
Cc:     Hans Verkuil <hans.verkuil@...co.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Geliang Tang <geliangtang@...il.com>,
        linux-input <linux-input@...r.kernel.org>,
        linux-media@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] media: input: Convert timers to use timer_setup()

On Thu, Oct 19, 2017 at 3:48 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Thu, Oct 19, 2017 at 03:45:38PM -0700, Kees Cook wrote:
>> On Thu, Oct 19, 2017 at 3:32 PM, Dmitry Torokhov
>> <dmitry.torokhov@...il.com> wrote:
>> > On Mon, Oct 16, 2017 at 04:14:43PM -0700, Kees Cook wrote:
>> >> In preparation for unconditionally passing the struct timer_list pointer to
>> >> all timer callbacks, switch to using the new timer_setup() and from_timer()
>> >> to pass the timer pointer explicitly.
>> >>
>> >> One input_dev user hijacks the input_dev software autorepeat timer to
>> >> perform its own repeat management. However, there is no path back to the
>> >> existing status variable, so add a generic one to the input structure and
>> >> use that instead.
>> >
>> > That is too bad and it should not be doing this. I'd rather av7110 used
>> > its own private timer for that.
>>
>> Yeah, that was a pretty weird case. I couldn't see how to avoid it,
>> though. I didn't see a way to hook the autorepeat, but I'm not too
>> familiar with the code here.
>
> You just need to manage the private timer in the driver and not mess up
> with the input core if input core's autorepeat does not provide the
> desired behavior...

I don't know how to fix this, but I still need to do this refactoring.
What's the correct step forward here? Should I temporarily disable the
timer in av7110?

Seems like the hijacking was introduced in ee820a648fb3 ("V4L/DVB
(5334): Dvb-ttpci: Infrared remote control refactoring").

Thanks!

-Kees

-- 
Kees Cook
Pixel Security