[PATCH] Bluetooth: delete the new SCO link if linking it fails

[PATCH] Bluetooth: delete the new SCO link if linking it fails

[Wentao Liang]

hci_connect_sco() adds a fresh SCO/eSCO connection with
hci_conn_add_unset(), which leaves its hold counter at zero and takes a
reference on the controller. If hci_conn_link() then fails, for example
because the link cannot be allocated, the error path calls
hci_conn_drop() on a connection nobody holds. The counter goes below
zero, the delayed deletion work is never armed, and the connection stays
in the hash with its controller reference until the controller is
unregistered.

Use hci_conn_del() for a connection created here, as the other
hci_conn_add_unset() error paths do, and keep the drop for a connection
that was found in the hash.

Fixes: 06149746e720 ("Bluetooth: hci_conn: Add support for linking multiple hcon")
Cc: stable@vger.kernel.org
Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
 net/bluetooth/hci_conn.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 29da3fe2b953..660eaf5adf96 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1896,6 +1896,7 @@ struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
 	struct hci_conn *acl;
 	struct hci_conn *sco;
 	struct hci_link *link;
+	bool new_sco = false;
 
 	acl = hci_connect_acl(hdev, dst, BT_SECURITY_LOW, HCI_AT_NO_BONDING,
 			      CONN_REASON_SCO_CONNECT, timeout);
@@ -1909,12 +1910,19 @@ struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
 			hci_conn_drop(acl);
 			return sco;
 		}
+
+		new_sco = true;
 	}
 
 	link = hci_conn_link(acl, sco);
 	if (!link) {
 		hci_conn_drop(acl);
-		hci_conn_drop(sco);
+
+		if (new_sco)
+			hci_conn_del(sco);
+		else
+			hci_conn_drop(sco);
+
 		return ERR_PTR(-ENOLINK);
 	}
 
-- 
2.34.1

Re: [PATCH] Bluetooth: delete the new SCO link if linking it fails

[Krzysztof Kozlowski]

On Wed, 04 Nov 2026 02:28:07 +0000, Wentao Liang wrote:
> hci_connect_sco() adds a fresh SCO/eSCO connection with
> hci_conn_add_unset(), which leaves its hold counter at zero and takes a
> reference on the controller. If hci_conn_link() then fails, for example
> because the link cannot be allocated, the error path calls
> hci_conn_drop() on a connection nobody holds. The counter goes below
> zero, the delayed deletion work is never armed, and the connection stays
> in the hash with its controller reference until the controller is
> unregistered.
> 
> Use hci_conn_del() for a connection created here, as the other
> hci_conn_add_unset() error paths do, and keep the drop for a connection
> that was found in the hash.
> 
> Fixes: 06149746e720 ("Bluetooth: hci_conn: Add support for linking multiple hcon")
> Cc: stable@vger.kernel.org
> Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
>  net/bluetooth/hci_conn.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 

Multiple things here:
1. Your team ignored completely previous feedback. Multiple times.

2. You use multiple identities with this email address, thus I doubt that we
   speak with an actual person.

3. Your bot does not even bother running checkpatch, right?

4. Nothing of this was reproduced nor tested.

5. Finally, the same feedback:
You sent multiple independent patches, to multiple independent
subsystems. The amount of these patches clearly suggest this was
AI generated and most likely not tested.

More importantly, you sent all this work without properly organizing
relevant patches into patchsets. This makes reviewing difficult
and might cause multiple reviewers to address the same issue.
Replying to the entire set is impossible and requires handling each
patch independently, instead of applying or discarding the set.
Maintainers also won't see the bigger picture of your work. Quite
worrying.

This is on the verge of hostile patch: bomb us with so many
contributions, we won't be able to handle them in efficient manner,
like responding ONCE to ask you to slow down.  Considering all this
is untested and LLM generated, I have even more doubts whether this
should be considered for review.

Please read kernel documentation BEFORE posting more work. It will
explain you how to identify subsystems, how to organize your work per
subsystem (so a patchset grouping multiple patches with a short cover
letter), how to document the issue discovery method and what was
or was not tested.

Best regards,
Krzysztof

RE: Bluetooth: delete the new SCO link if linking it fails

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 4119 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/series/1201153/

---Test result---

Test Summary:
CheckPatch                    FAIL      0.75 seconds
VerifyFixes                   PASS      0.12 seconds
VerifySignedoff               PASS      0.12 seconds
GitLint                       PASS      0.32 seconds
SubjectPrefix                 PASS      0.11 seconds
BuildKernel                   PASS      31.42 seconds
CheckAllWarning               PASS      35.06 seconds
CheckSparse                   PASS      38.07 seconds
BuildKernel32                 PASS      30.88 seconds
CheckKernelLLVM               PASS      35.24 seconds
TestRunnerSetup               PASS      745.30 seconds
TestRunner_l2cap-tester       FAIL      10.73 seconds
TestRunner_iso-tester         PASS      10.87 seconds
TestRunner_bnep-tester        PASS      3.21 seconds
TestRunner_mgmt-tester        PASS      91.90 seconds
TestRunner_rfcomm-tester      PASS      4.63 seconds
TestRunner_sco-tester         PASS      5.66 seconds
TestRunner_ioctl-tester       PASS      4.75 seconds
TestRunner_mesh-tester        PASS      10.87 seconds
TestRunner_smp-tester         PASS      4.49 seconds
TestRunner_userchan-tester    PASS      3.27 seconds
TestRunner_6lowpan-tester     PASS      5.38 seconds
IncrementalBuild              PASS      28.91 seconds

Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: delete the new SCO link if linking it fails
WARNING: Non-standard signature: Assisted-by:
#96: 
Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex

ERROR: Unrecognized email address: 'DeepSeek-V4.1-Flash and OpenAI Codex'
#96: 
Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex

total: 1 errors, 1 warnings, 0 checks, 27 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.

/home/runner/work/bluetooth-next/bluetooth-next/src/patch/14942649.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: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
Sanitizer errors:
==38==ERROR: AddressSanitizer: heap-use-after-free on address 0x7befcd8e33d0 at pc 0x55560205ae8e bp 0x7ffefc4748b0 sp 0x7ffefc4748a0
READ of size 4 at 0x7befcd8e33d0 thread T0
    #0 0x55560205ae8d in timeout_callback src/shared/timeout-mainloop.c:33
    #1 0x55560205bb75 in timeout_callback src/shared/mainloop.c:270
    #2 0x55560205caa6 in mainloop_run src/shared/mainloop.c:124
    #3 0x55560205f3fa in mainloop_run_with_signal src/shared/mainloop-notify.c:196
    #4 0x55560206464b in tester_run src/shared/tester.c:1223
    #5 0x555601f8e17d in main tools/l2cap-tester.c:3918
    #6 0x7fafce844600 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:59
    #7 0x7fafce844717 in __libc_start_main_impl ../csu/libc-start.c:360
    #8 0x555601f94c84 in _start (/home/runner/work/bluetooth-next/bluetooth-next/src/bluez/tools/l2cap-tester+0x16cc84) (BuildId: 91c9d49e9766c394468e27ffa29b05e7d348169f)

0x7befcd8e33d0 is located 0 bytes inside of 40-byte region [0x7befcd8e33d0,0x7befcd8e33f8)
freed by thread T0 here:
    #0 0x7fafcf1823ff in free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:51
    #1 0x55560205b36a in timeout_destroy src/shared/mainloop.c:251

previously allocated by thread T0 here:
    #0 0x7fafcf18360f in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:67
    #1 0x5556020452d5 in util_malloc src/shared/util.c:46

SUMMARY: AddressSanitizer: heap-use-after-free src/shared/timeout-mainloop.c:33 in timeout_callback
No test result found


https://github.com/bluez/bluetooth-next/pull/1057

---
Regards,
Linux Bluetooth