libstdc++ selects between a lock-free and a mutex-based policy for
std::shared_ptr reference counting based on this macro. Enabling this
option forces the lock-free policy, which avoids pulling in the
mutex-based implementation and can reduce code size.
Note: the lock-free policy avoids embedding a mutex in each control
block, saving about 88 bytes per shared_ptr, and improves performance
by using atomic operations instead of mutex locking.
Note: this option changes the ABI of libstdc++ atomic/shared_ptr
helpers. It can be incompatible when linking against prebuilt
libraries that were compiled without it, leading to link errors or
undefined runtime behavior. Only enable it if all C++ objects and
libraries in the build use the same setting.
fix(wifi): added validation for password and reserved data length in ESPTouch v2
Closes WIFI-7448, WIFI-7484, WIFI-7482, and WIFI-7444
See merge request espressif/esp-idf!50110
Allow specifying extra compiler flags (warning flags, preprocessor
definitions, etc.) via a new 'compile_options' entry in the
idf-build-file frontmatter. The options are applied to the source
file via target_compile_options in the generated main component
CMakeLists, with CMake quoting so that flags like -DMSG="hello world"
reach the compiler exactly as written.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add a new idf.py extension that allows building standalone C files
without requiring full project boilerplate. Source files can include
optional YAML frontmatter in block comments to specify sdkconfig
options, component dependencies, and target configuration.
When the frontmatter configuration changes, the stale sdkconfig is
removed so the new defaults are applied, and a target change also
clears the build directory since IDF_TARGET is pinned in the CMake
cache.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1. Added validation for password and reserved data length in ESPTouch v2
2. Added bound check for data index in ESPTouch v1 HT40
3. prevent buffer overflow when parsing MBSSID beacon
Move the following modules from the hal component into a new dedicated
esp_hal_debug_assist component, following the esp_hal_timg pattern:
- assist_debug (hal + target-specific LL headers)
- debug_probe (types + target-specific LL headers)
- riscv_trace (hal + types + source + target-specific LL headers)
- trace_ll (esp32/esp32s2/esp32s3 target-specific LL headers)
Update the following components to depend on esp_hal_debug_assist:
esp_system, riscv, bootloader_support, esp_hw_support, esp_riscv_trace
Remove riscv_trace_hal.c from the hal component.
heap_caps_calloc_base() calls heap_caps_malloc_base() from the same
translation unit (heap_caps_base.c). GNU ld --wrap only redirects
undefined references, so that intra-object call binds to the real
heap_caps_malloc_base and never enters __wrap_heap_caps_malloc_base.
As a result, allocations made through heap_caps_calloc() were never
recorded by heap tracing, silently hiding potentially large INTERNAL
leaks (e.g. mbedtls SSL buffers via MALLOC_CAP_INTERNAL).
Add heap_caps_calloc_base to the --wrap list and implement
__wrap_heap_caps_calloc_base, which records the allocation via a
noinline trace_calloc helper (mirroring trace_malloc so the recorded
call stack depth stays consistent) and calls __real_heap_caps_calloc_base.
The inner malloc_base call remains same-TU and unwrapped, so each
calloc produces exactly one trace record (no double counting).
