[RFC PATCH] Bluetooth: l2cap: honor local LE connection interval range

[RFC PATCH] Bluetooth: l2cap: honor local LE connection interval range

[Kyle Pepper]

Intersect a valid peer request with the locally configured interval
range. Reject disjoint ranges and preserve validation of the original
request before applying local policy.

Assisted-by: OpenCode:gpt-6.1-sol
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Submission review notes (not part of the commit message):
October 12 no-intersection trial accepts [16,24] and completes 30 ms
with STATUS 03 02 18 and normal host TX; the user hears silence. Volume
and multi-day acoustic comparison controls are incomplete. The working
intersection yields 20 ms. Maximum-only rejection failed in kernel 5
and is not this proposal. Generic minimum/range policy and LL-path
consistency remain RFC questions, not established by one renderer.

 net/bluetooth/l2cap_core.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 49a998804..49e201d3e 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4968,6 +4968,13 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
 	memset(&rsp, 0, sizeof(rsp));
 
 	err = hci_check_conn_params(min, max, latency, to_multiplier);
+	if (!err) {
+		/* Apply local policy only after validating the peer's request. */
+		min = max_t(u16, min, hcon->le_conn_min_interval);
+		max = min_t(u16, max, hcon->le_conn_max_interval);
+		err = hci_check_conn_params(min, max, latency, to_multiplier);
+	}
+
 	if (err)
 		rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
 	else

base-commit: 964430c038967fd06643e866f68115664e1a1bd1

RE: [RFC] Bluetooth: l2cap: honor local LE connection interval range

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1073 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/1184338/

---Test result---

Test Summary:
CheckPatch                    PASS      0.60 seconds
VerifyFixes                   PASS      0.08 seconds
VerifySignedoff               PASS      0.08 seconds
GitLint                       PASS      0.24 seconds
SubjectPrefix                 PASS      0.08 seconds
BuildKernel                   PASS      29.43 seconds
CheckAllWarning               PASS      33.15 seconds
CheckSparse                   PASS      35.82 seconds
BuildKernel32                 PASS      29.12 seconds
CheckKernelLLVM               PASS      32.99 seconds
TestRunnerSetup               PASS      699.77 seconds
TestRunner_l2cap-tester       PASS      12.84 seconds
IncrementalBuild              PASS      28.11 seconds



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

---
Regards,
Linux Bluetooth

Re: [RFC PATCH] Bluetooth: l2cap: honor local LE connection interval range

[Luiz Augusto von Dentz]

Hi Kyle,

On Mon, Oct 12, 2026 at 11:31 PM Kyle Pepper <cochcoder@proton.me> wrote:
>
> Intersect a valid peer request with the locally configured interval
> range. Reject disjoint ranges and preserve validation of the original
> request before applying local policy.
>
> Assisted-by: OpenCode:gpt-6.1-sol
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
> Submission review notes (not part of the commit message):
> October 12 no-intersection trial accepts [16,24] and completes 30 ms
> with STATUS 03 02 18 and normal host TX; the user hears silence. Volume
> and multi-day acoustic comparison controls are incomplete. The working
> intersection yields 20 ms. Maximum-only rejection failed in kernel 5
> and is not this proposal. Generic minimum/range policy and LL-path
> consistency remain RFC questions, not established by one renderer.

I need to check the git history but I believe we tried something
similar not long ago that created interoperability problems if we use
strict range matching like this.

>  net/bluetooth/l2cap_core.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 49a998804..49e201d3e 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -4968,6 +4968,13 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
>         memset(&rsp, 0, sizeof(rsp));
>
>         err = hci_check_conn_params(min, max, latency, to_multiplier);
> +       if (!err) {
> +               /* Apply local policy only after validating the peer's request. */
> +               min = max_t(u16, min, hcon->le_conn_min_interval);
> +               max = min_t(u16, max, hcon->le_conn_max_interval);
> +               err = hci_check_conn_params(min, max, latency, to_multiplier);
> +       }
> +
>         if (err)
>                 rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
>         else
>
> base-commit: 964430c038967fd06643e866f68115664e1a1bd1
>


-- 
Luiz Augusto von Dentz

[RFC PATCH v2] Bluetooth: l2cap: prefer compatible local LE intervals

[Kyle Pepper]

Use a valid intersection of a peer interval range and local preferences
when they overlap. Otherwise retain the peer request instead of treating
an initial preference as a hard supported bound.

Validate the original wire request first. Only narrow its interval range;
leave latency, timeout and disjoint-range acceptance unchanged.

Assisted-by: OpenCode:gpt-6.1-sol
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Changes from v1:
- Treat local ranges as preferences, not supported bounds.
- Prefer a valid intersection; otherwise keep the original valid peer request.
- Never repair an invalid original request by clipping.
- Preserve latency, supervision timeout and disjoint-range acceptance.

Four native controls check both the accepted L2CAP response and resulting HCI
update range: overlap, fast HID fallback, slow idle fallback and exact match.
Baseline passes 3/4 (no narrower overlap); the strict-bound negative control
passes 2/4 (rejects HID/idle); this revision passes 4/4. Its full reference-guest
L2CAP suite passes 115/115 without skips or captured KASAN/lockdep alerts.
The source-extracted sanitizer fixture passes 397,723 parameter cases plus two
framing/role cases. These are finite tests, not proof for every controller.

The independent BlueZ interval-test companion is not yet sent. Its overlap test
intentionally fails without this Linux change. ASHA completed-interval startup
and stream gating are separate profile work, not a new kernel ABI or hard bound.

A combined Arch 7.2.9 trial with this change and revised BlueZ was built in a
clean chroot. I report that stack working on hardware; the running test kernel
and BlueZ package versions were verified. This is combined-stack evidence,
not isolated attribution or complete N7/paired-device/negative-path coverage.
It is not hardware testing of the bluetooth-next kernel itself. Remote CI for
this revision has not run. Target master still matches the tested source base.

 net/bluetooth/l2cap_core.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4dd56e007..afde04a19 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5031,6 +5031,19 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
 	memset(&rsp, 0, sizeof(rsp));
 
 	err = hci_check_conn_params(min, max, latency, to_multiplier);
+	if (!err) {
+		u16 pref_min = max_t(u16, min, hcon->le_conn_min_interval);
+		u16 pref_max = min_t(u16, max, hcon->le_conn_max_interval);
+
+		/* Local preferences must not reject a valid peer request. */
+		if (pref_min <= pref_max &&
+		    !hci_check_conn_params(pref_min, pref_max, latency,
+					  to_multiplier)) {
+			min = pref_min;
+			max = pref_max;
+		}
+	}
+
 	if (err)
 		rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
 	else

base-commit: 397464709a204da9b8dc3b01d6ea42539d951cd2

RE: [RFC,v2] Bluetooth: l2cap: prefer compatible local LE intervals

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1348 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/1186108/

---Test result---

Test Summary:
CheckPatch                    PASS      0.80 seconds
VerifyFixes                   PASS      0.12 seconds
VerifySignedoff               PASS      0.12 seconds
GitLint                       FAIL      0.32 seconds
SubjectPrefix                 PASS      0.11 seconds
BuildKernel                   PASS      29.45 seconds
CheckAllWarning               PASS      33.54 seconds
CheckSparse                   PASS      37.36 seconds
BuildKernel32                 PASS      29.54 seconds
CheckKernelLLVM               PASS      34.08 seconds
TestRunnerSetup               PASS      705.13 seconds
TestRunner_l2cap-tester       PASS      12.94 seconds
IncrementalBuild              PASS      27.88 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[RFC,v2] Bluetooth: l2cap: prefer compatible local LE intervals

22: B1 Line exceeds max length (81>80): "passes 2/4 (rejects HID/idle); this revision passes 4/4. Its full reference-guest"


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

---
Regards,
Linux Bluetooth

[RFC PATCH v3] Bluetooth: l2cap: prefer compatible local LE intervals

[Kyle Pepper]

Use a valid intersection of a peer interval range and local preferences
when they overlap. Otherwise retain the peer request instead of treating
an initial preference as a hard supported bound.

Validate the original wire request first. Only narrow its interval range;
leave latency, timeout and disjoint-range acceptance unchanged.

Assisted-by: OpenCode:gpt-6.1-sol
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Changes since v2:
- Wrap test notes to avoid the GitLint B1 failure in series 1186108.
- Refresh onto bluetooth-next ff8b09806b7b; no source delta from v2.

Changes from v1 retained:
- Treat local ranges as preferences, not supported bounds.
- Prefer a valid intersection; otherwise keep the valid peer request.
- Never repair an invalid original request by clipping.
- Preserve latency, supervision timeout and disjoint-range acceptance.

Prior native controls check the accepted L2CAP response and HCI range:
overlap, fast HID fallback, slow idle fallback and exact match. Baseline
passes 3/4; strict bounds pass 2/4 (reject HID/idle); v2 passes 4/4.
The prior reference-guest full L2CAP suite passes 115/115, without skips
or captured KASAN/lockdep alerts. These are prior runs, not fresh v3 VMs.

The independent BlueZ test companion was sent as:
https://lore.kernel.org/r/20261015044221.55631-1-cochcoder@proton.me
Its overlap case intentionally fails without this kernel change.
Completed-interval startup/stream gating remains separate profile work.

The saved v2 CI report lists all jobs except GitLint passing, including
the native L2CAP tester. This is not a remote CI result for v3.
The combined Arch trial is reported working on hardware, not isolated
testing of bluetooth-next or exhaustive device/negative-path coverage.

 net/bluetooth/l2cap_core.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4dd56e007..afde04a19 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5031,6 +5031,19 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
 	memset(&rsp, 0, sizeof(rsp));
 
 	err = hci_check_conn_params(min, max, latency, to_multiplier);
+	if (!err) {
+		u16 pref_min = max_t(u16, min, hcon->le_conn_min_interval);
+		u16 pref_max = min_t(u16, max, hcon->le_conn_max_interval);
+
+		/* Local preferences must not reject a valid peer request. */
+		if (pref_min <= pref_max &&
+		    !hci_check_conn_params(pref_min, pref_max, latency,
+					  to_multiplier)) {
+			min = pref_min;
+			max = pref_max;
+		}
+	}
+
 	if (err)
 		rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
 	else

base-commit: ff8b09806b7b18884ad8d3a2b3d702da534a4e21

Re: [RFC PATCH] Bluetooth: l2cap: honor local LE connection interval range

[cochcoder]

Thanks for pointing this out. I looked at the git history and confirmed the interoperability problem. I've sent a RFC v2 as 20261015043336.47734-1-cochcoder@proton.me. It prefers a valid overlap but preserves the original valid peer request when there is no usable overlap, rather than rejecting it. The native controls cover overlap, fast HID, slow idle and exact-match requests. The strict-bound version rejects the HID and idle cases. The revised full L2CAP suite passes 115/115.



On Tuesday, October 13th, 2026 at 10:33 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:

> Hi Kyle,
>
> On Mon, Oct 12, 2026 at 11:31 PM Kyle Pepper <cochcoder@proton.me> wrote:
> >
> > Intersect a valid peer request with the locally configured interval
> > range. Reject disjoint ranges and preserve validation of the original
> > request before applying local policy.
> >
> > Assisted-by: OpenCode:gpt-6.1-sol
> > Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> > ---
> > Submission review notes (not part of the commit message):
> > October 12 no-intersection trial accepts [16,24] and completes 30 ms
> > with STATUS 03 02 18 and normal host TX; the user hears silence. Volume
> > and multi-day acoustic comparison controls are incomplete. The working
> > intersection yields 20 ms. Maximum-only rejection failed in kernel 5
> > and is not this proposal. Generic minimum/range policy and LL-path
> > consistency remain RFC questions, not established by one renderer.
>
> I need to check the git history but I believe we tried something
> similar not long ago that created interoperability problems if we use
> strict range matching like this.
>
> >  net/bluetooth/l2cap_core.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index 49a998804..49e201d3e 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -4968,6 +4968,13 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
> >         memset(&rsp, 0, sizeof(rsp));
> >
> >         err = hci_check_conn_params(min, max, latency, to_multiplier);
> > +       if (!err) {
> > +               /* Apply local policy only after validating the peer's request. */
> > +               min = max_t(u16, min, hcon->le_conn_min_interval);
> > +               max = min_t(u16, max, hcon->le_conn_max_interval);
> > +               err = hci_check_conn_params(min, max, latency, to_multiplier);
> > +       }
> > +
> >         if (err)
> >                 rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
> >         else
> >
> > base-commit: 964430c038967fd06643e866f68115664e1a1bd1
> >
>
>
> --
> Luiz Augusto von Dentz
>

RE: [RFC,v3] Bluetooth: l2cap: prefer compatible local LE intervals

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1073 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/1186705/

---Test result---

Test Summary:
CheckPatch                    PASS      0.69 seconds
VerifyFixes                   PASS      0.15 seconds
VerifySignedoff               PASS      6.34 seconds
GitLint                       PASS      9.00 seconds
SubjectPrefix                 PASS      0.48 seconds
BuildKernel                   PASS      28.32 seconds
CheckAllWarning               PASS      33.29 seconds
CheckSparse                   PASS      35.57 seconds
BuildKernel32                 PASS      28.55 seconds
CheckKernelLLVM               PASS      32.07 seconds
TestRunnerSetup               PASS      663.93 seconds
TestRunner_l2cap-tester       PASS      12.35 seconds
IncrementalBuild              PASS      29.45 seconds



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

---
Regards,
Linux Bluetooth

Re: [RFC PATCH v3] Bluetooth: l2cap: prefer compatible local LE intervals

[cochcoder]

Hi,

Following up on this patch, is there anything else needed to move it forward?

Thanks,
Kyle


On Thursday, October 15th, 2026 at 2:11 PM, Kyle Pepper <cochcoder@proton.me> wrote:

> Use a valid intersection of a peer interval range and local preferences
> when they overlap. Otherwise retain the peer request instead of treating
> an initial preference as a hard supported bound.
> 
> Validate the original wire request first. Only narrow its interval range;
> leave latency, timeout and disjoint-range acceptance unchanged.
> 
> Assisted-by: OpenCode:gpt-6.1-sol
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
> Changes since v2:
> - Wrap test notes to avoid the GitLint B1 failure in series 1186108.
> - Refresh onto bluetooth-next ff8b09806b7b; no source delta from v2.
> 
> Changes from v1 retained:
> - Treat local ranges as preferences, not supported bounds.
> - Prefer a valid intersection; otherwise keep the valid peer request.
> - Never repair an invalid original request by clipping.
> - Preserve latency, supervision timeout and disjoint-range acceptance.
> 
> Prior native controls check the accepted L2CAP response and HCI range:
> overlap, fast HID fallback, slow idle fallback and exact match. Baseline
> passes 3/4; strict bounds pass 2/4 (reject HID/idle); v2 passes 4/4.
> The prior reference-guest full L2CAP suite passes 115/115, without skips
> or captured KASAN/lockdep alerts. These are prior runs, not fresh v3 VMs.
> 
> The independent BlueZ test companion was sent as:
> https://lore.kernel.org/r/20261015044221.55631-1-cochcoder@proton.me
> Its overlap case intentionally fails without this kernel change.
> Completed-interval startup/stream gating remains separate profile work.
> 
> The saved v2 CI report lists all jobs except GitLint passing, including
> the native L2CAP tester. This is not a remote CI result for v3.
> The combined Arch trial is reported working on hardware, not isolated
> testing of bluetooth-next or exhaustive device/negative-path coverage.
> 
>  net/bluetooth/l2cap_core.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 4dd56e007..afde04a19 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -5031,6 +5031,19 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
>  	memset(&rsp, 0, sizeof(rsp));
>  
>  	err = hci_check_conn_params(min, max, latency, to_multiplier);
> +	if (!err) {
> +		u16 pref_min = max_t(u16, min, hcon->le_conn_min_interval);
> +		u16 pref_max = min_t(u16, max, hcon->le_conn_max_interval);
> +
> +		/* Local preferences must not reject a valid peer request. */
> +		if (pref_min <= pref_max &&
> +		    !hci_check_conn_params(pref_min, pref_max, latency,
> +					  to_multiplier)) {
> +			min = pref_min;
> +			max = pref_max;
> +		}
> +	}
> +
>  	if (err)
>  		rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
>  	else
> 
> base-commit: ff8b09806b7b18884ad8d3a2b3d702da534a4e21
>

[PATCH 1/1] Bluetooth: reject invalid LE supervision timeout relationships

[Kyle Pepper]

The LE parameter validator calculates an unsigned maximum latency by
subtracting one from a truncated quotient. If the quotient is zero,
this wraps and accepts invalid parameters. Exact quotient boundaries
also accept equality where the supervision timeout must be greater.

Compare the products directly after checking the field bounds. The
validated interval and latency limits keep the products within int.
This enforces the strict timeout relationship without division or
unsigned subtraction.

Sashiko identified the underflow while reviewing the soft interval
preference RFC. The bug is already present in its unpatched base; keep
this common-validator fix independent of that preference policy.

Assisted-by: LLM

Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Fix the pre-existing validator bug found during interval RFC review.
AI review: https://sashiko.dev/#/patchset/20261015181041.42873-1-cochcoder%40proton.me

 include/net/bluetooth/hci_core.h | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index e33b15808..97ba716c0 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -2371,8 +2371,6 @@ static inline struct smp_irk *hci_get_irk(struct hci_dev *hdev,
 static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
 					u16 to_multiplier)
 {
-	u16 max_latency;
-
 	if (min > max) {
 		BT_WARN("min %d > max %d", min, max);
 		return -EINVAL;
@@ -2398,19 +2396,14 @@ static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
 		return -EINVAL;
 	}
 
-	if (max >= to_multiplier * 8) {
-		BT_WARN("max %d >= to_multiplier %d * 8", max, to_multiplier);
-		return -EINVAL;
-	}
-
-	max_latency = (to_multiplier * 4 / max) - 1;
 	if (latency > 499) {
 		BT_WARN("latency %d > 499", latency);
 		return -EINVAL;
 	}
 
-	if (latency > max_latency) {
-		BT_WARN("latency %d > max_latency %d", latency, max_latency);
+	if ((latency + 1) * max >= to_multiplier * 4) {
+		BT_WARN("latency %d, max %d and timeout %d are incompatible",
+			latency, max, to_multiplier);
 		return -EINVAL;
 	}
 

base-commit: a063a00e6cd9e354aa6d67a154a0527951d7f881

RE: [1/1] Bluetooth: reject invalid LE supervision timeout relationships

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 4023 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/1203685/

---Test result---

Test Summary:
CheckPatch                    FAIL      2.38 seconds
VerifyFixes                   PASS      0.13 seconds
VerifySignedoff               PASS      4.33 seconds
GitLint                       PASS      2.87 seconds
SubjectPrefix                 PASS      0.17 seconds
BuildKernel                   PASS      42.30 seconds
CheckAllWarning               PASS      36.61 seconds
CheckSparse                   PASS      39.09 seconds
BuildKernel32                 PASS      34.96 seconds
CheckKernelLLVM               PASS      35.11 seconds
TestRunnerSetup               PASS      755.31 seconds
TestRunner_l2cap-tester       FAIL      10.73 seconds
TestRunner_iso-tester         PASS      11.05 seconds
TestRunner_bnep-tester        PASS      3.24 seconds
TestRunner_mgmt-tester        PASS      89.13 seconds
TestRunner_rfcomm-tester      PASS      4.73 seconds
TestRunner_sco-tester         PASS      5.73 seconds
TestRunner_ioctl-tester       PASS      4.75 seconds
TestRunner_mesh-tester        PASS      5.63 seconds
TestRunner_smp-tester         PASS      4.43 seconds
TestRunner_userchan-tester    PASS      3.44 seconds
TestRunner_6lowpan-tester     PASS      4.90 seconds
IncrementalBuild              PASS      29.31 seconds

Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[1/1] Bluetooth: reject invalid LE supervision timeout relationships
WARNING: Non-standard signature: Assisted-by:
#99: 
Assisted-by: LLM

ERROR: Unrecognized email address: 'LLM'
#99: 
Assisted-by: LLM

total: 1 errors, 1 warnings, 30 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/14955884.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:
==35==ERROR: AddressSanitizer: heap-use-after-free on address 0x7b7dc18e33d0 at pc 0x560bc1481eee bp 0x7fff2ba55e70 sp 0x7fff2ba55e60
READ of size 4 at 0x7b7dc18e33d0 thread T0
    #0 0x560bc1481eed in timeout_callback src/shared/timeout-mainloop.c:33
    #1 0x560bc1482ed5 in timeout_callback src/shared/mainloop.c:271
    #2 0x560bc1484006 in mainloop_run src/shared/mainloop.c:125
    #3 0x560bc148696a in mainloop_run_with_signal src/shared/mainloop-notify.c:196
    #4 0x560bc148bc4b in tester_run src/shared/tester.c:1297
    #5 0x560bc13b51dd in main tools/l2cap-tester.c:3918
    #6 0x7f3dc27ec600 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:59
    #7 0x7f3dc27ec717 in __libc_start_main_impl ../csu/libc-start.c:360
    #8 0x560bc13bbce4 in _start (/home/runner/work/bluetooth-next/bluetooth-next/src/bluez/tools/l2cap-tester+0x16dce4) (BuildId: 0d2067a7ef8fe61fcf622598953c7d0f996221a0)

0x7b7dc18e33d0 is located 0 bytes inside of 40-byte region [0x7b7dc18e33d0,0x7b7dc18e33f8)
freed by thread T0 here:
    #0 0x7f3dc312a3ff in free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:51
    #1 0x560bc14823ca in timeout_destroy src/shared/mainloop.c:252

previously allocated by thread T0 here:
    #0 0x7f3dc312b60f in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:67
    #1 0x560bc146c335 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/1076

---
Regards,
Linux Bluetooth

Re: [PATCH 1/1] Bluetooth: reject invalid LE supervision timeout relationships

[cochcoder]

I sent a separate BlueZ fix for the timeout-wrapper use-after-free
reported by l2cap-tester:

[PATCH] shared/timeout: Keep callback data alive during removal
https://lore.kernel.org/linux-bluetooth/20261106042339.811655-1-cochcoder@proton.me/



On Thursday, November 5th, 2026 at 9:18 PM, Kyle Pepper <cochcoder@proton.me> wrote:

> The LE parameter validator calculates an unsigned maximum latency by
> subtracting one from a truncated quotient. If the quotient is zero,
> this wraps and accepts invalid parameters. Exact quotient boundaries
> also accept equality where the supervision timeout must be greater.
> 
> Compare the products directly after checking the field bounds. The
> validated interval and latency limits keep the products within int.
> This enforces the strict timeout relationship without division or
> unsigned subtraction.
> 
> Sashiko identified the underflow while reviewing the soft interval
> preference RFC. The bug is already present in its unpatched base; keep
> this common-validator fix independent of that preference policy.
> 
> Assisted-by: LLM
> 
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
> Fix the pre-existing validator bug found during interval RFC review.
> AI review: https://sashiko.dev/#/patchset/20261015181041.42873-1-cochcoder%40proton.me
> 
>  include/net/bluetooth/hci_core.h | 13 +++----------
>  1 file changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index e33b15808..97ba716c0 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -2371,8 +2371,6 @@ static inline struct smp_irk *hci_get_irk(struct hci_dev *hdev,
>  static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
>  					u16 to_multiplier)
>  {
> -	u16 max_latency;
> -
>  	if (min > max) {
>  		BT_WARN("min %d > max %d", min, max);
>  		return -EINVAL;
> @@ -2398,19 +2396,14 @@ static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
>  		return -EINVAL;
>  	}
>  
> -	if (max >= to_multiplier * 8) {
> -		BT_WARN("max %d >= to_multiplier %d * 8", max, to_multiplier);
> -		return -EINVAL;
> -	}
> -
> -	max_latency = (to_multiplier * 4 / max) - 1;
>  	if (latency > 499) {
>  		BT_WARN("latency %d > 499", latency);
>  		return -EINVAL;
>  	}
>  
> -	if (latency > max_latency) {
> -		BT_WARN("latency %d > max_latency %d", latency, max_latency);
> +	if ((latency + 1) * max >= to_multiplier * 4) {
> +		BT_WARN("latency %d, max %d and timeout %d are incompatible",
> +			latency, max, to_multiplier);
>  		return -EINVAL;
>  	}
>  
> 
> base-commit: a063a00e6cd9e354aa6d67a154a0527951d7f881
>

Re: [PATCH 1/1] Bluetooth: reject invalid LE supervision timeout relationships

[Luiz Augusto von Dentz]

Hi Kyle,

On Thu, Nov 5, 2026 at 9:18 PM Kyle Pepper <cochcoder@proton.me> wrote:
>
> The LE parameter validator calculates an unsigned maximum latency by
> subtracting one from a truncated quotient. If the quotient is zero,
> this wraps and accepts invalid parameters. Exact quotient boundaries
> also accept equality where the supervision timeout must be greater.
>
> Compare the products directly after checking the field bounds. The
> validated interval and latency limits keep the products within int.
> This enforces the strict timeout relationship without division or
> unsigned subtraction.
>
> Sashiko identified the underflow while reviewing the soft interval
> preference RFC. The bug is already present in its unpatched base; keep
> this common-validator fix independent of that preference policy.
>
> Assisted-by: LLM

No empty space, and lets add a Fixes tag.

> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
> Fix the pre-existing validator bug found during interval RFC review.
> AI review: https://sashiko.dev/#/patchset/20261015181041.42873-1-cochcoder%40proton.me
>
>  include/net/bluetooth/hci_core.h | 13 +++----------
>  1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index e33b15808..97ba716c0 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -2371,8 +2371,6 @@ static inline struct smp_irk *hci_get_irk(struct hci_dev *hdev,
>  static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
>                                         u16 to_multiplier)
>  {
> -       u16 max_latency;
> -
>         if (min > max) {
>                 BT_WARN("min %d > max %d", min, max);
>                 return -EINVAL;
> @@ -2398,19 +2396,14 @@ static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
>                 return -EINVAL;
>         }
>
> -       if (max >= to_multiplier * 8) {
> -               BT_WARN("max %d >= to_multiplier %d * 8", max, to_multiplier);
> -               return -EINVAL;
> -       }
> -
> -       max_latency = (to_multiplier * 4 / max) - 1;
>         if (latency > 499) {
>                 BT_WARN("latency %d > 499", latency);
>                 return -EINVAL;
>         }
>
> -       if (latency > max_latency) {
> -               BT_WARN("latency %d > max_latency %d", latency, max_latency);
> +       if ((latency + 1) * max >= to_multiplier * 4) {
> +               BT_WARN("latency %d, max %d and timeout %d are incompatible",
> +                       latency, max, to_multiplier);
>                 return -EINVAL;
>         }
>
>
> base-commit: a063a00e6cd9e354aa6d67a154a0527951d7f881
>


-- 
Luiz Augusto von Dentz

[PATCH v2 1/1] Bluetooth: reject invalid LE supervision timeout relationships

[Kyle Pepper]

The LE parameter validator calculates an unsigned maximum latency by
subtracting one from a truncated quotient. If the quotient is zero,
this wraps and accepts invalid parameters. Exact quotient boundaries
also accept equality where the supervision timeout must be greater.

Compare the products directly after checking the field bounds. The
validated interval and latency limits keep the products within int.
This enforces the strict timeout relationship without division or
unsigned subtraction.

Sashiko identified the underflow while reviewing the soft interval
preference RFC. The bug is already present in its unpatched base; keep
this common-validator fix independent of that preference policy.

Fixes: 8757825b128e ("Bluetooth: hci_check_conn_params() check proper range")
Assisted-by: LLM
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Fix the pre-existing validator bug found during interval RFC review.
AI review: https://sashiko.dev/#/patchset/20261015181041.42873-1-cochcoder%40proton.me

v2:
- Add the introducing commit in Fixes, as requested by Luiz.
- Remove the blank line between attribution and human sign-off trailers.
- No source changes.

 include/net/bluetooth/hci_core.h | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index e33b15808..97ba716c0 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -2371,8 +2371,6 @@ static inline struct smp_irk *hci_get_irk(struct hci_dev *hdev,
 static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
 					u16 to_multiplier)
 {
-	u16 max_latency;
-
 	if (min > max) {
 		BT_WARN("min %d > max %d", min, max);
 		return -EINVAL;
@@ -2398,19 +2396,14 @@ static inline int hci_check_conn_params(u16 min, u16 max, u16 latency,
 		return -EINVAL;
 	}
 
-	if (max >= to_multiplier * 8) {
-		BT_WARN("max %d >= to_multiplier %d * 8", max, to_multiplier);
-		return -EINVAL;
-	}
-
-	max_latency = (to_multiplier * 4 / max) - 1;
 	if (latency > 499) {
 		BT_WARN("latency %d > 499", latency);
 		return -EINVAL;
 	}
 
-	if (latency > max_latency) {
-		BT_WARN("latency %d > max_latency %d", latency, max_latency);
+	if ((latency + 1) * max >= to_multiplier * 4) {
+		BT_WARN("latency %d, max %d and timeout %d are incompatible",
+			latency, max, to_multiplier);
 		return -EINVAL;
 	}
 

base-commit: a063a00e6cd9e354aa6d67a154a0527951d7f881

Re: [PATCH v2 1/1] Bluetooth: reject invalid LE supervision timeout relationships

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Fri, 06 Nov 2026 17:24:57 +0000 you wrote:
> The LE parameter validator calculates an unsigned maximum latency by
> subtracting one from a truncated quotient. If the quotient is zero,
> this wraps and accepts invalid parameters. Exact quotient boundaries
> also accept equality where the supervision timeout must be greater.
> 
> Compare the products directly after checking the field bounds. The
> validated interval and latency limits keep the products within int.
> This enforces the strict timeout relationship without division or
> unsigned subtraction.
> 
> [...]

Here is the summary with links:
  - [v2,1/1] Bluetooth: reject invalid LE supervision timeout relationships
    https://git.kernel.org/bluetooth/bluetooth-next/c/c1d50a71cdee

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html