On Mon, Feb 4, 2019 at 10:09 PM Sven Van Asbroeck <thesve...@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
