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