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>
Only update extend_adv_cb after HCI Set Extended Advertising
Parameters succeeds, so a failed update does not corrupt cached
legacy_pdu and related fields used by adv data validation.
(cherry picked from commit 31bd80fee8)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Map received error reason 0x00 to GATT_UNKNOWN_ERROR so the client
does not report GATT_SUCCESS with zero-length data on malformed errors.
(cherry picked from commit 1b6f9380f4)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
When sending an ATT error response after a failed server operation,
use p_tcb->sr_cmd.status instead of the last app callback status so
invalid error code 0x00 is not sent to the peer.
(cherry picked from commit 4c0488d92a)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Read Multiple may mix stack auto-responses with app async responses,
so multi_rsp_q order can differ from the request handle order. Look up
each response by handle (with occurrence for duplicates) instead of
walking the queue by index, and treat opcode-only buffers as empty.
(cherry picked from commit f91a41510c)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
esp_vfs_unregister_with_id() scanned only the first VFS_MAX_COUNT
(default 8, max 20) slots of s_fd_table[MAX_FDS] (MAX_FDS = FD_SETSIZE,
64 on non-Cygwin targets) when clearing stale references to the
unregistered VFS. Every other loop over s_fd_table in this file
(and in vfs_calls.c) correctly bounds on MAX_FDS.
Any global fd >= VFS_MAX_COUNT that was still open against the VFS
being unregistered was left with a stale vfs_index pointing at a slot
that esp_get_free_index() can immediately hand out to the next
esp_vfs_register*() call, causing later operations on that fd to be
routed into an unrelated filesystem's context.
Signed-off-by: yi chen <94xhn1@gmail.com>
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.
Validate MTU from DHCP option 26 against RFC 2132 minimum (68 bytes)
before applying to netif->mtu, preventing rogue DHCP servers from
setting MTU to 0 or other dangerously low values that cause integer
wraparound in IPv4 fragmentation.
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>
yi chen
Zhi Wei Jian
Rahul Tank
Zhang Hai Peng
Island
Guilherme Ferreira
Euripedes Rocha
Chen Jichang
wuzhenghui
guozifan
morris
Jiang Jiang Jian
David Cermak
Hu Rui
Zhang Wen Xu
Mahavir Jain
Frantisek Hrbata
Jin Cheng