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]
Date:   Wed, 8 Mar 2017 22:50:16 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Michał Kępień <kernel@...pniu.pl>,
        linux-input <linux-input@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Andy Shevchenko <andy@...radead.org>
Subject: Re: [PATCH v3] Input: sparse-keymap - use a managed allocation for
 keymap copy

On Wed, Mar 8, 2017 at 8:12 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Wed, Mar 08, 2017 at 09:22:17AM +0100, Michał Kępień wrote:
>> Some platform drivers use devm_input_allocate_device() together with
>> sparse_keymap_setup() in their .probe callbacks.  While using the former
>> simplifies error handling, using the latter necessitates calling
>> sparse_keymap_free() in the error path and upon module unloading to
>> avoid leaking the copy of the keymap allocated by sparse_keymap_setup().
>>
>> To help prevent such leaks and enable simpler error handling, make
>> sparse_keymap_setup() use devm_kmemdup() to create the keymap copy so
>> that it gets automatically freed.
>>
>> This works for both managed and non-managed input devices as the keymap
>> is freed after the last reference to the input device is dropped.
>>
>> Note that actions previously taken by sparse_keymap_free(), i.e. taking
>> the input device's mutex and zeroing its keycode and keycodemax fields,
>> are now redundant because the managed keymap will always be freed after
>> the input device is unregistered.

> OK, I think this looks good. Do platform folks want an immutable branch
> off 4.10 with this change so we can start cleaning sparse_keymap_free()
> users in this cycle?

If there PDx86 related patches are anticipated this cycle, definitely
we need an immutable branch (perhaps based on v4.11-rc1).

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ