Androids Bluetooth stack for example implements this decision as follows: /* If JustWorks auto-accept */ if ( p_ssp_cfm_req -> just_works ) { // Pairing consent for JustWorks needed if: // 1. Incoming (non-temporary) pairing is detected AND // 2. local IO capabilities are DisplayYesNo AND // 3. remote IO capabilities are DisplayOnly or NoInputNoOutput; if ( is_incoming && pairing_cb . bond_type != BOND_TYPE_TEMPORARY && (( p_ssp_cfm_req -> loc_io_caps == HCI_IO_CAP_DISPLAY_YESNO ) && ( p_ssp_cfm_req -> rmt_io_caps == HCI_IO_CAP_DISPLAY_ONLY || p_ssp_cfm_req -> rmt_io_caps == HCI_IO_CAP_NO_IO ))) { BTIF_TRACE_EVENT( "%s: User consent needed for incoming pairing request. loc_io_caps: " "%d, rmt_io_caps: %d", __func__ , p_ssp_cfm_req -> loc_io_caps , p_ssp_cfm_req -> rmt_io_caps ); } else { BTIF_TRACE_EVENT ( "%s: Auto-accept JustWorks pairing" , __func__ ); btif_dm_ssp_reply (& bd_addr , BT_SSP_VARIANT_CONSENT , true , 0 ); return; } }

The user will need to accept a JustWorks pairing procedure only if these terms are met:

- The pairing is non-temporary (involving a long-term key exchange - Bonding) - The local (the Androids) IO capabilities are DisplayYesNo, and the remote IO capabilities are limited (Display Only, or no IO).

In two or three sentences, describe the vulnerability in detail (code-level) that involve Stack Overflow attack.