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: 7+ 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-16 16:39 ` bluez.test.bot
2026-04-28 22:31 ` [PATCH] " Danilo Krummrich
2026-05-04 5:07 ` [PATCH v2] " Conor Kotwasinski
2026-05-04 6:22 ` Greg Kroah-Hartman
2026-05-04 7:29 ` [v2] " bluez.test.bot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.