* Re: [GIT PULL] bluetooth 2026-05-27
From: Luiz Augusto von Dentz @ 2026-05-28 12:49 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, linux-bluetooth, netdev
In-Reply-To: <20260527192430.1b490571@kernel.org>
Hi Jakub
Yeah, I'm still rebasing. Will amend that commit to add the missing sign-off.
--
Luiz Augusto von Dentz
On Wed, May 27, 2026 at 10:24 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 27 May 2026 17:12:46 -0400 Luiz Augusto von Dentz wrote:
> > The following changes since commit ab1513597c6cf17cd1ad2a21e3b045421b48e022:
> >
> > Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() (2026-05-20 16:35:47 -0400)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-27
> >
> > for you to fetch changes up to df35e8e0c8c4160c881bb673e3c7ee010824fbd5:
> >
> > Bluetooth: hci_sync: Reset device counters in hci_dev_close_sync() (2026-05-27 16:44:02 -0400)
>
> Are you still rebasing? Or did Linus convince you not to? :)
> Looks like we are missing your sign-off on:
>
> Commit c3d01980c64a ("Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success")
> committer Signed-off-by missing
> author email: kipreyyy@gmail.com
> committer email: luiz.von.dentz@intel.com
> Signed-off-by: Zhenghang Xiao <kipreyyy@gmail.com>
>
> If you're planning to no longer rebase your tress - don't worry about
> it. It's not a deal breaker. If you are rebasing anyway - could you
> amend?
--
Luiz Augusto von Dentz
^ permalink raw reply
* RE: [v3] Bluetooth: MGMT: validate advertising TLV before type checks
From: bluez.test.bot @ 2026-05-28 10:34 UTC (permalink / raw)
To: linux-bluetooth, rollkingzzc
In-Reply-To: <20260528094506.3699804-1-rollkingzzc@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1718 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=1102158
---Test result---
Test Summary:
CheckPatch PASS 0.56 seconds
VerifyFixes PASS 0.08 seconds
VerifySignedoff PASS 0.07 seconds
GitLint PASS 0.21 seconds
SubjectPrefix PASS 0.07 seconds
BuildKernel PASS 27.49 seconds
CheckAllWarning PASS 30.32 seconds
CheckSparse PASS 28.51 seconds
BuildKernel32 PASS 26.71 seconds
TestRunnerSetup PASS 596.18 seconds
TestRunner_mgmt-tester FAIL 227.64 seconds
TestRunner_mesh-tester FAIL 25.88 seconds
IncrementalBuild PASS 26.28 seconds
Details
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.265 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 1.836 seconds
Mesh - Send cancel - 2 Timed out 1.994 seconds
https://github.com/bluez/bluetooth-next/pull/252
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v2] Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()
From: bluez.test.bot @ 2026-05-28 10:27 UTC (permalink / raw)
To: linux-bluetooth, rollkingzzc
In-Reply-To: <20260528075641.3416308-1-rollkingzzc@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1042 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=1102052
---Test result---
Test Summary:
CheckPatch PASS 0.60 seconds
VerifyFixes PASS 0.09 seconds
VerifySignedoff PASS 0.09 seconds
GitLint PASS 0.23 seconds
SubjectPrefix PASS 0.08 seconds
BuildKernel PASS 26.39 seconds
CheckAllWarning PASS 29.02 seconds
CheckSparse PASS 27.78 seconds
BuildKernel32 PASS 25.61 seconds
TestRunnerSetup PASS 568.59 seconds
TestRunner_rfcomm-tester PASS 25.28 seconds
IncrementalBuild PASS 24.56 seconds
https://github.com/bluez/bluetooth-next/pull/251
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ] mgmt: Remove mgmt_ev[] strings of undefined MGMT events
From: bluez.test.bot @ 2026-05-28 9:55 UTC (permalink / raw)
To: linux-bluetooth, frederic.danis
In-Reply-To: <20260528074938.385847-1-frederic.danis@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 988 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=1102048
---Test result---
Test Summary:
CheckPatch PASS 0.47 seconds
GitLint PASS 0.34 seconds
BuildEll PASS 20.18 seconds
BluezMake PASS 623.08 seconds
MakeCheck PASS 0.98 seconds
MakeDistcheck PASS 241.62 seconds
CheckValgrind PASS 207.90 seconds
CheckSmatch PASS 327.54 seconds
bluezmakeextell PASS 165.12 seconds
IncrementalBuild PASS 615.69 seconds
ScanBuild PASS 947.64 seconds
https://github.com/bluez/bluez/pull/2158
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v3] Bluetooth: MGMT: validate advertising TLV before type checks
From: Zhang Cen @ 2026-05-28 9:45 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, Paul Menzel, zerocling0077,
2045gemini, Zhang Cen
tlv_data_is_valid() reads each advertising data field length from
data[i], then inspects data[i + 1] for managed EIR types before
checking that the current field still fits inside the supplied buffer.
A malformed field whose length byte is the last byte of the buffer can
therefore make the parser read one byte past the advertising data.
KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING
request reached that path:
BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid()
Read of size 1
Call trace:
tlv_data_is_valid()
add_advertising()
hci_mgmt_cmd()
hci_sock_sendmsg()
Move the existing element-length check before any type-octet inspection
so each non-empty element is proven to contain its type byte before the
parser looks at data[i + 1].
Fixes: 2bb36870e8cb ("Bluetooth: Unify advertising instance flags check")
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
---
v3:
- Move the KASAN excerpt earlier in the commit message.
- Add Reviewed-by from Paul Menzel.
net/bluetooth/mgmt.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index de5bd6b637b20..027b266ccc747 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -8638,6 +8638,12 @@ static bool tlv_data_is_valid(struct hci_dev *hdev, u32 adv_flags, u8 *data,
if (!cur_len)
continue;
+ /* If the current field length would exceed the total data
+ * length, then it's invalid.
+ */
+ if (i + cur_len >= len)
+ return false;
+
if (data[i + 1] == EIR_FLAGS &&
(!is_adv_data || flags_managed(adv_flags)))
return false;
@@ -8654,12 +8660,6 @@ static bool tlv_data_is_valid(struct hci_dev *hdev, u32 adv_flags, u8 *data,
if (data[i + 1] == EIR_APPEARANCE &&
appearance_managed(adv_flags))
return false;
-
- /* If the current field length would exceed the total data
- * length, then it's invalid.
- */
- if (i + cur_len >= len)
- return false;
}
return true;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: MGMT: validate advertising TLV before type checks
From: Cen Zhang @ 2026-05-28 9:39 UTC (permalink / raw)
To: Paul Menzel
Cc: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth,
linux-kernel, zerocling0077, 2045gemini
In-Reply-To: <f44f9f90-e71e-4e92-8af0-9fe6f21b2989@molgen.mpg.de>
Hi Paul,
Thanks for the review.
> Does Linux log something in this case?
>
There is no printk or other kernel log for this case. The malformed
advertising data makes tlv_data_is_valid() return false, and
add_advertising() then reports MGMT_STATUS_INVALID_PARAMS through the
Bluetooth management command status response. Keeping this quiet matches
the surrounding validation paths and avoids user-triggerable log noise.
> The diff looks good. Feel free to add:
>
> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
I will send v3 with the KASAN excerpt moved earlier in the commit
message, and with your Reviewed-by tag added.
Thanks,
Zhang Cen
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-28 9:01 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1086648
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 516271: mgmt: Remove mgmt_ev[] strings of undefined MGMT e...
From: fdanis-oss @ 2026-05-28 9:01 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1102048
Home: https://github.com/bluez/bluez
Commit: 516271591a80db6d744a611d7c684d2fb9032d72
https://github.com/bluez/bluez/commit/516271591a80db6d744a611d7c684d2fb9032d72
Author: Frédéric Danis <frederic.danis@collabora.com>
Date: 2026-05-28 (Thu, 28 May 2026)
Changed paths:
M lib/bluetooth/mgmt.h
Log Message:
-----------
mgmt: Remove mgmt_ev[] strings of undefined MGMT events
Remove event strings introduced in mgmt_ev[] but for which the MGMT
events has not been defined.
Those events are already part of the events_le_table[] in
monitor/packet.c
Fixes: f9557931ad36 ("monitor: Add decoding support for Sync Receiver events")
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: MGMT: validate advertising TLV before type checks
From: Paul Menzel @ 2026-05-28 8:59 UTC (permalink / raw)
To: Cen Zhang
Cc: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth,
linux-kernel, zerocling0077, 2045gemini
In-Reply-To: <20260528075701.3417224-1-rollkingzzc@gmail.com>
Dear Cen,
Thank you for your patch.
Am 28.05.26 um 09:57 schrieb Zhang, Cen:
> tlv_data_is_valid() reads each advertising data field length from
> data[i], then inspects data[i + 1] for managed EIR types before
> checking that the current field still fits inside the supplied buffer.
>
> A malformed field whose length byte is the last byte of the buffer can
> therefore make the parser read one byte past the advertising data.
>
> Move the existing element-length check before any type-octet inspection
> so each non-empty element is proven to contain its type byte before the
> parser looks at data[i + 1].
>
> KASAN reported an out-of-bounds read in tlv_data_is_valid(), reached
> through add_advertising() and hci_mgmt_cmd().
I’d add this after the second paragraph, and also add an excerpt, so
people also seeing the trace can find the patch/commit more easily.
> Fixes: 2bb36870e8cb ("Bluetooth: Unify advertising instance flags check")
> Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
> ---
> v2:
> - Drop the MGMT_OP_ADD_EXT_ADV_DATA hunk; bluetooth-next already
> validates that command length.
> - Keep only the tlv_data_is_valid() element-ordering fix.
> - Add a Fixes tag and avoid the raw KASAN headline that triggered
> checkpatch.
>
> net/bluetooth/mgmt.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index de5bd6b637b20..027b266ccc747 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -8638,6 +8638,12 @@ static bool tlv_data_is_valid(struct hci_dev *hdev, u32 adv_flags, u8 *data,
> if (!cur_len)
> continue;
>
> + /* If the current field length would exceed the total data
> + * length, then it's invalid.
> + */
> + if (i + cur_len >= len)
> + return false;
Does Linux log something in this case?
> +
> if (data[i + 1] == EIR_FLAGS &&
> (!is_adv_data || flags_managed(adv_flags)))
> return false;
> @@ -8654,12 +8660,6 @@ static bool tlv_data_is_valid(struct hci_dev *hdev, u32 adv_flags, u8 *data,
> if (data[i + 1] == EIR_APPEARANCE &&
> appearance_managed(adv_flags))
> return false;
> -
> - /* If the current field length would exceed the total data
> - * length, then it's invalid.
> - */
> - if (i + cur_len >= len)
> - return false;
> }
>
> return true;
The diff looks good. Feel free to add:
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
^ permalink raw reply
* [PATCH v2] Bluetooth: MGMT: validate advertising TLV before type checks
From: Zhang Cen @ 2026-05-28 7:57 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, zerocling0077, 2045gemini
tlv_data_is_valid() reads each advertising data field length from
data[i], then inspects data[i + 1] for managed EIR types before
checking that the current field still fits inside the supplied buffer.
A malformed field whose length byte is the last byte of the buffer can
therefore make the parser read one byte past the advertising data.
Move the existing element-length check before any type-octet inspection
so each non-empty element is proven to contain its type byte before the
parser looks at data[i + 1].
KASAN reported an out-of-bounds read in tlv_data_is_valid(), reached
through add_advertising() and hci_mgmt_cmd().
Fixes: 2bb36870e8cb ("Bluetooth: Unify advertising instance flags check")
Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
---
v2:
- Drop the MGMT_OP_ADD_EXT_ADV_DATA hunk; bluetooth-next already
validates that command length.
- Keep only the tlv_data_is_valid() element-ordering fix.
- Add a Fixes tag and avoid the raw KASAN headline that triggered
checkpatch.
net/bluetooth/mgmt.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index de5bd6b637b20..027b266ccc747 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -8638,6 +8638,12 @@ static bool tlv_data_is_valid(struct hci_dev *hdev, u32 adv_flags, u8 *data,
if (!cur_len)
continue;
+ /* If the current field length would exceed the total data
+ * length, then it's invalid.
+ */
+ if (i + cur_len >= len)
+ return false;
+
if (data[i + 1] == EIR_FLAGS &&
(!is_adv_data || flags_managed(adv_flags)))
return false;
@@ -8654,12 +8660,6 @@ static bool tlv_data_is_valid(struct hci_dev *hdev, u32 adv_flags, u8 *data,
if (data[i + 1] == EIR_APPEARANCE &&
appearance_managed(adv_flags))
return false;
-
- /* If the current field length would exceed the total data
- * length, then it's invalid.
- */
- if (i + cur_len >= len)
- return false;
}
return true;
--
2.43.0
^ permalink raw reply related
* [PATCH v2] Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()
From: Zhang Cen @ 2026-05-28 7:56 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, zerocling0077, 2045gemini
rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock,
but returns the selected listener after dropping that lock without
taking a reference. rfcomm_connect_ind() then locks the listener,
queues a child socket on it, and may notify it after unlocking it.
The buggy scenario involves two paths, with each column showing the
order within that path:
rfcomm_connect_ind(): listener close:
1. Find parent in 1. close() enters
rfcomm_get_sock_by_channel() rfcomm_sock_release().
2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown()
without pinning parent. closes the listener.
3. Call lock_sock(parent) and 3. rfcomm_sock_kill()
bt_accept_enqueue(parent, unlinks and puts parent.
sk, true).
4. Read parent flags and may 4. parent can be freed.
call sk_state_change().
If close wins the race, parent can be freed before
rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the
deferred-setup callback.
Take a reference on the listener before leaving rfcomm_sk_list.lock.
After lock_sock() succeeds, recheck that it is still in BT_LISTEN
before queueing a child, cache the deferred-setup bit while the parent
is locked, and drop the reference after the last parent use.
KASAN reported a slab-use-after-free in lock_sock_nested() from
rfcomm_connect_ind(), with the freeing stack going through
rfcomm_sock_kill() and rfcomm_sock_release().
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
---
v2:
- Wrap the interleaving description to satisfy GitLint.
- Add a Fixes tag.
net/bluetooth/rfcomm/sock.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 38d2355114cff..ed31d5f4fc76f 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -123,7 +123,7 @@ static struct sock *__rfcomm_get_listen_sock_by_addr(u8 channel, bdaddr_t *src)
}
/* Find socket with channel and source bdaddr.
- * Returns closest match.
+ * Returns closest match with an extra reference held.
*/
static struct sock *rfcomm_get_sock_by_channel(int state, u8 channel, bdaddr_t *src)
{
@@ -137,15 +137,25 @@ static struct sock *rfcomm_get_sock_by_channel(int state, u8 channel, bdaddr_t *
if (rfcomm_pi(sk)->channel == channel) {
/* Exact match. */
- if (!bacmp(&rfcomm_pi(sk)->src, src))
+ if (!bacmp(&rfcomm_pi(sk)->src, src)) {
+ sock_hold(sk);
break;
+ }
/* Closest match */
- if (!bacmp(&rfcomm_pi(sk)->src, BDADDR_ANY))
+ if (!bacmp(&rfcomm_pi(sk)->src, BDADDR_ANY)) {
+ if (sk1)
+ sock_put(sk1);
+
sk1 = sk;
+ sock_hold(sk1);
+ }
}
}
+ if (sk && sk1)
+ sock_put(sk1);
+
read_unlock(&rfcomm_sk_list.lock);
return sk ? sk : sk1;
@@ -945,6 +955,7 @@ int rfcomm_connect_ind(struct rfcomm_session *s, u8 channel, struct rfcomm_dlc *
{
struct sock *sk, *parent;
bdaddr_t src, dst;
+ bool defer_setup = false;
int result = 0;
BT_DBG("session %p channel %d", s, channel);
@@ -958,6 +969,11 @@ int rfcomm_connect_ind(struct rfcomm_session *s, u8 channel, struct rfcomm_dlc *
lock_sock(parent);
+ if (parent->sk_state != BT_LISTEN)
+ goto done;
+
+ defer_setup = test_bit(BT_SK_DEFER_SETUP, &bt_sk(parent)->flags);
+
/* Check for backlog size */
if (sk_acceptq_is_full(parent)) {
BT_DBG("backlog full %d", parent->sk_ack_backlog);
@@ -985,9 +1001,11 @@ int rfcomm_connect_ind(struct rfcomm_session *s, u8 channel, struct rfcomm_dlc *
done:
release_sock(parent);
- if (test_bit(BT_SK_DEFER_SETUP, &bt_sk(parent)->flags))
+ if (defer_setup)
parent->sk_state_change(parent);
+ sock_put(parent);
+
return result;
}
--
2.43.0
^ permalink raw reply related
* [PATCH BlueZ] mgmt: Remove mgmt_ev[] strings of undefined MGMT events
From: Frédéric Danis @ 2026-05-28 7:49 UTC (permalink / raw)
To: linux-bluetooth
Remove event strings introduced in mgmt_ev[] but for which the MGMT
events has not been defined.
Those events are already part of the events_le_table[] in
monitor/packet.c
Fixes: f9557931ad36 ("monitor: Add decoding support for Sync Receiver events")
---
lib/bluetooth/mgmt.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/bluetooth/mgmt.h b/lib/bluetooth/mgmt.h
index 1c741ed55..7fab3d7a0 100644
--- a/lib/bluetooth/mgmt.h
+++ b/lib/bluetooth/mgmt.h
@@ -1254,9 +1254,6 @@ static const char *mgmt_ev[] = {
"Advertisement Monitor Device Lost",
"Mesh Packet Found",
"Mesh Packet Complete",
- "PA Sync Established",
- "BIG Sync Established",
- "BIG Sync Lost",
};
static const char *mgmt_status[] = {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3] Bluetooth: 6lowpan: Fix peer and channel lifetime during teardown
From: Cen Zhang @ 2026-05-28 7:36 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, Hillf Danton, zerocling0077,
2045gemini
In-Reply-To: <20260511172310.3723421-1-rollkingzzc@gmail.com>
Hi Marcel, Luiz,
Gentle ping on this v3. This version makes the peer lifetime explicit
with a peer refcount, keeps lookup-returned peers pinned after the RCU
lookup, and defers the peer-owned L2CAP channel release out of the RCU
callback.
The bluetooth test bot reported no failures. Please let me know if you
would prefer this to be simplified or split differently.
Thanks,
Zhang Cen
Zhang Cen <rollkingzzc@gmail.com> 于2026年5月12日周二 01:23写道：
>
> A 6LoWPAN peer keeps a protocol-owned L2CAP channel reference in
> peer->chan. chan_close_cb() removes the peer from the RCU list when the
> channel is closed, but the old code also dropped that channel reference
> before the peer object stopped being observable by in-flight RCU readers.
>
> The buggy scenario involves two paths, with each column showing the order
> within that path:
>
> close path: lookup/transmit path:
> l2cap_conn_del() or another setup_header(), send_mcast_pkt(),
> close path holds a temporary bt_6lowpan_disconnect(), or
> channel reference chan_recv_cb() observes a peer
>
> l2cap_chan_del() drops the the reader leaves the RCU read
> connection-owned channel reference side critical section, or keeps
> using peer->chan inside it
>
> chan_close_cb() removes the peer the reader reads channel fields,
> from the peer list locks the channel, or sends
> through peer->chan
>
> the old chan_close_cb() dropped
> the peer-owned channel reference
>
> the close caller releases its
> temporary channel reference
>
> If the close path consumes the peer-owned channel reference before a
> reader finishes with peer->chan, the reader can use a freed l2cap_chan.
> The lookup helpers that returned raw peer pointers after rcu_read_unlock()
> also let callers outlive the peer object's kfree_rcu() lifetime.
>
> Give lowpan_peer its own refcount and make RCU lookups acquire a peer
> reference before returning a peer to code that runs outside the read-side
> critical section. Keep the peer-owned L2CAP channel reference attached to
> the peer until the last peer reference is dropped.
>
> The last peer put can happen from an RCU callback or from the network
> transmit path, so do not drop the final L2CAP channel reference directly
> from lowpan_peer_put(). Queue final peer destruction to a dedicated
> workqueue and release the channel and module references there. Store the
> peer, rather than a temporary channel reference, in the skb control block
> for unicast transmit, and put the peer after the send path is done.
> Multicast continues to use peer->chan only while it is inside the RCU
> read-side critical section.
>
> Wait for queued RCU callbacks and peer-destroy work during module exit so
> asynchronous peer destruction cannot outlive the module text.
>
> Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
> ---
> net/bluetooth/6lowpan.c | 128 ++++++++++++++++++++++++++++++++--------
> 1 file changed, 104 insertions(+), 24 deletions(-)
>
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index 23a229ab6..7a1b0d7b0 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -9,6 +9,8 @@
> #include <linux/etherdevice.h>
> #include <linux/module.h>
> #include <linux/debugfs.h>
> +#include <linux/refcount.h>
> +#include <linux/workqueue.h>
>
> #include <net/ipv6.h>
> #include <net/ip6_route.h>
> @@ -29,10 +31,12 @@ static struct dentry *lowpan_control_debugfs;
>
> #define IFACE_NAME_TEMPLATE "bt%d"
>
> +struct lowpan_peer;
> +
> struct skb_cb {
> struct in6_addr addr;
> struct in6_addr gw;
> - struct l2cap_chan *chan;
> + struct lowpan_peer *peer;
> };
> #define lowpan_cb(skb) ((struct skb_cb *)((skb)->cb))
>
> @@ -52,6 +56,7 @@ static bool enable_6lowpan;
> */
> static struct l2cap_chan *listen_chan;
> static DEFINE_MUTEX(set_lock);
> +static struct workqueue_struct *lowpan_peer_wq;
>
> enum {
> LOWPAN_PEER_CLOSING,
> @@ -61,6 +66,8 @@ enum {
> struct lowpan_peer {
> struct list_head list;
> struct rcu_head rcu;
> + struct work_struct destroy_work;
> + refcount_t refcnt;
> struct l2cap_chan *chan;
>
> /* peer addresses in various formats */
> @@ -95,13 +102,39 @@ static inline void peer_add(struct lowpan_btle_dev *dev,
> atomic_inc(&dev->peer_count);
> }
>
> +static inline bool lowpan_peer_get_unless_zero(struct lowpan_peer *peer)
> +{
> + return refcount_inc_not_zero(&peer->refcnt);
> +}
> +
> +static void lowpan_peer_destroy(struct work_struct *work)
> +{
> + struct lowpan_peer *peer = container_of(work, struct lowpan_peer,
> + destroy_work);
> +
> + l2cap_chan_put(peer->chan);
> + kfree(peer);
> + module_put(THIS_MODULE);
> +}
> +
> +static void lowpan_peer_put(struct lowpan_peer *peer)
> +{
> + if (refcount_dec_and_test(&peer->refcnt))
> + queue_work(lowpan_peer_wq, &peer->destroy_work);
> +}
> +
> +static void lowpan_peer_put_rcu(struct rcu_head *rcu)
> +{
> + struct lowpan_peer *peer = container_of(rcu, struct lowpan_peer, rcu);
> +
> + lowpan_peer_put(peer);
> +}
> +
> static inline bool peer_del(struct lowpan_btle_dev *dev,
> struct lowpan_peer *peer)
> {
> list_del_rcu(&peer->list);
> - kfree_rcu(peer, rcu);
> -
> - module_put(THIS_MODULE);
> + call_rcu(&peer->rcu, lowpan_peer_put_rcu);
>
> if (atomic_dec_and_test(&dev->peer_count)) {
> BT_DBG("last peer");
> @@ -179,7 +212,8 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
> &peer->chan->dst, peer->chan->dst_type,
> &peer->peer_addr);
>
> - if (!ipv6_addr_cmp(&peer->peer_addr, nexthop)) {
> + if (!ipv6_addr_cmp(&peer->peer_addr, nexthop) &&
> + lowpan_peer_get_unless_zero(peer)) {
> rcu_read_unlock();
> return peer;
> }
> @@ -189,7 +223,8 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
> neigh = __ipv6_neigh_lookup(dev->netdev, nexthop);
> if (neigh) {
> list_for_each_entry_rcu(peer, &dev->peers, list) {
> - if (!memcmp(neigh->ha, peer->lladdr, ETH_ALEN)) {
> + if (!memcmp(neigh->ha, peer->lladdr, ETH_ALEN) &&
> + lowpan_peer_get_unless_zero(peer)) {
> neigh_release(neigh);
> rcu_read_unlock();
> return peer;
> @@ -212,8 +247,9 @@ static struct lowpan_peer *lookup_peer(struct l2cap_conn *conn)
>
> list_for_each_entry_rcu(entry, &bt_6lowpan_devices, list) {
> peer = __peer_lookup_conn(entry, conn);
> - if (peer)
> + if (peer && lowpan_peer_get_unless_zero(peer))
> break;
> + peer = NULL;
> }
>
> rcu_read_unlock();
> @@ -361,8 +397,10 @@ static int chan_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
> return -ENOENT;
>
> dev = lookup_dev(chan->conn);
> - if (!dev || !dev->netdev)
> + if (!dev || !dev->netdev) {
> + lowpan_peer_put(peer);
> return -ENOENT;
> + }
>
> err = recv_pkt(skb, dev->netdev, peer);
> if (err) {
> @@ -370,6 +408,8 @@ static int chan_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
> err = -EAGAIN;
> }
>
> + lowpan_peer_put(peer);
> +
> return err;
> }
>
> @@ -380,6 +420,8 @@ static int setup_header(struct sk_buff *skb, struct net_device *netdev,
> struct ipv6hdr *hdr;
> struct lowpan_btle_dev *dev;
> struct lowpan_peer *peer;
> + struct l2cap_chan *chan;
> + u8 peer_lladdr[ETH_ALEN];
> u8 *daddr;
> int err, status = 0;
>
> @@ -388,9 +430,9 @@ static int setup_header(struct sk_buff *skb, struct net_device *netdev,
> dev = lowpan_btle_dev(netdev);
>
> memcpy(&ipv6_daddr, &hdr->daddr, sizeof(ipv6_daddr));
> + lowpan_cb(skb)->peer = NULL;
>
> if (ipv6_addr_is_multicast(&ipv6_daddr)) {
> - lowpan_cb(skb)->chan = NULL;
> daddr = NULL;
> } else {
> BT_DBG("dest IP %pI6c", &ipv6_daddr);
> @@ -406,10 +448,13 @@ static int setup_header(struct sk_buff *skb, struct net_device *netdev,
> return -ENOENT;
> }
>
> - daddr = peer->lladdr;
> - *peer_addr = peer->chan->dst;
> - *peer_addr_type = peer->chan->dst_type;
> - lowpan_cb(skb)->chan = peer->chan;
> + chan = peer->chan;
> + memcpy(peer_lladdr, peer->lladdr, ETH_ALEN);
> + *peer_addr = chan->dst;
> + *peer_addr_type = chan->dst_type;
> + lowpan_cb(skb)->peer = peer;
> +
> + daddr = peer_lladdr;
>
> status = 1;
> }
> @@ -417,8 +462,13 @@ static int setup_header(struct sk_buff *skb, struct net_device *netdev,
> lowpan_header_compress(skb, netdev, daddr, dev->netdev->dev_addr);
>
> err = dev_hard_header(skb, netdev, ETH_P_IPV6, NULL, NULL, 0);
> - if (err < 0)
> + if (err < 0) {
> + if (lowpan_cb(skb)->peer) {
> + lowpan_peer_put(lowpan_cb(skb)->peer);
> + lowpan_cb(skb)->peer = NULL;
> + }
> return err;
> + }
>
> return status;
> }
> @@ -486,6 +536,10 @@ static int send_mcast_pkt(struct sk_buff *skb, struct net_device *netdev)
> int ret;
>
> local_skb = skb_clone(skb, GFP_ATOMIC);
> + if (!local_skb) {
> + err = -ENOMEM;
> + continue;
> + }
>
> BT_DBG("xmit %s to %pMR type %u IP %pI6c chan %p",
> netdev->name,
> @@ -529,11 +583,17 @@ static netdev_tx_t bt_xmit(struct sk_buff *skb, struct net_device *netdev)
> }
>
> if (err) {
> - if (lowpan_cb(skb)->chan) {
> + struct lowpan_peer *peer = lowpan_cb(skb)->peer;
> +
> + if (peer) {
> + struct l2cap_chan *chan = peer->chan;
> +
> BT_DBG("xmit %s to %pMR type %u IP %pI6c chan %p",
> netdev->name, &addr, addr_type,
> - &lowpan_cb(skb)->addr, lowpan_cb(skb)->chan);
> - err = send_pkt(lowpan_cb(skb)->chan, skb, netdev);
> + &lowpan_cb(skb)->addr, chan);
> + err = send_pkt(chan, skb, netdev);
> + lowpan_peer_put(peer);
> + lowpan_cb(skb)->peer = NULL;
> } else {
> err = -ENOENT;
> }
> @@ -649,6 +709,8 @@ static struct l2cap_chan *add_peer_chan(struct l2cap_chan *chan,
> if (!peer)
> return NULL;
>
> + INIT_WORK(&peer->destroy_work, lowpan_peer_destroy);
> + refcount_set(&peer->refcnt, 1);
> peer->chan = chan;
>
> baswap((void *)peer->lladdr, &chan->dst);
> @@ -822,8 +884,6 @@ static void chan_close_cb(struct l2cap_chan *chan)
> last ? "last " : "1 ", peer);
> BT_DBG("chan %p orig refcnt %u", chan,
> kref_read(&chan->kref));
> -
> - l2cap_chan_put(chan);
> break;
> }
> }
> @@ -938,6 +998,7 @@ static int bt_6lowpan_connect(bdaddr_t *addr, u8 dst_type)
> static int bt_6lowpan_disconnect(struct l2cap_conn *conn, u8 dst_type)
> {
> struct lowpan_peer *peer;
> + struct l2cap_chan *chan;
>
> BT_DBG("conn %p dst type %u", conn, dst_type);
>
> @@ -945,11 +1006,14 @@ static int bt_6lowpan_disconnect(struct l2cap_conn *conn, u8 dst_type)
> if (!peer)
> return -ENOENT;
>
> - BT_DBG("peer %p chan %p", peer, peer->chan);
> + chan = peer->chan;
> +
> + BT_DBG("peer %p chan %p", peer, chan);
>
> - l2cap_chan_lock(peer->chan);
> - l2cap_chan_close(peer->chan, ENOENT);
> - l2cap_chan_unlock(peer->chan);
> + l2cap_chan_lock(chan);
> + l2cap_chan_close(chan, ENOENT);
> + l2cap_chan_unlock(chan);
> + lowpan_peer_put(peer);
>
> return 0;
> }
> @@ -1189,6 +1253,7 @@ static ssize_t lowpan_control_write(struct file *fp,
> peer = lookup_peer(conn);
> if (peer) {
> BT_DBG("6LoWPAN connection already exists");
> + lowpan_peer_put(peer);
> return -EALREADY;
> }
>
> @@ -1320,6 +1385,12 @@ static struct notifier_block bt_6lowpan_dev_notifier = {
>
> static int __init bt_6lowpan_init(void)
> {
> + int err;
> +
> + lowpan_peer_wq = alloc_ordered_workqueue("bt_6lowpan_peer", 0);
> + if (!lowpan_peer_wq)
> + return -ENOMEM;
> +
> lowpan_enable_debugfs = debugfs_create_file_unsafe("6lowpan_enable",
> 0644, bt_debugfs,
> NULL,
> @@ -1328,7 +1399,14 @@ static int __init bt_6lowpan_init(void)
> bt_debugfs, NULL,
> &lowpan_control_fops);
>
> - return register_netdevice_notifier(&bt_6lowpan_dev_notifier);
> + err = register_netdevice_notifier(&bt_6lowpan_dev_notifier);
> + if (err) {
> + debugfs_remove(lowpan_enable_debugfs);
> + debugfs_remove(lowpan_control_debugfs);
> + destroy_workqueue(lowpan_peer_wq);
> + }
> +
> + return err;
> }
>
> static void __exit bt_6lowpan_exit(void)
> @@ -1346,6 +1424,8 @@ static void __exit bt_6lowpan_exit(void)
> disconnect_devices();
>
> unregister_netdevice_notifier(&bt_6lowpan_dev_notifier);
> + rcu_barrier();
> + destroy_workqueue(lowpan_peer_wq);
> }
>
> module_init(bt_6lowpan_init);
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v4] Bluetooth: bnep: reject short frames before parsing
From: Cen Zhang @ 2026-05-28 7:35 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, zerocling0077, 2045gemini
In-Reply-To: <20260521052611.1815693-1-rollkingzzc@gmail.com>
Hi Luiz,
Gentle ping on this patch. The current version follows the previous
review feedback and the bluetooth test bot reported no failures.
Please let me know if you would prefer any further changes.
Thanks,
Zhang Cen
Zhang Cen <rollkingzzc@gmail.com> 于2026年5月21日周四 13:26写道：
>
> A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the
> packet type byte immediately and, for control packets, reads the control
> opcode and setup UUID-size byte before proving that those bytes are
> present. bnep_rx_control() also dereferences the control opcode without
> rejecting an empty control payload.
>
> Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL
> return gates each dereference. Split the control handler so the frame
> path can pass an opcode that has already been pulled, and keep the
> byte-buffer wrapper for extension control payloads.
>
> Validation reproduced this kernel report:
> KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790
> The buggy address belongs to the object at ffff88800c0f7908 which belongs
> to the cache kmalloc-8 of size 8
> The buggy address is located 0 bytes to the right of allocated 1-byte
> region [ffff88800c0f7908, ffff88800c0f7909)
> Read of size 1
> Call trace:
> dump_stack_lvl+0xb3/0x140 (?:?)
> print_address_description+0x57/0x3a0 (?:?)
> bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306)
> print_report+0xb9/0x2b0 (?:?)
> __virt_addr_valid+0x1ba/0x3a0 (?:?)
> srso_alias_return_thunk+0x5/0xfbef5 (?:?)
> kasan_addr_to_slab+0x21/0x60 (?:?)
> kasan_report+0xe0/0x110 (?:?)
> process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200)
> worker_thread+0x65c/0xe40 (?:?)
> __kthread_parkme+0x184/0x230 (?:?)
> kthread+0x35e/0x470 (?:?)
> _raw_spin_unlock_irq+0x28/0x50 (?:?)
> ret_from_fork+0x586/0x870 (?:?)
> __switch_to+0x74f/0xdc0 (?:?)
> ret_from_fork_asm+0x1a/0x30 (?:?)
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
> ---
> net/bluetooth/bnep/core.c | 51 ++++++++++++++++++++++++---------------
> 1 file changed, 31 insertions(+), 20 deletions(-)
>
> diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
> index 853c8d764..156cd3026 100644
> --- a/net/bluetooth/bnep/core.c
> +++ b/net/bluetooth/bnep/core.c
> @@ -206,14 +206,11 @@ static int bnep_ctrl_set_mcfilter(struct bnep_session *s, u8 *data, int len)
> return 0;
> }
>
> -static int bnep_rx_control(struct bnep_session *s, void *data, int len)
> +static int bnep_rx_control_cmd(struct bnep_session *s, u8 cmd, void *data,
> + int len)
> {
> - u8 cmd = *(u8 *)data;
> int err = 0;
>
> - data++;
> - len--;
> -
> switch (cmd) {
> case BNEP_CMD_NOT_UNDERSTOOD:
> case BNEP_SETUP_CONN_RSP:
> @@ -254,6 +251,14 @@ static int bnep_rx_control(struct bnep_session *s, void *data, int len)
> return err;
> }
>
> +static int bnep_rx_control(struct bnep_session *s, void *data, int len)
> +{
> + if (len < 1)
> + return -EILSEQ;
> +
> + return bnep_rx_control_cmd(s, *(u8 *)data, data + 1, len - 1);
> +}
> +
> static int bnep_rx_extension(struct bnep_session *s, struct sk_buff *skb)
> {
> struct bnep_ext_hdr *h;
> @@ -299,19 +304,26 @@ static int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb)
> {
> struct net_device *dev = s->dev;
> struct sk_buff *nskb;
> + u8 *data;
> u8 type, ctrl_type;
>
> dev->stats.rx_bytes += skb->len;
>
> - type = *(u8 *) skb->data;
> - skb_pull(skb, 1);
> - ctrl_type = *(u8 *)skb->data;
> + data = skb_pull_data(skb, sizeof(type));
> + if (!data)
> + goto badframe;
> + type = *data;
>
> if ((type & BNEP_TYPE_MASK) >= sizeof(__bnep_rx_hlen))
> goto badframe;
>
> if ((type & BNEP_TYPE_MASK) == BNEP_CONTROL) {
> - if (bnep_rx_control(s, skb->data, skb->len) < 0) {
> + data = skb_pull_data(skb, sizeof(ctrl_type));
> + if (!data)
> + goto badframe;
> + ctrl_type = *data;
> +
> + if (bnep_rx_control_cmd(s, ctrl_type, skb->data, skb->len) < 0) {
> dev->stats.tx_errors++;
> kfree_skb(skb);
> return 0;
> @@ -325,23 +337,22 @@ static int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb)
> /* Verify and pull ctrl message since it's already processed */
> switch (ctrl_type) {
> case BNEP_SETUP_CONN_REQ:
> - /* Pull: ctrl type (1 b), len (1 b), data (len bytes) */
> - if (!skb_pull(skb, 2 + *(u8 *)(skb->data + 1) * 2))
> + /* Pull: len (1 b), data (len * 2 bytes) */
> + data = skb_pull_data(skb, 1);
> + if (!data)
> + goto badframe;
> + if (!skb_pull(skb, *data * 2))
> goto badframe;
> break;
> case BNEP_FILTER_MULTI_ADDR_SET:
> - case BNEP_FILTER_NET_TYPE_SET: {
> - u8 *hdr;
> -
> - /* Pull ctrl type (1 b) + len (2 b) */
> - hdr = skb_pull_data(skb, 3);
> - if (!hdr)
> + case BNEP_FILTER_NET_TYPE_SET:
> + /* Pull: len (2 b), data (len bytes) */
> + data = skb_pull_data(skb, sizeof(u16));
> + if (!data)
> goto badframe;
> - /* Pull data (len bytes); length is big-endian */
> - if (!skb_pull(skb, get_unaligned_be16(&hdr[1])))
> + if (!skb_pull(skb, get_unaligned_be16(data)))
> goto badframe;
> break;
> - }
> default:
> kfree_skb(skb);
> return 0;
> --
> 2.43.0
>
^ permalink raw reply
* Re: [v4] Bluetooth: bnep: reject short frames before parsing
From: Cen Zhang @ 2026-05-28 7:34 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <6a0ebd2f.df581d38.61261.d5cb@mx.google.com>
Hi Luiz,
Gentle ping on this patch. The current version follows the previous
review feedback and the bluetooth test bot reported no failures.
Please let me know if you would prefer any further changes.
Thanks,
Zhang Cen
<bluez.test.bot@gmail.com> 于2026年5月21日周四 16:07写道：
>
> 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=1098453
>
> ---Test result---
>
> Test Summary:
> CheckPatch PASS 0.49 seconds
> GitLint PASS 0.19 seconds
> SubjectPrefix PASS 0.06 seconds
> BuildKernel PASS 19.75 seconds
> CheckAllWarning PASS 25.20 seconds
> CheckSparse PASS 22.00 seconds
> BuildKernel32 PASS 19.79 seconds
> TestRunnerSetup PASS 412.06 seconds
> TestRunner_bnep-tester PASS 14.59 seconds
> IncrementalBuild PASS 22.14 seconds
>
>
>
> https://github.com/bluez/bluetooth-next/pull/228
>
> ---
> Regards,
> Linux Bluetooth
>
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-28 5:38 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1086507
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-27
From: Jakub Kicinski @ 2026-05-28 2:24 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, linux-bluetooth, netdev
In-Reply-To: <20260527211246.371451-1-luiz.dentz@gmail.com>
On Wed, 27 May 2026 17:12:46 -0400 Luiz Augusto von Dentz wrote:
> The following changes since commit ab1513597c6cf17cd1ad2a21e3b045421b48e022:
>
> Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() (2026-05-20 16:35:47 -0400)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-27
>
> for you to fetch changes up to df35e8e0c8c4160c881bb673e3c7ee010824fbd5:
>
> Bluetooth: hci_sync: Reset device counters in hci_dev_close_sync() (2026-05-27 16:44:02 -0400)
Are you still rebasing? Or did Linus convince you not to? :)
Looks like we are missing your sign-off on:
Commit c3d01980c64a ("Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success")
committer Signed-off-by missing
author email: kipreyyy@gmail.com
committer email: luiz.von.dentz@intel.com
Signed-off-by: Zhenghang Xiao <kipreyyy@gmail.com>
If you're planning to no longer rebase your tress - don't worry about
it. It's not a deal breaker. If you are rebasing anyway - could you
amend?
^ permalink raw reply
* RE: [PATCH] Bluetooth: Add SPDX id lines to some source files
From: Bird, Tim @ 2026-05-28 0:03 UTC (permalink / raw)
To: Richard Fontana
Cc: marcel@holtmann.org, luiz.dentz@gmail.com, jannh@google.com,
kuba@kernel.org, kiran.k@intel.com, chharry@chromium.org,
gustavo@padovan.org, prameela.j04cs@gmail.com,
salvatore.benedetto@intel.com, maxk@qualcomm.com,
linux-bluetooth@vger.kernel.org, linux-spdx@vger.kernel.org,
linux-kernel@vger.kernel.org, J Lovejoy
In-Reply-To: <CAC1cPGzmKeonuzjA2xzn6qXrT3Bcj=DGOfkq_BXUSMXJ7ZHY1g@mail.gmail.com>
Hey Richard,
> -----Original Message-----
> From: Richard Fontana <rfontana@redhat.com>
> (cc'ing Jilayne Lovejoy in case she doesn't get these)
>
> On Fri, May 22, 2026 at 8:14 PM Tim Bird <tim.bird@sony.com> wrote:
> >
> > Many bluetooth source files are missing SPDX-License-Identifier
> > lines. Add appropriate IDs to these files, and remove other
> > license lines from the headers.
>
> So the subset of patches I've quoted below, most but not all of which
> seem to be associated with Maxim Krasnyansky <maxk@qualcomm.com>, all
> feature warranty disclaimer language that includes a disclaimer of
> warranty of "NONINFRINGEMENT OF THIRD PARTY RIGHTS" (and furthermore
> states "ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY
> PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF
> THIS SOFTWARE IS DISCLAIMED."). The GPLv2 warranty disclaimer
> language, and the abbreviated warranty disclaimer language in the
> FSF/GPLv2 "standard" notice often seen in kernel source files, itself
> does not refer to the warranty of noninfringement (disclaimers of
> which I believe did not become common in software industry licenses
> until well after the advent of GPLv2 and its predecessors).
Good catch. I didn't notice the warranty disclaimer difference (which
is a bit embarrassing on my part).
I'll redo this patch, leaving this different warranty language intact.
>
> Several years ago, when this effort to replace bespoke license notices
> with SPDX-License-Identifier strings got started, an issue was raised
> around what to do about license notices that included disclaimers of
> warranties going beyond what's recited in GPLv2, or those GPLv2
> standard notices. There's an argument that it would be inappropriate,
> and contrary to the licensor intent, to delete them, as you propose to
> do here (without permission from the authors/copyright owners).
I agree with this stance (that it's inappropriate to remove them)
In the next version of this patch I'll leave these "extended" disclaimers.
> I seem
> to remember Jilayne making an effort to gather views from lawyers in
> the field about this topic but I'm not sure what if anything became of
> that.
It would be nice to get a legal opinion. There are two different
issues, IMHO.
Issue 1: Is it legitimate to apply an additional level of legal disclaimer to the GPL 2.0
license itself? The language in section 1 of GPL v2 says "you may copy and distribute...[stuff]..
provided that you conspicuously and appropriately publish on each copy an appropriate copyright
notice and disclaimer of warranty. It say "an appropriate ... disclaimer of warranty". *"an"*
It doesn't say "the specific disclaimer of warranty contained herein" or anything else like that.
But 2b GPL v2 also does say "You must cause any work ... [derived from the Program]
.. to be licensed as a whole at no charge ... under the terms of this License." And sections
11 and 12 contain "the official" disclaimer of warranty for GPL v2.
(And actually, I think the official disclaimer wording: "WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO" is rather all-encompassing,
and legally also covers the extra issues explicitly mentioned in these Bluetooth header warranty disclaimers).
Unless I hear otherwise, I'm going to assume that It's legally OK to apply/retain
another level of warranty disclaimer, without creating a legal contradiction here.
If there *is* a contradiction by these extra disclaimers, then likely we would have to get
Qualcomm legal to agree to some resolution. A lot of this code was contributed in 2001
and 2002, so at least the patent concerns (for those parts) may be mostly eliminated by now.
Issue 2: if there is no legal contradiction, is it satisfactory to just leave the "extra" warranty
disclaimer, along with the SPDX-License-Identifier, without further explanatory text?
I believe so. But still - I may put a little notice on the warranty disclaimer left in these files
to explain that there are now multiple disclaimers in force (the GPL 2.0 one, and this one).
I actually think these two disclaimers are legally equivalent, but obviously some lawyers
disagree, or they wouldn't have written a new disclaimer and put it on here.
Do you have any opinion on adding a little note about this in these files (to go along
with the leftover disclaimers)?
> It's fairly likely that such language in other source files has
> just gotten deleted since then without anyone noticing the issue.
Yeah, probably.
I'll add this to my list of things to double-check to avoid any
contribution by me to this issue in the future.
Thanks!
-- Tim
> > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > index 3faea66b1979..e921ade2f61b 100644
> > --- a/include/net/bluetooth/bluetooth.h
> > +++ b/include/net/bluetooth/bluetooth.h
> > @@ -1,26 +1,10 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > /*
> > BlueZ - Bluetooth protocol stack for Linux
> > Copyright (C) 2000-2001 Qualcomm Incorporated
> > Copyright 2023 NXP
> >
> > Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
> > -
> > - This program is free software; you can redistribute it and/or modify
> > - it under the terms of the GNU General Public License version 2 as
> > - published by the Free Software Foundation;
> > -
> > - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > - OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
> > - IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
> > - CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
> > - WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > - ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > - OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > -
> > - ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS,
> > - COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
> > - SOFTWARE IS DISCLAIMED.
> > */
> >
> > #ifndef __BLUETOOTH_H
...
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-27 22:48 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1101147
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 0039e1: emulator/btdev: Add LE Set Host Feature V2 command...
From: Luiz Augusto von Dentz @ 2026-05-27 22:47 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: 0039e1bec0a59ec3b3982113e06a0b16898b51b5
https://github.com/bluez/bluez/commit/0039e1bec0a59ec3b3982113e06a0b16898b51b5
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-26 (Tue, 26 May 2026)
Changed paths:
M emulator/btdev.c
Log Message:
-----------
emulator/btdev: Add LE Set Host Feature V2 command emulation
Add emulation for LE Set Host Feature V2 (0x2097) command which
uses a 16-bit bit_number field (vs 8-bit in v1) to allow setting
extended LE feature bits. The command bit is set at byte 47 bit 4
as defined in bt.h.
Assisted-by: OpenCode:claude-opus-4.6
Commit: 68edaa560e92d5ee39bd97a80e20afbd2cde3c8f
https://github.com/bluez/bluez/commit/68edaa560e92d5ee39bd97a80e20afbd2cde3c8f
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-26 (Tue, 26 May 2026)
Changed paths:
M monitor/bt.h
M monitor/packet.c
Log Message:
-----------
monitor: Add decoding support for LE Set Host Feature V2
Add decoding support for LE Set Host Feature V2 (0x2097) command
which uses a 16-bit bit_number field to support extended LE feature
pages:
< HCI Command: LE Set Host F.. (0x08|0x0097) plen 3
Bit Number: 32
Features[0/0][8]:
00 00 00 00 01 00 00 00 ........
Connected Isochronous Stream (Host Support)
Bit Value: 1
> HCI Event: Command Complete (0x0e) plen 4
LE Set Host Feature V2 (0x08|0x0097) ncmd 1
Status: Success (0x00)
Assisted-by: OpenCode:claude-opus-4.6
Compare: https://github.com/bluez/bluez/compare/b493164ffbff...68edaa560e92
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH BlueZ v1 1/2] emulator/btdev: Add LE Set Host Feature V2 command emulation
From: patchwork-bot+bluetooth @ 2026-05-27 21:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260526170309.3529062-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, 26 May 2026 13:03:08 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> Add emulation for LE Set Host Feature V2 (0x2097) command which
> uses a 16-bit bit_number field (vs 8-bit in v1) to allow setting
> extended LE feature bits. The command bit is set at byte 47 bit 4
> as defined in bt.h.
>
> [...]
Here is the summary with links:
- [BlueZ,v1,1/2] emulator/btdev: Add LE Set Host Feature V2 command emulation
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=0039e1bec0a5
- [BlueZ,v1,2/2] monitor: Add decoding support for LE Set Host Feature V2
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=68edaa560e92
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] advertising: add property with advertisement ID
From: Luiz Augusto von Dentz @ 2026-05-27 21:16 UTC (permalink / raw)
To: Michal Dzik; +Cc: linux-bluetooth
In-Reply-To: <20260525041151.3893522-1-michal.dzik@streamunlimited.com>
Hi Michal,
On Mon, May 25, 2026 at 12:12 AM Michal Dzik
<michal.dzik@streamunlimited.com> wrote:
>
> Identifier is an internal value, but it must be exposed to client app
> if client app wants to use a advertisement in BAP broadcast
> ---
> doc/org.bluez.LEAdvertisement.rst | 6 ++++++
> src/advertising.c | 13 ++++++++++++-
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/doc/org.bluez.LEAdvertisement.rst b/doc/org.bluez.LEAdvertisement.rst
> index aae80f08f..4dd36a0cc 100644
> --- a/doc/org.bluez.LEAdvertisement.rst
> +++ b/doc/org.bluez.LEAdvertisement.rst
> @@ -235,3 +235,9 @@ The provided value is used only if the "CanSetTxPower" feature is enabled on the
> **org.bluez.LEAdvertisingManager(5)**.
>
> Values must be in range [-127 to +20], where units are in dBm.
> +
> +byte Identifier [read-write, optional]
> +``````````````````````````````````````
We use the term instance in other part of the API so Id got with that:
https://github.com/bluez/bluez/blob/master/doc/org.bluez.LEAdvertisingManager.rst#byte-activeinstances-readonly
> +Identifier of the advertisement. Set by bluetoothd after advertisement is registered with
> +**org.bluez.LEAdvertisingManager(5)**.
> diff --git a/src/advertising.c b/src/advertising.c
> index f529ecd14..3b758f51e 100644
> --- a/src/advertising.c
> +++ b/src/advertising.c
> @@ -1511,8 +1511,19 @@ static void add_client_complete(struct btd_adv_client *client, uint8_t status)
> queue_remove(client->manager->clients, client);
> g_idle_add(client_free_idle_cb, client);
>
> - } else
> + } else {
> + DBusMessageIter iter;
> +
> + /* Check if the attribute has the Identifier property */
> + if (g_dbus_proxy_get_property(client->proxy, "Identifier",
> + &iter)) {
> + g_dbus_proxy_set_property_basic(client->proxy,
> + "Identifier", DBUS_TYPE_BYTE, &client->instance,
> + NULL, NULL, NULL);
> + }
> +
> reply = dbus_message_new_method_return(client->reg);
> + }
>
> g_dbus_send_message(btd_get_dbus_connection(), reply);
> dbus_message_unref(client->reg);
> --
> 2.43.0
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [GIT PULL] bluetooth 2026-05-27
From: Luiz Augusto von Dentz @ 2026-05-27 21:12 UTC (permalink / raw)
To: davem, kuba; +Cc: linux-bluetooth, netdev
The following changes since commit ab1513597c6cf17cd1ad2a21e3b045421b48e022:
Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() (2026-05-20 16:35:47 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-27
for you to fetch changes up to df35e8e0c8c4160c881bb673e3c7ee010824fbd5:
Bluetooth: hci_sync: Reset device counters in hci_dev_close_sync() (2026-05-27 16:44:02 -0400)
----------------------------------------------------------------
bluetooth pull request for net:
- hci_core: Rework hci_dev_do_reset() to use hci_sync functions
- hci_conn: Fix memory leak in hci_le_big_terminate()
- hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close
- hci_sync: Reset device counters in hci_dev_close_sync()
- hci_sync: fix UAF in hci_le_create_cis_sync
- L2CAP: Fix possible crash on l2cap_ecred_conn_rsp
- L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn
- L2CAP: use chan timer to close channels in cleanup_listen()
- L2CAP: clear chan->ident on ECRED reconfiguration success
- ISO: fix UAF in iso_recv_frame
- ISO: serialize iso_sock_clear_timer with socket lock
- HIDP: fix missing length checks in hidp_input_report()
- 6lowpan: check skb_clone() return value in send_mcast_pkt()
- btusb: Allow firmware re-download when version matches
- hci_qca: Use 100 ms SSR delay for rampatch and NVM loading
----------------------------------------------------------------
Doruk Tan Ozturk (1):
Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync
Heitor Alves de Siqueira (3):
Bluetooth: hci_core: Rework hci_dev_do_reset() to use hci_sync functions
Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close
Bluetooth: hci_sync: Reset device counters in hci_dev_close_sync()
Luiz Augusto von Dentz (1):
Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp
Muhammad Bilal (3):
Bluetooth: HIDP: fix missing length checks in hidp_input_report()
Bluetooth: ISO: fix UAF in iso_recv_frame
Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock
Pavitra Jha (1):
Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()
Shuai Zhang (2):
Bluetooth: btusb: Allow firmware re-download when version matches
Bluetooth: hci_qca: Use 100 ms SSR delay for rampatch and NVM loading
Siwei Zhang (2):
Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn
Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
Zhao Dongdong (1):
Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()
Zhenghang Xiao (1):
Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success
drivers/bluetooth/btusb.c | 8 +++++++-
drivers/bluetooth/hci_qca.c | 4 ++--
net/bluetooth/6lowpan.c | 2 ++
net/bluetooth/hci_conn.c | 4 +++-
net/bluetooth/hci_core.c | 43 +++----------------------------------------
net/bluetooth/hci_sync.c | 16 +++++++++++++++-
net/bluetooth/hidp/core.c | 23 ++++++++++++++++++-----
net/bluetooth/iso.c | 12 ++++++++----
net/bluetooth/l2cap_core.c | 41 +++++++++++++++++++++++++++++++++--------
net/bluetooth/l2cap_sock.c | 16 +++++++++-------
10 files changed, 100 insertions(+), 69 deletions(-)
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-27 21:07 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1086393
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH v2 0/3] Bluetooth: hci_core: Refactor HCI reset functions
From: patchwork-bot+bluetooth @ 2026-05-27 20:50 UTC (permalink / raw)
To: Heitor Alves de Siqueira
Cc: marcel, luiz.dentz, padovan, schspa, linux-bluetooth,
linux-kernel, kernel-dev, luiz.von.dentz
In-Reply-To: <20260526-hci_send-v2-0-596977a9a814@igalia.com>
Hello:
This series was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 26 May 2026 10:50:56 -0300 you wrote:
> Dear maintainers,
>
> While investigating some warnings reported by syzbot on the hdev
> workqueue, Luiz kindly mentioned the possibility of reworking the reset
> functions in hci_core. A lot of the work done "manually" in
> hci_dev_do_reset() is already handled by the close/open functions in
> hci_sync, and those also handle missing functionality related to LE,
> discovery and advertising.
>
> [...]
Here is the summary with links:
- [v2,1/3] Bluetooth: hci_core: Rework hci_dev_do_reset() to use hci_sync functions
https://git.kernel.org/bluetooth/bluetooth-next/c/54f93846b7a8
- [v2,2/3] Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close
https://git.kernel.org/bluetooth/bluetooth-next/c/db6e813f5789
- [v2,3/3] Bluetooth: hci_sync: Reset device counters in hci_dev_close_sync()
https://git.kernel.org/bluetooth/bluetooth-next/c/a92f90568cc9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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