* Re: [PATCH] 6lowpan: fix NHC entry use-after-free on error path
From: Alexander Aring @ 2026-06-10 13:05 UTC (permalink / raw)
To: Yizhou Zhao
Cc: linux-bluetooth, Alexander Aring, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-wpan, netdev,
linux-kernel, Yuxiang Yang, Ao Wang, Xuewei Feng, Qi Li, Ke Xu,
stable
In-Reply-To: <20260609080054.4541-1-zhaoyz24@mails.tsinghua.edu.cn>
Hi,
On Tue, Jun 9, 2026 at 4:03 AM Yizhou Zhao
<zhaoyz24@mails.tsinghua.edu.cn> wrote:
>
> lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding
> lowpan_nhc_lock. If the descriptor has no uncompress callback, the error
> path drops the lock before printing nhc->name.
>
> lowpan_nhc_del() removes descriptors under the same lock and then relies
> on synchronize_net() before the owning module can be unloaded. That only
> waits for net RX RCU readers. lowpan_header_decompress() is also exported
> and can be reached from callers that are not necessarily covered by the net
> core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive
> path.
>
> This leaves a race where one task drops lowpan_nhc_lock in the error path,
> another task unregisters and frees the matching descriptor after
> synchronize_net() returns, and the first task then dereferences nhc->name
> for the warning.
>
> With the post-unlock window widened, KASAN reports:
>
> BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220
> Read of size 8
> lowpan_nhc_do_uncompression
> lowpan_header_decompress
>
> Fix this by printing the warning before dropping lowpan_nhc_lock, so the
> descriptor name is read while unregister is still excluded. The malformed
> packet is still rejected with -ENOTSUPP.
>
> Fixes: 92aa7c65d295 ("6lowpan: add generic nhc layer interface")
> Cc: stable@vger.kernel.org
> Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
> Reported-by: Ao Wang <wangao@seu.edu.cn>
> Reported-by: Xuewei Feng <fengxw06@126.com>
> Reported-by: Qi Li <qli01@tsinghua.edu.cn>
> Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
> Assisted-by: GLM:GLM-5.1
> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
looks good. Thanks.
Acked-by: Alexander Aring <aahringo@redhat.com>
- Alex
^ permalink raw reply
* Re: [PATCH v2 0/7] arm64: dts: qcom: enable WiFi/BT on SM8350 HDK
From: Konrad Dybcio @ 2026-06-10 11:56 UTC (permalink / raw)
To: Rob Herring, Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, Qiang Yu, Jeff Johnson,
Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-pci, linux-kernel,
linux-wireless, ath11k, devicetree, Bartosz Golaszewski,
linux-bluetooth, Bartosz Golaszewski
In-Reply-To: <20260608151835.GA2707238-robh@kernel.org>
On 6/8/26 5:18 PM, Rob Herring wrote:
> On Mon, Jun 08, 2026 at 09:59:18AM +0300, Dmitry Baryshkov wrote:
>> The SM8350 HDK has an onboard WCN6851 WiFi/BT chip, which for a long
>> time was not supported. Bring up different pieces required to enable
>> this SoC.
>>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Bumped num_vdevs to 4 to follow other similar devices (Jeff)
>> - Link to v1: https://patch.msgid.link/20260601-sm8350-wifi-v1-0-242917d88031@oss.qualcomm.com
>>
>> ---
>> Dmitry Baryshkov (7):
>> PCI: qcom: fix parsing of PERST# in the legacy case
>> wifi: ath11k: enable support for WCN6851
>> regulator: dt-bindings: qcom,qca6390-pmu: document WCN6851
>> dt-bindings: bluetooth: qcom,wcn6855-bt: document WCN6851
>> arm64: dts: qcom: sm8350: expand UART18 to 4 pins config
>> arm64: dts: qcom: sm8350: modernize PCIe entries
>> arm64: dts: qcom: sm8350-hdk: describe WiFi/BT chip
>
> Before adding new devices, can you (Qcom) fix the all the existing DT
> warnings related to QCom WiFi/BT:
>
> 6 (qcom,wcn6855-bt): 'vddrfa1p7-supply' is a required property
> 6 (qcom,wcn6855-bt): Unevaluated properties are not allowed ('vddrfa1p8-supply' was unexpected)
> 2 (qcom,wcn6855-bt): 'vddwlmx-supply' is a required property
> 2 (qcom,wcn6855-bt): 'vddwlcx-supply' is a required property
> 2 (qcom,wcn6855-bt): 'vddbtcmx-supply' is a required property
> 2 (qcom,wcn6855-bt): 'vddaon-supply' is a required property
> 2 (pci17cb,1103): 'vddwlmx-supply' is a required property
> 2 (pci17cb,1103): 'vddwlcx-supply' is a required property
> 2 (pci17cb,1103): 'vddrfacmn-supply' is a required property
> 2 (pci17cb,1103): 'vddrfa1p8-supply' is a required property
> 2 (pci17cb,1103): 'vddrfa1p2-supply' is a required property
> 2 (pci17cb,1103): 'vddrfa0p8-supply' is a required property
> 2 (pci17cb,1103): 'vddpcie1p8-supply' is a required property
> 2 (pci17cb,1103): 'vddpcie0p9-supply' is a required property
> 2 (pci17cb,1103): 'vddaon-supply' is a required property
Most of them will be gone with
https://lore.kernel.org/linux-arm-msm/20260522-surface-sp9-5g-for-next-v2-8-dd9d477407f5@gmail.com/
a single dt generates 2 DTBs (one overlayed) that throw almost all of
these errors.. we should be able to tackle the rest that remain shortly
Konrad
^ permalink raw reply
* RE: [BlueZ,v2] adapter: Fix failed bonding attempt after LE link disconnection
From: bluez.test.bot @ 2026-06-10 11:02 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260610082054.3915366-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1109089
---Test result---
Test Summary:
CheckPatch PASS 5.58 seconds
GitLint PASS 0.33 seconds
BuildEll PASS 21.00 seconds
BluezMake PASS 619.90 seconds
CheckSmatch PASS 325.95 seconds
bluezmakeextell PASS 166.15 seconds
IncrementalBuild PASS 605.73 seconds
ScanBuild PASS 948.54 seconds
https://github.com/bluez/bluez/pull/2213
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-10 10:16 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1107775
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] cc2e16: adapter: Fix failed bonding attempt after LE link ...
From: Šimon Mikuda @ 2026-06-10 10:16 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1109089
Home: https://github.com/bluez/bluez
Commit: cc2e16f0137dbc4f21b2f5078d2c28b63a886260
https://github.com/bluez/bluez/commit/cc2e16f0137dbc4f21b2f5078d2c28b63a886260
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-10 (Wed, 10 Jun 2026)
Changed paths:
M src/adapter.c
Log Message:
-----------
adapter: Fix failed bonding attempt after LE link disconnection
What happens when issue occurs:
- device is connected to both bearers BR/EDR and LE
- bonding is requested
- LE link disconnects
- pairing keys arrive
BlueZ would finish bonding request with error and mark device as
temporary. Then it would be disconnected+removed after default
temporary timeout (30 seconds).
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* RE: [v2] Bluetooth: qca: Add BT FW build version to kernel log
From: bluez.test.bot @ 2026-06-10 8:58 UTC (permalink / raw)
To: linux-bluetooth, xiuzhuo.shang
In-Reply-To: <20260610064232.2385866-1-xiuzhuo.shang@oss.qualcomm.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=1109012
---Test result---
Test Summary:
CheckPatch PASS 0.53 seconds
VerifyFixes PASS 0.07 seconds
VerifySignedoff PASS 0.07 seconds
GitLint PASS 0.20 seconds
SubjectPrefix PASS 0.06 seconds
BuildKernel PASS 26.56 seconds
CheckAllWarning PASS 29.70 seconds
CheckSparse PASS 27.92 seconds
BuildKernel32 PASS 26.02 seconds
TestRunnerSetup PASS 573.52 seconds
IncrementalBuild PASS 25.70 seconds
https://github.com/bluez/bluetooth-next/pull/301
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
From: Sergey Senozhatsky @ 2026-06-10 8:51 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Mark-yw Chen
Cc: Sean Wang, Tomasz Figa, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, stable, Sergey Senozhatsky
In-Reply-To: <20260609121329.1262170-1-senozhatsky@chromium.org>
On (26/06/09 21:10), Sergey Senozhatsky wrote:
> Every once in a while we see a hung btmtksdio_flush() task:
>
> INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
> __cancel_work_timer+0x3f4/0x460
> cancel_work_sync+0x1c/0x2c
> btmtksdio_flush+0x2c/0x40
> hci_dev_open_sync+0x10c4/0x2190
> [..]
>
> It all boils down to incorrect time_is_before_jiffies() usage in
> btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected
> to be terminated if running for longer than 5*HZ. However the
> timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ)
> evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a
> timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout)
> means that:
> - before the 5-second timeout: the condition is `int_status || false`,
> so it loops as long as there are pending interrupts.
> - after the 5-second timeout: the condition becomes `int_status || true`,
> which is always true.
>
> When the loop becomes infinite btmtksdio_txrx_work() loop never
> terminates and never releases the SDIO host.
>
> Fix loop termination condition to actually enforce a 5*HZ timeout.
Please hold off this patch, this change alone might not be enough.
Let us look closer into it, we'll come back you.
^ permalink raw reply
* Re: "cleanup" variable attribute follow-up
From: Bastien Nocera @ 2026-06-10 8:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <6a284da8.7dd3efdf.a331b.6852@mx.google.com>
I have fixes for some of the warnings checkpatch threw:
https://github.com/hadess/bluez/commit/1f69ae6c89e6811f554087a35152b9e5b5f20e5c
Let me know if you want me to send them in a v2.
Cheers
On Tue, 2026-06-09 at 10:30 -0700, bluez.test.bot@gmail.com wrote:
> 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=1108
> 616
>
> ---Test result---
>
> Test Summary:
> CheckPatch FAIL 2.51 seconds
> GitLint PASS 1.73 seconds
> BuildEll PASS 16.19 seconds
> BluezMake PASS 498.81 seconds
> MakeCheck PASS 18.30 seconds
> MakeDistcheck PASS 189.35 seconds
> CheckValgrind PASS 217.95 seconds
> CheckSmatch WARNING 253.71 seconds
> bluezmakeextell PASS 131.42 seconds
> IncrementalBuild PASS 985.31 seconds
> ScanBuild PASS 733.50 seconds
>
> Details
> ##############################
> Test: CheckPatch - FAIL
> Desc: Run checkpatch.pl script
> Output:
> [BlueZ,1/6] shared/util: Fix warnings when cleaning up NULL pointers
> WARNING:LONG_LINE: line length of 94 exceeds 80 columns
> #74: FILE: src/shared/util.h:130:
> + static inline void cleanup_##type (type **_ptr) { if (*_ptr
> != NULL) (func) (*_ptr); }
Fixed.
> WARNING:SPACING: space prohibited between function name and open
> parenthesis '('
> #74: FILE: src/shared/util.h:130:
> + static inline void cleanup_##type (type **_ptr) { if (*_ptr
> != NULL) (func) (*_ptr); }
Fixed
>
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxO)
> #74: FILE: src/shared/util.h:130:
> + static inline void cleanup_##type (type **_ptr) { if (*_ptr
> != NULL) (func) (*_ptr); }
Bogus.
> ^
>
> ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
> #74: FILE: src/shared/util.h:130:
> + static inline void cleanup_##type (type **_ptr) { if (*_ptr
> != NULL) (func) (*_ptr); }
Fixed.
>
> /github/workspace/src/patch/14619750.patch total: 2 errors, 2
> warnings, 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/14619750.patch has style problems, please
> review.
>
> NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO
> CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED
> SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
>
> NOTE: If any of the errors are false positives, please report
> them to the maintainer, see CHECKPATCH in MAINTAINERS.
>
>
> [BlueZ,4/6] main: Use _cleanup_() to simplify configuration parsing
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #90: FILE: src/main.c:265:
> + _cleanup_type_(GError) GError *err = NULL;
Those are all bogus, not sure why it's complaining there.
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #114: FILE: src/main.c:447:
> + _cleanup_type_(GError) GError *err = NULL;
> ^
>
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #210: FILE: src/main.c:895:
> + _cleanup_type_(GError) GError *err = NULL;
> ^
>
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #415: FILE: src/main.c:1214:
> + _cleanup_type_(GError) GError *err = NULL;
> ^
>
> ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
> #507: FILE: src/main.c:1577:
> + _cleanup_type_(GError) GError *err = NULL;
> ^
>
> /github/workspace/src/patch/14619699.patch total: 5 errors, 0
> warnings, 420 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/14619699.patch has style problems, please
> review.
>
> NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO
> CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED
> SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
>
> NOTE: If any of the errors are false positives, please report
> them to the maintainer, see CHECKPATCH in MAINTAINERS.
>
>
> ##############################
> Test: CheckSmatch - WARNING
> Desc: Run smatch tool with source
> Output:
> src/main.c: note: in included file (through src/device.h):
>
>
> https://github.com/bluez/bluez/pull/2201
>
> ---
> Regards,
> Linux Bluetooth
^ permalink raw reply
* RE: [v2] Bluetooth: SCO: Fix use-after-free on listening socket in sco_conn_ready()
From: bluez.test.bot @ 2026-06-10 8:33 UTC (permalink / raw)
To: linux-bluetooth, sanghyun.park.cnu
In-Reply-To: <20260610060824.552957-2-sanghyun.park.cnu@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
This is an automated email and please do not reply to this email.
Dear Submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.
----- Output -----
error: patch failed: net/bluetooth/sco.c:410
error: net/bluetooth/sco.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Please resolve the issue and submit the patches again.
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH BlueZ v2] adapter: Fix failed bonding attempt after LE link disconnection
From: Simon Mikuda @ 2026-06-10 8:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Simon Mikuda
In-Reply-To: <20260608111034.3684632-1-simon.mikuda@streamunlimited.com>
What happens when issue occurs:
- device is connected to both bearers BR/EDR and LE
- bonding is requested
- LE link disconnects
- pairing keys arrive
BlueZ would finish bonding request with error and mark device as
temporary. Then it would be disconnected+removed after default
temporary timeout (30 seconds).
---
src/adapter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/adapter.c b/src/adapter.c
index cc753fbd6..538f63e0a 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -8622,7 +8622,9 @@ static void dev_disconnected(struct btd_adapter *adapter,
disconnect_notify(device, reason);
}
- bonding_attempt_complete(adapter, &addr->bdaddr, addr->type,
+ /* device could be still connected to different bearer */
+ if (!device || !btd_device_is_connected(device))
+ bonding_attempt_complete(adapter, &addr->bdaddr, addr->type,
MGMT_STATUS_DISCONNECTED);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: qca: Add BT FW build version to kernel log
From: Bartosz Golaszewski @ 2026-06-10 8:17 UTC (permalink / raw)
To: Xiuzhuo Shang
Cc: linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, shuai.zhang, mengshi.wu, jinwang.li,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
In-Reply-To: <c0eee7b4-50ee-4635-b8d6-fe9cb4ea05a8@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 9:36 AM Xiuzhuo Shang
<xiuzhuo.shang@oss.qualcomm.com> wrote:
>
> Hi Bart,
>
> The main change in v2 was the commit message — I added the motivation and an example log line as
>
> Paul requested on v1. Carrying your Acked-by (given on v1) forward was just to avoid losing it. So
>
> v2 wasn't sent solely to collect a tag.
>
Well, I don't know it because you didn't add a changelog to v2. Please
add something like "Changes in v2:" in the future.
Bartosz
^ permalink raw reply
* Re: [PATCH BlueZ] shared/bap: Transition ASE to QoS Configured on CIS loss
From: Simon Mikuda @ 2026-06-10 7:57 UTC (permalink / raw)
To: Pauli Virtanen, linux-bluetooth
In-Reply-To: <e89af328197d3fb429c08b7a3107d7fd8e05ac00.camel@iki.fi>
this check is for ep (struct bt_bap_endpoint) that is used only for
unicast. broadcasts use different state in struct bt_bap_stream, so it
should be OK
On 6/10/26 00:15, Pauli Virtanen wrote:
> ti, 2026-06-09 kello 23:11 +0200, Simon Mikuda kirjoitti:
>> stream_io_disconnected() only handled the Releasing state, leaving
>> Enabling, Streaming and Disabling ASEs stuck when the CIS was lost
>> unexpectedly. The ASE shall autonomously move to QoS Configured on loss
>> of the CIS and notify the peer; add that transition.
>>
>> Fixes PTS test BAP/USR/SCC/BV-167-C
>> ---
>> src/shared/bap.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/src/shared/bap.c b/src/shared/bap.c
>> index deb85b264..350ed53d9 100644
>> --- a/src/shared/bap.c
>> +++ b/src/shared/bap.c
>> @@ -6779,6 +6779,14 @@ static bool stream_io_disconnected(struct io *io, void *user_data)
>> if (stream->ep->state == BT_ASCS_ASE_STATE_RELEASING)
>> stream_set_state(stream, BT_BAP_STREAM_STATE_CONFIG);
>>
>> + /* On loss of the CIS the ASE shall autonomously transition to QoS
>> + * Configured and notify the peer.
>> + */
>> + if (stream->ep->state == BT_ASCS_ASE_STATE_STREAMING ||
>> + stream->ep->state == BT_ASCS_ASE_STATE_ENABLING ||
>> + stream->ep->state == BT_ASCS_ASE_STATE_DISABLING)
>> + stream_set_state(stream, BT_BAP_STREAM_STATE_QOS);
>> +
>> bt_bap_stream_set_io(stream, -1);
>> return false;
>> }
> iirc it may be also broadcast source here, does it do the right thing?
>
^ permalink raw reply
* Re: [PATCH BlueZ] shared/bap: Don't link ucast streams before CIS IDs are assigned
From: Simon Mikuda @ 2026-06-10 7:46 UTC (permalink / raw)
To: Pauli Virtanen, linux-bluetooth
In-Reply-To: <0744a915b7ea628647a17fa9aad0aa4365f83989.camel@iki.fi>
I looked into it and 0 is valid ID (probably not used, but still valid).
There is a ugly part in bluez though, when stream is allocated cig and
cis in qos struct are 0 not 0xff:
stream = new0(struct bt_bap_stream, 1); /* qos all-zero: cig/cis = 0 */
and also in tests there are some struct comparisons that also use
cig/cis == 0. Some parts check for 0xff (BT_ISO_QOS_CIG_UNSET,
BT_ISO_QOS_CIS_UNSET)
Maybe more clean fix would be to hook this up to state, so that when
CIG/CIS is not at least configured it is rejected e.g.:
if (stream->ep->state < BT_ASCS_ASE_STATE_QOS || link->ep->state <
BT_ASCS_ASE_STATE_QOS)
return -EINVAL;
Also probably i should cleanup all structs (code and tests), so that cig
and cis are initialized properly with 0xff. And then provide the fix?
On 6/10/26 00:03, Pauli Virtanen wrote:
> ti, 2026-06-09 kello 23:11 +0200, Simon Mikuda kirjoitti:
>> bap_ucast_io_link pairs streams whose CIG/CIS IDs match, but the IDs
>> are unset in Codec Configured state, so a Sink and Source bound for
>> different CISes get linked. The stray link later propagates a
>> disconnect to the wrong ASE and breaks Receiver Start Ready.
>>
>> Skip linking until QoS Configured assigns the IDs.
>>
>> Fixes PTS test BAP/USR/STR/BV-362-C
>> ---
>> src/shared/bap.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/src/shared/bap.c b/src/shared/bap.c
>> index deb85b264..98537de60 100644
>> --- a/src/shared/bap.c
>> +++ b/src/shared/bap.c
>> @@ -2679,6 +2679,12 @@ static int bap_ucast_io_link(struct bt_bap_stream *stream,
>> stream->ep->dir == link->ep->dir)
>> return -EINVAL;
>>
>> + /* Don't link until QoS Configured assigns the CIS IDs; while unset
>> + * the check above would pair unrelated streams.
>> + */
>> + if (!stream->qos.ucast.cis_id || !link->qos.ucast.cis_id)
>> + return -EINVAL;
> Zero is valid CIS ID?
>
>> +
>> if (stream->client && !(stream->locked && link->locked))
>> return -EINVAL;
>>
^ permalink raw reply
* Re: [PATCH v2 4/7] dt-bindings: bluetooth: qcom,wcn6855-bt: document WCN6851
From: Krzysztof Kozlowski @ 2026-06-10 7:41 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pci, linux-kernel, linux-wireless, ath11k, devicetree,
Bartosz Golaszewski, linux-bluetooth, Bartosz Golaszewski
In-Reply-To: <20260608-sm8350-wifi-v2-4-efb68f1ff04c@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 09:59:22AM +0300, Dmitry Baryshkov wrote:
> WCN6851 is an earlier version of WCN6855 WiFi/BT chip, compatible with
> it. Add a device-specific compat string with the fallback to WCN6855
> one.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> .../devicetree/bindings/net/bluetooth/qcom,wcn6855-bt.yaml | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: qca: Add BT FW build version to kernel log
From: Xiuzhuo Shang @ 2026-06-10 7:36 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, shuai.zhang, mengshi.wu, jinwang.li,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
In-Reply-To: <CAMRc=MdojC6T1RuqRNE-ssoRw1pKyUHyOS9AD0ROfCpPPOqw1A@mail.gmail.com>
Hi Bart,
The main change in v2 was the commit message — I added the motivation and an example log line as
Paul requested on v1. Carrying your Acked-by (given on v1) forward was just to avoid losing it. So
v2 wasn't sent solely to collect a tag.
Thanks,
Xiuzhuo
On 6/10/2026 3:07 PM, Bartosz Golaszewski wrote:
> On Wed, 10 Jun 2026 08:42:32 +0200, Xiuzhuo Shang
> <xiuzhuo.shang@oss.qualcomm.com> said:
>> Firmware version is critical for bug triage. Users reporting issues
>> typically share dmesg output rather than debugfs contents, requiring
>> extra communication rounds to collect this information. Log the FW
>> build version directly to the kernel log so it is immediately
>> available in bug reports.
>>
>> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
>> ---
>
> Please don't send a new version if all you did is collected a single tag.
>
> Bart
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: net: wireless: qcom,ath10k: Document NVMEM cells
From: Krzysztof Kozlowski @ 2026-06-10 7:16 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, linux-mmc, devicetree,
linux-kernel, linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, Bartosz Golaszewski
In-Reply-To: <20260609-block-as-nvmem-v4-2-45712e6b22c6@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 09:52:27AM +0200, Loic Poulain wrote:
> Document the NVMEM cells supported by the ath10k driver, the
> mac-address, pre-calibration data, and calibration data.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> .../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index c21d66c7cd558ab792524be9afec8b79272d1c87..7391df5e7071e626af4c64b9919d48c41ac09f1e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -92,6 +92,22 @@ properties:
>
> ieee80211-freq-limit: true
>
> + nvmem-cells:
> + minItems: 1
> + maxItems: 3
> + description: |
If there is going to be resend:
Do not need '|' unless you need to preserve formatting.
> + References to nvmem cells for MAC address and/or calibration data.
> + Supported cell names are mac-address, calibration, and pre-calibration.
> +
> + nvmem-cell-names:
> + minItems: 1
> + maxItems: 3
> + items:
> + enum:
> + - mac-address
> + - calibration
> + - pre-calibration
This means you expect random order with variable number of items. Is
that intentional? If yes, please provide short explanation in the commit
msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: qca: Add BT FW build version to kernel log
From: Bartosz Golaszewski @ 2026-06-10 7:07 UTC (permalink / raw)
To: Xiuzhuo Shang
Cc: linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, shuai.zhang, mengshi.wu, jinwang.li,
Bartosz Golaszewski, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz
In-Reply-To: <20260610064232.2385866-1-xiuzhuo.shang@oss.qualcomm.com>
On Wed, 10 Jun 2026 08:42:32 +0200, Xiuzhuo Shang
<xiuzhuo.shang@oss.qualcomm.com> said:
> Firmware version is critical for bug triage. Users reporting issues
> typically share dmesg output rather than debugfs contents, requiring
> extra communication rounds to collect this information. Log the FW
> build version directly to the kernel log so it is immediately
> available in bug reports.
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
> ---
Please don't send a new version if all you did is collected a single tag.
Bart
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
From: Sean Wang @ 2026-06-10 6:52 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Mark-yw Chen, Sean Wang,
Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, stable
In-Reply-To: <20260609121329.1262170-1-senozhatsky@chromium.org>
Hi,
On Tue, Jun 9, 2026 at 7:19 AM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> Every once in a while we see a hung btmtksdio_flush() task:
>
> INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
> __cancel_work_timer+0x3f4/0x460
> cancel_work_sync+0x1c/0x2c
> btmtksdio_flush+0x2c/0x40
> hci_dev_open_sync+0x10c4/0x2190
> [..]
>
> It all boils down to incorrect time_is_before_jiffies() usage in
> btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected
> to be terminated if running for longer than 5*HZ. However the
> timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ)
> evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a
> timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout)
> means that:
> - before the 5-second timeout: the condition is `int_status || false`,
> so it loops as long as there are pending interrupts.
> - after the 5-second timeout: the condition becomes `int_status || true`,
> which is always true.
>
> When the loop becomes infinite btmtksdio_txrx_work() loop never
> terminates and never releases the SDIO host.
>
> Fix loop termination condition to actually enforce a 5*HZ timeout.
>
> Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> ---
> drivers/bluetooth/btmtksdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> index 5b0fab7b89b5..c6f80c419e90 100644
> --- a/drivers/bluetooth/btmtksdio.c
> +++ b/drivers/bluetooth/btmtksdio.c
> @@ -620,7 +620,7 @@ static void btmtksdio_txrx_work(struct work_struct *work)
> if (btmtksdio_rx_packet(bdev, rx_size) < 0)
> bdev->hdev->stat.err_rx++;
> }
> - } while (int_status || time_is_before_jiffies(txrx_timeout));
> + } while (int_status && time_is_after_jiffies(txrx_timeout));
yes, loop continues only while there is interrupt work and the timeout
deadline is still in the future
Reviewed-by: Sean Wang <sean.wang@mediatek.com>
Thanks for fixing this long-standing issue.
>
> /* Enable interrupt */
> if (bdev->func->irq_handler)
> --
> 2.54.0.1064.gd145956f57-goog
>
>
^ permalink raw reply
* [PATCH] Bluetooth: SCO: Fix use-after-free in sco_conn_ready() connect path
From: Sanghyun Park @ 2026-06-10 6:43 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz
Cc: Sanghyun Park, linux-bluetooth, linux-kernel
sco_conn_ready() reads conn->sk without holding the connection lock or
taking a socket reference. A concurrent close() can detach and free that
socket before sco_conn_ready() calls lock_sock(sk), resulting in a
use-after-free.
Fix this by taking the connection lock and using sco_sock_hold() to read
conn->sk with a reference held before calling lock_sock(). Drop the
reference with sock_put() after releasing the socket lock.
Race:
CPU0 (hci_rx_work) CPU1 (userspace close)
============================ ==========================
sco_conn_ready(conn):
sk = conn->sk
close(sco_fd)
sco_sock_release()
sco_sock_close()
__sco_sock_close()
sco_chan_del()
conn->sk = NULL
sock_orphan()
sco_sock_kill()
sock_put(sk) -> frees sk
lock_sock(sk)
// UAF: sk may already be freed
Signed-off-by: Sanghyun Park <sanghyun.park.cnu@gmail.com>
---
net/bluetooth/sco.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 6383db54657..c2c4b5a5b82 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -1306,16 +1306,21 @@ static int sco_sock_release(struct socket *sock)
static void sco_conn_ready(struct sco_conn *conn)
{
struct sock *parent;
- struct sock *sk = conn->sk;
+ struct sock *sk;
BT_DBG("conn %p", conn);
+ sco_conn_lock(conn);
+ sk = sco_sock_hold(conn);
+ sco_conn_unlock(conn);
+
if (sk) {
lock_sock(sk);
sco_sock_clear_timer(sk);
sk->sk_state = BT_CONNECTED;
sk->sk_state_change(sk);
release_sock(sk);
+ sock_put(sk);
} else {
sco_conn_lock(conn);
--
2.48.1
^ permalink raw reply related
* [PATCH v2] Bluetooth: qca: Add BT FW build version to kernel log
From: Xiuzhuo Shang @ 2026-06-10 6:42 UTC (permalink / raw)
To: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, shuai.zhang, mengshi.wu, jinwang.li,
xiuzhuo.shang, Bartosz Golaszewski
In-Reply-To: <20260609075417.1160702-1-xiuzhuo.shang@oss.qualcomm.com>
Firmware version is critical for bug triage. Users reporting issues
typically share dmesg output rather than debugfs contents, requiring
extra communication rounds to collect this information. Log the FW
build version directly to the kernel log so it is immediately
available in bug reports.
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
---
Example output:
Bluetooth: hci0: QCA FW build version: BTFW.MOSELLE.1.1.3-00106-MSL_PATCHZ-1
drivers/bluetooth/btqca.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index dda76365726f..04ebe290bc78 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -143,6 +143,8 @@ static int qca_read_fw_build_info(struct hci_dev *hdev)
hci_set_fw_info(hdev, "%s", build_label);
+ bt_dev_info(hdev, "QCA FW build version: %s", build_label);
+
kfree(build_label);
out:
kfree_skb(skb);
--
2.43.0
^ permalink raw reply related
* [bluetooth-next:master] BUILD SUCCESS e5ea095d9bd1f3cf78d56f780d0f278f77663373
From: kernel test robot @ 2026-06-10 6:12 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master
branch HEAD: e5ea095d9bd1f3cf78d56f780d0f278f77663373 Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant
elapsed time: 766m
configs tested: 174
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260610 gcc-8.5.0
arc randconfig-002-20260610 gcc-8.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260610 gcc-8.5.0
arm randconfig-002-20260610 gcc-8.5.0
arm randconfig-003-20260610 gcc-8.5.0
arm randconfig-004-20260610 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260610 gcc-11.5.0
arm64 randconfig-002-20260610 gcc-11.5.0
arm64 randconfig-003-20260610 gcc-11.5.0
arm64 randconfig-004-20260610 gcc-11.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260610 gcc-11.5.0
csky randconfig-002-20260610 gcc-11.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260610 clang-22
hexagon randconfig-002-20260610 clang-22
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260610 gcc-14
i386 buildonly-randconfig-002-20260610 gcc-14
i386 buildonly-randconfig-003-20260610 gcc-14
i386 buildonly-randconfig-004-20260610 gcc-14
i386 buildonly-randconfig-005-20260610 gcc-14
i386 buildonly-randconfig-006-20260610 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260610 gcc-14
i386 randconfig-002-20260610 gcc-14
i386 randconfig-003-20260610 gcc-14
i386 randconfig-004-20260610 gcc-14
i386 randconfig-005-20260610 gcc-14
i386 randconfig-006-20260610 gcc-14
i386 randconfig-007-20260610 gcc-14
i386 randconfig-011-20260610 gcc-14
i386 randconfig-012-20260610 gcc-14
i386 randconfig-013-20260610 gcc-14
i386 randconfig-014-20260610 gcc-14
i386 randconfig-015-20260610 gcc-14
i386 randconfig-016-20260610 gcc-14
i386 randconfig-017-20260610 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260610 clang-22
loongarch randconfig-002-20260610 clang-22
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001-20260610 clang-22
nios2 randconfig-002-20260610 clang-22
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260610 gcc-8.5.0
parisc randconfig-002-20260610 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc microwatt_defconfig gcc-16.1.0
powerpc randconfig-001-20260610 gcc-8.5.0
powerpc randconfig-002-20260610 gcc-8.5.0
powerpc64 randconfig-001-20260610 gcc-8.5.0
powerpc64 randconfig-002-20260610 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-16.1.0
riscv randconfig-001-20260610 gcc-16.1.0
riscv randconfig-002 gcc-16.1.0
riscv randconfig-002-20260610 gcc-16.1.0
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-16.1.0
s390 randconfig-001-20260610 gcc-16.1.0
s390 randconfig-002 gcc-16.1.0
s390 randconfig-002-20260610 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sh randconfig-001 gcc-16.1.0
sh randconfig-001-20260610 gcc-16.1.0
sh randconfig-002 gcc-16.1.0
sh randconfig-002-20260610 gcc-16.1.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260610 gcc-14.3.0
sparc randconfig-002-20260610 gcc-14.3.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260610 gcc-14.3.0
sparc64 randconfig-002-20260610 gcc-14.3.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260610 gcc-14.3.0
um randconfig-002-20260610 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260610 gcc-14
x86_64 buildonly-randconfig-002-20260610 gcc-14
x86_64 buildonly-randconfig-003-20260610 gcc-14
x86_64 buildonly-randconfig-004-20260610 gcc-14
x86_64 buildonly-randconfig-005-20260610 gcc-14
x86_64 buildonly-randconfig-006-20260610 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260610 gcc-13
x86_64 randconfig-002-20260610 gcc-13
x86_64 randconfig-003-20260610 gcc-13
x86_64 randconfig-004-20260610 gcc-13
x86_64 randconfig-005-20260610 gcc-13
x86_64 randconfig-006-20260610 gcc-13
x86_64 randconfig-011-20260610 gcc-14
x86_64 randconfig-012-20260610 gcc-14
x86_64 randconfig-013-20260610 gcc-14
x86_64 randconfig-014-20260610 gcc-14
x86_64 randconfig-015-20260610 gcc-14
x86_64 randconfig-016-20260610 gcc-14
x86_64 randconfig-071-20260610 gcc-14
x86_64 randconfig-072-20260610 gcc-14
x86_64 randconfig-073-20260610 gcc-14
x86_64 randconfig-074-20260610 gcc-14
x86_64 randconfig-075-20260610 gcc-14
x86_64 randconfig-076-20260610 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa randconfig-001-20260610 gcc-14.3.0
xtensa randconfig-002-20260610 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] Bluetooth: SCO: Fix use-after-free on listening socket in sco_conn_ready()
From: Sanghyun Park @ 2026-06-10 6:08 UTC (permalink / raw)
To: marcel, johan.hedberg, luiz.dentz
Cc: Sanghyun Park, linux-bluetooth, linux-kernel
sco_conn_ready() calls sco_get_sock_listen() which returns a raw
pointer to a listening socket without taking a reference. After
releasing sco_sk_list.lock, a concurrent close() of the listening socket
can free it between the list lookup return and lock_sock(parent),
resulting in a use-after-free.
Fix by taking a reference with sock_hold() inside sco_get_sock_listen()
while the list lock is still held, and dropping it with sock_put() in
sco_conn_ready() after release_sock().
Race:
CPU0 (HCI event workqueue) CPU1 (userspace)
============================ ==========================
sco_conn_ready():
parent = sco_get_sock_listen()
// returns parent without a reference
close(listen_fd):
sco_sock_release()
sco_sock_kill()
sock_put(parent) -> frees parent
lock_sock(parent)
// UAF: parent may already be freed
Signed-off-by: Sanghyun Park <sanghyun.park.cnu@gmail.com>
---
Changes in v2:
- Move sock_hold() from sco_conn_ready() into sco_get_sock_listen() so
the reference is taken while sco_sk_list.lock is still held.
- Drop the verbose reproduction/KASAN text, personal note, and unverified
Fixes tag from the commit message.
- Fix whitespace damage.
net/bluetooth/sco.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 6383db54657..20518bbc93a 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -410,6 +410,11 @@ static struct sock *sco_get_sock_listen(bdaddr_t *src)
sk1 = sk;
}
+ if (sk)
+ sock_hold(sk);
+ else if (sk1)
+ sock_hold(sk1);
+
read_unlock(&sco_sk_list.lock);
return sk ? sk : sk1;
@@ -1336,6 +1341,7 @@ static void sco_conn_ready(struct sco_conn *conn)
BTPROTO_SCO, GFP_ATOMIC, 0);
if (!sk) {
release_sock(parent);
+ sock_put(parent);
sco_conn_unlock(conn);
return;
}
@@ -1357,6 +1363,7 @@ static void sco_conn_ready(struct sco_conn *conn)
parent->sk_data_ready(parent);
release_sock(parent);
+ sock_put(parent);
sco_conn_unlock(conn);
}
^ permalink raw reply related
* Re: [PATCH v1] Bluetooth: qca: Add BT FW build version log
From: Xiuzhuo Shang @ 2026-06-10 5:49 UTC (permalink / raw)
To: Paul Menzel, Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, linux-arm-msm,
linux-bluetooth, linux-kernel, cheng.jiang, quic_chezhou,
wei.deng, shuai.zhang, mengshi.wu, jinwang.li
In-Reply-To: <8697f148-5e21-44b4-a949-9d348e39c2ea@molgen.mpg.de>
Hi，Paul，
On 6/9/2026 6:29 PM, Paul Menzel wrote:
> Dear Xiuzhuo, dear Bartosz
>
>
> Am 09.06.26 um 11:39 schrieb Bartosz Golaszewski:
>> On Tue, 9 Jun 2026 09:54:17 +0200, Xiuzhuo Shang said:
>>> Printf BT FW build version log after BT FW downloaded.
>
> Please paste the new lines, so reviewers see how it is going to look like. Please also document a motivation (answering Why?).
Thanks for your suggestion, I will send PATCH v2.
>
>>> Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
>>> ---
>>> drivers/bluetooth/btqca.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
>>> index dda76365726f..04ebe290bc78 100644
>>> --- a/drivers/bluetooth/btqca.c
>>> +++ b/drivers/bluetooth/btqca.c
>>> @@ -143,6 +143,8 @@ static int qca_read_fw_build_info(struct hci_dev *hdev)
>>>
>>> hci_set_fw_info(hdev, "%s", build_label);
>>>
>>> + bt_dev_info(hdev, "QCA FW build version: %s", build_label);
>>> +
>>> kfree(build_label);
>>> out:
>>> kfree_skb(skb);
>>
>> This string can be read from debugfs, do we need an additional message in the
>> kernel log?
>
> In my opinion the firmware version should be part of the Linux logs, as that is what users share with bug reports, and you do not want to have several cycles collecting information. For example, currently for QCA6174 it’s currently:
>
> Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware rome 0x302 build 0x111
>
>
> Kind regards,
>
> Paul
>
>
> PS:
>
> ```
> $ sudo dmesg | grep -e ath10k -e Bluetooth
> [ 17.880668] ath10k_pci 0000:3a:00.0: enabling device (0000 -> 0002)
> [ 17.883428] ath10k_pci 0000:3a:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
> [ 18.138972] ath10k_pci 0000:3a:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535
> [ 18.138977] ath10k_pci 0000:3a:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 0
> [ 18.139068] ath10k_pci 0000:3a:00.0: firmware ver WLAN.RM.4.4.1-00309- api 6 features wowlan,ignore-otp,mfp crc32 0793bcf2
> [ 18.206593] ath10k_pci 0000:3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
> [ 18.221145] Bluetooth: Core ver 2.22
> [ 18.221802] Bluetooth: HCI device and connection manager initialized
> [ 18.221807] Bluetooth: HCI socket layer initialized
> [ 18.221808] Bluetooth: L2CAP socket layer initialized
> [ 18.221813] Bluetooth: SCO socket layer initialized
> [ 18.258187] Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00000302.bin
> [ 18.258192] Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware rome 0x302 build 0x111
> [ 18.301557] ath10k_pci 0000:3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
> [ 18.381567] ath10k_pci 0000:3a:00.0 wlp58s0: renamed from wlan0
> [ 18.619003] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin
> [ 18.643646] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
> ```
^ permalink raw reply
* RE: [BlueZ] avrcp: Abort continuing response on fragmented CT replies
From: bluez.test.bot @ 2026-06-09 23:06 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260609212656.3900190-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 989 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=1108830
---Test result---
Test Summary:
CheckPatch PASS 0.47 seconds
GitLint PASS 0.32 seconds
BuildEll PASS 20.54 seconds
BluezMake PASS 650.26 seconds
MakeCheck PASS 3.37 seconds
MakeDistcheck PASS 248.95 seconds
CheckValgrind PASS 225.60 seconds
CheckSmatch PASS 353.04 seconds
bluezmakeextell PASS 182.32 seconds
IncrementalBuild PASS 659.64 seconds
ScanBuild PASS 1039.95 seconds
https://github.com/bluez/bluez/pull/2211
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ] avdtp: Return correct error when SEP is inuse
From: bluez.test.bot @ 2026-06-09 23:06 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260609213013.3900808-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 989 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=1108834
---Test result---
Test Summary:
CheckPatch PASS 0.28 seconds
GitLint PASS 0.20 seconds
BuildEll PASS 20.53 seconds
BluezMake PASS 669.66 seconds
MakeCheck PASS 2.95 seconds
MakeDistcheck PASS 247.75 seconds
CheckValgrind PASS 228.75 seconds
CheckSmatch PASS 352.15 seconds
bluezmakeextell PASS 184.12 seconds
IncrementalBuild PASS 662.09 seconds
ScanBuild PASS 1053.81 seconds
https://github.com/bluez/bluez/pull/2212
---
Regards,
Linux Bluetooth
^ 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