[PW_SID:1075938] [v5,1/3] Bluetooth: SMP: force responder MITM requirements before building the pairing response#3439
[PW_SID:1075938] [v5,1/3] Bluetooth: SMP: force responder MITM requirements before building the pairing response#3439BluezTestBot wants to merge 4 commits intoworkflowfrom
Conversation
This patch adds workflow files for ci: [sync.yml] - The workflow file for scheduled work - Sync the repo with upstream repo and rebase the workflow branch - Review the patches in the patchwork and creates the PR if needed [ci.yml] - The workflow file for CI tasks - Run CI tests when PR is created Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
… pairing response 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: 2b64d15 ("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>
…state 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: fff3490 ("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>
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: bbb69b3 ("Bluetooth: Add return check for L2CAP security level set") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
CheckPatch |
|
GitLint |
|
SubjectPrefix |
|
BuildKernel |
|
CheckAllWarning |
|
CheckSparse |
|
BuildKernel32 |
|
TestRunnerSetup |
|
TestRunner_l2cap-tester |
|
TestRunner_iso-tester |
|
TestRunner_bnep-tester |
|
TestRunner_mgmt-tester |
|
TestRunner_rfcomm-tester |
|
TestRunner_sco-tester |
|
TestRunner_ioctl-tester |
|
TestRunner_mesh-tester |
|
TestRunner_smp-tester |
|
TestRunner_userchan-tester |
|
IncrementalBuild |
github-actions
bot
force-pushed
the
workflow
branch
7 times, most recently
from
f07ea67 to
9a108c6
Compare
4 participants
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: 2b64d15 ("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(-)