[lkml]   [2019]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC v1 0/3] Address potential user-after-free on module unload
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.

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(-)


 \ /
  Last update: 2019-02-04 23:10    [W:0.213 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site