From: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
To: linux-bluetooth@vger.kernel.org
Cc: luiz.dentz@gmail.com, quic_mohamull@quicinc.com,
quic_hbandi@quicinc.com, quic_anubhavg@quicinc.com,
Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Subject: [PATCH BlueZ v1 1/2] client: avoid registering ranging objects as direct children of "/"
Date: Thu, 3 Sep 2026 15:46:34 +0530 [thread overview]
Message-ID: <20260903101635.3370149-2-naga.akella@oss.qualcomm.com> (raw)
In-Reply-To: <20260903101635.3370149-1-naga.akella@oss.qualcomm.com>
With the default provider path "/", cs_ranging_obj_create() exported
each device's RangingProvider1 object as a direct child of root. That
triggers a NULL-dereference bug in gdbus/object.c's
invalidate_parent_data(), crashing bluetoothctl with SIGSEGV on the
first ChannelSounding1.ProcedureData signal.
Fix by nesting under RANGING_PROVIDER_PATH that is
never independently registered, so the leaf's immediate parent isn't
root. src/ranging.c's provider watch matches any descendant of the
registered root, so discovery is unaffected.
---
client/cs.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/client/cs.c b/client/cs.c
index be546cc20..7533d053b 100644
--- a/client/cs.c
+++ b/client/cs.c
@@ -357,12 +357,23 @@ static struct cs_session *cs_find_session(GDBusProxy *proxy)
* main()); bluetoothd's RegisterRangingProvider watches the exact path it
* is given via GetManagedObjects()/InterfacesAdded, so any other path would
* silently never be discovered.
+ *
+ * Exported RangingProvider1 objects are nested under RANGING_PROVIDER_PATH
+ * rather than directly under "/" (see cs_ranging_obj_create()), to avoid a
+ * gdbus/object.c bug hit when linking a brand-new direct child of a path
+ * that already has an ObjectManager attached.
*/
#define RANGING_PROVIDER_INTERFACE "org.bluez.RangingProvider1"
#define CS_PROCEDURE_DATA_INTERFACE "org.bluez.ChannelSounding1"
#define DEFAULT_PROVIDER_PATH "/"
+/* Prefix used for exported RangingProvider1 objects when the registered
+ * provider root is "/" (see cs_ranging_obj_create()); matches the object
+ * path test/example-ranging-provider uses for the same purpose.
+ */
+#define RANGING_PROVIDER_PATH "/org/example/ranging"
+
struct cs_ranging_obj {
char *path; /* exported RangingProvider object path */
char *dev_path; /* Device this estimate applies to */
@@ -479,8 +490,20 @@ static struct cs_ranging_obj *cs_ranging_obj_create(const char *dev_path)
obj = g_new0(struct cs_ranging_obj, 1);
obj->dev_path = g_strdup(dev_path);
+ /* Never export a RangingProvider1 object as a direct child of "/":
+ * bluetoothctl attaches its ObjectManager there, so "/" already has
+ * registered gdbus object data, and gdbus/object.c's
+ * invalidate_parent_data() dereferences a NULL "grandparent" when
+ * asked to link a brand-new top-level child in that state. Nesting
+ * under RANGING_PROVIDER_PATH instead keeps the immediate parent
+ * unregistered, so gdbus skips the ancestor walk instead of
+ * crashing. bluetoothd's provider watch matches any descendant of
+ * the given root (see path_has_root() in src/ranging.c), so the
+ * extra path component doesn't affect discovery.
+ */
if (!strcmp(cs_provider_path, "/"))
- obj->path = g_strdup_printf("/%s", leaf);
+ obj->path = g_strdup_printf("%s/%s", RANGING_PROVIDER_PATH,
+ leaf);
else
obj->path = g_strdup_printf("%s/%s", cs_provider_path, leaf);
@@ -1537,6 +1560,9 @@ static const struct bt_shell_menu cs_menu = {
"\t\t\t\t\t\t[path] is the provider root object"
" path; default \"/\", the only path"
" bluetoothctl exposes an ObjectManager at.\n"
+ "\t\t\t\t\t\texported RangingProvider1 objects are"
+ " nested under /org/example/ranging rather"
+ " than directly under \"/\".\n"
"\t\t\t\t\t\tsee test/example-ranging-provider for a"
" minimal standalone provider skeleton.\n\t\t\t\t\t\tOnly one"
" provider may be registered per adapter at"
--
next prev parent reply other threads:[~2026-09-03 10:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 10:16 [PATCH BlueZ v1 0/2] client/cs: fix crash in reference ranging provider Naga Bhavani Akella
2026-09-03 10:16 ` Naga Bhavani Akella [this message]
2026-09-03 12:07 ` bluez.test.bot
2026-09-03 10:16 ` [PATCH BlueZ v1 2/2] doc: note RangingProvider1 objects are nested in bluetoothctl-cs Naga Bhavani Akella
2026-09-08 19:20 ` [PATCH BlueZ v1 0/2] client/cs: fix crash in reference ranging provider patchwork-bot+bluetooth
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=20260903101635.3370149-2-naga.akella@oss.qualcomm.com \
--to=naga.akella@oss.qualcomm.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=quic_anubhavg@quicinc.com \
--cc=quic_hbandi@quicinc.com \
--cc=quic_mohamull@quicinc.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.