CVE-2026-80563

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

(trigger_write()) that dereferences the per-device gpio_la_poll_priv. The

file is created with debugfs_create_file_unsafe(), and the handler never

takes a debugfs reference. Nothing keeps the object alive while the

handler runs.

priv is allocated with devm_kzalloc(). devres frees it when the platform

device is unbound. debugfs_create_file_unsafe() installs no full_proxy

wrapper, so debugfs_remove_recursive() in gpio_la_poll_remove() does not

wait for an in-flight trigger_write(). The blob_lock taken there does not

help, because trigger_write() never takes it. A write that races an unbind

therefore writes into freed memory:

trigger_write() gpio_la_poll_remove()

priv = m->private

buf = memdup_user() [may sleep]

mutex_lock(&priv->blob_lock)

debugfs_remove_recursive() [no wait]

mutex_unlock(&priv->blob_lock)

(remove returns; devres frees priv)

priv->trig_data = buf <-- use-after-free write

priv->trig_len = count

The race is reachable by root via

/sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind.

Create "trigger" with debugfs_create_file() instead. Its full_proxy

wrapper makes debugfs_remove_recursive() drain any in-flight ->write

before it returns.

The use-after-free is confirmed under KASAN with a minimal reproducer of

the same debugfs_create_file_unsafe() plus devm_kzalloc() pattern

(available on request); it produces a slab-use-after-free write in the

handler.