SpiffsFS.create_file() rejected names only when strictly longer than
obj_name_len, but CONFIG_SPIFFS_OBJ_NAME_LEN's documented semantics
(see components/spiffs/Kconfig) are that the length includes the
zero-termination character, so the maximum number of actual name
characters is obj_name_len - 1.
With the old check, a name exactly obj_name_len characters long was
accepted. SpiffsObjIndexPage.to_binary() then computes the NUL padding
after the name as (obj_name_len - len(name)), which is 0 in that case,
so the generated image's fixed-size name field ends up with no NUL
terminator anywhere in its reserved region.
Fix the boundary so the generator enforces the same maximum length
that the Kconfig help text documents.
esp_partition_write/read/erase_range/mmap in partition_linux.c (the
`linux` target backend used by --preview set-target linux / host_test)
validated the requested range with `offset + size > partition->size`.
When `size` is close to SIZE_MAX, this addition wraps around size_t and
can evaluate to a small value, so the check passes even though the
request is far out of bounds. A caller passing e.g.
esp_partition_write(partition, 1, src, SIZE_MAX) sails through both
bounds checks and reaches the byte-copy loop with new_size == SIZE_MAX,
causing out-of-bounds reads/writes far past both the caller's buffer
and the mmap'd emulated-flash file.
Replace all four instances with the overflow-safe form already used by
the other esp_partition backends (partition_target.c,
partition_bootloader.c, partition_tee.c):
`size > partition->size - offset`, which is safe because the preceding
check already guarantees offset <= partition->size.
Signed-off-by: yi chen <94xhn1@gmail.com>
NVSEncryptedPartition held two XTS_CONTEXT members (mEctxt, mDctxt) for
encryption / decryption. Their AES round keys are derived from the NVS
encryption key (HMAC-derived or plaintext from nvs_keys partition) and
therefore are sensitive secrets.
The destructor was empty, so when the NVS encrypted partition object
was destroyed -- on nvs_flash_deinit_partition(), on initialization
errors, and on any other teardown path -- the XTS round keys were left
in DRAM until the freed object's memory happened to be overwritten by
a later allocation. A subsequent stack/heap leak primitive would
recover the AES key from those bytes.
Fix:
* Initialize both XTS contexts in the constructor so the destructor's
free path is always safe (previously xts_init was only called in
init(); destruction before init() would have run xts_free on an
uninitialized struct).
* Provide a real destructor that calls XTS_FUNC(xts_free) on both
contexts, which performs mbedtls_platform_zeroize / esp_aes_xts free
semantics on the underlying AES contexts.
Add a Unity test case that arms only ANA_CMPR_CROSS_POS (resp. only
ANA_CMPR_CROSS_NEG) on a unit and asserts that a real transition of
the matching direction fires the callback exactly once, while a
transition of the opposite (never-armed) direction does not fire at
all.
This closes a gap in the existing test_apps: none of the current
cases isolate cross direction, so a swapped POS/NEG interrupt mask in
the LL layer (fixed in the previous commit) previously went
undetected.
On the scan-based comparator IP (ESP32-H4/S31), a crossing is only
sampled/latched when a scan is explicitly triggered, so the new test
case also triggers a scan after each level change on that IP, plus
one extra priming scan right after enabling the unit so the internal
compare state starts in sync with the already-set initial GPIO level.
Signed-off-by: Tiago Medicci <tiago.medicci@espressif.com>
In components/soc/esp32c5/register/soc/gpio_ext_struct.h (ESP32-C5),
components/soc/esp32c61/register/soc/gpio_ext_struct.h (ESP32-C61),
and components/soc/esp32p4/register/hw_ver3/soc/gpio_struct.h
(ESP32-P4), the analog comparator raw/status/enable/clear register
fields are named comp_neg_0_*/comp0_neg_* for bit 0 and
comp_pos_0_*/comp0_pos_* for bit 1, but each field's own comment says
the opposite: bit 0 is documented as "analog comparator pos edge
interrupt raw/status/enable/clear" and bit 1 as the "neg" counterpart.
The LL masks were defined from the field names rather than from this
documented behavior, so ANALOG_CMPR_LL_POS_CROSS_INTR_MASK() ended up
selecting bit 1 and ANALOG_CMPR_LL_NEG_CROSS_INTR_MASK() bit 0.
A new test case, added in the following commit, arms only one cross
direction at a time and checks that a matching transition fires the
callback while the opposite, never-armed direction does not; without
this fix it reproducibly fails on ESP32-C5, ESP32-P4, and ESP32-C61.
Signed-off-by: Tiago Medicci <tiago.medicci@espressif.com>
Restore the use_secure_element field in esp_tls_cfg_t, esp_tls_cfg_server_t
and httpd_ssl_config_t, and esp_transport_ssl_use_secure_element(), as
deprecated no-ops so that existing code keeps compiling. Setting them now
fails at runtime with ESP_ERR_NOT_SUPPORTED, as the feature is accessed
via the esp_key_config_t interface. To be removed in the next major release.
No compile-time deprecation attribute on this release branch; the field and
function stay warning-free here and carry only documentation notes.
tarun.kumar
Wang Meng Yang
yi chen
Martin Vychodil
Ashish Sharma
sonika.rathi
Sumeet Singh
wuzhenghui
yanzihan@espressif.com
Jiang Jiang Jian
Chen Chen
Rahul Tank
morris
linruihao
Aditya Patwardhan
luoxu
Meet Patel
Konstantin Kondrashov
Tiago Medicci
gaoxu
Alexey Lapshin
Hu Rui