[bluez/bluez] f50d29: client: avoid registering ranging objects as direc...

[bluez/bluez] f50d29: client: avoid registering ranging objects as direc...

[Bhavani]

  Branch: refs/heads/1156962
  Home:   https://github.com/bluez/bluez
  Commit: f50d29a37ce1978ecbab9b3c0358c8507b41cca9
      https://github.com/bluez/bluez/commit/f50d29a37ce1978ecbab9b3c0358c8507b41cca9
  Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
  Date:   2026-09-03 (Thu, 03 Sep 2026)

  Changed paths:
    M client/cs.c

  Log Message:
  -----------
  client: avoid registering ranging objects as direct children of "/"

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.


  Commit: 017011766f798aa7c4ea01c50ac0f10e7924afcd
      https://github.com/bluez/bluez/commit/017011766f798aa7c4ea01c50ac0f10e7924afcd
  Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
  Date:   2026-09-03 (Thu, 03 Sep 2026)

  Changed paths:
    M doc/bluetoothctl-cs.rst

  Log Message:
  -----------
  doc: note RangingProvider1 objects are nested in bluetoothctl-cs

register_provider's exported RangingProvider1 objects live under
/org/example/ranging rather than directly under "/", to avoid a
gdbus/object.c bug when linking new top-level children of a path
that already has an ObjectManager attached. Document that alongside
the existing default-path note.


Compare: https://github.com/bluez/bluez/compare/f50d29a37ce1%5E...017011766f79

To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications