* Re: [PATCH BlueZ v1] hciemu: Fix crash if hciemu_client_new return NULL
From: patchwork-bot+bluetooth @ 2026-05-06 13:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260505201548.1328953-1-luiz.dentz@gmail.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 5 May 2026 16:15:48 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> The following crahs can be observed if hciemu_client_new fails:
>
> Invalid read of size 8
> at 0x12DA79: queue_get_entries (queue.c:356)
> by 0x118434: hciemu_get_client (hciemu.c:277)
> by 0x1184A3: hciemu_client_get_host (hciemu.c:301)
> by 0x11536B: setup_powered_common (l2cap-tester.c:1452)
> by 0x11568E: setup_powered_client (l2cap-tester.c:1491)
> by 0x1324C6: setup_callback (tester.c:500)
> by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
> by 0x48A33FF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
> by 0x48A36F2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
> by 0x133868: mainloop_run (mainloop-glib.c:65)
> by 0x133C9F: mainloop_run_with_signal (mainloop-notify.c:196)
> by 0x13325F: tester_run (tester.c:1085)
> Address 0x4c1e388 is 8 bytes inside a block of size 32 free'd
> at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
> by 0x1187BF: hciemu_new_num (hciemu.c:437)
>
> [...]
Here is the summary with links:
- [BlueZ,v1] hciemu: Fix crash if hciemu_client_new return NULL
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=6aa7f5b4e022
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ v1 1/2] monitor: Add features bits defined in 6.2
From: patchwork-bot+bluetooth @ 2026-05-06 13:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260504211303.1081876-1-luiz.dentz@gmail.com>
Hello:
This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 4 May 2026 17:13:01 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> This adds features bits defined as per core spec 6.2:
> https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/low-energy-controller/link-layer-specification.html#UUID-56ada5ed-4ae3-acee-198f-27ead57d86f1
> ---
> monitor/packet.c | 7 +++++++
> 1 file changed, 7 insertions(+)
Here is the summary with links:
- [BlueZ,v1,1/2] monitor: Add features bits defined in 6.2
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=fda84f7004fa
- [BlueZ,v1,2/2] monitor: Add decoding for Short Connection Interval feature
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=79cfd07224ff
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ v1 1/4] shared/hci: Add BPF filter for registered events
From: patchwork-bot+bluetooth @ 2026-05-06 13:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260501143847.724150-1-luiz.dentz@gmail.com>
Hello:
This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Fri, 1 May 2026 10:38:44 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> Implement a BPF socket filter in bt_hci_register/bt_hci_unregister that
> uses setsockopt(SO_ATTACH_FILTER) to only accept HCI events that have
> been registered, plus BT_HCI_EVT_CMD_COMPLETE and BT_HCI_EVT_CMD_STATUS
> which are always needed for command response processing.
>
> [...]
Here is the summary with links:
- [BlueZ,v1,1/4] shared/hci: Add BPF filter for registered events
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=ccc22a919388
- [BlueZ,v1,2/4] shared/hci: Add bt_hci_register_subevent for LE Meta events
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=98f7190cf6b9
- [BlueZ,v1,3/4] ranging/rap_hci: Use bt_hci_register_subevent for LE CS events
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=45e1e7ca2243
- [BlueZ,v1,4/4] hci-tester: Use bt_hci_register_subevent for LE Meta events
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=3502f9f51704
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ v1 1/4] emulator/vhci: Add debug messages to error paths
From: patchwork-bot+bluetooth @ 2026-05-06 13:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260505204719.1348473-1-luiz.dentz@gmail.com>
Hello:
This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 5 May 2026 16:47:16 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> Add debug_callback, debug_destroy and debug_data fields to struct vhci
> so vhci_set_debug stores the callback locally in addition to passing it
> to btdev. Introduce a variadic vhci_debug() helper using util_debug_va
> and add debug messages to the following error paths:
>
> [...]
Here is the summary with links:
- [BlueZ,v1,1/4] emulator/vhci: Add debug messages to error paths
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=d0d42d034f9f
- [BlueZ,v1,2/4] emulator/hciemu: Add debug messages to error paths
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=d4c965eec4d3
- [BlueZ,v1,3/4] tools/gap-tester: Enable hciemu debug output
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=164941a6c145
- [BlueZ,v1,4/4] tools/userchan-tester: Enable hciemu debug output
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=e51115ccd4df
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: fix UAF read of ->accept_q in bt_accept_poll()
From: Jann Horn @ 2026-05-06 12:04 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, stable
In-Reply-To: <CABBYNZLzyh7a7sZ+0U4DAq8TB6e6=WdNrfKrxGXMqnYAMT0KnA@mail.gmail.com>
On Tue, May 5, 2026 at 5:06 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> On Mon, May 4, 2026 at 11:11 AM Jann Horn <jannh@google.com> wrote:
> >
> > Use lock_sock() to guard against bt_accept_poll() racing with concurrent
> > close(accept()), which can lead to UAF:
> >
> > task 1 task 2
> > ====== ======
> > __x64_sys_poll
> > __se_sys_poll
> > __do_sys_poll
> > do_sys_poll
> > do_poll
> > do_pollfd
> > vfs_poll
> > sock_poll
> > bt_sock_poll
> > bt_accept_poll
> > [read ->accept_q next pointer]
> > __x64_sys_accept
> > __se_sys_accept
> > __do_sys_accept
> > __sys_accept4
> > __sys_accept4_file
> > do_accept
> > l2cap_sock_accept
> > bt_accept_dequeue
> > bt_accept_unlink
> > [removes new socket from ->accept_q]
> > __x64_sys_close
> > __se_sys_close
> > __do_sys_close
> > fput_close_sync
> > __fput
> > sock_close
> > __sock_release
> > l2cap_sock_release
> > l2cap_sock_kill
> > sock_put
> > sk_free
> > __sk_free
> > sk_destruct
> > __sk_destruct
> > [frees new socket]
> > [UAF read of ->sk_state]
> >
> > This UAF only leads to incorrect reads, it does not corrupt memory; it is a
> > fairly tight race window; I believe every race attempt requires an
> > incoming bluetooth connection; and the leaked data is limited.
> >
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Jann Horn <jannh@google.com>
> > ---
> > net/bluetooth/af_bluetooth.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
> > index 33d053d63407..d24897167838 100644
> > --- a/net/bluetooth/af_bluetooth.c
> > +++ b/net/bluetooth/af_bluetooth.c
> > @@ -521,13 +521,17 @@ static inline __poll_t bt_accept_poll(struct sock *parent)
> > struct bt_sock *s, *n;
> > struct sock *sk;
> >
> > + lock_sock(parent);
> > list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
> > sk = (struct sock *)s;
> > if (sk->sk_state == BT_CONNECTED ||
> > (test_bit(BT_SK_DEFER_SETUP, &bt_sk(parent)->flags) &&
> > - sk->sk_state == BT_CONNECT2))
> > + sk->sk_state == BT_CONNECT2)) {
> > + release_sock(parent);
> > return EPOLLIN | EPOLLRDNORM;
> > + }
> > }
> > + release_sock(parent);
>
> There is the following comments though:
>
> https://sashiko.dev/#/patchset/20260504-bluetooth-accept-uaf-fix-v1-1-1ca63c0efadd%40google.com
Regarding the LLM output on whether lock_sock(parent) is enough: The
locking I'm adding here is the same as what bt_accept_dequeue() uses
for protection; if event handling can also remove accept_q elements
without holding appropriate locks, I think that is a separate (and
bigger) bug.
I see I've just been CC'ed on
<https://lore.kernel.org/all/20260506114338.2873496-1-n05ec@lzu.edu.cn/>,
which seems to be a broader fix; if you want to go with that patch,
this one is superfluous.
> I'm not really sure if likes for the poll are supposed to be done
> lockless, if they are, we cannot use lock_sock here and will likely
> need to rework accept_q so it doesn't contain deferred sks, as those
> shouldn't be considered ready for acceptance.
I don't see why that would be a problem;
Documentation/filesystems/vfs.rst says nothing about wanting lockless
operation, and if you look around at other poll handlers, you'll see
several ->poll() handlers that take sleeping locks:
- dma_buf_poll() calls dma_resv_lock(), which locks a W/W mutex
- vb2_fop_poll() sometimes calls mutex_lock_interruptible()
- virtio_rpmsg_poll() calls mutex_lock()
My understanding is that is is preferable, but not required, for
->poll() handlers to be fast if they're used by high-performance
userspace code, since event loops might hit ->poll() handlers fairly
often (especially if userspace uses an API like poll() or select(); I
think with epoll you only get one or two ->poll() callbacks once the
file descriptor actually becomes ready); I think this probably isn't
really an issue for bluetooth listening sockets.
^ permalink raw reply
* [PATCH v4] Bluetooth: serialize accept_q access
From: Ren Wei @ 2026-05-06 11:43 UTC (permalink / raw)
To: linux-bluetooth, netdev
Cc: marcel, luiz.dentz, davem, edumazet, kuba, pabeni, horms, jannh,
yuantan098, yifanwucs, tomapufckgml, bird, wangjiexun2025, n05ec
From: Jiexun Wang <wangjiexun2025@gmail.com>
bt_sock_poll() walks the accept queue without synchronization, while
child teardown can unlink the same socket and drop its last reference.
The unsynchronized accept queue walk has existed since the initial
Bluetooth import.
Protect accept_q with a dedicated lock for queue updates and polling.
Also rework bt_accept_dequeue() to take temporary child references under
the queue lock before dropping it and locking the child socket.
Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reported-by: Jann Horn <jannh@google.com>
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
Changes in v4:
- no functional changes
- clarify that the race dates back to the initial Bluetooth import
- update trailers
I noticed Jann also proposed a fix at
https://patchwork.kernel.org/project/bluetooth/patch/20260504-bluetooth-accept-uaf-fix-v1-1-1ca63c0efadd@google.com/,
so we're adding his Reported-by tag here. Please let us know if this
isn't appropriate.
- v3 Link: https://lore.kernel.org/all/20260404162324.2789862-1-n05ec@lzu.edu.cn/
Changes in v3:
- move sk_acceptq_added()/sk_acceptq_removed() inside accept_q_lock
critical sections to serialize sk_ack_backlog updates with accept_q
operations
- v2 Link: https://lore.kernel.org/all/06a6b4549acba207847ce532dedbf1c95ab22d13.1774925231.git.wangjiexun2025@gmail.com/
Changes in v2:
- add Tested-by: Ren Wei <enjou1224z@gmail.com>
- resend to the public Bluetooth/netdev lists
include/net/bluetooth/bluetooth.h | 1 +
net/bluetooth/af_bluetooth.c | 87 +++++++++++++++++++++++--------
2 files changed, 66 insertions(+), 22 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 69eed69f7f26..3faea66b1979 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -398,6 +398,7 @@ void baswap(bdaddr_t *dst, const bdaddr_t *src);
struct bt_sock {
struct sock sk;
struct list_head accept_q;
+ spinlock_t accept_q_lock; /* protects accept_q */
struct sock *parent;
unsigned long flags;
void (*skb_msg_name)(struct sk_buff *, void *, int *);
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index 2b94e2077203..fa14b9a915eb 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -154,6 +154,7 @@ struct sock *bt_sock_alloc(struct net *net, struct socket *sock,
sock_init_data(sock, sk);
INIT_LIST_HEAD(&bt_sk(sk)->accept_q);
+ spin_lock_init(&bt_sk(sk)->accept_q_lock);
sock_reset_flag(sk, SOCK_ZAPPED);
@@ -214,6 +215,7 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk, bool bh)
{
const struct cred *old_cred;
struct pid *old_pid;
+ struct bt_sock *par = bt_sk(parent);
BT_DBG("parent %p, sk %p", parent, sk);
@@ -224,9 +226,13 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk, bool bh)
else
lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
- list_add_tail(&bt_sk(sk)->accept_q, &bt_sk(parent)->accept_q);
bt_sk(sk)->parent = parent;
+ spin_lock_bh(&par->accept_q_lock);
+ list_add_tail(&bt_sk(sk)->accept_q, &par->accept_q);
+ sk_acceptq_added(parent);
+ spin_unlock_bh(&par->accept_q_lock);
+
/* Copy credentials from parent since for incoming connections the
* socket is allocated by the kernel.
*/
@@ -244,8 +250,6 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk, bool bh)
bh_unlock_sock(sk);
else
release_sock(sk);
-
- sk_acceptq_added(parent);
}
EXPORT_SYMBOL(bt_accept_enqueue);
@@ -254,45 +258,72 @@ EXPORT_SYMBOL(bt_accept_enqueue);
*/
void bt_accept_unlink(struct sock *sk)
{
+ struct sock *parent = bt_sk(sk)->parent;
+
BT_DBG("sk %p state %d", sk, sk->sk_state);
+ spin_lock_bh(&bt_sk(parent)->accept_q_lock);
list_del_init(&bt_sk(sk)->accept_q);
- sk_acceptq_removed(bt_sk(sk)->parent);
+ sk_acceptq_removed(parent);
+ spin_unlock_bh(&bt_sk(parent)->accept_q_lock);
bt_sk(sk)->parent = NULL;
sock_put(sk);
}
EXPORT_SYMBOL(bt_accept_unlink);
+static struct sock *bt_accept_get(struct sock *parent, struct sock *sk)
+{
+ struct bt_sock *bt = bt_sk(parent);
+ struct sock *next = NULL;
+
+ /* accept_q is modified from child teardown paths too, so take a
+ * temporary reference before dropping the queue lock.
+ */
+ spin_lock_bh(&bt->accept_q_lock);
+
+ if (sk) {
+ if (bt_sk(sk)->parent != parent)
+ goto out;
+
+ if (!list_is_last(&bt_sk(sk)->accept_q, &bt->accept_q)) {
+ next = &list_next_entry(bt_sk(sk), accept_q)->sk;
+ sock_hold(next);
+ }
+ } else if (!list_empty(&bt->accept_q)) {
+ next = &list_first_entry(&bt->accept_q,
+ struct bt_sock, accept_q)->sk;
+ sock_hold(next);
+ }
+
+out:
+ spin_unlock_bh(&bt->accept_q_lock);
+ return next;
+}
+
struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
{
- struct bt_sock *s, *n;
- struct sock *sk;
+ struct sock *sk, *next;
BT_DBG("parent %p", parent);
restart:
- list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
- sk = (struct sock *)s;
-
+ for (sk = bt_accept_get(parent, NULL); sk; sk = next) {
/* Prevent early freeing of sk due to unlink and sock_kill */
- sock_hold(sk);
lock_sock(sk);
/* Check sk has not already been unlinked via
* bt_accept_unlink() due to serialisation caused by sk locking
*/
- if (!bt_sk(sk)->parent) {
+ if (bt_sk(sk)->parent != parent) {
BT_DBG("sk %p, already unlinked", sk);
release_sock(sk);
sock_put(sk);
- /* Restart the loop as sk is no longer in the list
- * and also avoid a potential infinite loop because
- * list_for_each_entry_safe() is not thread safe.
- */
goto restart;
}
+ next = bt_accept_get(parent, sk);
+
/* sk is safely in the parent list so reduce reference count */
sock_put(sk);
@@ -310,6 +341,8 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
sock_graft(sk, newsock);
release_sock(sk);
+ if (next)
+ sock_put(next);
return sk;
}
@@ -518,18 +551,28 @@ EXPORT_SYMBOL(bt_sock_stream_recvmsg);
static inline __poll_t bt_accept_poll(struct sock *parent)
{
- struct bt_sock *s, *n;
+ struct bt_sock *bt = bt_sk(parent);
+ struct bt_sock *s;
struct sock *sk;
+ __poll_t mask = 0;
+
+ spin_lock_bh(&bt->accept_q_lock);
+ list_for_each_entry(s, &bt->accept_q, accept_q) {
+ int state;
- list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
sk = (struct sock *)s;
- if (sk->sk_state == BT_CONNECTED ||
- (test_bit(BT_SK_DEFER_SETUP, &bt_sk(parent)->flags) &&
- sk->sk_state == BT_CONNECT2))
- return EPOLLIN | EPOLLRDNORM;
+ state = READ_ONCE(sk->sk_state);
+
+ if (state == BT_CONNECTED ||
+ (test_bit(BT_SK_DEFER_SETUP, &bt->flags) &&
+ state == BT_CONNECT2)) {
+ mask = EPOLLIN | EPOLLRDNORM;
+ break;
+ }
}
+ spin_unlock_bh(&bt->accept_q_lock);
- return 0;
+ return mask;
}
__poll_t bt_sock_poll(struct file *file, struct socket *sock,
--
2.34.1
^ permalink raw reply related
* RE: Add helper for "cleanup" variable attribute
From: bluez.test.bot @ 2026-05-06 11:15 UTC (permalink / raw)
To: linux-bluetooth, hadess
In-Reply-To: <20260506091824.2920716-2-hadess@hadess.net>
[-- Attachment #1: Type: text/plain, Size: 4626 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1090349
---Test result---
Test Summary:
CheckPatch FAIL 1.57 seconds
GitLint PASS 1.32 seconds
BuildEll PASS 20.73 seconds
BluezMake PASS 654.60 seconds
MakeCheck PASS 19.06 seconds
MakeDistcheck PASS 249.78 seconds
CheckValgrind PASS 296.64 seconds
CheckSmatch WARNING 355.15 seconds
bluezmakeextell PASS 184.37 seconds
IncrementalBuild PASS 1277.75 seconds
ScanBuild PASS 1024.24 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ,2/5] shared/util: Add helper for "cleanup" variable attribute
ERROR:OPEN_BRACE: open brace '{' following function definitions go on the next line
#74: FILE: src/shared/util.h:96:
+static inline void freep(void *p) {
ERROR:CODE_INDENT: code indent should use tabs where possible
#75: FILE: src/shared/util.h:97:
+ free(*(void**) p);$
WARNING:LEADING_SPACE: please, no spaces at the start of a line
#75: FILE: src/shared/util.h:97:
+ free(*(void**) p);$
ERROR:POINTER_LOCATION: "(foo**)" should be "(foo **)"
#75: FILE: src/shared/util.h:97:
+ free(*(void**) p);
/github/workspace/src/patch/14557019.patch total: 3 errors, 1 warnings, 13 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
NOTE: Whitespace errors detected.
You may wish to use scripts/cleanpatch or scripts/cleanfile
/github/workspace/src/patch/14557019.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[BlueZ,5/5] main: Use _cleanup_() to simplify GError-handling
ERROR:OPEN_BRACE: open brace '{' following function definitions go on the next line
#66: FILE: src/main.c:208:
+static inline void free_error(void *err) {
ERROR:CODE_INDENT: code indent should use tabs where possible
#67: FILE: src/main.c:209:
+ g_error_free(*(void**) err);$
WARNING:LEADING_SPACE: please, no spaces at the start of a line
#67: FILE: src/main.c:209:
+ g_error_free(*(void**) err);$
ERROR:POINTER_LOCATION: "(foo**)" should be "(foo **)"
#67: FILE: src/main.c:209:
+ g_error_free(*(void**) err);
/github/workspace/src/patch/14557018.patch total: 3 errors, 1 warnings, 127 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
NOTE: Whitespace errors detected.
You may wish to use scripts/cleanpatch or scripts/cleanfile
/github/workspace/src/patch/14557018.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/main.c: note: in included file (through src/device.h):src/shared/gatt-server.c:271:25: warning: Variable length array is used.src/shared/gatt-server.c:614:25: warning: Variable length array is used.src/shared/gatt-server.c:712:25: warning: Variable length array is used.src/shared/gatt-server.c:271:25: warning: Variable length array is used.src/shared/gatt-server.c:614:25: warning: Variable length array is used.src/shared/gatt-server.c:712:25: warning: Variable length array is used.src/shared/gatt-server.c:271:25: warning: Variable length array is used.src/shared/gatt-server.c:614:25: warning: Variable length array is used.src/shared/gatt-server.c:712:25: warning: Variable length array is used.src/main.c: note: in included file (through src/device.h):src/main.c: note: in included file (through src/device.h):
https://github.com/bluez/bluez/pull/2101
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez] 7ffffa: all: Remove more unneeded MIN/MAX macro definition
From: hadess @ 2026-05-06 10:06 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1090349
Home: https://github.com/bluez/bluez
Commit: 7ffffa83a1d73a2e3a2236a441ed7bd2b7ffa611
https://github.com/bluez/bluez/commit/7ffffa83a1d73a2e3a2236a441ed7bd2b7ffa611
Author: Bastien Nocera <hadess@hadess.net>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M lib/bluetooth/hci.c
M src/main.c
M src/shared/gatt-server.c
Log Message:
-----------
all: Remove more unneeded MIN/MAX macro definition
Commit: feebce7236870c9c6ef782e59c61c110ddd2d785
https://github.com/bluez/bluez/commit/feebce7236870c9c6ef782e59c61c110ddd2d785
Author: Bastien Nocera <hadess@hadess.net>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M src/shared/util.h
Log Message:
-----------
shared/util: Add helper for "cleanup" variable attribute
Use the widespread "cleanup" variable attribute:
https://gcc.gnu.org/onlinedocs/gcc/Common-Attributes.html#index-cleanup
It is implemented by both GCC and clang on platforms where bluez is
used, and can help reduce memory leaks, while improving readability.
See also:
https://systemd.io/CODING_STYLE/#memory-allocation
https://docs.gtk.org/glib/auto-cleanup.html
Commit: bdb11f70c15bee5a5deb37c011797ef2500f5eb2
https://github.com/bluez/bluez/commit/bdb11f70c15bee5a5deb37c011797ef2500f5eb2
Author: Bastien Nocera <hadess@hadess.net>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M doc/maintainer-guidelines.rst
Log Message:
-----------
doc: Recommend using _cleanup_ and friends
Commit: 5984b16421ae28dc1c0fe2dfe1c5e9ccf78be055
https://github.com/bluez/bluez/commit/5984b16421ae28dc1c0fe2dfe1c5e9ccf78be055
Author: Bastien Nocera <hadess@hadess.net>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M src/main.c
Log Message:
-----------
main: Use _cleanup_() to simplify configuration parsing
Makes dealing with the error path easier.
Commit: 036ef74099d88226fd820a29fd70f732ec06aaba
https://github.com/bluez/bluez/commit/036ef74099d88226fd820a29fd70f732ec06aaba
Author: Bastien Nocera <hadess@hadess.net>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M src/main.c
Log Message:
-----------
main: Use _cleanup_() to simplify GError-handling
Use _cleanup_() to simplify GError-handling in the error paths.
Compare: https://github.com/bluez/bluez/compare/7ffffa83a1d7%5E...036ef74099d8
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [BlueZ 4/5] main: Use _cleanup_() to simplify configuration parsing
From: Bastien Nocera @ 2026-05-06 9:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260506091824.2920716-1-hadess@hadess.net>
Makes dealing with the error path easier.
---
src/main.c | 70 ++++++++++++++++--------------------------------------
1 file changed, 20 insertions(+), 50 deletions(-)
diff --git a/src/main.c b/src/main.c
index 8aa19a3e3346..3a2c3e645a74 100644
--- a/src/main.c
+++ b/src/main.c
@@ -462,7 +462,7 @@ static bool parse_config_int(GKeyFile *config, const char *group,
size_t min, size_t max)
{
size_t tmp;
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
char *endptr = NULL;
if (!parse_config_string(config, group, key, &str))
@@ -471,25 +471,21 @@ static bool parse_config_int(GKeyFile *config, const char *group,
tmp = strtol(str, &endptr, 0);
if (!endptr || *endptr != '\0') {
error("%s.%s = %s is not integer", group, key, str);
- g_free(str);
return false;
}
if (tmp < min) {
- g_free(str);
warn("%s.%s = %zu is out of range (< %zu)", group, key, tmp,
min);
return false;
}
if (tmp > max) {
- g_free(str);
warn("%s.%s = %zu is out of range (> %zu)", group, key, tmp,
max);
return false;
}
- g_free(str);
if (val)
*val = tmp;
@@ -500,10 +496,9 @@ static bool parse_config_signed_int(GKeyFile *config, const char *group,
const char *key, int8_t *val,
long min, long max)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
char *endptr = NULL;
long tmp;
- bool result = false;
str = g_key_file_get_string(config, group, key, NULL);
if (!str)
@@ -512,28 +507,24 @@ static bool parse_config_signed_int(GKeyFile *config, const char *group,
tmp = strtol(str, &endptr, 0);
if (!endptr || *endptr != '\0') {
warn("%s.%s = %s is not integer", group, key, str);
- goto cleanup;
+ return false;
}
if (tmp < min) {
warn("%s.%s = %ld is out of range (< %ld)", group, key, tmp,
min);
- goto cleanup;
+ return false;
}
if (tmp > max) {
warn("%s.%s = %ld is out of range (> %ld)", group, key, tmp,
max);
- goto cleanup;
+ return false;
}
if (val)
*val = (int8_t) tmp;
- result = true;
-
-cleanup:
- g_free(str);
- return result;
+ return true;
}
struct config_param {
@@ -915,7 +906,7 @@ static bool parse_config_bool(GKeyFile *config, const char *group,
static void parse_privacy(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
if (!parse_config_string(config, "General", "Privacy", &str)) {
btd_opts.privacy = 0x00;
@@ -948,13 +939,11 @@ static void parse_privacy(GKeyFile *config)
DBG("Invalid privacy option: %s", str);
btd_opts.privacy = 0x00;
}
-
- g_free(str);
}
static void parse_repairing(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
if (!parse_config_string(config, "General", "JustWorksRepairing",
&str)) {
@@ -963,13 +952,12 @@ static void parse_repairing(GKeyFile *config)
}
btd_opts.jw_repairing = parse_jw_repairing(str);
- g_free(str);
}
static bool parse_config_hex(GKeyFile *config, char *group,
const char *key, uint32_t *val)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
if (!parse_config_string(config, group, key, &str))
return false;
@@ -977,37 +965,34 @@ static bool parse_config_hex(GKeyFile *config, char *group,
if (val)
*val = strtol(str, NULL, 16);
- g_free(str);
return true;
}
static void parse_device_id(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
parse_config_string(config, "General", "DeviceID", &str);
if (!str)
return;
parse_did(str);
- g_free(str);
}
static void parse_ctrl_mode(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
parse_config_string(config, "General", "ControllerMode", &str);
if (!str)
return;
btd_opts.mode = get_mode(str);
- g_free(str);
}
static void parse_multi_profile(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
parse_config_string(config, "General", "MultiProfile", &str);
if (!str)
@@ -1019,8 +1004,6 @@ static void parse_multi_profile(GKeyFile *config)
btd_opts.mps = MPS_MULTIPLE;
else
btd_opts.mps = MPS_OFF;
-
- g_free(str);
}
static gboolean parse_kernel_experimental(const char *key, const char *value,
@@ -1043,20 +1026,18 @@ static gboolean parse_kernel_experimental(const char *key, const char *value,
static void parse_kernel_exp(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
if (!parse_config_string(config, "General", "KernelExperimental",
&str))
return;
parse_kernel_experimental(NULL, str, NULL, NULL);
-
- g_free(str);
}
static void parse_secure_conns(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
if (!parse_config_string(config, "General", "SecureConnections",
&str))
@@ -1068,8 +1049,6 @@ static void parse_secure_conns(GKeyFile *config)
btd_opts.secure_conn = SC_ON;
else if (!strcmp(str, "only"))
btd_opts.secure_conn = SC_ONLY;
-
- g_free(str);
}
static void parse_general(GKeyFile *config)
@@ -1120,14 +1099,13 @@ static void parse_general(GKeyFile *config)
static void parse_gatt_cache(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
parse_config_string(config, "GATT", "Cache", &str);
if (!str)
return;
btd_opts.gatt_cache = parse_gatt_cache_str(str);
- g_free(str);
}
static enum bt_gatt_export_t parse_gatt_export_str(const char *str)
@@ -1147,14 +1125,13 @@ static enum bt_gatt_export_t parse_gatt_export_str(const char *str)
static void parse_gatt_export(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
parse_config_string(config, "GATT", "ExportClaimedServices", &str);
if (!str)
return;
btd_opts.gatt_export = parse_gatt_export_str(str);
- g_free(str);
}
static uint8_t parse_gatt_seclevel_str(const char *str)
@@ -1176,7 +1153,7 @@ static uint8_t parse_gatt_seclevel_str(const char *str)
static void parse_gatt_seclevel(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
if (!btd_opts.testing)
return;
@@ -1186,7 +1163,6 @@ static void parse_gatt_seclevel(GKeyFile *config)
return;
btd_opts.gatt_seclevel = parse_gatt_seclevel_str(str);
- g_free(str);
}
static void parse_gatt(GKeyFile *config)
@@ -1204,7 +1180,7 @@ static void parse_gatt(GKeyFile *config)
static void parse_csis_sirk(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
if (!parse_config_string(config, "CSIS", "SIRK", &str))
return;
@@ -1213,8 +1189,6 @@ static void parse_csis_sirk(GKeyFile *config)
hex2bin(str, btd_opts.csis.sirk, sizeof(btd_opts.csis.sirk));
else if (!gen_sirk(str))
DBG("Unable to generate SIRK from string");
-
- g_free(str);
}
static void parse_csis(GKeyFile *config)
@@ -1305,7 +1279,7 @@ static void parse_le_cs_config(GKeyFile *config)
static void parse_avdtp_session_mode(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
if (!parse_config_string(config, "AVDTP", "SessionMode", &str))
return;
@@ -1318,13 +1292,11 @@ static void parse_avdtp_session_mode(GKeyFile *config)
DBG("Invalid mode option: %s", str);
btd_opts.avdtp.session_mode = BT_IO_MODE_BASIC;
}
-
- g_free(str);
}
static void parse_avdtp_stream_mode(GKeyFile *config)
{
- char *str = NULL;
+ _cleanup_(g_free) char *str = NULL;
if (!parse_config_string(config, "AVDTP", "StreamMode", &str))
return;
@@ -1337,8 +1309,6 @@ static void parse_avdtp_stream_mode(GKeyFile *config)
DBG("Invalid mode option: %s", str);
btd_opts.avdtp.stream_mode = BT_IO_MODE_BASIC;
}
-
- g_free(str);
}
static void parse_avdtp(GKeyFile *config)
--
2.54.0
^ permalink raw reply related
* [BlueZ 3/5] doc: Recommend using _cleanup_ and friends
From: Bastien Nocera @ 2026-05-06 9:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260506091824.2920716-1-hadess@hadess.net>
---
doc/maintainer-guidelines.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/maintainer-guidelines.rst b/doc/maintainer-guidelines.rst
index 44d3e258db6e..b67c6596f4c1 100644
--- a/doc/maintainer-guidelines.rst
+++ b/doc/maintainer-guidelines.rst
@@ -98,6 +98,9 @@ do this:
The above assumes that a kernel tree resides in ``~/src/linux/``.
+Also make sure to use ``_cleanup_free_`` and ``_cleanup_(free_func)`` when
+possible. It makes your code much nicer to read (and shorter), and avoids
+common memory leaks on error paths.
Rule 4: Pay extra attention to adding new files to the tree
-----------------------------------------------------------
--
2.54.0
^ permalink raw reply related
* [BlueZ 0/5] Add helper for "cleanup" variable attribute
From: Bastien Nocera @ 2026-05-06 9:14 UTC (permalink / raw)
To: linux-bluetooth
As discussed in:
https://lore.kernel.org/linux-bluetooth/ed949f2550f79a4bef19bd482bf8b069ad5b7e0c.camel@hadess.net/
Implement a cleanup helper.
The MIN/MAX fix is here because it touches the same hunk in src/main.c
as the other patches. Feel free to pick it up straight away while the
rest is discussed.
Bastien Nocera (5):
all: Remove more unneeded MIN/MAX macro definition
shared/util: Add helper for "cleanup" variable attribute
doc: Recommend using _cleanup_ and friends
main: Use _cleanup_() to simplify configuration parsing
main: Use _cleanup_() to simplify GError-handling
doc/maintainer-guidelines.rst | 3 +
lib/bluetooth/hci.c | 4 --
src/main.c | 101 +++++++++++-----------------------
src/shared/gatt-server.c | 8 ---
src/shared/util.h | 7 +++
5 files changed, 41 insertions(+), 82 deletions(-)
--
2.54.0
^ permalink raw reply
* [BlueZ 2/5] shared/util: Add helper for "cleanup" variable attribute
From: Bastien Nocera @ 2026-05-06 9:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260506091824.2920716-1-hadess@hadess.net>
Use the widespread "cleanup" variable attribute:
https://gcc.gnu.org/onlinedocs/gcc/Common-Attributes.html#index-cleanup
It is implemented by both GCC and clang on platforms where bluez is
used, and can help reduce memory leaks, while improving readability.
See also:
https://systemd.io/CODING_STYLE/#memory-allocation
https://docs.gtk.org/glib/auto-cleanup.html
---
src/shared/util.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/shared/util.h b/src/shared/util.h
index 67629dddfaa9..90e3b32f86fe 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -93,6 +93,13 @@ do { \
#define newa(t, n) ((t*) alloca(sizeof(t)*(n)))
#define malloc0(n) (calloc(1, (n)))
+static inline void freep(void *p) {
+ free(*(void**) p);
+}
+
+#define _cleanup_(f) __attribute__((cleanup(f)))
+#define _cleanup_free_ _cleanup_(freep)
+
char *strdelimit(char *str, char *del, char c);
int strsuffix(const char *str, const char *suffix);
char *strstrip(char *str);
--
2.54.0
^ permalink raw reply related
* [BlueZ 5/5] main: Use _cleanup_() to simplify GError-handling
From: Bastien Nocera @ 2026-05-06 9:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260506091824.2920716-1-hadess@hadess.net>
Use _cleanup_() to simplify GError-handling in the error paths.
---
src/main.c | 29 ++++++++++++-----------------
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/src/main.c b/src/main.c
index 3a2c3e645a74..a2fe3ffdc914 100644
--- a/src/main.c
+++ b/src/main.c
@@ -205,6 +205,12 @@ static const struct group_table {
{ }
};
+static inline void free_error(void *err) {
+ g_error_free(*(void**) err);
+}
+
+#define _cleanup_error_ _cleanup_(free_error)
+
static int8_t check_sirk_alpha_numeric(char *str)
{
int8_t val = 0;
@@ -252,7 +258,7 @@ GKeyFile *btd_get_main_conf(void)
static GKeyFile *load_config(const char *name)
{
- GError *err = NULL;
+ _cleanup_error_ GError *err = NULL;
GKeyFile *keyfile;
int len;
@@ -285,7 +291,6 @@ static GKeyFile *load_config(const char *name)
if (!g_error_matches(err, G_FILE_ERROR, G_FILE_ERROR_NOENT))
error("Parsing %s failed: %s", main_conf_file_path,
err->message);
- g_error_free(err);
g_key_file_free(keyfile);
return NULL;
}
@@ -436,14 +441,13 @@ static int get_mode(const char *str)
static bool parse_config_string(GKeyFile *config, const char *group,
const char *key, char **val)
{
- GError *err = NULL;
+ _cleanup_error_ GError *err = NULL;
char *tmp;
tmp = g_key_file_get_string(config, group, key, &err);
if (err) {
if (err->code != G_KEY_FILE_ERROR_KEY_NOT_FOUND)
DBG("%s", err->message);
- g_error_free(err);
return false;
}
@@ -885,14 +889,13 @@ static bool parse_config_u8(GKeyFile *config, const char *group,
static bool parse_config_bool(GKeyFile *config, const char *group,
const char *key, bool *val)
{
- GError *err = NULL;
+ _cleanup_error_ GError *err = NULL;
gboolean tmp;
tmp = g_key_file_get_boolean(config, group, key, &err);
if (err) {
if (err->code != G_KEY_FILE_ERROR_KEY_NOT_FOUND)
DBG("%s", err->message);
- g_error_free(err);
return false;
}
@@ -1205,8 +1208,8 @@ static void parse_csis(GKeyFile *config)
static bool parse_cs_role(GKeyFile *config, const char *group,
const char *key, uint8_t *val)
{
- GError *err = NULL;
- char *str = NULL;
+ _cleanup_error_ GError *err = NULL;
+ _cleanup_(g_free) char *str = NULL;
char *endptr = NULL;
int numeric_val;
@@ -1215,7 +1218,6 @@ static bool parse_cs_role(GKeyFile *config, const char *group,
if (err) {
if (err->code != G_KEY_FILE_ERROR_KEY_NOT_FOUND)
DBG("%s", err->message);
- g_error_free(err);
return false;
}
@@ -1225,17 +1227,14 @@ static bool parse_cs_role(GKeyFile *config, const char *group,
if (!strcmp(str, "Initiator") || !strcmp(str, "initiator")) {
if (val)
*val = 1;
- g_free(str);
return true;
} else if (!strcmp(str, "Reflector") || !strcmp(str, "reflector")) {
if (val)
*val = 2;
- g_free(str);
return true;
} else if (!strcmp(str, "Both") || !strcmp(str, "both")) {
if (val)
*val = 3;
- g_free(str);
return true;
}
@@ -1246,7 +1245,6 @@ static bool parse_cs_role(GKeyFile *config, const char *group,
warn("%s.%s = %s is not a valid value. "
"Expected: 1/Initiator, 2/Reflector, or 3/Both",
group, key, str);
- g_free(str);
return false;
}
@@ -1254,14 +1252,12 @@ static bool parse_cs_role(GKeyFile *config, const char *group,
warn("%s.%s = %d is out of range. "
"Valid values: 1 (Initiator), 2 (Reflector), 3 (Both)",
group, key, numeric_val);
- g_free(str);
return false;
}
if (val)
*val = numeric_val;
- g_free(str);
return true;
}
@@ -1575,7 +1571,7 @@ static GOptionEntry options[] = {
int main(int argc, char *argv[])
{
GOptionContext *context;
- GError *err = NULL;
+ _cleanup_error_ GError *err = NULL;
uint16_t sdp_mtu = 0;
uint32_t sdp_flags = 0;
int gdbus_flags = 0;
@@ -1588,7 +1584,6 @@ int main(int argc, char *argv[])
if (g_option_context_parse(context, &argc, &argv, &err) == FALSE) {
if (err != NULL) {
g_printerr("%s\n", err->message);
- g_error_free(err);
} else
g_printerr("An unknown error occurred\n");
exit(1);
--
2.54.0
^ permalink raw reply related
* [BlueZ 1/5] all: Remove more unneeded MIN/MAX macro definition
From: Bastien Nocera @ 2026-05-06 9:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260506091824.2920716-1-hadess@hadess.net>
---
lib/bluetooth/hci.c | 4 ----
src/main.c | 4 ----
src/shared/gatt-server.c | 8 --------
3 files changed, 16 deletions(-)
diff --git a/lib/bluetooth/hci.c b/lib/bluetooth/hci.c
index 44eea054b0ac..f50a30c610be 100644
--- a/lib/bluetooth/hci.c
+++ b/lib/bluetooth/hci.c
@@ -33,10 +33,6 @@
#include "hci.h"
#include "hci_lib.h"
-#ifndef MIN
-#define MIN(x, y) ((x) < (y) ? (x) : (y))
-#endif
-
typedef struct {
char *str;
unsigned int val;
diff --git a/src/main.c b/src/main.c
index 9a3d2da25d4d..8aa19a3e3346 100644
--- a/src/main.c
+++ b/src/main.c
@@ -205,10 +205,6 @@ static const struct group_table {
{ }
};
-#ifndef MIN
-#define MIN(x, y) ((x) < (y) ? (x) : (y))
-#endif
-
static int8_t check_sirk_alpha_numeric(char *str)
{
int8_t val = 0;
diff --git a/src/shared/gatt-server.c b/src/shared/gatt-server.c
index 6273899965c0..709a8f94bb6a 100644
--- a/src/shared/gatt-server.c
+++ b/src/shared/gatt-server.c
@@ -26,14 +26,6 @@
#include "src/shared/util.h"
#include "src/shared/timeout.h"
-#ifndef MAX
-#define MAX(a, b) ((a) > (b) ? (a) : (b))
-#endif
-
-#ifndef MIN
-#define MIN(a, b) ((a) < (b) ? (a) : (b))
-#endif
-
/*
* TODO: This is an arbitrary limit. Come up with something reasonable or
* perhaps an API to set this value if there is a use case for it.
--
2.54.0
^ permalink raw reply related
* [syzbot] [bluetooth?] WARNING in l2cap_send_conn_req
From: syzbot @ 2026-05-06 8:54 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel, luiz.dentz, marcel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: f1a5e78a55eb Merge tag 'drm-fixes-2026-05-02' of https://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=117699ba580000
kernel config: https://syzkaller.appspot.com/x/.config?x=7f195f6be48c12ec
dashboard link: https://syzkaller.appspot.com/bug?extid=97721dd81f792e838ba0
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-f1a5e78a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c76a260376ef/vmlinux-f1a5e78a.xz
kernel image: https://storage.googleapis.com/syzbot-assets/31edd841d28f/bzImage-f1a5e78a.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+97721dd81f792e838ba0@syzkaller.appspotmail.com
------------[ cut here ]------------
workqueue: cannot queue hci_tx_work on wq hci0
WARNING: kernel/workqueue.c:2298 at __queue_work+0xd1f/0xfc0 kernel/workqueue.c:2296, CPU#0: kworker/0:5/5309
Modules linked in:
CPU: 0 UID: 0 PID: 5309 Comm: kworker/0:5 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: events l2cap_info_timeout
RIP: 0010:__queue_work+0xd4a/0xfc0 kernel/workqueue.c:2296
Code: 83 c5 18 4c 89 e8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ef e8 47 54 a5 00 49 8b 75 00 49 81 c7 70 01 00 00 4c 89 f7 4c 89 fa <67> 48 0f b9 3a 48 83 c4 58 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc
RSP: 0018:ffffc9000e42f778 EFLAGS: 00010082
RAX: 1ffff1100254618a RBX: 0000000000000008 RCX: ffff88800e470000
RDX: ffff888043643970 RSI: ffffffff8a9d8360 RDI: ffffffff9033c3b0
RBP: 0000000000000020 R08: ffff888012a30c3f R09: 1ffff11002546187
R10: dffffc0000000000 R11: ffffed1002546188 R12: dffffc0000000000
R13: ffff888012a30c50 R14: ffffffff9033c3b0 R15: ffff888043643970
FS: 0000000000000000(0000) GS:ffff88808c885000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fba154bda50 CR3: 0000000012441000 CR4: 0000000000352ef0
Call Trace:
<TASK>
queue_work_on+0x106/0x1d0 kernel/workqueue.c:2432
l2cap_send_conn_req+0x243/0x370 net/bluetooth/l2cap_core.c:1253
l2cap_start_connection net/bluetooth/l2cap_core.c:1408 [inline]
l2cap_conn_start+0xb2b/0xf20 net/bluetooth/l2cap_core.c:1549
l2cap_info_timeout+0x68/0xa0 net/bluetooth/l2cap_core.c:1685
process_one_work kernel/workqueue.c:3302 [inline]
process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3385
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3466
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
----------------
Code disassembly (best guess):
0: 83 c5 18 add $0x18,%ebp
3: 4c 89 e8 mov %r13,%rax
6: 48 c1 e8 03 shr $0x3,%rax
a: 42 80 3c 20 00 cmpb $0x0,(%rax,%r12,1)
f: 74 08 je 0x19
11: 4c 89 ef mov %r13,%rdi
14: e8 47 54 a5 00 call 0xa55460
19: 49 8b 75 00 mov 0x0(%r13),%rsi
1d: 49 81 c7 70 01 00 00 add $0x170,%r15
24: 4c 89 f7 mov %r14,%rdi
27: 4c 89 fa mov %r15,%rdx
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 48 83 c4 58 add $0x58,%rsp
33: 5b pop %rbx
34: 41 5c pop %r12
36: 41 5d pop %r13
38: 41 5e pop %r14
3a: 41 5f pop %r15
3c: 5d pop %rbp
3d: c3 ret
3e: cc int3
3f: cc int3
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [Bug 221449] Wireless gamepad stopped working through Bluetooth
From: bugzilla-daemon @ 2026-05-06 6:40 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221449-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221449
--- Comment #6 from Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) ---
> What's a good way to isolate the kernel as the issue? Install and reboot with
> an older and newer version and test the behavior under each, or is there a
> better way?
That’s the easiest way. Sometimes it’s possible to do all this in a virtual
machine and the Bluetooth controller is passed into the virtual machine. But
setting this up is unfortunately, at least last I checked, non-trivial.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221449] Wireless gamepad stopped working through Bluetooth
From: bugzilla-daemon @ 2026-05-06 6:39 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221449-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221449
Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pmenzel+bugzilla.kernel.org
| |@molgen.mpg.de
--- Comment #5 from Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) ---
Next to trying the Linux kernel, could you please run `sudo journalctl` and
look at the date in the beginning and see if that goes back far enough? If the
gamepad worked over Bluetooth back then, you could look at the first occurrence
of the error message, and see if these are an indicator.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221449] Wireless gamepad stopped working through Bluetooth
From: bugzilla-daemon @ 2026-05-06 4:27 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221449-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221449
--- Comment #4 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) ---
Fedora is preparing switching to 7.0. For the latest kernels, try
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221449] Wireless gamepad stopped working through Bluetooth
From: bugzilla-daemon @ 2026-05-06 2:12 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221449-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221449
--- Comment #3 from Arvin Ignaci (arvin.ignaci@gmail.com) ---
Wow, didn't realize the kernel moved that fast. I'm on the latest version of
Fedora, which I thought was a pretty up-to-date distro, and 6.19 seems to be
the only version available in the repos. Looks like I'll have to figure out how
to install from source on Silverblue...
What's a good way to isolate the kernel as the issue? Install and reboot with
an older and newer version and test the behavior under each, or is there a
better way?
(Sorry if these are really basic questions; I haven't really done any kernel
development before.)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH 6/9] dt-bindings: bluetooth: qcom: Add NVMEM BD address cell
From: Rob Herring (Arm) @ 2026-05-06 1:33 UTC (permalink / raw)
To: Loic Poulain
Cc: Bjorn Andersson, devicetree, Krzysztof Kozlowski, linux-arm-msm,
Marcel Holtmann, Konrad Dybcio, David S. Miller, linux-mmc,
Jens Axboe, netdev, Simon Horman, Rocky Liao, daniel,
linux-wireless, Ulf Hansson, Eric Dumazet, Balakrishna Godavarthi,
linux-kernel, Bartosz Golaszewski, Jakub Kicinski, Paolo Abeni,
linux-bluetooth, Conor Dooley, Luiz Augusto von Dentz,
Jeff Johnson, ath10k, linux-block, Johannes Berg
In-Reply-To: <20260428-block-as-nvmem-v1-6-6ad23e75190a@oss.qualcomm.com>
On Tue, 28 Apr 2026 16:23:11 +0200, Loic Poulain wrote:
> Add support for an NVMEM cell provider for "local-bd-address",
> allowing the Bluetooth stack to retrieve controller's BD address
> from non-volatile storage such as an EEPROM or an eMMC partition.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> .../bindings/net/bluetooth/qcom,bluetooth-common.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* RE: [BlueZ,v1,1/4] emulator/vhci: Add debug messages to error paths
From: bluez.test.bot @ 2026-05-05 21:53 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260505204719.1348473-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1090123
---Test result---
Test Summary:
CheckPatch PASS 1.97 seconds
GitLint PASS 1.46 seconds
BuildEll PASS 19.86 seconds
BluezMake PASS 611.29 seconds
CheckSmatch PASS 322.85 seconds
bluezmakeextell PASS 167.27 seconds
IncrementalBuild PASS 612.35 seconds
ScanBuild PASS 896.75 seconds
https://github.com/bluez/bluez/pull/2100
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v1] hciemu: Fix crash if hciemu_client_new return NULL
From: bluez.test.bot @ 2026-05-05 21:53 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260505201548.1328953-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1090113
---Test result---
Test Summary:
CheckPatch FAIL 0.66 seconds
GitLint FAIL 0.32 seconds
BuildEll PASS 19.99 seconds
BluezMake PASS 602.95 seconds
CheckSmatch PASS 320.60 seconds
bluezmakeextell PASS 163.77 seconds
IncrementalBuild PASS 603.35 seconds
ScanBuild PASS 908.15 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ,v1] hciemu: Fix crash if hciemu_client_new return NULL
WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#106:
by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
/github/workspace/src/patch/14556374.patch total: 0 errors, 1 warnings, 10 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14556374.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,v1] hciemu: Fix crash if hciemu_client_new return NULL
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
14: B1 Line exceeds max length (95>80): " by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)"
16: B1 Line exceeds max length (87>80): " by 0x48A36F2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)"
21: B1 Line exceeds max length (95>80): " at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)"
https://github.com/bluez/bluez/pull/2099
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v1,1/2] Bluetooth: HCI: Add initial support for Short Connection Interval feature
From: bluez.test.bot @ 2026-05-05 21:28 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260505200147.1325903-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 14156 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1090104
---Test result---
Test Summary:
CheckPatch PASS 2.70 seconds
GitLint FAIL 0.56 seconds
SubjectPrefix PASS 0.20 seconds
BuildKernel PASS 26.91 seconds
CheckAllWarning PASS 29.32 seconds
CheckSparse PASS 28.03 seconds
BuildKernel32 PASS 25.85 seconds
TestRunnerSetup PASS 563.34 seconds
TestRunner_l2cap-tester FAIL 18.59 seconds
TestRunner_iso-tester PASS 309.82 seconds
TestRunner_bnep-tester FAIL 18.21 seconds
TestRunner_mgmt-tester FAIL 22.89 seconds
TestRunner_rfcomm-tester PASS 40.92 seconds
TestRunner_sco-tester PASS 80.08 seconds
TestRunner_ioctl-tester FAIL 49.57 seconds
TestRunner_mesh-tester PASS 39.00 seconds
TestRunner_smp-tester PASS 17.90 seconds
TestRunner_userchan-tester PASS 19.79 seconds
TestRunner_6lowpan-tester PASS 34.53 seconds
IncrementalBuild PASS 42.47 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v1,1/2] Bluetooth: HCI: Add initial support for Short Connection Interval feature
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (82>80): "[v1,1/2] Bluetooth: HCI: Add initial support for Short Connection Interval feature"
##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
Crash detected:
==34== by 0x13325F: tester_run (tester.c:1085)
==34== by 0x1142AD: main (l2cap-tester.c:3295)
==34== Address 0x50 is not stack'd, malloc'd or (recently) free'd
==34==
==34==
==34== Process terminating with default action of signal 11 (SIGSEGV)
==34== Access not within mapped region at address 0x50
==34== at 0x12BE24: bthost_set_cmd_complete_cb (bthost.c:3487)
==34== by 0x11596D: setup_powered_client_callback (l2cap-tester.c:1317)
==34== by 0x12E5B0: request_complete (mgmt.c:320)
==34== by 0x12F045: can_read_data (mgmt.c:408)
==34== by 0x131AB8: watch_callback (io-glib.c:173)
==34== by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A33FF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A36F2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x133868: mainloop_run (mainloop-glib.c:65)
==34== by 0x133C9F: mainloop_run_with_signal (mainloop-notify.c:196)
==34== by 0x13325F: tester_run (tester.c:1085)
==34== by 0x1142AD: main (l2cap-tester.c:3295)
==34== If you believe this happened as a result of a stack
==34== overflow in your program's main thread (unlikely but
==34== possible), you can try to increase the size of the
==34== main thread stack using the --main-stacksize= flag.
==34== The main thread stack size used in this run was 8388608.
==34==
Valgrind errors:
==34== by 0x11596D: setup_powered_client_callback (l2cap-tester.c:1317)
==34== by 0x12E5B0: request_complete (mgmt.c:320)
==34== by 0x12F045: can_read_data (mgmt.c:408)
==34== by 0x131AB8: watch_callback (io-glib.c:173)
==34== by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A33FF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A36F2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x133868: mainloop_run (mainloop-glib.c:65)
==34== by 0x133C9F: mainloop_run_with_signal (mainloop-notify.c:196)
==34== by 0x13325F: tester_run (tester.c:1085)
==34== by 0x1142AD: main (l2cap-tester.c:3295)
==34== If you believe this happened as a result of a stack
==34== overflow in your program's main thread (unlikely but
==34== possible), you can try to increase the size of the
==34== main thread stack using the --main-stacksize= flag.
==34== The main thread stack size used in this run was 8388608.
==34==
==34== HEAP SUMMARY:
==34== in use at exit: 66,134 bytes in 464 blocks
==34== total heap usage: 632 allocs, 168 frees, 80,436 bytes allocated
==34==
==34== LEAK SUMMARY:
==34== definitely lost: 0 bytes in 0 blocks
==34== indirectly lost: 0 bytes in 0 blocks
==34== possibly lost: 0 bytes in 0 blocks
==34== still reachable: 66,134 bytes in 464 blocks
==34== suppressed: 0 bytes in 0 blocks
==34== Rerun with --leak-check=full to see details of leaked memory
==34==
==34== For lists of detected and suppressed errors, rerun with: -s
==34== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Crash detected:
==34== suppressed: 0 bytes in 0 blocks
==34== Rerun with --leak-check=full to see details of leaked memory
==34==
==34== For lists of detected and suppressed errors, rerun with: -s
==34== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Segmentation fault
Process 33 exited with status 139
reboot: Restarting system
reboot: machine restart
No test result found
##############################
Test: TestRunner_bnep-tester - FAIL
Desc: Run bnep-tester with test-runner
Output:
Crash detected:
==34== by 0x12C99F: tester_run (tester.c:1085)
==34== by 0x111CB3: main (bnep-tester.c:298)
==34== Address 0x50 is not stack'd, malloc'd or (recently) free'd
==34==
==34==
==34== Process terminating with default action of signal 11 (SIGSEGV)
==34== Access not within mapped region at address 0x50
==34== at 0x125C44: bthost_set_cmd_complete_cb (bthost.c:3487)
==34== by 0x111F42: setup_powered_client_callback (bnep-tester.c:244)
==34== by 0x127F00: request_complete (mgmt.c:320)
==34== by 0x1288B5: can_read_data (mgmt.c:408)
==34== by 0x12B328: watch_callback (io-glib.c:173)
==34== by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A33FF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A36F2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x12CFA8: mainloop_run (mainloop-glib.c:65)
==34== by 0x12D3DF: mainloop_run_with_signal (mainloop-notify.c:196)
==34== by 0x12C99F: tester_run (tester.c:1085)
==34== by 0x111CB3: main (bnep-tester.c:298)
==34== If you believe this happened as a result of a stack
==34== overflow in your program's main thread (unlikely but
==34== possible), you can try to increase the size of the
==34== main thread stack using the --main-stacksize= flag.
==34== The main thread stack size used in this run was 8388608.
==34==
Valgrind errors:
==34== by 0x111F42: setup_powered_client_callback (bnep-tester.c:244)
==34== by 0x127F00: request_complete (mgmt.c:320)
==34== by 0x1288B5: can_read_data (mgmt.c:408)
==34== by 0x12B328: watch_callback (io-glib.c:173)
==34== by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A33FF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A36F2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x12CFA8: mainloop_run (mainloop-glib.c:65)
==34== by 0x12D3DF: mainloop_run_with_signal (mainloop-notify.c:196)
==34== by 0x12C99F: tester_run (tester.c:1085)
==34== by 0x111CB3: main (bnep-tester.c:298)
==34== If you believe this happened as a result of a stack
==34== overflow in your program's main thread (unlikely but
==34== possible), you can try to increase the size of the
==34== main thread stack using the --main-stacksize= flag.
==34== The main thread stack size used in this run was 8388608.
==34==
==34== HEAP SUMMARY:
==34== in use at exit: 25,333 bytes in 82 blocks
==34== total heap usage: 237 allocs, 155 frees, 39,167 bytes allocated
==34==
==34== LEAK SUMMARY:
==34== definitely lost: 0 bytes in 0 blocks
==34== indirectly lost: 0 bytes in 0 blocks
==34== possibly lost: 0 bytes in 0 blocks
==34== still reachable: 25,333 bytes in 82 blocks
==34== suppressed: 0 bytes in 0 blocks
==34== Rerun with --leak-check=full to see details of leaked memory
==34==
==34== For lists of detected and suppressed errors, rerun with: -s
==34== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Crash detected:
==34== suppressed: 0 bytes in 0 blocks
==34== Rerun with --leak-check=full to see details of leaked memory
==34==
==34== For lists of detected and suppressed errors, rerun with: -s
==34== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault
Process 33 exited with status 139
reboot: Restarting system
reboot: machine restart
No test result found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Crash detected:
==34== by 0x14F1DF: tester_run (tester.c:1085)
==34== by 0x12B999: main (mgmt-tester.c:15134)
==34== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==34==
==34==
==34== Process terminating with default action of signal 11 (SIGSEGV)
==34== Access not within mapped region at address 0x0
==34== at 0x145134: bthost_notify_ready (bthost.c:1190)
==34== by 0x12FA10: read_info_callback (mgmt-tester.c:223)
==34== by 0x14A420: request_complete (mgmt.c:320)
==34== by 0x14AFD5: can_read_data (mgmt.c:408)
==34== by 0x14DA48: watch_callback (io-glib.c:173)
==34== by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A33FF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A36F2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x14F7E8: mainloop_run (mainloop-glib.c:65)
==34== by 0x14FC1F: mainloop_run_with_signal (mainloop-notify.c:196)
==34== by 0x14F1DF: tester_run (tester.c:1085)
==34== by 0x12B999: main (mgmt-tester.c:15134)
==34== If you believe this happened as a result of a stack
==34== overflow in your program's main thread (unlikely but
==34== possible), you can try to increase the size of the
==34== main thread stack using the --main-stacksize= flag.
==34== The main thread stack size used in this run was 8388608.
==34==
Valgrind errors:
==34== by 0x12FA10: read_info_callback (mgmt-tester.c:223)
==34== by 0x14A420: request_complete (mgmt.c:320)
==34== by 0x14AFD5: can_read_data (mgmt.c:408)
==34== by 0x14DA48: watch_callback (io-glib.c:173)
==34== by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A33FF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x48A36F2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==34== by 0x14F7E8: mainloop_run (mainloop-glib.c:65)
==34== by 0x14FC1F: mainloop_run_with_signal (mainloop-notify.c:196)
==34== by 0x14F1DF: tester_run (tester.c:1085)
==34== by 0x12B999: main (mgmt-tester.c:15134)
==34== If you believe this happened as a result of a stack
==34== overflow in your program's main thread (unlikely but
==34== possible), you can try to increase the size of the
==34== main thread stack using the --main-stacksize= flag.
==34== The main thread stack size used in this run was 8388608.
==34==
==34== HEAP SUMMARY:
==34== in use at exit: 182,331 bytes in 2,112 blocks
==34== total heap usage: 2,379 allocs, 267 frees, 204,063 bytes allocated
==34==
==34== LEAK SUMMARY:
==34== definitely lost: 0 bytes in 0 blocks
==34== indirectly lost: 0 bytes in 0 blocks
==34== possibly lost: 0 bytes in 0 blocks
==34== still reachable: 182,331 bytes in 2,112 blocks
==34== suppressed: 0 bytes in 0 blocks
==34== Rerun with --leak-check=full to see details of leaked memory
==34==
==34== For lists of detected and suppressed errors, rerun with: -s
==34== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Crash detected:
==34== suppressed: 0 bytes in 0 blocks
==34== Rerun with --leak-check=full to see details of leaked memory
==34==
==34== For lists of detected and suppressed errors, rerun with: -s
==34== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault
Process 33 exited with status 139
reboot: Restarting system
reboot: machine restart
No test result found
##############################
Test: TestRunner_ioctl-tester - FAIL
Desc: Run ioctl-tester with test-runner
Output:
Total: 28, Passed: 0 (0.0%), Failed: 11, Not Run: 17
Failed Test Cases
Device List Timed out -31.727 seconds
Device Info Timed out -6.903 seconds
Reset Stat Timed out -6.909 seconds
Set Link Mode - ACCEPT Timed out -6.915 seconds
Set Pkt Type - DM Timed out -15.155 seconds
Set Pkt Type - DH Timed out -15.162 seconds
Set Pkt Type - HV Timed out -15.167 seconds
Set Pkt Type - 2-DH Timed out -15.174 seconds
Set Pkt Type - 2-DH Timed out -15.181 seconds
Set Pkt Type - ALL Timed out -15.187 seconds
Set ACL MTU - 1 Timed out -15.192 seconds
https://github.com/bluez/bluetooth-next/pull/147
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez] 7828f7: emulator/vhci: Add debug messages to error paths
From: Luiz Augusto von Dentz @ 2026-05-05 21:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1090123
Home: https://github.com/bluez/bluez
Commit: 7828f7436ad604c278d96e491c24815eb5eba465
https://github.com/bluez/bluez/commit/7828f7436ad604c278d96e491c24815eb5eba465
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
M emulator/vhci.c
Log Message:
-----------
emulator/vhci: Add debug messages to error paths
Add debug_callback, debug_destroy and debug_data fields to struct vhci
so vhci_set_debug stores the callback locally in addition to passing it
to btdev. Introduce a variadic vhci_debug() helper using util_debug_va
and add debug messages to the following error paths:
- vhci_write_callback: failed io_send
- vhci_read_callback: failed read
- vhci_debugfs_write: failed open and failed write
Commit: eeb46df9fd4944f73df1b5bc991582fa94140872
https://github.com/bluez/bluez/commit/eeb46df9fd4944f73df1b5bc991582fa94140872
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
M emulator/hciemu.c
Log Message:
-----------
emulator/hciemu: Add debug messages to error paths
Introduce a variadic hciemu_debug() helper using util_debug_va and add
debug messages to the following error paths:
- create_vhci: failed to open vhci
- hciemu_client_new: failed to create btdev, bthost, or socketpair
Commit: 3037ba762200454aada62411a4d4567150ed39a5
https://github.com/bluez/bluez/commit/3037ba762200454aada62411a4d4567150ed39a5
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
M tools/gap-tester.c
Log Message:
-----------
tools/gap-tester: Enable hciemu debug output
Add print_debug callback and call hciemu_set_debug when debug output is
enabled so that hciemu error paths are visible during test runs.
Commit: 5125b3d39fe26a3c5c824fb18bc44a8e05602b37
https://github.com/bluez/bluez/commit/5125b3d39fe26a3c5c824fb18bc44a8e05602b37
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
M tools/userchan-tester.c
Log Message:
-----------
tools/userchan-tester: Enable hciemu debug output
Call hciemu_set_debug when debug output is enabled so that hciemu error
paths are visible during test runs.
Compare: https://github.com/bluez/bluez/compare/7828f7436ad6%5E...5125b3d39fe2
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] fae0c7: hciemu: Fix crash if hciemu_client_new return NULL
From: Luiz Augusto von Dentz @ 2026-05-05 21:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1090113
Home: https://github.com/bluez/bluez
Commit: fae0c76f643a6d9c925998a29e3b25baa0b79ce8
https://github.com/bluez/bluez/commit/fae0c76f643a6d9c925998a29e3b25baa0b79ce8
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
M emulator/hciemu.c
Log Message:
-----------
hciemu: Fix crash if hciemu_client_new return NULL
The following crahs can be observed if hciemu_client_new fails:
Invalid read of size 8
at 0x12DA79: queue_get_entries (queue.c:356)
by 0x118434: hciemu_get_client (hciemu.c:277)
by 0x1184A3: hciemu_client_get_host (hciemu.c:301)
by 0x11536B: setup_powered_common (l2cap-tester.c:1452)
by 0x11568E: setup_powered_client (l2cap-tester.c:1491)
by 0x1324C6: setup_callback (tester.c:500)
by 0x48A304D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
by 0x48A33FF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
by 0x48A36F2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
by 0x133868: mainloop_run (mainloop-glib.c:65)
by 0x133C9F: mainloop_run_with_signal (mainloop-notify.c:196)
by 0x13325F: tester_run (tester.c:1085)
Address 0x4c1e388 is 8 bytes inside a block of size 32 free'd
at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x1187BF: hciemu_new_num (hciemu.c:437)
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox