Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190204220952.30761-1-TheSven73@googlemail.com>
In-Reply-To: <20190204220952.30761-1-TheSven73@googlemail.com>
From:   Kees Cook <keescook@chromium.org>
Date:   Tue, 5 Feb 2019 14:57:11 +0000
Message-ID: <CAGXu5jJ0g1FUd3mX=RkJCN=BazaWWybAuapvjngpLcWtz3FQGw@mail.gmail.com>
Subject: Re: [RFC v1 0/3] Address potential user-after-free on module unload
To:     Sven Van Asbroeck <thesven73@gmail.com>
Cc:     Tejun Heo <tj@kernel.org>, Lai Jiangshan <jiangshanlai@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Sebastian Reichel <sre@kernel.org>,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Greg KH <gregkh@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Feb 4, 2019 at 10:09 PM Sven Van Asbroeck <thesven73@gmail.com> wrote:
>
> I think there _might_ be potential use-after-free issues on module unload.
>
> They are hard to trigger, but I think I've seen them bring the whole
> kernel down when they do occur. Can be triggered by doing an insmod of
> a vulnerable module, rapidly followed by an rmmod.
>
> Caused by drivers which schedule work / delayed_work, but do not clean it up
> properly on module unload. Which means the work function could run _after_
> the module has unloaded.
>
> A quick grep through the kernel sources brings up many instances.
> I leave it to people more knowledgeable than me to determine if this problem
> is likely to happen, and/or if it can be exploited to become a security risk.
>
> Perhaps developers can be 'nudged' into doing the right thing by using
> resource-managed versions of INIT_WORK() / INIT_DELAYED_WORK(), which may
> address the issue quite elegantly.

Can a Coccinelle script get written to find module-use of the non-devm
work init?

It seems like finding these in __init functions should be relatively
easy? (Or can we add runtime detection in the existing INIT_*WORK()
code to see if it is running from the wrong place?)

-Kees

>
> Attached is a proposal patch, followed by sample fixes for two vulnerable
> modules. As far as I can tell, many more modules are vulnerable.
>
> Sven Van Asbroeck (3):
>   workqueue: Add resource-managed version of INIT_[DELAYED_]WORK()
>   max17042_battery: fix potential user-after-free on module unload
>   cap11xx: fix potential user-after-free on module unload
>
>  drivers/input/keyboard/cap11xx.c        |  6 ++-
>  drivers/power/supply/max17042_battery.c |  5 ++-
>  include/linux/workqueue.h               |  7 ++++
>  kernel/workqueue.c                      | 54 +++++++++++++++++++++++++
>  4 files changed, 70 insertions(+), 2 deletions(-)
>
> --
> 2.17.1
>


-- 
Kees Cook