On Wed, 8 Apr 2026 at 17:23, Alberto Ruiz via B4 Relay <[email protected]> wrote: > > From: Alberto Ruiz <[email protected]> > > If device_add() succeeds during CUSE initialization but a subsequent > step (cdev_alloc() or cdev_add()) fails, the error path calls > put_device() without first calling device_del(). This leaks the > devtmpfs entry created by device_add(), leaving a stale /dev/<name> > node that persists until reboot. > > Since the cuse_conn is never linked into cuse_conntbl on the failure > path, cuse_channel_release() sees cc->dev == NULL and skips > device_unregister(), so no other code path cleans up the node. > > This has several consequences: > > - The device name is permanently poisoned: any subsequent attempt to > create a CUSE device with the same name hits the stale sysfs entry, > device_add() fails, and the new device is aborted. > > - The collision manifests as ENODEV returned to userspace with no > dmesg diagnostic, making it very difficult to debug. > > - The failure is self-perpetuating: once a name is leaked, all future > attempts with that name fail identically. > > Fix this by introducing an err_dev label that calls device_del() to > undo device_add() before falling through to err_unlock. The existing > err_unlock path from a device_add() failure correctly skips device_del() > since the device was never added. > > Signed-off-by: Alberto Ruiz <[email protected]>
Applied, thanks. Miklos
