Reject an implausible SPI-read frame-length header and drain the
socket RX buffer to resync Sn_RX_RD, instead of looping forever on
the unrecoverable descriptor and starving the system.
esp-idf-sbom reports four ESP-IDF CVEs against this branch because NVD
pins them to 5.3.5 -- the version release/v5.3 still reports until 5.3.6
is released -- even though the fixes are already merged here:
- CVE-2026-45160 DHCP server OOB read (9f713dbc94)
- CVE-2026-45541 esp_http_server WebSocket NULL dereference (f88a47e4f3)
- CVE-2026-45542 protocomm SRP6a heap overflow (0ea58d7984)
- CVE-2026-46532 BlueDroid AVRCP vendor-command parser OOB read (7c004d3fe3)
esp-idf-sbom merges this repository-local excluded_cves.yaml into its
exclusion list when scanning the tree, so these CVEs are reported as
excluded for this branch while the released v5.3.5 tag, which predates
this file, is still reported. Once version.cmake is bumped to 5.3.6 the
entries become no-ops (NVD does not list 5.3.6) and can be removed.
Compared to the release/v5.5 file this backport was adapted from, the
two ESP-TEE CVEs do not apply (NVD pins them to 5.5.4 and 6.0 only) and
CVE-2026-46532 is added (fixed in the released v5.5.4, but only after
v5.3.5 on this branch).
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Reformat the test partition before each mount so those tests always start from
a known-empty filesystem.
Co-authored-by: Cursor <cursoragent@cursor.com>
The reassembly buffer must be reset to its origin at the beginning of every
transaction. prov_msg_recv() pulls the PDU type byte (advancing buf->data by
one) and nothing restores it between transactions. Without this reset,
buf->data drifts forward by one byte per received PDU, causing the segment-0
memcpy to write past the end of the statically allocated rx buffer
(PROV_RX_BUF_SIZE), and the XACT_SEG_DATA() offsets used for continuation
segments to be skewed by the accumulated drift.
(cherry picked from commit 2c4acaa2aa)
Co-authored-by: luoxu <luoxu@espressif.com>
Fix multiple wire-format and robustness issues in the DFD client
(dfd_cli.c):
- handle_capabilities: read oob_retrieval_supported as u8 instead of
le32. The server encodes a single byte; le32 over-consumed 3 bytes
of the URL scheme list and could over-read the buffer.
- handle_upload_status: extract upload_progress from bits 0-6 (& 0x7F)
and upload_type from bit 7 (>> 7), matching the server encoding
(progress | BIT(7)). The previous >>1 / &0x01 returned wrong values,
mis-classified in-band vs OOB, and falsely rejected valid OOB
messages with high progress.
- handle_dfd_status: correct the transfer-mode byte layout to
trans_mode bits 0-1, update_policy bit 2, RFU bits 3-7 (previously
read bits 6-7 / 5), and fix the RFU mask to 0xF8. Now matches the
struct bitfield definition and the DFD server.
- handle_dfd_status: report status+phase and return early when
buf->len == 0 (IDLE phase) instead of pulling 10 absent bytes.
- bt_mesh_dfd_cli_distribution_start: encode trans_mode/update_policy
into bits 0-2 so the server decodes them correctly.
- handle_receiver_list: validate buf->len >= entries_cnt * 5 before
the loop, and handle entries_cnt == 0 without relying on calloc(0).
- handle_receiver_status: pass the status value (not the whole union)
to the %d log format, fixing undefined behavior.
- dfd_client_recv_status: drop the dead BLE_MESH_DFD_OP_CAPABILITIES_GET
case (a client-send opcode) from the receive switch.
- bt_mesh_dfd_cli_receivers_add: widen msg_length to uint32_t to avoid
uint16_t overflow that bypassed the PDU size guard; add a NULL check
for the receivers array.
- bt_mesh_dfd_cli_distribution_upload_oob_start: return -EINVAL
instead of -1 for consistency with the rest of the file.
(cherry picked from commit 43137475e1)
Co-authored-by: luoxu <luoxu@espressif.com>
