Add smp_repairing_is_allowed() behind BT_BLE_SMP_HARDENED_REPAIRING so a
peer cannot replace an existing bond with one that has less MITM
protection, no Secure Connections, or a shorter key. Compare a preceding
Security Request against the pairing command AuthReq, not the
association-model result, and always allow first pairing.
A refusal keeps the stored bond. Pairing-failure erase is split by link
role: default is erase as Central and keep as Peripheral.
Closes BLERP (NDSS 2026) V3, V4 and V6.
Keep the existing bond until the new pairing is encrypted, and on encryption
failure drop the link instead of clearing keys. Recovering from a peer that
really deleted the bond is opt-in through BT_BLE_SMP_UNBOND_ON_KEY_MISSING.
Closes BLERP (NDSS 2026) V5, and stops an unauthenticated Pairing Request
from dropping the stored keys (V2 exploitation).
With MBEDTLS_PSA_ASSUME_EXCLUSIVE_BUFFERS enabled, an in-place
psa_cipher_update() reaches the selected cipher implementation without
defensive buffer copies. The ESP AES PSA driver accepts an in-place
update of any length for CTR (PSA classifies CTR as a stream cipher, so
the driver's block_length is 1), but on targets without the AES
peripheral (e.g. ESP32-C61) the operation falls back to the mbedtls
builtin cipher layer, which rejects in-place updates whose length is
not a multiple of the block size (MBEDTLS_ERR_CIPHER_BAD_INPUT_DATA,
surfacing as PSA_ERROR_INVALID_ARGUMENT).
Round the in-place test length down to a block multiple when
CONFIG_MBEDTLS_HARDWARE_AES is not set; partial-block PSRAM coverage is
retained through the separate-buffer alignment tests.
esp_mspi_align.c resolves PSRAM encryption state through esp_psram, a
dependency esp_hw_support declares only outside the no-OS builds. Nothing
in the bootloader calls the helper, so drop the source there rather than
keep one whose dependency cannot be satisfied. ESP-TEE still builds it,
as its mbedtls port calls into it.
fix(bt/bluedroid): fixed the function prototype of the command handler of READ LOCAL SUPPORTED CODECS.
Closes BTQABR2023-888
See merge request espressif/esp-idf!51832
esp_hmac_calculate() enabled and reset the Digital Signature (DS)
peripheral, but HMAC has no dependency on DS (the dependency runs the
other way: a DS operation uses HMAC/SHA).
The DS peripheral drives the RSA (MPI) accelerator internally, so pulsing
the DS reset also resets the RSA datapath. This coupling exists on every
target that has the DS peripheral: the MPI reset routine itself clears the
DS reset "otherwise RSA is held in reset".
esp_hmac_calculate() holds only the HMAC and SHA/AES locks, not the MPI
lock, so it can corrupt a concurrent RSA/MPI operation. On multi-core
targets (e.g. ESP32-P4, ESP32-S31, ESP32-S3) an HMAC on one core resets an
RSA op running on another core; on single-core targets (e.g. ESP32-C5) the
same corruption happens when an HMAC preempts an in-flight RSA op. The
result is a wrong RSA result or a crash in the computation.
Remove the DS peripheral enable/reset from the HMAC path. SHA, which HMAC
depends on, is enabled independently, so the HMAC output is unchanged.
This also drops a few redundant register writes.
Do not reject osi_thread_post_event() when only POSTING is set.
QUEUED already prevents double-queueing; rejecting POSTING caused
HCI downstream lost wakeup. Add generic osi_event and hci downstream
diagnostics for post failures.
Mahavir Jain
wanckl
zhiweijian
Martin Vychodil
Hu Rui
Island
yinqingzhao
morris
Liu Linyan
hejiaxin
Marius Vikhammer
harshal.patil
Jiang Jiang Jian
Sudeep Mohanty
Ashish Sharma
hebinglin
Zhou Xiao
Fu Hanxi
wuzhenghui
Jan Beran
zhanghaipeng