[PATCH v4 0/2] Bluetooth: SMP: honor local MITM requirements for legacy pairing

[PATCH v4 0/2] Bluetooth: SMP: honor local MITM requirements for legacy pairing

[Oleh Konko]

hi,

this v4 series follows up on Luiz's latest review direction.

1/2 moves the primary fix into smp_cmd_pairing_req(): when the local
side requires BT_SECURITY_HIGH, the responder first verifies that MITM
is achievable and then forces SMP_AUTH_MITM in the pairing response so
the responder auth bits and later method selection stay aligned.

2/2 keeps the stored legacy responder STK authentication bit tied to the
achieved MITM state rather than to pending_sec_level. that keeps the key
metadata consistent with the pairing result as defense in depth.

both patches carry Fixes and Cc: stable.

if anyone with recent Bluetooth qualification access can run this
against PTS as well, that would still be very helpful.

thanks,
Oleh

[PATCH v4 1/2] Bluetooth: SMP: force responder MITM requirements before building the pairing response

[Oleh Konko]

smp_cmd_pairing_req() currently builds the pairing response from the
initiator auth_req before enforcing the local BT_SECURITY_HIGH
requirement. If the initiator omits SMP_AUTH_MITM, the response can
also omit it even though the local side still requires MITM.

tk_request() then sees an auth value without SMP_AUTH_MITM and may
select JUST_CFM, making method selection inconsistent with the pairing
policy the responder already enforces.

When the local side requires HIGH security, first verify that MITM can
be achieved from the IO capabilities and then force SMP_AUTH_MITM in the
response before build_pairing_cmd(). This keeps the responder auth bits
and later method selection aligned.

Fixes: 2b64d153a0cc ("Bluetooth: Add MITM mechanism to LE-SMP")
Cc: stable@vger.kernel.org
Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Signed-off-by: Oleh Konko <security@1seal.org>
---
 net/bluetooth/smp.c | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index e67bf7b34ea..4eaadbe0d2f 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -1809,6 +1809,19 @@ static u8 smp_cmd_pairing_req(struct l2cap_conn *conn, struct sk_buff *skb)
 		return 0;
 	}
 
+	/* If we need MITM check that it can be achieved. */
+	if (conn->hcon->pending_sec_level >= BT_SECURITY_HIGH) {
+		u8 method;
+
+		method = get_auth_method(smp, conn->hcon->io_capability,
+					 req->io_capability);
+		if (method == JUST_WORKS || method == JUST_CFM)
+			return SMP_AUTH_REQUIREMENTS;
+
+		/* Force MITM bit if it isn't set by the initiator. */
+		auth |= SMP_AUTH_MITM;
+	}
+
 	build_pairing_cmd(conn, req, &rsp, auth);
 
 	if (rsp.auth_req & SMP_AUTH_SC) {
@@ -1826,16 +1839,6 @@ static u8 smp_cmd_pairing_req(struct l2cap_conn *conn, struct sk_buff *skb)
 	if (sec_level > conn->hcon->pending_sec_level)
 		conn->hcon->pending_sec_level = sec_level;
 
-	/* If we need MITM check that it can be achieved */
-	if (conn->hcon->pending_sec_level >= BT_SECURITY_HIGH) {
-		u8 method;
-
-		method = get_auth_method(smp, conn->hcon->io_capability,
-					 req->io_capability);
-		if (method == JUST_WORKS || method == JUST_CFM)
-			return SMP_AUTH_REQUIREMENTS;
-	}
-
 	key_size = min(req->max_key_size, rsp.max_key_size);
 	if (check_enc_key_size(conn, key_size))
 		return SMP_ENC_KEY_SIZE;
-- 
2.50.0

RE: Bluetooth: SMP: honor local MITM requirements for legacy pairing

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2593 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=1075166

---Test result---

Test Summary:
CheckPatch                    PENDING   0.60 seconds
GitLint                       PENDING   0.36 seconds
SubjectPrefix                 PASS      0.14 seconds
BuildKernel                   PASS      26.52 seconds
CheckAllWarning               PASS      29.17 seconds
CheckSparse                   PASS      31.85 seconds
BuildKernel32                 PASS      25.71 seconds
TestRunnerSetup               PASS      568.97 seconds
TestRunner_l2cap-tester       PASS      28.52 seconds
TestRunner_iso-tester         PASS      40.23 seconds
TestRunner_bnep-tester        PASS      6.34 seconds
TestRunner_mgmt-tester        FAIL      116.93 seconds
TestRunner_rfcomm-tester      PASS      9.51 seconds
TestRunner_sco-tester         FAIL      14.39 seconds
TestRunner_ioctl-tester       PASS      10.16 seconds
TestRunner_mesh-tester        FAIL      11.52 seconds
TestRunner_smp-tester         PASS      8.58 seconds
TestRunner_userchan-tester    PASS      6.67 seconds
IncrementalBuild              PENDING   0.96 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.121 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
BUG: sleeping function called from invalid context at net/core/sock.c:3782
Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    1.784 seconds
Mesh - Send cancel - 2                               Timed out    1.996 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

[PATCH v4 2/2] Bluetooth: SMP: derive legacy responder STK authentication from MITM state

[Oleh Konko]

The legacy responder path in smp_random() currently labels the stored
STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH.
That reflects what the local service requested, not what the pairing
flow actually achieved.

For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear
and the resulting STK should remain unauthenticated even if the local
side requested HIGH security. Use the established MITM state when
storing the responder STK so the key metadata matches the pairing result.

This also keeps the legacy path aligned with the Secure Connections code,
which already treats JUST_WORKS/JUST_CFM as unauthenticated.

Fixes: fff3490f4781 ("Bluetooth: Fix setting correct authentication information for SMP STK")
Cc: stable@vger.kernel.org
Signed-off-by: Oleh Konko <security@1seal.org>
---
 net/bluetooth/smp.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 4eaadbe0d2f..e504ccd745a 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -1018,10 +1018,7 @@ static u8 smp_random(struct smp_chan *smp)
 
 		smp_s1(smp->tk, smp->prnd, smp->rrnd, stk);
 
-		if (hcon->pending_sec_level == BT_SECURITY_HIGH)
-			auth = 1;
-		else
-			auth = 0;
+		auth = test_bit(SMP_FLAG_MITM_AUTH, &smp->flags) ? 1 : 0;
 
 		/* Even though there's no _RESPONDER suffix this is the
 		 * responder STK we're adding for later lookup (the initiator
-- 
2.50.0

Re: [PATCH v4 0/2] Bluetooth: SMP: honor local MITM requirements for legacy pairing

[patchwork-bot+bluetooth]

Hello:

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

On Tue, 31 Mar 2026 11:52:12 +0000 you wrote:
> hi,
> 
> this v4 series follows up on Luiz's latest review direction.
> 
> 1/2 moves the primary fix into smp_cmd_pairing_req(): when the local
> side requires BT_SECURITY_HIGH, the responder first verifies that MITM
> is achievable and then forces SMP_AUTH_MITM in the pairing response so
> the responder auth bits and later method selection stay aligned.
> 
> [...]

Here is the summary with links:
  - [v4,1/2] Bluetooth: SMP: force responder MITM requirements before building the pairing response
    (no matching commit)
  - [v4,2/2] Bluetooth: SMP: derive legacy responder STK authentication from MITM state
    https://git.kernel.org/bluetooth/bluetooth-next/c/3a0b100b337c

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