Do not rewrite static or non-resolvable random peer addresses to
identity type 0x03 when CONFIG_BT_BLE_RPA_SUPPORTED is enabled.
(cherry picked from commit 2ef10ef488)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
HFP AG:
- Fix mSBC EV3 second-packet payload length calculation to prevent OOB read and infinite loop
- Add init/deinit guards in HF AG helper functions to avoid NULL deref
- Break SCO CI data loop when SCO is not open to prevent CPU starvation
- Guard BTM_FreeSCN(0) and reset SCN after free in bta_ag_del_records
- Use OI_UINT32 for mSBC decode frame length to avoid stack corruption
- Bound AT Dial command string copy to BTA_AG_AT_MAX_LEN
HFP Client:
- Use OI_UINT32 for mSBC decode frame length to avoid stack corruption
- Free SDP db, collision/AT timers and queued AT cmds before scb reset on disable
- Fix mSBC EV3 second-packet payload length calculation (same as AG)
- Reject pcm_resample input smaller than overlap window (96 bytes) on filtered path
- Break SCO CI data loop when SCO is not open to prevent CPU starvation
- Guard BTM_FreeSCN(0) and reset SCN after free in bta_hf_client_del_record
ESP_FAULT_ASSERT(C) was silently deleted by the optimizer when C is a cached
flag/status already proven by a preceding `if (!C) return/goto`: the compiler
folds C to a constant and drops all three checks, removing the fault-injection
protection with no warning.
In release/v5.x, esp_fault.h resides in the esp_hw_support (G1)
component, so the G0 components (hal, esp_rom) must not depend on it.
Copy its contents to esp_common as esp_fault_internal.h, keep
esp_fault.h as a compatibility wrapper around it, and switch the hal
and esp_rom ECDSA/ECC code to the internal header.
Prevent signature verification failures on targets that do not round hardware words
to 16-word boundaries (e.g. ESP32-S3, ESP32-C6, and ESP32-P4), where exponent blinding
can cause `num_words` to vary between calls, leading to reuse of an incorrectly sized
cached `Rinv`.
Perform modulo reduction on the base before size checks to allow RSA-4096
CRT (2048-bit exponentiations) to use the hardware accelerator instead of
falling back to software. Fix input validation, negative zero sign issues,
and early memory cleanup paths in esp_mpi_exp_mod()
Peers may report custom or non-standard codec UUIDs in AT+BAC alongside
CVSD/mSBC. Returning BTA_AG_CODEC_NONE on the first unknown entry
discarded already-parsed standard codecs. Log unknown UUIDs and continue
parsing so negotiated capabilities still reflect supported codecs.
ECDSA based Secure Boot V2 is not functional for certain input vectors on
ESP32-C5/C61/H2/P4 and on the preview targets ESP32-H4/H21. RSA based Secure
Boot V2 is the recommended scheme where the SoC supports it. This issue will be
fixed in a future hardware ECO revision; more details will be shared through the
hardware errata document.
A new hidden Kconfig option SECURE_BOOT_V2_ECDSA_INSECURE marks the affected
mass-production SoCs (ESP32-C5/C61/H2/P4). On these SoCs, when hardware Secure
Boot V2 is enabled, the ECDSA (V2) signing scheme is no longer offered by
default; it must be turned on explicitly via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
under "Allow potentially insecure options" (CONFIG_SECURE_BOOT_INSECURE). App
signing without hardware Secure Boot is not affected. Note that ESP32-C61 has no
RSA based Secure Boot V2, so it has no Secure Boot scheme enabled by default.
The preview targets ESP32-H4 and ESP32-H21 mark ECDSA Secure Boot V2 as not
supported in their SoC capabilities instead of using the option above. As
ESP32-H4 has no other Secure Boot V2 scheme, Secure Boot is disabled entirely on
it; ESP32-H21 retains RSA based Secure Boot V2.
The security documentation keeps the ECDSA Secure Boot V2 content visible and
adds a warning describing the limitation (including that ECDSA Secure Boot V2 on
ESP32-C61 is not recommended for production). CI apps that exercise ECDSA Secure
Boot V2 on the affected SoCs set CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
accordingly.
