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
1) Fix crash while connecting to dpp akm
2) Fix phy ref cnt for power management for offchannel_tx
3) Introduced a variable to indicate dpp ap for scan results
4) Introduced WIFI_AUTH_UNKNOWN for ap with misconfigured security parameters
Update inq_var.state only after btsnd_hcic_ble_ext_scan_enable succeeds.
Clear BTM_BLE_SCANNING on explicit stop and controller scan timeout.
(cherry picked from commit 23519567e4)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Default all Bluedroid layer trace levels to NONE when BLE async log
is enabled without BLE_LOG_HOST_LOG.
(cherry picked from commit 1f8f935e3f)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Do not check CCCD before sending notify in battery_set,
input_set and feature_set.
(cherry picked from commit 81bbcaca4e)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Jiang Jiang Jian
Konstantin Kondrashov
Adam Múdry
Zhou Xiao
Martin Vychodil
gadget-man
Shreyas Sheth
Alexey Gerenkov
morris
Luo XuandWang Mengyang
Zhang Hai Peng
Renz Bagaporo
Jin Cheng
Chen Jichang
muhaidong
Xu Si Yu
Alexey Lapshin