The test only runs with MBEDTLS_CONSTANT_TIME_PRIME_GEN disabled:
with the constant-time prime generation that is now the default,
RSA-2048 key generation takes over a minute on most targets (~86 s on
ESP32-S3), exceeding the test timeout and starving the task watchdog.
mbedtls 4.1.1 made the small-factor test in prime generation
constant-time (a CT GCD against the product of primes up to 997, run
for every prime candidate). This makes RSA key generation roughly ten
times slower on ESP chips and starves the idle task since the software
GCD never yields, tripping the task watchdog.
Add MBEDTLS_CONSTANT_TIME_PRIME_GEN under the new "Security hardening"
menu, default y so the upstream constant-time behavior ships as the
secure default. When disabled, esp_config.h defines
MBEDTLS_MPI_PRIME_SIEVE_VARIABLE_TIME and mbedtls uses the pre-3.6.7
variable-time trial division, restoring key generation performance on
devices where no untrusted co-resident code could time key generation.
Set SECURE_BOOT_SHA384_EN when enabling ECDSA-P384 Secure Boot V2 on
ESP32-P4, as done on C5/H4/S31, so that ROM verifies the bootloader
using the SHA-384 scheme. The eFuse exists only on the rev >= v3.0
eFuse table, so the Kconfig option is gated on rev >= v3.0.
When a loop is deleted while an internal legacy "cleanup" event is still
queued (posted by a deferred self-unregistration from within a handler),
esp_event_loop_delete() drained the queue but only freed the post payload,
leaking the heap copy of the handler context allocated for the legacy path.
Free ctx->handler_ctx for queued legacy cleanup events while draining the
queue, mirroring the cleanup done in esp_event_loop_run().
Add a regression test that leaves a legacy cleanup event queued and asserts
no memory is leaked on loop deletion.
When esp_event_loop_run() exited via the ticks-expired break path,
loop->running_task was left pointing to the current task handle.
Any subsequent trylock in esp_event_handler_unregister_with_internal()
would see a stale non-NULL running_task and take the wrong code path.
esp_event_post_to() could access loop->queue / loop->mutex after
esp_event_loop_delete() freed them when both ran concurrently.
Introduce esp_event_loop_state_t with:
- posts_in_flight: reference-count incremented atomically (under
state.lock spinlock) before touching any loop resources, decremented
on every exit path via goto on_err.
- deleting: atomic_bool set by esp_event_loop_delete() to block new
posts from entering the critical section.
esp_event_loop_delete() sets deleting=true, then busy-waits (releasing
and re-acquiring loop->mutex each tick) until posts_in_flight reaches
zero before proceeding with teardown.
esp_event_isr_post_to() performs a lock-free atomic_load of deleting as
a best-effort guard; ISR context cannot participate in the spinlock
protocol but the window is documented and accepted.
After processing an esp_event_handler_cleanup sentinel, execution fell
through into the regular dispatch block. Every loop-level (ANY_BASE/
ANY_ID) handler was invoked with base="cleanup" and event_data pointing
at the internal esp_event_remove_handler_context_t struct.
Consequences:
- Information disclosure: internal handler addresses and loop instance
pointer are exposed to every loop-level handler.
- UAF: if a handler stores event_data for later use, post_instance_delete
frees the ctx, turning the stored pointer into a dangling reference.
- Logic corruption: handlers that switch on base with a default branch
misbehave on every unregister anywhere in the system.
Fix: wrap the regular dispatch block in an else clause so it is skipped
entirely for cleanup events. post_instance_delete, ticks accounting, and
xSemaphoreGiveRecursive remain in the shared tail executed for both paths.
Closes SEC_221
1) loop->mutex is created with xSemaphoreCreateRecursiveMutex(). FreeRTOS
requires that recursive mutexes are only acquired and released with
xSemaphoreTakeRecursive / xSemaphoreGiveRecursive.
esp_event_handler_unregister_with_internal() used the non-recursive
xSemaphoreTake(loop->mutex, 0) / xSemaphoreGive(loop->mutex) in the fast
path. The non-recursive Take bypasses uxRecursiveCallCount bookkeeping;
if the same task subsequently takes the mutex recursively (e.g. re-entry
from a handler or a follow-up register), the call count drifts. The
non-recursive Give then unconditionally drops the holder, allowing another
task to acquire the mutex while the original task still believes it holds
the lock — a full lock violation on the handler list leading to UAF and
potential RCE on attacker-driven event floods.
Fix: replace xSemaphoreTake/xSemaphoreGive with the Recursive variants in
the fast (try-take with timeout 0) path of unregister_with_internal.
2) avoid use-after-free when unregistering handler from a callback
The recursive try-lock introduced in SEC-220 succeeds re-entrantly when a
handler unregisters itself from within its own callback, causing the handler
node to be freed immediately while the dispatch loop still writes profiling
counters to it after the callback returns. Route the in-callback case to the
deferred cleanup path and only free directly once no dispatch is active.
Closes SEC_220
esp_event_is_handler_registered() walked loop_nodes, base_nodes, id_nodes
and handler lists with no lock held, then released an unowned mutex at the
'out:' label via xSemaphoreGive().
Concurrent register/unregister/delete operations can free handler nodes
during the unlocked walk (SLIST UAF). The xSemaphoreGive on an unowned
recursive mutex corrupts the recursive call-count of any task that
legitimately holds the mutex.
Fix:
- Take loop->mutex with xSemaphoreTakeRecursive before the traversal.
- Replace xSemaphoreGive at the 'out:' label with xSemaphoreGiveRecursive
so every exit path holds the mutex for exactly one balanced take/give.
Closes SEC_219
fprintf(file, buf) is a format-string sink: if any registered event base
or handler name contains "%", fprintf interprets it as a format directive,
causing an information leak or crash.
Replace with fprintf(file, "%s", buf) so the buffer is always treated as
plain text regardless of its content.
Closes SEC_064
Meet Patel
Jiang Jiang Jian
morris
Shu Chen
Chen Jichang
Martin Vychodil
Island
Mahavir Jain
Ashish Sharma
Chen Chen
akshat
Wang Meng Yang
yangfeng
nilesh.kale
muhaidong
zhuanghang
zhangyanjiao
Kapil Gupta
Konstantin Kondrashov