Re: [PATCH v2] sysfs: return -ENOENT from move/rename when kobj->sd is NULL

[Danilo Krummrich]

On Mon May 4, 2026 at 7:07 AM CEST, Conor Kotwasinski wrote:
> sysfs_move_dir_ns() and sysfs_rename_dir_ns() pass kobj->sd to
> kernfs_rename_ns() unconditionally. If sysfs_remove_dir() has already
> cleared kobj->sd, the NULL flows through and kernfs_rename_ns()
> dereferences it via rcu_access_pointer(kn->__parent), which KASAN
> surfaces as a stack-segment fault on the shadow lookup:
>
>   Oops: stack segment: 0000 [#1] SMP KASAN PTI
>   RIP: 0010:kernfs_rename_ns+0x3a/0x7a0 fs/kernfs/dir.c:1752
>   Call Trace:
>    kobject_move+0x525/0x6e0 lib/kobject.c:569
>    device_move+0xe0/0x730 drivers/base/core.c:4606
>    hci_conn_del_sysfs+0xb8/0x1a0 net/bluetooth/hci_sysfs.c:75
>    hci_conn_cleanup net/bluetooth/hci_conn.c:173 [inline]
>    hci_conn_del+0xc36/0x1240 net/bluetooth/hci_conn.c:1234
>    hci_conn_hash_flush+0x191/0x260 net/bluetooth/hci_conn.c:2638
>    hci_dev_close_sync+0x821/0x1100 net/bluetooth/hci_sync.c:5327
>    hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]
>    hci_unregister_dev+0x21a/0x5b0 net/bluetooth/hci_core.c:2715
>
> syzbot has reported 35 hits with this signature across net, net-next
> and linux-next between July 2025 and January 2026, via both vhci
> release and HCIDEVRESET ioctl.
>
> Return -ENOENT in that case, consistent with sysfs_create_dir_ns().
> The underlying ordering problem in bluetooth -- device_move() called
> after the target's sysfs has been torn down -- is a separate issue.
>
> Reported-by: syzbot+d1db96f72a452dc9cbd2@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://lore.kernel.org/all/687c6966.a70a0220.693ce.00a5.GAE@xxxxxxxxxx/
> Reported-by: syzbot+faeac5b54ba997a96278@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://syzkaller.appspot.com/bug?extid=faeac5b54ba997a96278
> Fixes: 324a56e16e44 ("kernfs: s/sysfs_dirent/kernfs_node/ and rename its friends accordingly")

This is just a rename commit with no functional change, so I think we should
pick the following commit instead:

Fixes: 608e266a2d4e ("sysfs: make kobj point to sysfs_dirent instead of dentry")

However, that commit is quite old, so it raises a bit the question, why does
this pop up now?

Technically, the API contract only talks about callers have to serialize calls,
i.e. your if (!kobj->sd) check should not have any TOCTOU issues, but it does
not talk about ordering.

That said, why does the bluetooth API run into this now?

> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Conor Kotwasinski <conorkotwasinski2024@xxxxxxxxxxxxxxxxxx>

Regardless of the above, the patch seems still fine even if it turns out to be
hardening only.

Reviewed-by: Danilo Krummrich <dakr@xxxxxxxxxx>