Return BTM_HCI_ERROR | hci_status from legacy BLE 4.2 GAP HCI command
paths instead of mapping failures to BTM_ILLEGAL_VALUE or
BTM_NO_RESOURCES. Add btm_ble_status_from_hci() helper and propagate
real status through scan start/stop completion callbacks.
(cherry picked from commit 47dd785a18)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Read By Type Response Length is one octet (max 255). When MTU was
large enough to return a long characteristic value in one pair, the
server wrote (UINT8)(value_len + 2) and overflowed (e.g. 513 -> 1),
so the client rejected the PDU as GATT_INVALID_PDU (0x04).
Cap server value to 253 bytes per pair, clamp the length byte, and
continue long reads via Read Blob when the capped size is returned.
(cherry picked from commit 97905afccc)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Skip prepare-write echo validation when the GATT stack reports a
non-success status. ATT Error Response carries no prepare-write echo
body (rsp_len=0), so the check incorrectly overwrote errors such as
GATT_INSUF_AUTHENTICATION (0x05) with GATT_INVALID_PDU (0x04).
(cherry picked from commit d5b9350d0f)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Release the BLE sync semaphore and record HCI status when a
synchronous command is rejected via Command Status, since no
Command Complete event follows.
(cherry picked from commit 29ae92f4ef)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
When service change cancels in-progress discovery, bta_gattc_disc_cmpl()
re-triggers discovery without marking auto_update as REQ_WAITING. If a
client command is queued in p_q_cmd, bta_gattc_start_discover() refuses
to restart and the command is never dispatched.
(cherry picked from commit 13926bb9bc)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Route unknown BD_ADDR and other immediate failures through the existing
need_cb path so ESP_GAP_BLE_UPDATE_CONN_PARAMS_EVT is always delivered.
(cherry picked from commit f9eaeb5e84)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Include client_if, handle, bd_addr, and server cache state in the
warning logged when notification registration skips handle validation.
(cherry picked from commit 1085a32be8)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
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.
Zhang Hai Peng
Jiang Jiang Jian
Island
yangfeng
Zhang Wen Xu
Euripedes Rocha Filho
Xu Si Yu
morris
Guo Zifan
Shreyas Sheth
gaoxu
wanckl
igor.udot
Mahavir Jain
Rahul Tank
Astha Verma
harshal.patil
Kapil Gupta
xiongweichao
Aditya Patwardhan