WL_Flash::write() and WL_Flash::read() computed:
uint32_t count = (size - 1) / this->cfg.wl_page_size;
`size` is `size_t` (unsigned). Neither the public wl_write()/wl_read() API
(wear_levelling.cpp), nor the newer wl_bdl_write()/wl_bdl_read() block-device
path (wl_blockdev.cpp), reject size == 0 before calling into WL_Flash, and
wear_levelling.h does not document size == 0 as invalid (a 0-byte
write/read is a reasonable no-op, mirroring POSIX write()/read() with
count == 0).
When size == 0, `size - 1` wraps around to SIZE_MAX, so `count` becomes an
enormous page count instead of 0. The functions then loop that many times,
reading (write()) or writing (read()) `wl_page_size` bytes per iteration
through the flash partition, immediately walking past the caller-supplied
buffer on the very first iteration:
- write(): out-of-bounds *read* from the caller's `src` buffer.
- read(): out-of-bounds *write* into the caller's `dest` buffer -- the
more severe case, since it corrupts caller memory with flash
content instead of merely over-reading.
Verified with a standalone reproduction that compiles the unmodified
WL_Flash.cpp against a mock Flash_Access partition: calling
`wl.write(0, an_8_byte_buffer, 0)` with no other change immediately
segfaults (confirmed count == 0xFFFFFFFF for wl_page_size == 4096); with
this fix applied the same call returns ESP_OK without touching memory
outside the buffer, and normal non-zero-size read/write is unaffected.
Add an early `size == 0` return (mirroring the existing `!initialized`
guard) to both functions, and a host_test regression case exercising
wl_write()/wl_read() with size == 0 through the public API.
Disclosure: this fix was prepared with AI assistance (Claude) and reviewed
by me before submission.
Signed-off-by: yi chen <94xhn1@gmail.com>
esp-idf-sbom reports four ESP-IDF CVEs against this branch because NVD
pins them to 5.4.4 -- the version release/v5.4 still reports until 5.4.5
is released -- even though the fixes are already merged here:
- CVE-2026-45160 DHCP server OOB read (2bf4dd1200)
- CVE-2026-45541 esp_http_server WebSocket NULL dereference (37508ab911)
- CVE-2026-45542 protocomm SRP6a heap overflow (f5d24a7e91)
- CVE-2026-46532 BlueDroid AVRCP vendor-command parser OOB read (56053c4d1f)
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.4.4 tag, which predates
this file, is still reported. Once version.cmake is bumped to 5.4.5 the
entries become no-ops (NVD does not list 5.4.5) 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.4.4 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>
