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

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

[Luiz Augusto von Dentz]

From: Oleh Konko <security@1seal.org>

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>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
v5: Address the comments on
https://sashiko.dev/#/patchset/bt-smp-v4-ea63d24bfcd1416f9da279190fab15fc%401seal.org?patch=14762

 net/bluetooth/smp.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 485e3468bd26..deb8dd244b77 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -1826,7 +1826,7 @@ 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 we need MITM check that it can be achieved. */
 	if (conn->hcon->pending_sec_level >= BT_SECURITY_HIGH) {
 		u8 method;
 
@@ -1834,6 +1834,10 @@ static u8 smp_cmd_pairing_req(struct l2cap_conn *conn, struct sk_buff *skb)
 					 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;
+		rsp.auth_req |= SMP_AUTH_MITM;
 	}
 
 	key_size = min(req->max_key_size, rsp.max_key_size);
-- 
2.53.0

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

[Luiz Augusto von Dentz]

From: Oleh Konko <security@1seal.org>

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>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
 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 deb8dd244b77..98f1da4f5f55 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.53.0

[PATCH v5 3/3] Bluetooth: L2CAP: Fix allowing to change security multiple times

[Luiz Augusto von Dentz]

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

If FLAG_PENDING_SECURITY is already set it means SMP pairing process
is in progress and hcon->pending_sec_level shouldn't be changed since it
may require to change pairing requirements (MITM), which may not be
supported depending on stage of the pairing procedure, and
may result in a security level that don't match with the pairing keys
authentication (e.g. upgrading to BT_SECURITY_HIGH without setting
MITM requirements).

To fix tis problem the code will now return -EINPROGRESS if a process
call setsockopt(BT_SECURITY) and set FLAG_PENDING_SECURITY it needs to
await the socket to resume and clear the flag before it can update the
security level again.

Fixes: bbb69b37be15 ("Bluetooth: Add return check for L2CAP security level set")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
v5: New patch to address comments on:
https://sashiko.dev/#/patchset/bt-smp-v4-ea63d24bfcd1416f9da279190fab15fc%401seal.org?patch=14763

 net/bluetooth/l2cap_sock.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 71e8c1b45bce..786ca7c6e272 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -929,6 +929,15 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname,
 
 		/* change security for LE channels */
 		if (chan->scid == L2CAP_CID_ATT) {
+			/* If security already pending, return error to avoid
+			 * changing the pending_sec_level while the pairing
+			 * procedure is still ongoing.
+			 */
+			if (test_bit(FLAG_PENDING_SECURITY, &chan->flags)) {
+				err = -EINPROGRESS;
+				break;
+			}
+
 			if (smp_conn_security(conn->hcon, sec.level)) {
 				err = -EINVAL;
 				break;
-- 
2.53.0

RE: [v5,1/3] Bluetooth: SMP: force responder MITM requirements before building the pairing response

[bluez.test.bot]

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

---Test result---

Test Summary:
CheckPatch                    PENDING   0.32 seconds
GitLint                       PENDING   0.29 seconds
SubjectPrefix                 PASS      0.40 seconds
BuildKernel                   PASS      25.80 seconds
CheckAllWarning               PASS      28.42 seconds
CheckSparse                   PASS      27.16 seconds
BuildKernel32                 PASS      25.12 seconds
TestRunnerSetup               PASS      564.24 seconds
TestRunner_l2cap-tester       PASS      27.98 seconds
TestRunner_iso-tester         PASS      37.67 seconds
TestRunner_bnep-tester        PASS      6.35 seconds
TestRunner_mgmt-tester        FAIL      113.95 seconds
TestRunner_rfcomm-tester      PASS      9.42 seconds
TestRunner_sco-tester         FAIL      14.23 seconds
TestRunner_ioctl-tester       PASS      10.27 seconds
TestRunner_mesh-tester        FAIL      12.52 seconds
TestRunner_smp-tester         PASS      8.54 seconds
TestRunner_userchan-tester    PASS      6.67 seconds
IncrementalBuild              PENDING   0.63 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: 488 (98.8%), Failed: 2, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.105 seconds
LL Privacy - Start Discovery 2 (Disable RL)          Failed       0.177 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    2.695 seconds
Mesh - Send cancel - 2                               Timed out    1.998 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH v5 1/3] Bluetooth: SMP: force responder MITM requirements before building the pairing response

[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 Wed,  1 Apr 2026 12:01:51 -0400 you wrote:
> From: Oleh Konko <security@1seal.org>
> 
> 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.
> 
> [...]

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

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