On the Linux port, tasks are pthreads that cannot be forcibly paused;
the scheduler "unschedules" a task only by selecting a different next
task, and the outgoing task keeps running until it next blocks itself
in event_wait (e.g. via vPortYield). If the scheduler later switches
back into such a task (event_signal) before it ever parked in
event_wait, that wake is never consumed and event_triggered stays
latched. The task's next voluntary block then returns immediately
instead of blocking (e.g. vTaskDelay(100ms) returning in 0ms), which
desynchronizes kernel and port scheduling state.
Clear the outgoing task's pending event when switching to a different
task, under s_port_mutex and atomically with the scheduling decision.
Any latched-but-unconsumed wake is stale at that point; a legitimate
wake can only be delivered later, once the scheduler selects the task
again as next_thread.
Add event_clear() to the wait_for_event helper to support this.
Verified: minimal repros (busy-wait with another ready task, and
pthread-blocked task) now measure 92-101 ms for vTaskDelay(100ms)
instead of 0 ms; linux_freertos kernel test app 18/18 pass; the
previously failing esp_linenoise host test suite passes 34/34.
Drop the internal assert in dac_continuous_enable() and call
dac_priv_enable_channel() directly, since the surrounding state
machine already guarantees the preconditions.
Co-authored-by: Cursor <cursoragent@cursor.com>
GCC 16 flags the volatile accumulator in the cache writeback loops even
though it is volatile, as it is only used to update itself. Drop the
accumulator and rely on the volatile-qualified psram pointer to keep
the cache-line reads from being optimized out.
GCC 16 raised the default level of -Wunused-but-set-variable and now
flags variables that are only used to update themselves. Remove the
'removed' counter in pmksa_cache_flush() (its only read was commented
out) and mark the EAP-FAST PAC entry counters as unused, since their
only read is inside wpa_printf(MSG_DEBUG, ...) which compiles to a
no-op when debug logging is disabled.
fix(esp_tee): Add additional input validation checks for TEE service calls
Closes SEC-585, SEC-610, and SEC-1058
See merge request espressif/esp-idf!50062
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.
ESP32-C2 and ESP32-C61 have no RSA based Secure Boot V2 support, so the
CI configs that pin the RSA signing scheme and key fail the app signing
scheme/key check on these targets.
- flash_enc_wifi_2.data_partition_verification: add C2/C61 sdkconfig
overlays that switch to the ECDSA P-256 signing scheme and key (no
force-enable needed as Secure Boot V2 itself is not enabled here).
- on_update_no_sb_rsa: disable the build on targets without
SOC_SECURE_BOOT_V2_RSA, mirroring simple_ota_example, since this
config specifically exercises the RSA scheme.
httpd_req_get_hdr_value_str() detected truncation with `val_size < full_size`, where full_size is the strlcpy() return value. strlcpy() returns strlen() of the source (the terminating null is not counted), so truncation actually occurs when strlen(src) >= val_size. At strlen(src) == val_size the value is copied as val_size - 1 chars + NUL (i.e. truncated) yet ESP_OK was returned, so the caller never learned the value was cut.
Use `val_size <= full_size` and correct the misleading comment about strlcpy()'s return value.
Same truncation-reporting class fixed for httpd_cookie_key_value in PR #16202; httpd_req_get_hdr_value_str was missed. No memory-safety impact: strlcpy() null-terminates if val_size > 0.
Handle absent IROM/DROM alignment gap in SPIRAM-XIP memprot tests
Closes IDFCI-5004, IDFCI-11739, and IDFCI-11738
See merge request espressif/esp-idf!50133