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

[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

[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 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