linux-kernel - Re: [RFC v1 0/3] Address potential user-after-free on module unload

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:   Thu, 7 Feb 2019 14:20:56 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Sven Van Asbroeck <thesven73@...il.com>
Cc:     Kees Cook <keescook@...omium.org>, Tejun Heo <tj@...nel.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Sebastian Reichel <sre@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [RFC v1 0/3] Address potential user-after-free on module unload

Hi Sven,

On Thu, Feb 7, 2019 at 1:49 PM Sven Van Asbroeck <thesven73@...il.com> wrote:
>
> On Tue, Feb 5, 2019 at 9:57 AM Kees Cook <keescook@...omium.org> wrote:
> >
> > Can a Coccinelle script get written to find module-use of the non-devm
> > work init?
>
> Ok so I hacked together a Coccinelle script to find these
> user-after-free issues,
> related to work left running when the device or module is removed.
>
> As far as I can see, these issues may crash/corrupt the kernel even on
> _device_ remove/unplug. Users don't need root for that...
>
> I got 71 hits. At least one is a false positive.
> 34 out of 71 could benefit from devm_init_work().
...
> ./drivers//input/serio/ps2-gpio.c:412:1-18: missing clean-up of
> INIT_WORK/INIT_DELAYED_WORK initialized here (maybe use devm_)

OK, this seems to be a real issue. We need to make sure we flush the
TX work inside ps2_gpio_close().

> ./drivers//input/keyboard/matrix_keypad.c:512:1-18: missing clean-up
> of INIT_WORK/INIT_DELAYED_WORK initialized here

This is not as simple. The work in question is scheduled from
matrix_keypad_start() and matrix_keypad_stop() uses flush_work() to
make sure currently running instance completes after making sure that
it will not be rescheduled. And matrix_keypad_stop() is guaranteed to
be called by input core when input device is being unregistered if
input device was opened. So in effect we do not actually leak work
past driver remove().

Thanks.

-- 
Dmitry