180cf09933 changed the default to true
if the config file did not set it, but it still remained false if
the config file did not exist at all. This change fixes that.
Fixes: https://github.com/bluez/bluez/issues/886
btd_adapter_get_device() may return NULL on the next call stack:
btd_adapter_get_device()
adapter_create_device()
device_create()
device_new()
g_try_malloc0()
It is necessary to prevent this to avoid dereferencing a null
pointer further.
This commit fixes the heap-use-after-free error when connecting 2
controllers. When a controller is connected
admin_policy_adapter_probe is called. If policy_data was already
allocated it gets freed, if not, it only gets allocated. Eventually
add_interface is called. Here policy_data is put in the "data" variable
(specific for each controller) and the process_changes task is called
with idle priority. This function ultimately accesses policy_data from
the "data" variable.
When Bluez crashes the flow is:
1)first controller is attached
2)admin_policy_adapter_probe is called and policy_data is allocated
4)second controller is attached
5)admin_policy_adapter_probe is called and policy_data is freed, then
allocated again
6)process_changes runs and the policy_data for the first controller is
read, but it was already freed, thus the crash
After pretty hostname, and static hostname, also support transient
hostname as a last resort before 'BlueZ X.XX'.
This happens on Fedora's Workstation installation as it calls
"hostnamectl set-hostname" on startup. In Fedora Silverblue, the default
hostname is set as fedora in /etc/os-release.
In both cases, we should fall back to that transient hostname, as bad as
it could be.
Note that the transient hostname needs to be monitored through the
kernel directly, as explained in:
https://www.freedesktop.org/software/systemd/man/org.freedesktop.hostname1.html
device.trusted is a user preference which controls if the devices needs
to be authorized or not so the plugin shall not overwrite it and instead
just honor what user has set and skip authorizing if already trusted.
Fixes: https://github.com/bluez/bluez/issues/372
While performing static tool analysis using coverity
found following reports for resouse leak
bluez-5.64/plugins/sixaxis.c:425: alloc_arg:
"get_pairing_type_for_device" allocates memory that is
stored into "sysfs_path".
bluez-5.64/plugins/sixaxis.c:428: leaked_storage: Variable "sysfs_path"
going out of scope leaks the storage it points to.
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.
