CVE-2026-80563: gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind
In the Linux kernel, the following vulnerability has been resolved:
gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind
The "trigger" debugfs file has a hand-rolled ->write handler (triggerwrite()) that dereferences the per-device gpiolapollpriv. The file is created with debugfscreatefileunsafe(), and the handler never takes a debugfs reference. Nothing keeps the object alive while the handler runs.
priv is allocated with devmkzalloc(). devres frees it when the platform device is unbound. debugfscreatefileunsafe() installs no fullproxy wrapper, so debugfsremoverecursive() in gpiolapollremove() does not wait for an in-flight triggerwrite(). The bloblock taken there does not help, because triggerwrite() never takes it. A write that races an unbind therefore writes into freed memory:
triggerwrite() gpiolapollremove() priv = m->private buf = memdupuser() [may sleep] mutexlock(&priv->bloblock) debugfsremoverecursive() [no wait] mutexunlock(&priv->bloblock) (remove returns; devres frees priv) priv->trigdata = buf <-- use-after-free write priv->triglen = count
The race is reachable by root via /sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind.
Create "trigger" with debugfscreatefile() instead. Its fullproxy wrapper makes debugfsremoverecursive() drain any in-flight ->write before it returns.
The use-after-free is confirmed under KASAN with a minimal reproducer of the same debugfscreatefileunsafe() plus devmkzalloc() pattern (available on request); it produces a slab-use-after-free write in the handler.
Affected Software
Event History
Frequently Asked Questions
Who can trigger this issue?
The race is reachable by root, which must be able to write to the driver's debugfs trigger file while the associated platform device is being unbound.
What conditions are required for exploitation?
An in-flight trigger_write() operation must race with device unbind and removal of the debugfs entries. The write handler can sleep after copying user data, allowing removal to complete and devres to free the per-device allocation before the handler updates it.
Does the debugfs removal path prevent the race?
No. The trigger file is created with debugfs_create_file_unsafe(), so debugfs_remove_recursive() does not wait for an in-flight write handler, and the handler does not take the blob_lock used during removal.