Linux bluetooth development
 help / color / mirror / Atom feed
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"
-- 


  reply	other threads:[~2026-09-03 10:16 UTC|newest]

Thread overview: 4+ 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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox