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
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
when esp_event_handler_unregister_with_internal cannot take
the loop mutex (e.g., when the handler unregisters itself),
create an event with a special base identifier and add it to
the queue of the corresponding loop to postpone the removal
of the handler from the list at a time when the loop mutex can be
successfully taken.
handler_execute function is looking to match the handler only in the
list of loop events but does not look in the base event handler list
nor the id event handler list. So unless the event handler is
registered to be triggered for all event bases and all event ids of
an event loop, its profiling fields (invoked and time) are not updated
when it is called.
This commit updates the search for the matching handler to also look
in base event list and ID event list.
Closes https://github.com/espressif/esp-idf/issues/15041
* Decomposed tests into atomic unit tests
* Made tests less time-dependent, hence more robust
on different platforms (ESP32, QEMU, Linux)
* Ported most of the tests to linux
* Removed some redundant tests
* Fixed bug the tests discovered
* Simplified parts of the tests to be more clear
* Partially used C++ to simplify setup/teardown
* Unified setup/teardown in general
* Description of unregistering was incorrect
* Made clear that event loop arg mustn't be NULL
* Added parameter check in create function
Closes https://github.com/espressif/esp-idf/issues/6761
Closes IDFGH-4969
When a handler instance is the last one in the list und unregisters
itself, the handler iterator will be invalidated by entering free'd
memory. Same applies for event base and id, if they become empty.
Merges https://github.com/espressif/esp-idf/pull/4139
Fixes an issue with post instance data preparation. Currently, there is
no way to check if event data has really been set during handler
execution preparation. When data is not allocated from the heap, user
could have passed 0x0 which can lead to failed checks.
This also implements using the already allocated data memory for posting
events from non-ISR functions when data size is less than the capacity.
Konstantin Kondrashov
David Cermak
Guillaume Souchere
Jakob Hasse
Zim Kalinowski
Alexey Lapshin
Amaryllis Kulla
Liu Han
Renz Christian Bagaporo
Xentec
Anton Maklakov
Roland Dobai
Ivan Grokhotkov