This replaces the uses of g_memdup with util_memdup since the former has
been deprecated:
warning: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead
[-Wdeprecated-declarations]
g_memdup2 requires bumping glib version which would likely have its
own problems thus why util_memdup was introduced.
This patch replaces the rand() function to the getrandom() syscall.
It was reported by the Coverity scan
rand() should not be used for security-related applications, because
linear congruential algorithms are too easy to break
When |admin_policy_remove| is called, we set |devices| to NULL but never
set it back until |admin_init|. This makes admin lost track of current
registered device interface, so the next |admin_policy_removed| will not
be able to unregister those interfaces.
Reviewed-by: Archie Pusaka <apusaka@chromium.org>
BT core spec 5.3 promotes the usage of inclusive languages.
This CL uses "central" as it is deemed to be more appropriate.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Fixes the following double free which happen due to exit calling
btd_unregister_adapter_driver:
Invalid read of size 8
at 0x1CDA97: queue_foreach (queue.c:198)
by 0x1318B8: admin_policy_remove (admin.c:591)
by 0x18982A: plugin_cleanup (plugin.c:217)
by 0x12E3FD: main (main.c:1214)
Address 0x547ffb8 is 8 bytes inside a block of size 32 free'd
at 0x483A9F5: free (vg_replace_malloc.c:538)
by 0x1318CB: admin_policy_remove (admin.c:592)
by 0x18F416: unload_driver (adapter.c:7215)
by 0x496F50F: g_slist_foreach (in /usr/lib64/libglib-2.0.so.0.6600.8)
by 0x131988: admin_exit (admin.c:623)
by 0x18982A: plugin_cleanup (plugin.c:217)
by 0x12E3FD: main (main.c:1214)
Block was alloc'd at
at 0x4839809: malloc (vg_replace_malloc.c:307)
by 0x1CDE1E: btd_malloc (util.c:33)
by 0x1CD83D: queue_new (queue.c:47)
by 0x13150D: admin_init (admin.c:614)
by 0x18966B: plugin_init (plugin.c:187)
by 0x12E358: main (main.c:1198)
This fixes the following trace:
8 bytes in 1 blocks are definitely lost in loss record 27 of 274
at 0x4839809: malloc (vg_replace_malloc.c:307)
by 0x495BBB8: g_malloc (in /usr/lib64/libglib-2.0.so.0.6600.8)
by 0x494C024: g_key_file_get_string_list (in /usr/lib64/libglib-2.0.so.0.6600.8)
by 0x131ECD: key_file_load_service_allowlist (admin.c:294)
by 0x131ECD: load_policy_settings (admin.c:346)
by 0x131ECD: admin_policy_adapter_probe (admin.c:497)
by 0x18F554: probe_driver (adapter.c:4858)
by 0x19DF5A: load_drivers (adapter.c:4873)
by 0x19DF5A: adapter_register (adapter.c:8975)
by 0x19DF5A: read_info_complete (adapter.c:9791)
by 0x1CE831: request_complete (mgmt.c:264)
by 0x1CF7D4: can_read_data (mgmt.c:356)
by 0x1DE634: watch_callback (io-glib.c:157)
by 0x4953A9E: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6600.8)
by 0x49A5A97: ??? (in /usr/lib64/libglib-2.0.so.0.6600.8)
by 0x4953162: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.6600.8)
Instead of using BTD_SERVICE_STATE_CONNECTING use
btd_service_is_initiator to determine if the service initiated the
connection and then proceed to connect other service immediately.
Fixes: https://github.com/bluez/bluez/issues/205
If admin_policy_settings is not found when loading, we should create one
instead of printing error.
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
Currently admin doesn't handle adapter removed callbacks, which causes
interfaces AdminPolicySet1 and AdminPolicyStatus1 not being
unregistered, which in turns causes these interfaces can not be
re-registered once adapter is back.
This adds handler for adapter_remove.
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
This patch fixes a bug when setting empty service allowlist, the
allowlist sets successfully but it fails to be stored in the file.
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
This adds code to store the ServiceAllowlist to file
/var/lib/bluetooth/{MAC_ADDR}/admin_policy
The stored settings will be loaded upon admin_policy initialized.
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
This adds callbacks for device resolved and device removed. It is
necessary for implementation of "AffectedByPolicy" property since it
needs to register an interface for each device object and unregister it
once the device gets removed.
This adds code to register interface org.bluez.AdminPolicyStatus.
The interface will provide read-only properties to indicate the current
settings of admin policies. We separate this from AdminPolicySet so that
normal clients can check current policy settings while only a few
clients can change policies.
This patch also adds readonly property ServiceAllowlist to
AdminPolicyStatus1, which indicates the current setting of service
allowlist.
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
This adds code to register interface org.bluez.AdminPolicySet1.
The interface will provide methods to limit users to operate certain
functions of bluez, such as allow/disallow user to taggle adapter power,
or only allow users to connect services in the specified list, etc.
This patch also implements ServiceAllowlist in
org.bluez.AdminPolicySet1.
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
This adds code to register admin_policy driver to adapter when
admin plugin is enabled.
The following test steps were performed:
1. restart bluetoothd
2. check if "Admin Policy is enabled" in system log
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
When cable pairing a PS3 clone device, we should try and keep the USB device
name to create a new btd_device so that the joypad is named after its USB name
when connecting through Bluetooth.
If that isn't done, "Shanwan" clone joypads are named like the genuine joypads, and
kernel Bluetooth quirks aren't applied.
gh-issue: https://github.com/bluez/bluez/issues/46
During system suspend, all peer devices are disconnected. On resume, HID
devices will reconnect but audio devices stay disconnected. As a quality
of life improvement, mark audio devices that were disconnected due to
suspend and attempt to reconnect them when the controller resumes (after
a delay for better co-existence with Wi-Fi).
With clang, comparing an array with NULL generates a warning because the
value is always non-NULL. With maintainer mode enabled, this becomes a
compilation error.
If the device went through any kind of pairing once, it might have been
set as trusted. Make sure to set the device as untrusted before starting
the cable pairing authorization so that we don't exit early from
process_auth_queue() (which considers trusted devices to be paired).
PIN codes "1111", and "1234" are fairly common PIN codes used for audio
devices such as speakers and headsets. This replaces similar quirks
already present in gnome-bluetooth's PIN database.
1. Setup PS3 controller through cable pairing
2. Remove device from BlueZ's database
3. Plug original PS3 controller back
As we don't change the master bdaddr on the device itself, the joypad
will likely be trying to connect to BlueZ, and fail to connect after a
small period of time. But the device will appear connected just long
enough for the cable pairing to say "hey, I already have this setup".
Ideally, we would test for whether the device is temporary, or already
trusted, but testing for whether we've setup its internal services *and*
it's connected, rather than *or*, is sufficient.
This allows to skip SDP search for DualShock 3 devices, since some
DS3 clones do not provide any SDP record. This allows them to operate
nonetheless.
The HID SDP record is lifted straight off an original DualShock 3
controller. The PNPID SDP record is not set as not required to provide
a working device.
Tested with a "SHANWAN" clone controller.
This fixes the following problems:
plugins/sixaxis.c:443:7: error: ‘version’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!setup_device(fd, sysfs_path, name, source, vid, pid, version, type, adapter))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
plugins/sixaxis.c:409:34: note: ‘version’ was declared here
uint16_t bus, vid, pid, source, version;
^~~~~~~
plugins/sixaxis.c:443:7: error: ‘source’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!setup_device(fd, sysfs_path, name, source, vid, pid, version, type, adapter))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
plugins/sixaxis.c:409:26: note: ‘source’ was declared here
uint16_t bus, vid, pid, source, version;
^~~~~~
cc1: all warnings being treated as errors
And many instances of code going over 80 columns.
This patch adds support for "pairing" a Dualshock4 controller over USB
into the sixaxis plugin, similarly to what the Sixaxis/PS3 controller
supported.
Actual bonding happens on first connection, but the device will be
marked as trusted when the agent replies.
This patch is based on DS4 supprt for sixpair tool by t0xicCode:
975c38cb6c
Move the struct containing the Sixaxis-compatible devices to a
header shared with the input profiles code, so as to reduce device
declaration.
Adding support for new devices should be as easy as adding the device's
declaration in profiles/input/sixaxis.h
Previously, users doing cable configuration of Sixaxis PS3 controllers
would only get asked whether a device was allowed to connect to the
computer when switching it to Bluetooth mode: unplugging it, and
pressing the PS button.
Instead, we should ask the user straight away, through the agent,
whether the pad should be allowed to connect.
This makes it easier to setup those devices, while keeping security.
We can't easily enter digits other than 1 through 4 (inclusive)
so leave it up to the agent to figure out a good passcode
for the iCade.
Note that we can not use the VID/PID of the device, as it is not
yet known at that point.
Some games check the device name to recognize a playstation controller.
This changes the device name, when using a PS3 controller over
bluetooth, to match the device name, that is advertised when using the
controller via USB.
There are two problems:
- When main.conf is not found, bluetoothd copies short the default set
of reconnecting intervals to reconnect_interval. It does not match
the reconnct_interval_len used as the array length.
So if a link of device is disconnected, bluetoothd is run over
reconnect_interval as time proceeds and will not time out as expected.
bluetooothd with --debug option outputed the following log in my box:
plugins/policy.c:reconnect_set_timer() attempt 1/7 1 seconds
plugins/policy.c:reconnect_timeout() Reconnecting profiles
plugins/policy.c:conn_fail_cb() status 4
plugins/policy.c:reconnect_set_timer() attempt 2/7 2 seconds
plugins/policy.c:reconnect_timeout() Reconnecting profiles
plugins/policy.c:conn_fail_cb() status 4
plugins/policy.c:reconnect_set_timer() attempt 3/7 0 seconds
plugins/policy.c:reconnect_timeout() Reconnecting profiles
plugins/policy.c:conn_fail_cb() status 4
plugins/policy.c:reconnect_set_timer() attempt 4/7 0 seconds
- When ReconnectIntervals in main.conf includes invalid characters,
reconnct_interval_len value is bigger than the default array length.
So if ReconnectAttempts value in main.conf is bigger than
reconnct_interval_len value and a link of device is disconnected,
bluetoothd is run over reconnect_interval as time proceeds and will
not time out as expected.
bluetooothd with --debug option outputed the following log in my box,
if ReconnectAttempts value was 28 and ReconnectIntervals was inproper:
...
plugins/policy.c:reconnect_set_timer() attempt 6/28 32 seconds
plugins/policy.c:reconnect_timeout() Reconnecting profiles
plugins/policy.c:conn_fail_cb() status 4
plugins/policy.c:reconnect_set_timer() attempt 7/28 64 seconds
plugins/policy.c:reconnect_timeout() Reconnecting profiles
plugins/policy.c:conn_fail_cb() status 4
plugins/policy.c:reconnect_set_timer() attempt 8/28 0 seconds
...
plugins/policy.c:reconnect_set_timer() attempt 25/28 1 seconds
plugins/policy.c:reconnect_timeout() Reconnecting profiles
plugins/policy.c:conn_fail_cb() status 4
plugins/policy.c:reconnect_set_timer() attempt 26/28 3 seconds
plugins/policy.c:reconnect_timeout() Reconnecting profiles
plugins/policy.c:conn_fail_cb() status 4
plugins/policy.c:reconnect_set_timer() attempt 27/28 110683472 seconds
This fix properly uses the default set of reconnecting intervals.
