New ble_log_test app captures the runtime hook output through the test
peripheral and validates the version info frame: source code, BLE Log
version, a hex-valid idf commit that must be non-zero, per-lib commit
fields non-zero exactly when the matching lib is linked, and chip
model/revision matching esp_chip_info(). The README carries the
generated empty Supported Targets table to match the build-test
manifest.
The test drives transports via sustained writes instead of
ble_log_flush(): the flush window disables the module, so hook frames
written during a flush would be dropped.
Also move .build-test-rules.yml from ble_log_perf_test/ to the
test_apps/ root (one manifest entry per app, as elsewhere in ESP-IDF).
Both apps stay disabled until BLE Log test runners are available.
Verified: full esp32c6 build of the app; the build-test checker's own
parsing logic confirms the README table matches the manifest.
Replace the 2-byte BLE Log info record with a 58-byte version info
frame (BLE_LOG_VERSION 5 -> 6; the abandoned branch that claimed the
version-6 slot frees it, so the overall bump stays 5 -> 6):
- idf build commit (12 bytes), injected at build time by
register_ble_log_idf_commit() next to the other register_* helpers;
the git probe is only trusted when the IDF tree itself is a
repo/worktree, since rev-parse walks up parent directories
- controller, btdm_common, BLE Mesh and BLE Audio lib commits (10
bytes each, zero-padded), every getter guarded by the exact
condition that links its lib, so configs without the lib leave the
field zero (no link errors)
- chip model and revision from esp_chip_info() at runtime
Lib strings are copied NUL-safely instead of assuming a fixed hash
length; the mesh commit is the substring after the last space of
bt_mesh_v11_commit_str. Frame layout is pinned by a static assert.
Verified on target: esp32, esp32c3, esp32c5 and esp32h4 boards (the
h4 run covers controller + btdm_common + mesh in one build); the
audio-enabled build is blocked by pre-existing esp_ble_audio compile
errors on this base (audio symbol verified with nm instead).
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.
Liu Linyan
Michael.B
Zhou Xiao
Mahavir Jain
wanckl
zhiweijian
Martin Vychodil
Hu Rui
Island
yinqingzhao
morris
hejiaxin
Marius Vikhammer
harshal.patil
Jiang Jiang Jian
Sudeep Mohanty
Ashish Sharma
hebinglin
Fu Hanxi
wuzhenghui
zhanghaipeng