public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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>

      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