1SEAL-2026-011: Linux Bluetooth SMP legacy pairing can satisfy BT_SECURITY_HIGH without MITM

summary

Linux mislabels the responder STK from legacy LE pairing as authenticated when a local service requested BT_SECURITY_HIGH, even if the pairing actually completed as JUST_WORKS or JUST_CFM without MITM protection.

the vulnerable decision is in net/bluetooth/smp.c:smp_random(). in the affected path, the kernel derives the stored STK authentication bit from hcon->pending_sec_level instead of from the achieved MITM state tracked in SMP_FLAG_MITM_AUTH.

once the wrong authenticated=1 bit is stored, Linux maps that STK back to BT_SECURITY_HIGH, restores that level onto the active connection, and later authorization checks can accept the link as if MITM had been achieved.

upstream fix status

Linux maintainers accepted the report and landed a two-commit fix set in mainline on April 1, 2026:

• d05111bfe37bfd8bd4d2dfe6675d6bdeef43f7c7 — Bluetooth: SMP: force responder MITM requirements before building the pairing response
• 20756fec2f0108cb88e815941f1ffff88dc286fe — Bluetooth: SMP: derive legacy responder STK authentication from MITM state

these commits are the public upstream fix boundary for the issue described here. downstream backport status should be checked separately.

severity

affected versions

artifact	status
torvalds/linux@267594792a71018788af69e836c52e34bb8054af	confirmed affected during reporting
kernels carrying the legacy SMP responder path before the April 1, 2026 upstream fixes	likely affected

this advisory does not claim an exact historical introduction version because the vulnerable behavior was not bisected to its first appearance.

patched versions

• mainline containing d05111bfe37bfd8bd4d2dfe6675d6bdeef43f7c7
• mainline containing 20756fec2f0108cb88e815941f1ffff88dc286fe

for packaged kernels, use your vendor or distro changelog to confirm whether both commits were backported.

am i affected?

you are affected if all of the following are true:

• your kernel does not yet contain the April 1, 2026 upstream fixes
• your system uses the legacy BLE SMP pairing path
• a local BLE service, socket, or policy path requires BT_SECURITY_HIGH
• an attacker can reach the device over BLE radio range

root cause

the vulnerable branch in smp_random() is small:

smp_s1(smp->tk, smp->prnd, smp->rrnd, stk);

if (hcon->pending_sec_level == BT_SECURITY_HIGH)
	auth = 1;
else
	auth = 0;

hci_add_ltk(hcon->hdev, &hcon->dst, hcon->dst_type,
	    SMP_STK, auth, stk, smp->enc_key_size, ediv, rand);

for legacy pairing, pending_sec_level is what the local service asked for. it is not evidence that MITM authentication was achieved. the kernel already tracks the achieved property separately through SMP_FLAG_MITM_AUTH, but the legacy responder path never mirrored that distinction when storing the STK.

exploitation chain

1. a victim Linux host exposes a BLE path that requests BT_SECURITY_HIGH
2. a remote BLE device in radio range initiates legacy pairing with auth_req=0x00
3. tk_request() selects JUST_CFM, so SMP_FLAG_MITM_AUTH remains clear
4. smp_random() still stores the responder STK with authenticated=1 because pending_sec_level is high
5. smp_ltk_sec_level() maps that stored bit to BT_SECURITY_HIGH
6. hci_le_ltk_request_evt() restores that level onto the live connection
7. smp_sufficient_security() returns true for a high-security check

impact

this is an authentication bypass for BLE services that rely on BT_SECURITY_HIGH to require MITM-protected pairing. in affected deployments, a remote BLE device can complete an unauthenticated legacy pairing flow and still be treated by the kernel as having satisfied the high-security requirement.

workarounds

• avoid relying on legacy pairing as the only protection for sensitive BLE services
• prefer environments or configurations that do not expose security-critical BLE paths to unauthenticated nearby peers
• if you maintain a downstream kernel, backport both upstream commits together rather than only one leg

fix

the upstream remediation split the problem into two complementary fixes:

• enforce responder MITM requirements before constructing the pairing response
• derive the legacy responder STK authentication bit from the achieved MITM state, not from pending_sec_level

the smallest core trust correction is:

auth = test_bit(SMP_FLAG_MITM_AUTH, &smp->flags) ? 1 : 0;

timeline

date	event
2026-03-15	private report prepared and submitted to the Linux kernel security process
2026-03-17	maintainer review raises technical objections and requests clarification
2026-03-18	maintainer confirms the bug and begins driving the fix direction
2026-04-01	upstream fix commits land in mainline
2026-04-04	public advisory published

credit

discovered and reported by Oleh Konko (1seal).

references

• pinned vulnerable tree
• vulnerable callsite
• security mapping path
• authorization gate
• upstream fix 1
• upstream fix 2
• Linux kernel security process
• CWE-287: Improper Authentication