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

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

[Oleh Konko]

hi,

this series follows up on the private security discussion around legacy
LE pairing and BT_SECURITY_HIGH.

1/2 fixes the primary issue in tk_request(): when the local side
requires HIGH security, method selection must still consider that local
MITM requirement even if the remote auth_req does not set SMP_AUTH_MITM.

2/2 keeps the stored responder STK authentication bit aligned with the
pairing result by deriving it from the achieved MITM state rather than
from pending_sec_level. that keeps the legacy path consistent with the
existing Secure Connections handling and acts 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 be very helpful.

thanks,
Oleh

[PATCH v3 1/2] Bluetooth: SMP: honor local HIGH security when selecting legacy pairing method

[Oleh Konko]

tk_request() currently forces JUST_CFM whenever the remote auth_req
omits SMP_AUTH_MITM. That ignores the local pending_sec_level, even
though the responder may still require BT_SECURITY_HIGH.

The pairing-request path already rejects JUST_WORKS/JUST_CFM when
pending_sec_level >= BT_SECURITY_HIGH, so letting tk_request() ignore the
local MITM requirement can make method selection inconsistent with the
policy the stack already enforces.

Only select JUST_CFM when the remote does not request MITM and the local
side does not require HIGH security. Otherwise, derive the method from
the IO capability table.

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 | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index e67bf7b34ea..a9fb9b513d6 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -863,13 +863,14 @@ static int tk_request(struct l2cap_conn *conn, u8 remote_oob, u8 auth,
 	bt_dev_dbg(hcon->hdev, "auth:%u lcl:%u rem:%u", auth, local_io,
 		   remote_io);
 
-	/* If neither side wants MITM, either "just" confirm an incoming
-	 * request or use just-works for outgoing ones. The JUST_CFM
-	 * will be converted to JUST_WORKS if necessary later in this
-	 * function. If either side has MITM look up the method from the
-	 * table.
+	/* If the remote doesn't request MITM and the local side doesn't
+	 * require HIGH security, either "just" confirm an incoming request
+	 * or use just-works for outgoing ones. The JUST_CFM will be
+	 * converted to JUST_WORKS if necessary later in this function.
+	 * Otherwise, look up the method from the table.
 	 */
-	if (!(auth & SMP_AUTH_MITM))
+	if (!(auth & SMP_AUTH_MITM) &&
+	    hcon->pending_sec_level < BT_SECURITY_HIGH)
 		smp->method = JUST_CFM;
 	else
 		smp->method = get_auth_method(smp, local_io, remote_io);
-- 
2.50.0

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

[bluez.test.bot]

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

---Test result---

Test Summary:
CheckPatch                    PENDING   0.72 seconds
GitLint                       PENDING   0.41 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      26.81 seconds
CheckAllWarning               PASS      29.79 seconds
CheckSparse                   PASS      28.09 seconds
BuildKernel32                 PASS      25.94 seconds
TestRunnerSetup               PASS      567.37 seconds
TestRunner_l2cap-tester       PASS      29.34 seconds
TestRunner_iso-tester         PASS      39.60 seconds
TestRunner_bnep-tester        PASS      6.23 seconds
TestRunner_mgmt-tester        FAIL      112.23 seconds
TestRunner_rfcomm-tester      PASS      9.38 seconds
TestRunner_sco-tester         FAIL      14.27 seconds
TestRunner_ioctl-tester       PASS      9.93 seconds
TestRunner_mesh-tester        FAIL      11.47 seconds
TestRunner_smp-tester         PASS      10.45 seconds
TestRunner_userchan-tester    PASS      6.60 seconds
IncrementalBuild              PENDING   0.60 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: 485 (98.2%), Failed: 5, Not Run: 4

Failed Test Cases
Adv. connectable & connected (central) - Success     Failed       0.125 seconds
Adv. non-connectable & connected (central) - Success Failed       0.122 seconds
Ext Adv. connectable & connected (central)           Failed       0.182 seconds
Ext Adv. non-connectable & connected (central)       Failed       0.185 seconds
Read Exp Feature - Success                           Failed       0.108 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.837 seconds
Mesh - Send cancel - 2                               Timed out    1.993 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH v3 1/2] Bluetooth: SMP: honor local HIGH security when selecting legacy pairing method

[Luiz Augusto von Dentz]

Hi @Christian Eggers,

On Mon, Mar 30, 2026 at 11:33 AM Oleh Konko <security@1seal.org> wrote:
>
> tk_request() currently forces JUST_CFM whenever the remote auth_req
> omits SMP_AUTH_MITM. That ignores the local pending_sec_level, even
> though the responder may still require BT_SECURITY_HIGH.
>
> The pairing-request path already rejects JUST_WORKS/JUST_CFM when
> pending_sec_level >= BT_SECURITY_HIGH, so letting tk_request() ignore the
> local MITM requirement can make method selection inconsistent with the
> policy the stack already enforces.
>
> Only select JUST_CFM when the remote does not request MITM and the local
> side does not require HIGH security. Otherwise, derive the method from
> the IO capability table.
>
> 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 | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index e67bf7b34ea..a9fb9b513d6 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -863,13 +863,14 @@ static int tk_request(struct l2cap_conn *conn, u8 remote_oob, u8 auth,
>         bt_dev_dbg(hcon->hdev, "auth:%u lcl:%u rem:%u", auth, local_io,
>                    remote_io);
>
> -       /* If neither side wants MITM, either "just" confirm an incoming
> -        * request or use just-works for outgoing ones. The JUST_CFM
> -        * will be converted to JUST_WORKS if necessary later in this
> -        * function. If either side has MITM look up the method from the
> -        * table.
> +       /* If the remote doesn't request MITM and the local side doesn't
> +        * require HIGH security, either "just" confirm an incoming request
> +        * or use just-works for outgoing ones. The JUST_CFM will be
> +        * converted to JUST_WORKS if necessary later in this function.
> +        * Otherwise, look up the method from the table.
>          */
> -       if (!(auth & SMP_AUTH_MITM))
> +       if (!(auth & SMP_AUTH_MITM) &&
> +           hcon->pending_sec_level < BT_SECURITY_HIGH)
>                 smp->method = JUST_CFM;
>         else
>                 smp->method = get_auth_method(smp, local_io, remote_io);
> --
> 2.50.0

Do you have any capacity to test if such change affects any SMP test with PTS?

-- 
Luiz Augusto von Dentz

Re: [PATCH v3 1/2] Bluetooth: SMP: honor local HIGH security when selecting legacy pairing method

[Luiz Augusto von Dentz]

Hi Oleh,

On Mon, Mar 30, 2026 at 11:33 AM Oleh Konko <security@1seal.org> wrote:
>
> tk_request() currently forces JUST_CFM whenever the remote auth_req
> omits SMP_AUTH_MITM. That ignores the local pending_sec_level, even
> though the responder may still require BT_SECURITY_HIGH.
>
> The pairing-request path already rejects JUST_WORKS/JUST_CFM when
> pending_sec_level >= BT_SECURITY_HIGH, so letting tk_request() ignore the
> local MITM requirement can make method selection inconsistent with the
> policy the stack already enforces.
>
> Only select JUST_CFM when the remote does not request MITM and the local
> side does not require HIGH security. Otherwise, derive the method from
> the IO capability table.
>
> 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 | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index e67bf7b34ea..a9fb9b513d6 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -863,13 +863,14 @@ static int tk_request(struct l2cap_conn *conn, u8 remote_oob, u8 auth,
>         bt_dev_dbg(hcon->hdev, "auth:%u lcl:%u rem:%u", auth, local_io,
>                    remote_io);
>
> -       /* If neither side wants MITM, either "just" confirm an incoming
> -        * request or use just-works for outgoing ones. The JUST_CFM
> -        * will be converted to JUST_WORKS if necessary later in this
> -        * function. If either side has MITM look up the method from the
> -        * table.
> +       /* If the remote doesn't request MITM and the local side doesn't
> +        * require HIGH security, either "just" confirm an incoming request
> +        * or use just-works for outgoing ones. The JUST_CFM will be
> +        * converted to JUST_WORKS if necessary later in this function.
> +        * Otherwise, look up the method from the table.
>          */
> -       if (!(auth & SMP_AUTH_MITM))
> +       if (!(auth & SMP_AUTH_MITM) &&
> +           hcon->pending_sec_level < BT_SECURITY_HIGH)
>                 smp->method = JUST_CFM;
>         else
>                 smp->method = get_auth_method(smp, local_io, remote_io);
> --
> 2.50.0

https://sashiko.dev/#/patchset/bt-smp-v3-b13a5d5f53ed4efaba74be7539453366%401seal.org

Seem valid, perhaps we will need to do something like the following to
force the SMP_AUTH_MITM bit in the response:

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 485e3468bd26..9841acc9d074 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 not set by 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;

-- 
Luiz Augusto von Dentz

[PATCH v3 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 a9fb9b513d6..0e20497988e 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -1019,10 +1019,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