In cuse_process_init_reply(), if device_add() succeeds but cdev_alloc() or cdev_add() fails, the error path calls put_device() without first calling device_del(). This leaves a stale /dev node that permanently poisons the device name -- any subsequent attempt to create a CUSE device with the same name silently fails with ENODEV.
The fix is a 3-line change: redirect the cdev_alloc() failure to a new err_dev label that calls device_del() before falling through to err_unlock. Patch 2 adds a kselftest that reproduces the bug by forcing cdev_alloc() to fail after device_add() has succeeded, then verifying that no /dev node is leaked. To trigger the failure deterministically, a CONFIG_FAULT_INJECTION-guarded module parameter (cuse_inject_cdev_failure) is added to cuse.c. The test falls back to failslab with stack-trace filtering when the parameter is unavailable. I'm on the fence about the fault injection parameter in patch 2 -- it's only a few lines and it's guarded behind CONFIG_FAULT_INJECTION, but I understand if it feels too intrusive for production code. Happy to drop the kselftest or rework the injection approach if the maintainers prefer. The fix in patch 1 stands on its own regardless. Signed-off-by: Alberto Ruiz <[email protected]> --- Alberto Ruiz (2): fuse: fix device node leak in cuse_process_init_reply() selftests: add CUSE device-node leak regression test fs/fuse/cuse.c | 17 +- tools/testing/selftests/Makefile | 1 + tools/testing/selftests/filesystems/cuse/Makefile | 7 + tools/testing/selftests/filesystems/cuse/config | 5 + .../selftests/filesystems/cuse/cuse_leak_test.c | 406 +++++++++++++++++++++ 5 files changed, 435 insertions(+), 1 deletion(-) --- base-commit: 631919fb12fe7b1f0453fe1035e62ce704bc3923 change-id: 20260408-wip-cuse-leak-fix-e84494706d8e Best regards, -- Alberto Ruiz <[email protected]>
