From: "Danilo Krummrich" <dakr@kernel.org>
To: "Conor Kotwasinski" <conorkotwasinski2024@u.northwestern.edu>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
<driver-core@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<linux-bluetooth@vger.kernel.org>,
<syzbot+d1db96f72a452dc9cbd2@syzkaller.appspotmail.com>,
<syzbot+faeac5b54ba997a96278@syzkaller.appspotmail.com>
Subject: Re: [PATCH v2] sysfs: return -ENOENT from move/rename when kobj->sd is NULL
Date: Mon, 04 May 2026 22:55:42 +0200 [thread overview]
Message-ID: <DIA6XD2G5094.1FA2NH60YN1C0@kernel.org> (raw)
In-Reply-To: <20260504050736.17672-1-conorkotwasinski2024@u.northwestern.edu>
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@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/687c6966.a70a0220.693ce.00a5.GAE@google.com/
> Reported-by: syzbot+faeac5b54ba997a96278@syzkaller.appspotmail.com
> 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@vger.kernel.org
> Signed-off-by: Conor Kotwasinski <conorkotwasinski2024@u.northwestern.edu>
Regardless of the above, the patch seems still fine even if it turns out to be
hardening only.
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
prev parent reply other threads:[~2026-05-04 20:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 15:06 [PATCH] sysfs: return -ENOENT from move/rename when kobj->sd is NULL Conor Kotwasinski
2026-04-28 22:31 ` Danilo Krummrich
2026-05-04 5:07 ` [PATCH v2] " Conor Kotwasinski
2026-05-04 6:22 ` Greg Kroah-Hartman
2026-05-04 20:55 ` Danilo Krummrich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DIA6XD2G5094.1FA2NH60YN1C0@kernel.org \
--to=dakr@kernel.org \
--cc=conorkotwasinski2024@u.northwestern.edu \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=syzbot+d1db96f72a452dc9cbd2@syzkaller.appspotmail.com \
--cc=syzbot+faeac5b54ba997a96278@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox