* Re: [PATCH net] 6lowpan: fix off-by-one in multicast context address compression
From: patchwork-bot+netdevbpf @ 2026-06-02 2:30 UTC (permalink / raw)
To: Yizhou Zhao
Cc: netdev, alex.aring, davem, edumazet, kuba, pabeni, horms,
linux-bluetooth, linux-wpan, linux-kernel, yangyx22, wangao,
fengxw06, qli01, xuke
In-Reply-To: <20260527081806.42747-1-zhaoyz24@mails.tsinghua.edu.cn>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 27 May 2026 16:18:01 +0800 you wrote:
> The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses
> &data[1] as destination and &ipaddr->s6_addr[11] as source, but
> both should be offset by one: &data[2] and &ipaddr->s6_addr[12]
> respectively.
>
> This off-by-one has two consequences:
> 1. data[1] is overwritten with s6_addr[11], corrupting the RIID
> field in the compressed multicast address
> 2. data[5] is never written, so uninitialized kernel stack memory
> is transmitted over the network via lowpan_push_hc_data(),
> leaking kernel stack contents
>
> [...]
Here is the summary with links:
- [net] 6lowpan: fix off-by-one in multicast context address compression
https://git.kernel.org/netdev/net/c/2a58899d1100
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: hci_sync: fix simultaneous discovery stuck in FINDING
From: Jiajia Liu @ 2026-06-02 2:23 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Brian Gix, linux-bluetooth, linux-kernel
In-Reply-To: <CABBYNZJ2Bm1Zw40hVEKQYuXjOLvLv8V+CrTugm4_1sbFdUw=Kg@mail.gmail.com>
On Mon, Jun 01, 2026 at 09:32:38AM -0400, Luiz Augusto von Dentz wrote:
> Hi Jiajia,
>
> On Sun, May 31, 2026 at 9:26 PM Jiajia Liu <liujiajia@kylinos.cn> wrote:
> >
> > When hci_inquiry_complete_evt is called between le_scan_disable and
> > le_set_scan_enable_complete and no remote name needs to be resolved,
> > the interleaved discovery with SIMULTANEOUS quirk gets stuck in
> > DISCOVERY_FINDING. le_set_scan_enable_complete does not check inquiry
> > state. No one sets DISCOVERY_STOPPED in this process.
> >
> > < HCI Command: LE Set Extended Scan Enable #1764 [hci0] 608.610392
> > Extended scan: Disabled (0x00)
> > Filter duplicates: Disabled (0x00)
> > Duration: 0 msec (0x0000)
> > Period: 0.00 sec (0x0000)
> > > HCI Event: Inquiry Complete (0x01) #1765 [hci0] 608.610548
> > Status: Success (0x00)
> > > HCI Event: Command Complete (0x0e) #1766 [hci0] 608.611589
> > LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
> > Status: Success (0x00)
>
> This isn't enough, though, where are the MGMT commands?
It was the last output where the scan was stuck in finding state during
scan test. No Discovering: Disabled MGMT Event report.
complete reproduction log is at
https://drive.google.com/file/d/1dsCtntVdh0zFK6QsbxW26UWjJQE_1xMS/view?usp=sharing
The summary of this last scan including Start Discovery.
@ MGMT Command: Start Discovery (0x0023) plen 1 {0x0001} [hci0] 598.347552
Address type: 0x07
BR/EDR
LE Public
LE Random
...
< HCI Command: LE Set Extended Scan Enable (0x08|0x0042) plen 6 #1741 [hci0] 598.357554
Extended scan: Enabled (0x01)
Filter duplicates: Enabled (0x01)
Duration: 0 msec (0x0000)
Period: 0.00 sec (0x0000)
> HCI Event: Command Complete (0x0e) plen 4 #1742 [hci0] 598.359436
LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
Status: Success (0x00)
@ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 598.359535
Address type: 0x07
BR/EDR
LE Public
LE Random
Discovery: Enabled (0x01)
< HCI Command: Inquiry (0x01|0x0001) plen 5 #1743 [hci0] 598.359568
Access code: 0x9e8b33 (General Inquiry)
Length: 10.24s (0x08)
Num responses: 0
> HCI Event: Command Status (0x0f) plen 4 #1744 [hci0] 598.361410
Inquiry (0x01|0x0001) ncmd 2
Status: Success (0x00)
...
>
> > Add scan_disable_complete to check state and stop discovery if stuck.
> > Tested with bluetooth AX201 (8087:0026) in Dell Vostro 13 laptop.
> >
> > [4517.963204] hci0: state 0 -> 1
> > [4518.096858] hci0: state 1 -> 2
> > [4528.353765] hci0: state 2 -> 0
> > [4528.353776] hci0: state finding to stopped
> > [4533.966844] hci0: state 0 -> 1
> > [4534.097702] hci0: state 1 -> 2
> > [4544.478600] hci0: state 2 -> 0
> >
> > Fixes: 8ffde2a73f2c ("Bluetooth: Convert le_scan_disable timeout to hci_sync")
> > Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> > ---
> > net/bluetooth/hci_sync.c | 25 ++++++++++++++++++++++++-
> > 1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> > index aff8562a8690..4cb1c82cc3f0 100644
> > --- a/net/bluetooth/hci_sync.c
> > +++ b/net/bluetooth/hci_sync.c
> > @@ -361,6 +361,28 @@ static int interleaved_inquiry_sync(struct hci_dev *hdev, void *data)
> > return hci_inquiry_sync(hdev, DISCOV_INTERLEAVED_INQUIRY_LEN, 0);
> > }
> >
> > +static void scan_disable_complete(struct hci_dev *hdev, void *data, int err)
> > +{
> > + if (err)
> > + return;
> > +
> > + hci_dev_lock(hdev);
> > +
> > + if (hdev->discovery.type != DISCOV_TYPE_INTERLEAVED)
> > + goto unlock;
> > +
> > + if (hci_test_quirk(hdev, HCI_QUIRK_SIMULTANEOUS_DISCOVERY)) {
> > + if (!test_bit(HCI_INQUIRY, &hdev->flags) &&
> > + hdev->discovery.state == DISCOVERY_FINDING) {
> > + hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
> > + bt_dev_dbg(hdev, "state finding to stopped");
>
> hci_discovery_set_state already prints the state so printing it again
> is probably unnecessary. Also, this probably needs to be handled via
> hci_event.c since it is not necessarily le_scan_disable that would
> cause scan to be disabled, hci_scan_disable_sync can cause it as well.
will move to le_set_scan_enable_complete
>
> > + }
> > + }
> > +
> > +unlock:
> > + hci_dev_unlock(hdev);
> > +}
> > +
> > static void le_scan_disable(struct work_struct *work)
> > {
> > struct hci_dev *hdev = container_of(work, struct hci_dev,
> > @@ -373,7 +395,8 @@ static void le_scan_disable(struct work_struct *work)
> > if (!hci_dev_test_flag(hdev, HCI_LE_SCAN))
> > goto _return;
> >
> > - status = hci_cmd_sync_queue(hdev, scan_disable_sync, NULL, NULL);
> > + status = hci_cmd_sync_queue(hdev, scan_disable_sync, NULL,
> > + scan_disable_complete);
> > if (status) {
> > bt_dev_err(hdev, "failed to disable LE scan: %d", status);
> > goto _return;
> > --
> > 2.53.0
> >
>
>
> --
> Luiz Augusto von Dentz
^ permalink raw reply
* RE: [v2,1/2] Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync
From: bluez.test.bot @ 2026-06-01 23:47 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260601204157.13923-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3508 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=1104231
---Test result---
Test Summary:
CheckPatch FAIL 1.31 seconds
VerifyFixes PASS 0.12 seconds
VerifySignedoff PASS 0.12 seconds
GitLint FAIL 0.59 seconds
SubjectPrefix PASS 0.22 seconds
BuildKernel PASS 24.89 seconds
CheckAllWarning PASS 27.42 seconds
CheckSparse PASS 26.41 seconds
BuildKernel32 PASS 24.37 seconds
TestRunnerSetup PASS 520.37 seconds
TestRunner_iso-tester PASS 78.40 seconds
IncrementalBuild PASS 26.38 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v2,1/2] Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync
WARNING: Reported-by: should be immediately followed by Closes: with a URL to the report
#103:
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
total: 0 errors, 1 warnings, 0 checks, 7 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/14605715.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v2,2/2] Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#112:
During the unlocked window, could a concurrent close() destroy the connection
WARNING: Reported-by: should be immediately followed by Closes: with a URL to the report
#118:
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
total: 0 errors, 2 warnings, 0 checks, 8 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/14605716.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
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:
[v2,2/2] Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer
7: B3 Line contains hard tab characters (\t): " bis = iso_pi(sk)->conn->hcon;"
8: B3 Line contains hard tab characters (\t): " /* Release the socket before lookups since that requires hci_dev_lock"
9: B3 Line contains hard tab characters (\t): " * which shall not be acquired while holding sock_lock for proper"
10: B3 Line contains hard tab characters (\t): " * ordering."
11: B3 Line contains hard tab characters (\t): " */"
12: B3 Line contains hard tab characters (\t): " release_sock(sk);"
13: B3 Line contains hard tab characters (\t): " hci_dev_lock(bis->hdev);"
https://github.com/bluez/bluetooth-next/pull/271
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Bluetooth: hci_h5: reset hci_uart::priv in the close() method
From: bluez.test.bot @ 2026-06-01 23:46 UTC (permalink / raw)
To: linux-bluetooth, s.shtylyov
In-Reply-To: <4f997f21-786e-4745-80c1-0d6da94c0d48@auroraos.dev>
[-- 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=1104221
---Test result---
Test Summary:
CheckPatch PASS 0.59 seconds
VerifyFixes PASS 0.09 seconds
VerifySignedoff PASS 0.09 seconds
GitLint PASS 0.24 seconds
SubjectPrefix PASS 0.08 seconds
BuildKernel PASS 25.29 seconds
CheckAllWarning PASS 27.74 seconds
CheckSparse PASS 26.86 seconds
BuildKernel32 PASS 24.91 seconds
TestRunnerSetup PASS 540.54 seconds
IncrementalBuild PASS 24.70 seconds
https://github.com/bluez/bluetooth-next/pull/270
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [RFC PATCH 0/5] Bluetooth: enable context analysis
From: Pauli Virtanen @ 2026-06-01 20:59 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZKjKr5yM2ORC_v67tpCOuDe86WT6e4hYbOFL92RNOtTcQ@mail.gmail.com>
Hi Luiz,
1. kesäkuuta 2026 19.42.39 UTC Luiz Augusto von Dentz <luiz.dentz@gmail.com> kirjoitti:
>Hi Pauli,
>
>On Sat, May 16, 2026 at 7:15 AM Pauli Virtanen <pav@iki.fi> wrote:
>>
>> Set up compiler context analysis that generate compiler warnings on
>> problems that Clang -Wthread-safety can detect:
>>
>> https://docs.kernel.org/dev-tools/context-analysis.html
>>
>> Clang 22, and probably Clang 23 [1] will be required. Sparse locking
>> analysis support was removed in commit
>> 5b63d0ae94ccfd64dcbdb693d88eb3650eb3c64c, this is its successor.
>>
>> This series enables the analysis and adds minimal annotations to silence
>> some false positives.
>>
>> Also, one patch to fix what looks like a legitimate locking issue in
>> iso.c.
>>
>> In future, it probably is a good idea to make more use of it and add
>> __must_hold, __guarded_by etc annotations.
>>
>> Kernel test robot appears to be checking for these, but not sure in what
>> trees [2]
>>
>> BlueZ testbot doesn't check these currently but it's possible to add
>> https://github.com/bluez/action-ci/pull/4
>
>I would like to merge the above changes to action-ci but apparently
>there are some conflicts. Can you fix that? It seems fine as a
>starting point so we might as well merge it if there is nothing
>blocking it. Or did you submit it as an RFC because something is still
>pending?
I can fix the conflicts in the action-ci, should have time for that next week.
This series is also RFC mostly since we don't have this in CI.
>
>> [1] https://lore.kernel.org/all/CANpmjNN4O=W70sAc5gaVkTAFdrGGOW+XBMyuehfz3_QMiT=uCw@mail.gmail.com/
>> [2] https://lore.kernel.org/all/202605060005.JYWpZXr2-lkp@intel.com/
>>
>> Pauli Virtanen (5):
>> Bluetooth: af_bluetooth: Add minimal context analysis annotations
>> Bluetooth: hci_core: Add minimal context analysis annotations
>> Bluetooth: ISO: lock same hdev as what is released
>> Bluetooth: L2CAP: Add minimal context analysis annotations
>> Bluetooth: enable context analysis
>>
>> drivers/bluetooth/Makefile | 2 ++
>> net/bluetooth/Makefile | 2 ++
>> net/bluetooth/af_bluetooth.c | 7 +++++--
>> net/bluetooth/hci_core.c | 3 +++
>> net/bluetooth/iso.c | 14 ++++++++------
>> net/bluetooth/l2cap_sock.c | 1 +
>> 6 files changed, 21 insertions(+), 8 deletions(-)
>>
>> --
>> 2.54.0
>>
>>
>
>
^ permalink raw reply
* [PATCH v2 2/2] Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer
From: Luiz Augusto von Dentz @ 2026-06-01 20:41 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260601204157.13923-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
In iso_sock_rebind_bc(), the bis pointer is cached, then the socket lock is
dropped:
bis = iso_pi(sk)->conn->hcon;
/* Release the socket before lookups since that requires hci_dev_lock
* which shall not be acquired while holding sock_lock for proper
* ordering.
*/
release_sock(sk);
hci_dev_lock(bis->hdev);
During the unlocked window, could a concurrent close() destroy the connection
and free the bis structure, causing hci_dev_lock(bis->hdev) to access memory
after it is freed, fix this by using the hdev reference which was safely
acquired via iso_conn_get_hdev().
Fixes: d3413703d5f8 ("Bluetooth: ISO: Add support to bind to trigger PAST")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/iso.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
index a93269eb53b7..8c52800bb93a 100644
--- a/net/bluetooth/iso.c
+++ b/net/bluetooth/iso.c
@@ -1083,7 +1083,7 @@ static int iso_sock_rebind_bc(struct sock *sk, struct sockaddr_iso *sa,
* ordering.
*/
release_sock(sk);
- hci_dev_lock(bis->hdev);
+ hci_dev_lock(hdev);
lock_sock(sk);
if (!iso_pi(sk)->conn || iso_pi(sk)->conn->hcon != bis) {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync
From: Luiz Augusto von Dentz @ 2026-06-01 20:41 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
hci_get_route() returns a reference-counted hci_dev pointer via
hci_dev_hold(). The function exits normally or with an error without ever
releasing it.
Fixes: 07a9342b94a9 ("Bluetooth: ISO: Send BIG Create Sync via hci_sync")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/iso.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
index eef3a1332893..a93269eb53b7 100644
--- a/net/bluetooth/iso.c
+++ b/net/bluetooth/iso.c
@@ -1596,6 +1596,7 @@ static void iso_conn_big_sync(struct sock *sk)
release_sock(sk);
hci_dev_unlock(hdev);
+ hci_dev_put(hdev);
}
static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg,
--
2.53.0
^ permalink raw reply related
* [PATCH] Bluetooth: hci_h5: reset hci_uart::priv in the close() method
From: Sergey Shtylyov @ 2026-06-01 20:21 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth
Unlike the other HCI UART drivers, the 3-wire UART driver doesn't reset
hci_uart::priv in its close() method -- this shouldn't pose a problem as
all the methods in *struct* hci_uart_proto should only be called after the
open() method that sets up hci_uart::priv properly. However, it seems wise
to be more consistent and provide for the *struct* hci_uart_proto methods
the same state that exists before the first open() method call (so that
they rather crash than dereference a stale hci_uart::priv pointer)...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev>
---
The patch is against the master branch of the bluetooth-next.git repo.
drivers/bluetooth/hci_h5.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index d35383718212..c6d9f70ad3bb 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -273,6 +273,7 @@ static int h5_close(struct hci_uart *hu)
if (!hu->serdev)
kfree(h5);
+ hu->priv = NULL;
return 0;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] bluetooth: btintel: Add Bluetooth SAR revision 2 support
From: Luiz Augusto von Dentz @ 2026-06-01 20:02 UTC (permalink / raw)
To: Kiran K
Cc: linux-bluetooth, ravishankar.srivatsa, chethan.tumkur.narayan,
Ravindra
In-Reply-To: <20260601124825.216489-1-kiran.k@intel.com>
Hi Kiran,
On Mon, Jun 1, 2026 at 8:29 AM Kiran K <kiran.k@intel.com> wrote:
>
> BRDS revision 2 introduces per-chain (Chain A and Chain B) TX power
> limits across five sub-bands (2.4G, 5.2G, 5.8/5.9G, 6G-low, 6G-high),
> replacing the single-chain per-modulation model of revisions 0 and 1.
>
> - Add btintel_set_sar_rev2() which sends the full Rev2 DDC sequence:
> 0x019e inc-power-mode enable flag (1 byte)
> 0x0311 2.4 GHz sub-band limits (2 bytes)
> 0x0312 5.2 GHz sub-band limits (2 bytes)
> 0x0313 5.8/5.9 GHz sub-band limits (2 bytes)
> 0x0314 5.8/5.9 GHz sub-band limits again (2 bytes, duplicate FW reg)
> 0x0315 6 GHz low sub-band limits (2 bytes)
> 0x0316 6 GHz high sub-band limits (2 bytes)
> followed by the SAR-init-complete command (0xfe25).
>
> logs from dmesg when BTSAR2 is enabled in Coreboot/BIOS:
>
> Bluetooth: hci0: BT SAR Rev2: revision=2 bt_sar_bios=1 inc_power_mode=1
> Bluetooth: hci0: BT SAR Rev2 Chain A: 2g4=76 5g2=0 5g8_5g9=0 6g1=0 6g3=0
> Bluetooth: hci0: BT SAR Rev2 Chain B: 2g4=102 5g2=0 5g8_5g9=0 6g1=0 6g3=0
>
> Signed-off-by: Ravindra <ravindra@intel.com>
> Signed-off-by: Kiran K <kiran.k@intel.com>
> ---
> changes in v2:
> - Update commit message to include logs
> - Validate the ACPI types/size before accessing.
>
> drivers/bluetooth/btintel.c | 195 +++++++++++++++++++++++++++++++++++-
> drivers/bluetooth/btintel.h | 18 ++++
> 2 files changed, 212 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
> index 5e9cac090bd8..3f6e5285c780 100644
> --- a/drivers/bluetooth/btintel.c
> +++ b/drivers/bluetooth/btintel.c
> @@ -51,6 +51,7 @@ enum {
> #define BTINTEL_BT_DOMAIN 0x12
> #define BTINTEL_SAR_LEGACY 0
> #define BTINTEL_SAR_INC_PWR 1
> +#define BTINTEL_SAR_REV2 2
> #define BTINTEL_SAR_INC_PWR_SUPPORTED 0
>
> #define CMD_WRITE_BOOT_PARAMS 0xfc0e
> @@ -3104,6 +3105,111 @@ static int btintel_set_mutual_sar(struct hci_dev *hdev, struct btintel_sar_inc_p
> return 0;
> }
>
> +/* btintel_send_sar_rev2_band - send DDC command for one Rev2 sub-band
> + *
> + * Each DDC 0x0311-0x0316 carries 2 bytes: [ChainA_value, ChainB_value].
> + * cmd->len = 4 (2 id + 2 data)
> + * HCI total = 5 bytes (1 len + 4)
> + */
> +static int btintel_send_sar_rev2_band(struct hci_dev *hdev,
> + struct btintel_cp_ddc_write *cmd,
> + u16 id, u8 chain_a, u8 chain_b)
> +{
> + cmd->len = 4;
> + cmd->id = cpu_to_le16(id);
> + cmd->data[0] = chain_a;
> + cmd->data[1] = chain_b;
> + return btintel_send_sar_ddc(hdev, cmd, 5);
> +}
> +
> +static int btintel_set_sar_rev2(struct hci_dev *hdev,
> + struct btintel_sar_rev2 *sar)
> +{
> + struct btintel_cp_ddc_write *cmd;
> + struct sk_buff *skb;
> + u8 buffer[64];
> + u8 enable;
> + int ret;
> +
> + cmd = (void *)buffer;
> +
> + /* DDC 0x019e: enable/disable increased power mode SAR (1 byte) */
> + cmd->len = 3;
> + cmd->id = cpu_to_le16(0x019e);
> + cmd->data[0] = (sar->inc_power_mode == BTINTEL_SAR_INC_PWR_SUPPORTED) ?
> + 0x01 : 0x00;
> + ret = btintel_send_sar_ddc(hdev, cmd, 4);
> + if (ret)
> + return ret;
> +
> + /* DDC 0x0311-0x0316: per sub-band ChainA + ChainB limits */
> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0311,
> + sar->chain_a.subband_2g4,
> + sar->chain_b.subband_2g4);
> + if (ret)
> + return ret;
> +
> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0312,
> + sar->chain_a.subband_5g2,
> + sar->chain_b.subband_5g2);
> + if (ret)
> + return ret;
> +
> + /* 0x0313 and 0x0314 both carry the 5G8/5G9 value */
> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0313,
> + sar->chain_a.subband_5g8_5g9,
> + sar->chain_b.subband_5g8_5g9);
> + if (ret)
> + return ret;
> +
> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0314,
> + sar->chain_a.subband_5g8_5g9,
> + sar->chain_b.subband_5g8_5g9);
> + if (ret)
> + return ret;
> +
> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0315,
> + sar->chain_a.subband_6g1,
> + sar->chain_b.subband_6g1);
> + if (ret)
> + return ret;
> +
> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0316,
> + sar->chain_a.subband_6g3,
> + sar->chain_b.subband_6g3);
> + if (ret)
> + return ret;
> +
> + /* Notify firmware that SAR initialisation is complete */
> + enable = 0x01;
> + skb = __hci_cmd_sync(hdev, 0xfe25, sizeof(enable), &enable, HCI_CMD_TIMEOUT);
> + if (IS_ERR(skb)) {
> + bt_dev_warn(hdev, "Failed to send Intel SAR Rev2 Enable (%ld)",
> + PTR_ERR(skb));
> + return PTR_ERR(skb);
> + }
> +
> + kfree_skb(skb);
> + return 0;
> +}
> +
> +static int btintel_sar_rev2_send_to_device(struct hci_dev *hdev,
> + struct btintel_sar_rev2 *sar,
> + struct intel_version_tlv *ver)
> +{
> + u16 cnvi = ver->cnvi_top & 0xfff;
> + u16 cnvr = ver->cnvr_top & 0xfff;
> +
> + if (cnvi < BTINTEL_CNVI_BLAZARI || cnvr != BTINTEL_CNVR_WHP2) {
> + bt_dev_dbg(hdev, "BT SAR Rev2 not supported on this platform (cnvi=0x%x cnvr=0x%x)",
> + cnvi, cnvr);
> + return -EOPNOTSUPP;
> + }
> +
> + bt_dev_info(hdev, "Applying Bluetooth SAR Rev2");
> + return btintel_set_sar_rev2(hdev, sar);
> +}
> +
> static int btintel_sar_send_to_device(struct hci_dev *hdev, struct btintel_sar_inc_pwr *sar,
> struct intel_version_tlv *ver)
> {
> @@ -3130,6 +3236,7 @@ static int btintel_acpi_set_sar(struct hci_dev *hdev, struct intel_version_tlv *
> {
> union acpi_object *bt_pkg, *buffer = NULL;
> struct btintel_sar_inc_pwr sar;
> + struct btintel_sar_rev2 sar_rev2;
> acpi_status status;
> u8 revision;
> int ret;
> @@ -3150,14 +3257,100 @@ static int btintel_acpi_set_sar(struct hci_dev *hdev, struct intel_version_tlv *
> goto error;
> }
>
> + if (buffer->package.elements[0].type != ACPI_TYPE_INTEGER) {
> + bt_dev_warn(hdev, "BT_SAR: unexpected ACPI type for revision field");
> + ret = -EINVAL;
> + goto error;
> + }
> +
> revision = buffer->package.elements[0].integer.value;
>
> - if (revision > BTINTEL_SAR_INC_PWR) {
> + if (revision > BTINTEL_SAR_REV2) {
> bt_dev_dbg(hdev, "BT_SAR: revision: 0x%2.2x not supported", revision);
> ret = -EOPNOTSUPP;
> goto error;
> }
>
> + if (revision == BTINTEL_SAR_REV2 && bt_pkg->package.count == 13) {
> + /* Element layout: 0 = revision, 1 = bt_sar_bios (u32),
> + * 2 = inc_power_mode (u32), 3..12 = per-chain sub-band
> + * limits (u8 each). Validate each ACPI element is an
> + * integer and fits its destination width before we read
> + * the union; otherwise we could misinterpret string
> + * lengths or buffer pointers as TX power limits, or
> + * silently truncate out-of-range BIOS values into a
> + * regulatory-critical sub-band field.
> + */
> + static const u64 rev2_max[13] = {
> + U8_MAX, /* revision */
https://sashiko.dev/#/patchset/20260601124825.216489-1-kiran.k%40intel.com
Looks like Sashiko has some comments regarding this.
> + U32_MAX, U32_MAX, /* bt_sar_bios, inc_power_mode */
> + U8_MAX, U8_MAX, U8_MAX, U8_MAX, U8_MAX, /* chain A */
> + U8_MAX, U8_MAX, U8_MAX, U8_MAX, U8_MAX, /* chain B */
> + };
> + union acpi_object *e;
> + int i;
> +
> + for (i = 0; i < 13; i++) {
> + e = &bt_pkg->package.elements[i];
> + if (e->type != ACPI_TYPE_INTEGER) {
> + bt_dev_warn(hdev, "BT SAR Rev2: unexpected ACPI type at element %d",
> + i);
> + ret = -EINVAL;
> + goto error;
> + }
> + if (e->integer.value > rev2_max[i]) {
> + bt_dev_warn(hdev, "BT SAR Rev2: element %d value 0x%llx out of range",
> + i, e->integer.value);
> + ret = -ERANGE;
> + goto error;
> + }
> + }
> +
> + memset(&sar_rev2, 0, sizeof(sar_rev2));
> + sar_rev2.revision = revision;
> + sar_rev2.bt_sar_bios = bt_pkg->package.elements[1].integer.value;
> + sar_rev2.inc_power_mode = bt_pkg->package.elements[2].integer.value;
> +
> + sar_rev2.chain_a.subband_2g4 = bt_pkg->package.elements[3].integer.value;
> + sar_rev2.chain_a.subband_5g2 = bt_pkg->package.elements[4].integer.value;
> + sar_rev2.chain_a.subband_5g8_5g9 = bt_pkg->package.elements[5].integer.value;
> + sar_rev2.chain_a.subband_6g1 = bt_pkg->package.elements[6].integer.value;
> + sar_rev2.chain_a.subband_6g3 = bt_pkg->package.elements[7].integer.value;
> +
> + sar_rev2.chain_b.subband_2g4 = bt_pkg->package.elements[8].integer.value;
> + sar_rev2.chain_b.subband_5g2 = bt_pkg->package.elements[9].integer.value;
> + sar_rev2.chain_b.subband_5g8_5g9 = bt_pkg->package.elements[10].integer.value;
> + sar_rev2.chain_b.subband_6g1 = bt_pkg->package.elements[11].integer.value;
> + sar_rev2.chain_b.subband_6g3 = bt_pkg->package.elements[12].integer.value;
> +
> + bt_dev_dbg(hdev, "BT SAR Rev2: revision=%u bt_sar_bios=%u inc_power_mode=%u",
> + sar_rev2.revision, sar_rev2.bt_sar_bios, sar_rev2.inc_power_mode);
> + bt_dev_dbg(hdev, "BT SAR Rev2 Chain A: 2g4=%u 5g2=%u 5g8_5g9=%u 6g1=%u 6g3=%u",
> + sar_rev2.chain_a.subband_2g4, sar_rev2.chain_a.subband_5g2,
> + sar_rev2.chain_a.subband_5g8_5g9, sar_rev2.chain_a.subband_6g1,
> + sar_rev2.chain_a.subband_6g3);
> + bt_dev_dbg(hdev, "BT SAR Rev2 Chain B: 2g4=%u 5g2=%u 5g8_5g9=%u 6g1=%u 6g3=%u",
> + sar_rev2.chain_b.subband_2g4, sar_rev2.chain_b.subband_5g2,
> + sar_rev2.chain_b.subband_5g8_5g9, sar_rev2.chain_b.subband_6g1,
> + sar_rev2.chain_b.subband_6g3);
> +
> + if (sar_rev2.bt_sar_bios != 1) {
> + bt_dev_info(hdev, "Bluetooth SAR Rev2 is not enabled");
If you are going to return an erro I guess a bt_dev_warn is probably
better here, if this is not an unexpected error then bt_dev_dbg is
probably better. Actually shouldn't you stop loading if bt_sar_bios
doesn't match? Otherwise you might print entries that don't correspond
to the expected fields above, so I'd just bail out early and stop
loading after checking it.
> + ret = -EOPNOTSUPP;
> + goto error;
> + }
> +
> + ret = btintel_sar_rev2_send_to_device(hdev, &sar_rev2, ver);
> + goto error;
> + }
> +
> + if (revision == BTINTEL_SAR_REV2) {
> + bt_dev_warn(hdev, "BT SAR Rev2: unexpected ACPI package count %d (expected 13)",
> + bt_pkg->package.count);
> + ret = -EINVAL;
> + goto error;
> + }
> +
> memset(&sar, 0, sizeof(sar));
>
> if (revision == BTINTEL_SAR_LEGACY && bt_pkg->package.count == 8) {
> diff --git a/drivers/bluetooth/btintel.h b/drivers/bluetooth/btintel.h
> index 70d812ad36a2..3b5a228ca3c0 100644
> --- a/drivers/bluetooth/btintel.h
> +++ b/drivers/bluetooth/btintel.h
> @@ -64,6 +64,7 @@ struct intel_tlv {
>
> /* CNVR */
> #define BTINTEL_CNVR_FMP2 0x910
> +#define BTINTEL_CNVR_WHP2 0xA10 /* Whale Peak2 - Panther Lake */
>
> #define BTINTEL_IMG_BOOTLOADER 0x01 /* Bootloader image */
> #define BTINTEL_IMG_IML 0x02 /* Intermediate image */
> @@ -202,6 +203,23 @@ struct btintel_sar_inc_pwr {
> u8 le_lr;
> };
>
> +/* Bluetooth SAR feature (BRDS), Revision 2 - per-chain sub-band power limits */
> +struct btintel_sar_band_limits {
> + u8 subband_2g4;
> + u8 subband_5g2;
> + u8 subband_5g8_5g9;
> + u8 subband_6g1;
> + u8 subband_6g3;
> +};
> +
> +struct btintel_sar_rev2 {
> + u8 revision;
> + u32 bt_sar_bios; /* 1: BIOS-managed SAR enabled */
> + u32 inc_power_mode; /* 0: supported, 1: disabled */
> + struct btintel_sar_band_limits chain_a;
> + struct btintel_sar_band_limits chain_b;
> +};
> +
> #define INTEL_HW_PLATFORM(cnvx_bt) ((u8)(((cnvx_bt) & 0x0000ff00) >> 8))
> #define INTEL_HW_VARIANT(cnvx_bt) ((u8)(((cnvx_bt) & 0x003f0000) >> 16))
> #define INTEL_CNVX_TOP_TYPE(cnvx_top) ((cnvx_top) & 0x00000fff)
> --
> 2.54.0
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [RFC PATCH 0/5] Bluetooth: enable context analysis
From: Luiz Augusto von Dentz @ 2026-06-01 19:42 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <cover.1778930064.git.pav@iki.fi>
Hi Pauli,
On Sat, May 16, 2026 at 7:15 AM Pauli Virtanen <pav@iki.fi> wrote:
>
> Set up compiler context analysis that generate compiler warnings on
> problems that Clang -Wthread-safety can detect:
>
> https://docs.kernel.org/dev-tools/context-analysis.html
>
> Clang 22, and probably Clang 23 [1] will be required. Sparse locking
> analysis support was removed in commit
> 5b63d0ae94ccfd64dcbdb693d88eb3650eb3c64c, this is its successor.
>
> This series enables the analysis and adds minimal annotations to silence
> some false positives.
>
> Also, one patch to fix what looks like a legitimate locking issue in
> iso.c.
>
> In future, it probably is a good idea to make more use of it and add
> __must_hold, __guarded_by etc annotations.
>
> Kernel test robot appears to be checking for these, but not sure in what
> trees [2]
>
> BlueZ testbot doesn't check these currently but it's possible to add
> https://github.com/bluez/action-ci/pull/4
I would like to merge the above changes to action-ci but apparently
there are some conflicts. Can you fix that? It seems fine as a
starting point so we might as well merge it if there is nothing
blocking it. Or did you submit it as an RFC because something is still
pending?
> [1] https://lore.kernel.org/all/CANpmjNN4O=W70sAc5gaVkTAFdrGGOW+XBMyuehfz3_QMiT=uCw@mail.gmail.com/
> [2] https://lore.kernel.org/all/202605060005.JYWpZXr2-lkp@intel.com/
>
> Pauli Virtanen (5):
> Bluetooth: af_bluetooth: Add minimal context analysis annotations
> Bluetooth: hci_core: Add minimal context analysis annotations
> Bluetooth: ISO: lock same hdev as what is released
> Bluetooth: L2CAP: Add minimal context analysis annotations
> Bluetooth: enable context analysis
>
> drivers/bluetooth/Makefile | 2 ++
> net/bluetooth/Makefile | 2 ++
> net/bluetooth/af_bluetooth.c | 7 +++++--
> net/bluetooth/hci_core.c | 3 +++
> net/bluetooth/iso.c | 14 ++++++++------
> net/bluetooth/l2cap_sock.c | 1 +
> 6 files changed, 21 insertions(+), 8 deletions(-)
>
> --
> 2.54.0
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV
From: patchwork-bot+bluetooth @ 2026-06-01 19:10 UTC (permalink / raw)
To: Nils Helmig; +Cc: linux-bluetooth, marcel, luiz.dentz
In-Reply-To: <20260530123934.4583-1-nils.helmig@web.de>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Sat, 30 May 2026 14:39:34 +0200 you wrote:
> Add the vendor/product ID (0x37ad, 0x0600) to usb_device_id table
> for Realtek 8761BUV.
>
> The device info from /sys/kernel/debug/usb/devices as below.
>
> T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=37ad ProdID=0600 Rev= 2.00
> S: Manufacturer=
> S: Product=TP-Link Bluetooth USB Adapter
> S: SerialNumber=ACA7F14FD2A5
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> [...]
Here is the summary with links:
- [v3] Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV
https://git.kernel.org/bluetooth/bluetooth-next/c/b2aa1661149c
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 v1] Bluetooth: btintel_pcie: Fix null pointer dereference in remove
From: patchwork-bot+bluetooth @ 2026-06-01 19:10 UTC (permalink / raw)
To: Chandrashekar Devegowda
Cc: linux-bluetooth, linux-pci, bhelgaas, ravishankar.srivatsa,
chethan.tumkur.narayan
In-Reply-To: <20260601102612.2164388-1-chandrashekar.devegowda@intel.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 1 Jun 2026 15:56:11 +0530 you wrote:
> Add a NULL check for pci_get_drvdata() in btintel_pcie_remove() to
> prevent a null pointer dereference. This can occur when
> btintel_pcie_remove() is called concurrently from the PLDR
> device_reprobe path on another CPU, after pci_set_drvdata(pdev, NULL)
> has already been executed.
>
> Fixes: 8c0693e29dba ("Bluetooth: btintel_pcie: Support Product level reset")
> Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
>
> [...]
Here is the summary with links:
- [v1] Bluetooth: btintel_pcie: Fix null pointer dereference in remove
https://git.kernel.org/bluetooth/bluetooth-next/c/2bf22888ea6d
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 v5] Bluetooth: fix memory leak in error path of hci_alloc_dev()
From: patchwork-bot+bluetooth @ 2026-06-01 19:10 UTC (permalink / raw)
To: Bharath Reddy
Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel, syzkaller-bugs,
syzbot+535ecc844591e50588a5
In-Reply-To: <20260601032426.119034-1-kbreddy.rpbc@gmail.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 1 Jun 2026 08:54:26 +0530 you wrote:
> Early failures in Bluetooth HCI UART configuration leak SRCU percpu
> memory.
>
> When device initialization fails before hci_register_dev() completes,
> the HCI_UNREGISTER flag is never set. As a result, when the device
> reference count reaches zero, bt_host_release() evaluates this flag as
> false and falls back to a direct kfree(hdev).
>
> [...]
Here is the summary with links:
- [v5] Bluetooth: fix memory leak in error path of hci_alloc_dev()
https://git.kernel.org/bluetooth/bluetooth-next/c/cf767a2d88f7
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 0/2] Bluetooth: hci_qca: fix NULL pointer dereferences for non-serdev devices
From: patchwork-bot+bluetooth @ 2026-06-01 19:10 UTC (permalink / raw)
To: Zijun Hu
Cc: brgl, marcel, luiz.dentz, mengshi.wu, dmitry.baryshkov,
quic_saluvala, zijun_hu, luiz.von.dentz, bartosz.golaszewski,
linux-arm-msm, linux-bluetooth, linux-kernel
In-Reply-To: <20260601-fix_none_serdev-v1-0-8d0497ba83b0@oss.qualcomm.com>
Hello:
This series was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 01 Jun 2026 04:30:54 -0700 you wrote:
> When a QCA controller is attached via a non-serdev path (e.g. hci_uart
> line discipline), hu->serdev is NULL. A couple of code paths dereference
> it unconditionally, leading to NULL pointer dereferences.
>
> This series fixes two such cases:
>
> - qca_setup() dereferences the result of
> serdev_device_get_drvdata(hu->serdev).
> - qca_dmp_hdr() dereferences hu->serdev->dev.driver->name.
>
> [...]
Here is the summary with links:
- [1/2] Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-serdev device
https://git.kernel.org/bluetooth/bluetooth-next/c/7bfdd3d9129c
- [2/2] Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for non-serdev device
https://git.kernel.org/bluetooth/bluetooth-next/c/4fcae45539b9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [Bug 221552] btmtk: MT7921 (USB 0e8d:e020 / PCI 14c3:7920) Bluetooth broken since 7.0.7 - fix for 0489:e0e2 does not cover this PID
From: bugzilla-daemon @ 2026-06-01 19:03 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221552-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221552
--- Comment #3 from Gunjan Bagayatkar (gpbagayatkar@gmail.com) ---
While I cannot speak for OP,
what I can confirm is,
I was facing similar issue as OP on similar machine, and after upgrading to
7.0.10 it is fixed.
Bluetooth works (discovering devices, pairing, listening to music, all work)
My specs:
model: Lenovo LOQ 15AHP10
wifi chip: MediaTek MT7921
OS: openSUSE Tumbleweed
previous known-good kernel: unknown (newly bought machine)
kernel with failing bluetooth: 7.0.9
kernel with working bluetooth: 7.0.10
I received new kernel via distribution rolling upgrade
lspci -nnk :
03:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7920]
DeviceName: Realtek
Subsystem: Lenovo Device [17aa:e020]
Kernel driver in use: mt7921e
(same as OP)
lsusb :
Bus 001 Device 004: ID 0e8d:e020 MediaTek Inc. Wireless_Device
(same as OP)
modinfo btmtk
filename:
/usr/lib/modules/7.0.10-2-default/kernel/drivers/bluetooth/btmtk.ko.zst
firmware: mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin
firmware: mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
firmware: mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin
firmware: mediatek/mt7668pr2h.bin
firmware: mediatek/mt7663pr2h.bin
firmware: mediatek/mt7622pr2h.bin
(2 new lines than OP. this is working state)
--
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: Bluetooth: eir: Fix stack OOB write in eir_create_adv_data()
From: bluez.test.bot @ 2026-06-01 18:59 UTC (permalink / raw)
To: linux-bluetooth, bestswngs
In-Reply-To: <20260601162203.1253918-2-xmei5@asu.edu>
[-- Attachment #1: Type: text/plain, Size: 3408 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=1104138
---Test result---
Test Summary:
CheckPatch FAIL 0.78 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint FAIL 0.40 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 28.38 seconds
CheckAllWarning PASS 31.35 seconds
CheckSparse PASS 30.08 seconds
BuildKernel32 PASS 27.75 seconds
TestRunnerSetup PASS 606.70 seconds
TestRunner_l2cap-tester PASS 64.46 seconds
TestRunner_iso-tester PASS 93.80 seconds
TestRunner_bnep-tester PASS 19.81 seconds
TestRunner_mgmt-tester FAIL 220.39 seconds
TestRunner_rfcomm-tester PASS 26.70 seconds
TestRunner_sco-tester PASS 33.44 seconds
TestRunner_ioctl-tester PASS 27.01 seconds
TestRunner_mesh-tester FAIL 26.98 seconds
TestRunner_smp-tester PASS 23.79 seconds
TestRunner_userchan-tester PASS 20.52 seconds
TestRunner_6lowpan-tester PASS 23.05 seconds
IncrementalBuild PASS 32.28 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: eir: Fix stack OOB write in eir_create_adv_data()
WARNING: Reported-by: should be immediately followed by Closes: with a URL to the report
#146:
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
total: 0 errors, 1 warnings, 0 checks, 8 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/14605450.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
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:
Bluetooth: eir: Fix stack OOB write in eir_create_adv_data()
11: B3 Line contains hard tab characters (\t): " if (adv) {"
12: B3 Line contains hard tab characters (\t): " memcpy(ptr, adv->adv_data, adv->adv_data_len);"
25: B1 Line exceeds max length (82>80): " BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:302)"
##############################
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.257 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 2.782 seconds
Mesh - Send cancel - 2 Timed out 1.991 seconds
https://github.com/bluez/bluetooth-next/pull/269
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v1 2/2] Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer
From: Luiz Augusto von Dentz @ 2026-06-01 18:56 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260601185620.727132-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
In iso_sock_rebind_bc(), the bis pointer is cached, then the socket lock is
dropped:
bis = iso_pi(sk)->conn->hcon;
/* Release the socket before lookups since that requires hci_dev_lock
* which shall not be acquired while holding sock_lock for proper
* ordering.
*/
release_sock(sk);
hci_dev_lock(bis->hdev);
During the unlocked window, could a concurrent close() destroy the connection
and free the bis structure, causing hci_dev_lock(bis->hdev) to access memory
after it is freed, fix this by using the hdev reference which was safely
acquired via iso_conn_get_hdev().
Fixes: d3413703d5f8 ("Bluetooth: ISO: Add support to bind to trigger PAST")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/iso.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
index 3978a78d5252..c648c3b3e75e 100644
--- a/net/bluetooth/iso.c
+++ b/net/bluetooth/iso.c
@@ -1098,7 +1098,7 @@ static int iso_sock_rebind_bc(struct sock *sk, struct sockaddr_iso *sa,
* ordering.
*/
release_sock(sk);
- hci_dev_lock(bis->hdev);
+ hci_dev_lock(hdev);
lock_sock(sk);
if (!iso_pi(sk)->conn || iso_pi(sk)->conn->hcon != bis) {
--
2.53.0
^ permalink raw reply related
* [PATCH v1 1/2] Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync
From: Luiz Augusto von Dentz @ 2026-06-01 18:56 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
hci_get_route() returns a reference-counted hci_dev pointer via
hci_dev_hold(). The function exits normally or with an error without ever
releasing it.
Fixes: 07a9342b94a9 ("Bluetooth: ISO: Send BIG Create Sync via hci_sync")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/iso.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
index b998741b2d3b..3978a78d5252 100644
--- a/net/bluetooth/iso.c
+++ b/net/bluetooth/iso.c
@@ -1600,7 +1600,6 @@ static void iso_conn_big_sync(struct sock *sk)
release_sock(sk);
hdev = hci_get_route(&dst, &src, src_type);
-
if (!hdev)
return;
@@ -1624,6 +1623,7 @@ static void iso_conn_big_sync(struct sock *sk)
release_sock(sk);
hci_dev_unlock(hdev);
+ hci_dev_put(hdev);
}
static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg,
--
2.53.0
^ permalink raw reply related
* RE: Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
From: bluez.test.bot @ 2026-06-01 18:50 UTC (permalink / raw)
To: linux-bluetooth, oss
In-Reply-To: <20260601140444.1676239-2-oss@fourdim.xyz>
[-- Attachment #1: Type: text/plain, Size: 1150 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=1104048
---Test result---
Test Summary:
CheckPatch PASS 1.63 seconds
VerifyFixes PASS 0.11 seconds
VerifySignedoff PASS 0.11 seconds
GitLint PASS 0.28 seconds
SubjectPrefix PASS 0.10 seconds
BuildKernel PASS 25.36 seconds
CheckAllWarning PASS 28.79 seconds
CheckSparse PASS 26.78 seconds
BuildKernel32 PASS 24.76 seconds
TestRunnerSetup PASS 529.97 seconds
TestRunner_l2cap-tester PASS 59.39 seconds
TestRunner_smp-tester PASS 23.58 seconds
TestRunner_6lowpan-tester PASS 22.70 seconds
IncrementalBuild PASS 24.41 seconds
https://github.com/bluez/bluetooth-next/pull/268
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v2] bluetooth: btintel: Add Bluetooth SAR revision 2 support
From: bluez.test.bot @ 2026-06-01 18:48 UTC (permalink / raw)
To: linux-bluetooth, kiran.k
In-Reply-To: <20260601124825.216489-1-kiran.k@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1163 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=1104005
---Test result---
Test Summary:
CheckPatch PASS 1.19 seconds
VerifyFixes PASS 0.16 seconds
VerifySignedoff PASS 0.14 seconds
GitLint PASS 0.36 seconds
SubjectPrefix FAIL 0.13 seconds
BuildKernel PASS 28.45 seconds
CheckAllWarning PASS 29.87 seconds
CheckSparse PASS 26.84 seconds
BuildKernel32 PASS 24.85 seconds
TestRunnerSetup PASS 536.15 seconds
IncrementalBuild PASS 24.15 seconds
Details
##############################
Test: SubjectPrefix - FAIL
Desc: Check subject contains "Bluetooth" prefix
Output:
"Bluetooth: " prefix is not specified in the subject
https://github.com/bluez/bluetooth-next/pull/267
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-01 18:20 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1103543
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] b55c05: advertising: add property with advertisement Instance
From: mdzik-sue @ 2026-06-01 18:19 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: b55c0559bda8cc16efc63892adb56f278c19993d
https://github.com/bluez/bluez/commit/b55c0559bda8cc16efc63892adb56f278c19993d
Author: Michal Dzik <michal.dzik@streamunlimited.com>
Date: 2026-06-01 (Mon, 01 Jun 2026)
Changed paths:
M doc/org.bluez.LEAdvertisement.rst
M src/advertising.c
Log Message:
-----------
advertising: add property with advertisement Instance
Instance is an internal value, but it must be exposed to client app if
client app wants to use a advertisement in BAP broadcast.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Commit: e2874db00a40a1379172f3939ea670063b7e918d
https://github.com/bluez/bluez/commit/e2874db00a40a1379172f3939ea670063b7e918d
Author: Michal Dzik <michal.dzik@streamunlimited.com>
Date: 2026-06-01 (Mon, 01 Jun 2026)
Changed paths:
M client/advertising.c
M client/advertising.h
M client/main.c
Log Message:
-----------
client: add advertisement instance support
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Compare: https://github.com/bluez/bluez/compare/17fbb48d8f7c...e2874db00a40
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH v7 1/1] Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
From: Luiz Augusto von Dentz @ 2026-06-01 17:58 UTC (permalink / raw)
To: Siwei Zhang; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <20260601140444.1676239-2-oss@fourdim.xyz>
Hi Siwei,
On Mon, Jun 1, 2026 at 10:05 AM Siwei Zhang <oss@fourdim.xyz> wrote:
>
> l2cap_sock_new_connection_cb() accesses l2cap_pi(sk)->chan after
> release_sock(parent). Once the parent lock is released, the child
> socket sk can be freed by another task.
>
> Allocate the channel outside the func to prevent this.
>
> Fixes: 8ffb929098a5 ("Bluetooth: Remove parent socket usage from l2cap_core.c")
> Cc: stable@kernel.org
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Siwei Zhang <oss@fourdim.xyz>
> ---
> include/net/bluetooth/l2cap.h | 8 +++--
> net/bluetooth/6lowpan.c | 32 +++++++++++--------
> net/bluetooth/l2cap_core.c | 60 ++++++++++++++++++++++++++---------
> net/bluetooth/l2cap_sock.c | 48 ++++++++++++++++------------
> net/bluetooth/smp.c | 18 +++++------
> 5 files changed, 106 insertions(+), 60 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index 5172afee5494..f7a11e6431f0 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -619,7 +619,8 @@ struct l2cap_chan {
> struct l2cap_ops {
> char *name;
>
> - struct l2cap_chan *(*new_connection) (struct l2cap_chan *chan);
> + int (*new_connection)(struct l2cap_chan *chan,
> + struct l2cap_chan *new_chan);
> int (*recv) (struct l2cap_chan * chan,
> struct sk_buff *skb);
> void (*teardown) (struct l2cap_chan *chan, int err);
> @@ -883,9 +884,10 @@ static inline __u16 __next_seq(struct l2cap_chan *chan, __u16 seq)
> return (seq + 1) % (chan->tx_win_max + 1);
> }
>
> -static inline struct l2cap_chan *l2cap_chan_no_new_connection(struct l2cap_chan *chan)
> +static inline int l2cap_chan_no_new_connection(struct l2cap_chan *chan,
> + struct l2cap_chan *new_chan)
> {
> - return NULL;
> + return -EOPNOTSUPP;
> }
>
> static inline int l2cap_chan_no_recv(struct l2cap_chan *chan, struct sk_buff *skb)
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index 23a229ab6a33..284eefb73e94 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -622,6 +622,15 @@ static bool is_bt_6lowpan(struct hci_conn *hcon)
> return true;
> }
>
> +static void chan_init(struct l2cap_chan *chan)
> +{
> + l2cap_chan_set_defaults(chan);
> +
> + chan->chan_type = L2CAP_CHAN_CONN_ORIENTED;
> + chan->mode = L2CAP_MODE_LE_FLOWCTL;
> + chan->imtu = 1280;
> +}
> +
> static struct l2cap_chan *chan_create(void)
> {
> struct l2cap_chan *chan;
> @@ -630,11 +639,7 @@ static struct l2cap_chan *chan_create(void)
> if (!chan)
> return NULL;
>
> - l2cap_chan_set_defaults(chan);
> -
> - chan->chan_type = L2CAP_CHAN_CONN_ORIENTED;
> - chan->mode = L2CAP_MODE_LE_FLOWCTL;
> - chan->imtu = 1280;
> + chan_init(chan);
>
> return chan;
> }
> @@ -743,19 +748,20 @@ static inline void chan_ready_cb(struct l2cap_chan *chan)
> ifup(dev->netdev);
> }
>
> -static inline struct l2cap_chan *chan_new_conn_cb(struct l2cap_chan *pchan)
> +static inline int chan_new_conn_cb(struct l2cap_chan *pchan,
> + struct l2cap_chan *chan)
> {
> - struct l2cap_chan *chan;
> -
> - chan = chan_create();
> - if (!chan)
> - return NULL;
> -
> + chan_init(chan);
> chan->ops = pchan->ops;
>
> + /* Take a reference to match the put in chan_close_cb(). The caller
> + * drops its own local reference after __l2cap_chan_add().
> + */
> + l2cap_chan_hold(chan);
> +
> BT_DBG("chan %p pchan %p", chan, pchan);
>
> - return chan;
> + return 0;
> }
>
> static void unregister_dev(struct lowpan_btle_dev *dev)
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index fdccd62ccca8..3edf6680899e 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -4005,6 +4005,36 @@ static inline int l2cap_command_rej(struct l2cap_conn *conn,
> return 0;
> }
>
> +/* Allocate and initialise a channel for an incoming connection. The returned
> + * channel carries the caller's local reference, which must be dropped once
> + * __l2cap_chan_add() has pinned it via the conn list.
> + */
> +static struct l2cap_chan *l2cap_new_connection(struct l2cap_chan *pchan)
> +{
> + struct l2cap_chan *chan;
> +
> + chan = l2cap_chan_create();
> + if (!chan)
> + return NULL;
> +
> + if (pchan->ops->new_connection(pchan, chan) < 0) {
> + l2cap_chan_put(chan);
> + return NULL;
> + }
> +
> + return chan;
> +}
> +
> +/* Link a channel from l2cap_new_connection() into conn and release the local
> + * reference it carried. __l2cap_chan_add() pins the channel via the conn list,
> + * so it remains valid after this returns.
> + */
> +static void l2cap_chan_add_new(struct l2cap_conn *conn, struct l2cap_chan *chan)
> +{
> + __l2cap_chan_add(conn, chan);
> + l2cap_chan_put(chan);
> +}
> +
> static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
> u8 *data, u8 rsp_code)
> {
> @@ -4051,7 +4081,7 @@ static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
> goto response;
> }
>
> - chan = pchan->ops->new_connection(pchan);
> + chan = l2cap_new_connection(pchan);
> if (!chan)
> goto response;
>
> @@ -4069,7 +4099,7 @@ static void l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
> chan->psm = psm;
> chan->dcid = scid;
>
> - __l2cap_chan_add(conn, chan);
> + l2cap_chan_add_new(conn, chan);
>
> dcid = chan->scid;
>
> @@ -4881,6 +4911,7 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
> struct l2cap_le_conn_rsp rsp;
> struct l2cap_chan *chan, *pchan;
> u16 dcid, scid, credits, mtu, mps;
> + u16 rsp_mtu, rsp_mps;
> __le16 psm;
> u8 result;
>
> @@ -4893,6 +4924,8 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
> psm = req->psm;
> dcid = 0;
> credits = 0;
> + rsp_mtu = 0;
> + rsp_mps = 0;
>
> if (mtu < 23 || mps < 23)
> return -EPROTO;
> @@ -4953,7 +4986,7 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
> goto response_unlock;
> }
>
> - chan = pchan->ops->new_connection(pchan);
> + chan = l2cap_new_connection(pchan);
> if (!chan) {
> result = L2CAP_CR_LE_NO_MEM;
> goto response_unlock;
> @@ -4968,12 +5001,14 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
> chan->omtu = mtu;
> chan->remote_mps = mps;
>
> - __l2cap_chan_add(conn, chan);
> + l2cap_chan_add_new(conn, chan);
>
> l2cap_le_flowctl_init(chan, __le16_to_cpu(req->credits));
>
> dcid = chan->scid;
> credits = chan->rx_credits;
> + rsp_mtu = chan->imtu;
> + rsp_mps = chan->mps;
>
> __set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
>
> @@ -5001,13 +5036,8 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
> return 0;
>
> response:
> - if (chan) {
> - rsp.mtu = cpu_to_le16(chan->imtu);
> - rsp.mps = cpu_to_le16(chan->mps);
> - } else {
> - rsp.mtu = 0;
> - rsp.mps = 0;
> - }
> + rsp.mtu = cpu_to_le16(rsp_mtu);
> + rsp.mps = cpu_to_le16(rsp_mps);
>
> rsp.dcid = cpu_to_le16(dcid);
> rsp.credits = cpu_to_le16(credits);
> @@ -5177,7 +5207,7 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
> continue;
> }
>
> - chan = pchan->ops->new_connection(pchan);
> + chan = l2cap_new_connection(pchan);
> if (!chan) {
> result = L2CAP_CR_LE_NO_MEM;
> continue;
> @@ -5192,7 +5222,7 @@ static inline int l2cap_ecred_conn_req(struct l2cap_conn *conn,
> chan->omtu = mtu;
> chan->remote_mps = mps;
>
> - __l2cap_chan_add(conn, chan);
> + l2cap_chan_add_new(conn, chan);
>
> l2cap_ecred_init(chan, __le16_to_cpu(req->credits));
>
> @@ -7399,14 +7429,14 @@ static void l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
> goto next;
>
> l2cap_chan_lock(pchan);
> - chan = pchan->ops->new_connection(pchan);
> + chan = l2cap_new_connection(pchan);
> if (chan) {
> bacpy(&chan->src, &hcon->src);
> bacpy(&chan->dst, &hcon->dst);
> chan->src_type = bdaddr_src_type(hcon);
> chan->dst_type = dst_type;
>
> - __l2cap_chan_add(conn, chan);
> + l2cap_chan_add_new(conn, chan);
> }
>
> l2cap_chan_unlock(pchan);
> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> index dede550d6031..598f24c8f704 100644
> --- a/net/bluetooth/l2cap_sock.c
> +++ b/net/bluetooth/l2cap_sock.c
> @@ -46,7 +46,8 @@ static struct bt_sock_list l2cap_sk_list = {
> static const struct proto_ops l2cap_sock_ops;
> static void l2cap_sock_init(struct sock *sk, struct sock *parent);
> static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
> - int proto, gfp_t prio, int kern);
> + int proto, gfp_t prio, int kern,
> + struct l2cap_chan *chan);
> static void l2cap_sock_cleanup_listen(struct sock *parent);
>
> bool l2cap_is_socket(struct socket *sock)
> @@ -1507,12 +1508,13 @@ static void l2cap_sock_cleanup_listen(struct sock *parent)
> }
> }
>
> -static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
> +static int l2cap_sock_new_connection_cb(struct l2cap_chan *chan,
> + struct l2cap_chan *new_chan)
> {
> struct sock *sk, *parent = chan->data;
>
> if (!parent)
> - return NULL;
> + return -EINVAL;
>
> lock_sock(parent);
>
> @@ -1520,15 +1522,15 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
> if (sk_acceptq_is_full(parent)) {
> BT_DBG("backlog full %d", parent->sk_ack_backlog);
> release_sock(parent);
> - return NULL;
> + return -ENOBUFS;
> }
>
> sk = l2cap_sock_alloc(sock_net(parent), NULL, BTPROTO_L2CAP,
> - GFP_ATOMIC, 0);
> + GFP_ATOMIC, 0, new_chan);
> if (!sk) {
> release_sock(parent);
> - return NULL;
> - }
> + return -ENOMEM;
> + }
>
> bt_sock_reclassify_lock(sk, BTPROTO_L2CAP);
>
> @@ -1538,7 +1540,7 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
>
> release_sock(parent);
>
> - return l2cap_pi(sk)->chan;
> + return 0;
> }
>
> static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
> @@ -1939,10 +1941,10 @@ static struct proto l2cap_proto = {
> };
>
> static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
> - int proto, gfp_t prio, int kern)
> + int proto, gfp_t prio, int kern,
> + struct l2cap_chan *chan)
> {
> struct sock *sk;
> - struct l2cap_chan *chan;
>
> sk = bt_sock_alloc(net, sock, &l2cap_proto, proto, prio, kern);
> if (!sk)
> @@ -1953,14 +1955,11 @@ static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
>
> INIT_LIST_HEAD(&l2cap_pi(sk)->rx_busy);
>
> - chan = l2cap_chan_create();
> - if (!chan) {
> - sk_free(sk);
> - if (sock)
> - sock->sk = NULL;
> - return NULL;
> - }
> -
> + /* The sock owns two refs on chan, matching the puts in
> + * l2cap_sock_kill() and l2cap_sock_destruct(). The caller keeps
> + * its own ref independent of these.
> + */
> + l2cap_chan_hold(chan);
Hmm, this doesn't sound right. Why would we need 2 references for
l2cap_sock_kill and l2cap_sock_destruct? Whener we do l2cap_chan_put
we should set the pointer to NULL and not keep 2 references since the
destruct maybe called without it being killed first, either way having
to handle multiple reference like this is not optimal so we should fix
this if we can.
> l2cap_chan_hold(chan);
>
> l2cap_pi(sk)->chan = chan;
> @@ -1972,6 +1971,7 @@ static int l2cap_sock_create(struct net *net, struct socket *sock, int protocol,
> int kern)
> {
> struct sock *sk;
> + struct l2cap_chan *chan;
>
> BT_DBG("sock %p", sock);
>
> @@ -1986,10 +1986,18 @@ static int l2cap_sock_create(struct net *net, struct socket *sock, int protocol,
>
> sock->ops = &l2cap_sock_ops;
>
> - sk = l2cap_sock_alloc(net, sock, protocol, GFP_ATOMIC, kern);
> - if (!sk)
> + chan = l2cap_chan_create();
> + if (!chan)
> return -ENOMEM;
>
> + sk = l2cap_sock_alloc(net, sock, protocol, GFP_ATOMIC, kern, chan);
> + if (!sk) {
> + l2cap_chan_put(chan);
> + return -ENOMEM;
> + }
> + /* Sock has taken its own refs on chan; drop the chan_create() ref. */
> + l2cap_chan_put(chan);
> +
> l2cap_sock_init(sk, NULL);
> bt_sock_link(&l2cap_sk_list, sk);
> return 0;
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index 1739c1989dbd..887a2fc34391 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -3204,16 +3204,11 @@ static const struct l2cap_ops smp_chan_ops = {
> .get_sndtimeo = l2cap_chan_no_get_sndtimeo,
> };
>
> -static inline struct l2cap_chan *smp_new_conn_cb(struct l2cap_chan *pchan)
> +static inline int smp_new_conn_cb(struct l2cap_chan *pchan,
> + struct l2cap_chan *chan)
> {
> - struct l2cap_chan *chan;
> -
> BT_DBG("pchan %p", pchan);
>
> - chan = l2cap_chan_create();
> - if (!chan)
> - return NULL;
> -
> chan->chan_type = pchan->chan_type;
> chan->ops = &smp_chan_ops;
> chan->scid = pchan->scid;
> @@ -3229,9 +3224,14 @@ static inline struct l2cap_chan *smp_new_conn_cb(struct l2cap_chan *pchan)
> */
> atomic_set(&chan->nesting, L2CAP_NESTING_SMP);
>
> - BT_DBG("created chan %p", chan);
> + /* Take a reference to match the put in smp_teardown_cb(). The caller
> + * drops its own local reference after __l2cap_chan_add().
> + */
> + l2cap_chan_hold(chan);
>
> - return chan;
> + BT_DBG("initialised chan %p", chan);
> +
> + return 0;
> }
>
> static const struct l2cap_ops smp_root_chan_ops = {
> --
> 2.54.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH bluetooth] Bluetooth: eir: Fix stack OOB write in eir_create_adv_data()
From: Luiz Augusto von Dentz @ 2026-06-01 17:38 UTC (permalink / raw)
To: Xiang Mei; +Cc: linux-bluetooth, Marcel Holtmann, linux-kernel, Xiang Mei
In-Reply-To: <20260601162203.1253918-2-xmei5@asu.edu>
Hi Xiang,
On Mon, Jun 1, 2026 at 12:22 PM Xiang Mei <bestswngs@gmail.com> wrote:
>
> From: Weiming Shi <bestswngs@gmail.com>
>
> eir_create_adv_data() builds the advertising data into a fixed-size
> buffer of "size" bytes (31 for the legacy path in hci_set_adv_data_sync()).
> It may prepend a 3-byte "Flags" AD structure, but the per-instance
> advertising data is then copied without checking that it still fits:
>
> skip_flags:
> if (adv) {
> memcpy(ptr, adv->adv_data, adv->adv_data_len);
>
> The "Flags" structure is added whenever BR/EDR is disabled
> (LE_AD_NO_BREDR), which is the normal state for an LE-only controller.
> However, the mgmt length validator tlv_data_max_len() only reserves
> those 3 bytes when the user-supplied adv_flags carries a managed-flags
> bit (DISCOV / LIMITED_DISCOV / MANAGED_FLAGS). Adding an instance with
> flags == 0 reserves nothing, so adv_data_len is accepted up to the full
> buffer size. At advertise time the 3 flag bytes are still prepended,
> and the subsequent memcpy() writes 3 + adv_data_len bytes into the
> size-byte buffer, overflowing it by the attacker-controlled tail of
> adv_data:
>
> BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:302)
> Write of size 31 at addr ffff88800b7e7bac by task kworker/u9:0/51
> Workqueue: hci0 hci_cmd_sync_work
> __asan_memcpy (mm/kasan/shadow.c:106)
> eir_create_adv_data (net/bluetooth/eir.c:302)
> hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1689)
> hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:2015)
> hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)
> This frame has 1 object:
> [32, 64) 'cp'
Add the btmon trace of the MGMT command when this is triggered, and
explaing how the advertisement was created, as with bluetoothd?
> The inconsistency dates back to when the managed "Flags" field was first
> added to the Add Advertising path: the prepended LE_AD_NO_BREDR flag does
> not depend on the user-supplied adv_flags, but tlv_data_is_valid() only
> reserved room when MGMT_ADV_FLAG_DISCOV was set. Commit 47c03902269a
> ("Bluetooth: eir: Fix possible crashes on eir_create_adv_data") later
> added the "size" argument and bounds-checked the "Flags" and "Tx Power"
> AD structures, but left this copy unguarded. Guard it the same way so
> the data is only copied when it fits.
>
> The bug is reachable by a local user with CAP_NET_ADMIN that owns an
> LE-only controller using the legacy advertising path.
>
> Fixes: b44133ff03be ("Bluetooth: Support the "discoverable" adv flag")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> net/bluetooth/eir.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/eir.c b/net/bluetooth/eir.c
> index 3f72111ba651..e574f8f61e16 100644
> --- a/net/bluetooth/eir.c
> +++ b/net/bluetooth/eir.c
> @@ -297,7 +297,7 @@ u8 eir_create_adv_data(struct hci_dev *hdev, u8 instance, u8 *ptr, u8 size)
> }
>
> skip_flags:
> - if (adv) {
> + if (adv && ad_len + adv->adv_data_len <= size) {
So we have 2 options: 1) Don't add flags if there is no space, or 2)
Don't add the user provided data. We should probably choose option 1,
not option 2 since option 2 probably means the advertisement is
useless.
> memcpy(ptr, adv->adv_data, adv->adv_data_len);
> ad_len += adv->adv_data_len;
> ptr += adv->adv_data_len;
> --
> 2.43.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH bluetooth] Bluetooth: eir: Fix stack OOB write in eir_create_adv_data()
From: Xiang Mei @ 2026-06-01 16:22 UTC (permalink / raw)
To: linux-bluetooth
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Weiming Shi,
linux-kernel, Xiang Mei
From: Weiming Shi <bestswngs@gmail.com>
eir_create_adv_data() builds the advertising data into a fixed-size
buffer of "size" bytes (31 for the legacy path in hci_set_adv_data_sync()).
It may prepend a 3-byte "Flags" AD structure, but the per-instance
advertising data is then copied without checking that it still fits:
skip_flags:
if (adv) {
memcpy(ptr, adv->adv_data, adv->adv_data_len);
The "Flags" structure is added whenever BR/EDR is disabled
(LE_AD_NO_BREDR), which is the normal state for an LE-only controller.
However, the mgmt length validator tlv_data_max_len() only reserves
those 3 bytes when the user-supplied adv_flags carries a managed-flags
bit (DISCOV / LIMITED_DISCOV / MANAGED_FLAGS). Adding an instance with
flags == 0 reserves nothing, so adv_data_len is accepted up to the full
buffer size. At advertise time the 3 flag bytes are still prepended,
and the subsequent memcpy() writes 3 + adv_data_len bytes into the
size-byte buffer, overflowing it by the attacker-controlled tail of
adv_data:
BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:302)
Write of size 31 at addr ffff88800b7e7bac by task kworker/u9:0/51
Workqueue: hci0 hci_cmd_sync_work
__asan_memcpy (mm/kasan/shadow.c:106)
eir_create_adv_data (net/bluetooth/eir.c:302)
hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1689)
hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:2015)
hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)
This frame has 1 object:
[32, 64) 'cp'
The inconsistency dates back to when the managed "Flags" field was first
added to the Add Advertising path: the prepended LE_AD_NO_BREDR flag does
not depend on the user-supplied adv_flags, but tlv_data_is_valid() only
reserved room when MGMT_ADV_FLAG_DISCOV was set. Commit 47c03902269a
("Bluetooth: eir: Fix possible crashes on eir_create_adv_data") later
added the "size" argument and bounds-checked the "Flags" and "Tx Power"
AD structures, but left this copy unguarded. Guard it the same way so
the data is only copied when it fits.
The bug is reachable by a local user with CAP_NET_ADMIN that owns an
LE-only controller using the legacy advertising path.
Fixes: b44133ff03be ("Bluetooth: Support the "discoverable" adv flag")
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/bluetooth/eir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/eir.c b/net/bluetooth/eir.c
index 3f72111ba651..e574f8f61e16 100644
--- a/net/bluetooth/eir.c
+++ b/net/bluetooth/eir.c
@@ -297,7 +297,7 @@ u8 eir_create_adv_data(struct hci_dev *hdev, u8 instance, u8 *ptr, u8 size)
}
skip_flags:
- if (adv) {
+ if (adv && ad_len + adv->adv_data_len <= size) {
memcpy(ptr, adv->adv_data, adv->adv_data_len);
ad_len += adv->adv_data_len;
ptr += adv->adv_data_len;
--
2.43.0
^ permalink raw reply related
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