[bluez/bluez] ae77eb: adapter/advertising: fix mgmt endian bug

[ni-thib <noreply@github.com>]

  Branch: refs/heads/1156908
  Home:   https://github.com/bluez/bluez
  Commit: ae77ebe6659c0520101792d8961a53cdfa9774cf
      https://github.com/bluez/bluez/commit/ae77ebe6659c0520101792d8961a53cdfa9774cf
  Author: Nicolas Thibert <nithibert@gmail.com>
  Date:   2026-09-03 (Thu, 03 Sep 2026)

  Changed paths:
    M src/adapter.c
    M src/advertising.c

  Log Message:
  -----------
  adapter/advertising: fix mgmt endian bug

Several places in adapter.c and advertising.c write a native-endian
value directly into a __le16/__le32 field of an mgmt command struct,
skipping the cpu_to_le16()/cpu_to_le32() conversion used everywhere
else in this codebase for the same purpose. This is a no-op on
little-endian hosts (where cpu_to_le16()/cpu_to_le32() are themselves
no-ops), which is why it has gone unnoticed, but corrupts the value on
big-endian hosts.

Confirmed live on MIPS big-endian (OpenWrt/ath79): set_blocked_keys()
sends key_count=2 (2 blocked keys), which the kernel's
__le16_to_cpu() correctly interprets as 512 (0x0002 byte-swapped is
0x0200) since the wire bytes were never actually swapped to little-
endian on the way out -- producing "expected 8706 bytes, got 36
bytes" / "Failed to set blocked keys: Invalid Parameters" errors in
dmesg/bluetoothd logs.

add_advertising()'s cp->duration and refresh_extended_adv()'s
cp.duration/cp.min_interval/cp.max_interval have the identical bug. It
is inert with bluetoothctl's default (0) duration/interval values (0
byte-swapped is still 0), but A/B tested live (patch removed vs.
applied, bluetoothctl's advertise submenu "interval 100 100" set
explicitly) confirms this is not just a theoretical correctness fix:
with the bug present, the device stops being discoverable by a real
BLE scanner the moment a non-default interval is requested, and
becomes discoverable again immediately once patched. Any application
that sets an explicit advertising interval or duration hits this.

v2: use cpu_to_le16()/cpu_to_le32() instead of htobs()/htobl(), as
requested by Luiz. Retested live on the same MIPS big-endian board
(blocked keys + explicit advertising interval): behaves identically
to the v1 fix, no regressions.



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