tg_info is still in use after task_uninit_info(), unifies
lib_stream_* with life cycle of task info to avoid this issue.
| ==1940861==ERROR: AddressSanitizer: heap-use-after-free on address 0xf47032e0 at pc 0x5676dc4f bp 0xf2f38c68 sp 0xf2f38c58
|
|#10 0xf7abec89 in __asan::__asan_report_load2 (addr=4100993760) at ../../../../src/libsanitizer/asan/asan_rtl.cpp:119
|#11 0x5677356a in nxsem_destroy (sem=0xf47032e0) at semaphore/sem_destroy.c:73
|#12 0x56773695 in sem_destroy (sem=0xf47032e0) at semaphore/sem_destroy.c:120
|#13 0x5676faa2 in nxmutex_destroy (mutex=0xf47032e0) at include/nuttx/mutex.h:126
|#14 0x567a3430 in lib_stream_release (group=0xf4901ba0) at stdio/lib_libstream.c:98
|#15 0x5676da75 in group_release (group=0xf4901ba0) at group/group_leave.c:162
|#16 0x5676e51c in group_leave (tcb=0xf5377740) at group/group_leave.c:360
|#17 0x569fe79b in nxtask_exithook (tcb=0xf5377740, status=0) at task/task_exithook.c:455
|#18 0x569f90b9 in _exit (status=0) at task/exit.c:82
|#19 0x56742680 in exit (status=0) at stdlib/lib_exit.c:61
|#20 0x56a69c78 in iperf_showusage (progname=0xf2f28838 "iperf", exitcode=0) at iperf_main.c:91
|#21 0x56a6a6ec in iperf_main (argc=1, argv=0xf2f28830) at iperf_main.c:140
|#22 0x5679c148 in nxtask_startup (entrypt=0x56a69c78 <iperf_main>, argc=1, argv=0xf2f28830) at sched/task_startup.c:70
|#23 0x56767f58 in nxtask_start () at task/task_start.c:134
Signed-off-by: chao an <anchao@xiaomi.com>
The task_group specific list can be used to store information about
mmappings.
For a driver or filesystem performing mmap can also enable munmap by
adding an item to this list using mm_map_add(). The item is then
returned in the corresponding munmap call.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Summary:
- I noticed that nxplayer (HTTP audio streaming) + command execution
via telnet sometimes causes memory corruption.
See https://github.com/apache/nuttx/pull/7947 for the detail.
- This commit fixes this issue by calling lib_stream_release() before
lib_stream_release() in group_leave.c
Impact:
- Should be none
Testing:
- Tested with spresense:wifi_smp
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
When the signal sent by the sender is blocked in the target task,
if the target task has an action registered with sa_flags SA_KENELHAND,
it will directly respond to the action in the context of the sender.
When the action is executed, it will have the parameters set by the
target task with sigaction:sa_user.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
_assert is a kernel procedure, entered via system call to make the core
dump in privileged mode.
Running exit() from this context is not OK as it runs the registered
exit functions and flushes streams, which must not be done
from privileged mode as it is a security hole.
Thus, implement assert() into user space (again) and remove the exit()
call from the kernel procedure.
Instantiate the correct address environment when reading the process's
argument vector. Otherwise doing this will crash the system every time,
causing a recursive assert loop.
Also try to do a bit of sanity checking before attempting to read the
process's memory, it might be in a bad state in which case this will
fail anyway.
This is preparation for flushing streams from user space, like it should
be done.
- Move tg_streamlist (group, kernel space) ->
ta_streamlist (TLS, user space)
- Access stream list via tg_info in kernel
- Access stream list via TLS in user space
- Remove / rename nxsched_get_streams -> lib_getstreams
- Remove system call for nxsched_get_streams
The user stack is dependent on the user address environment. As the
process exits, this address environment is destroyed anyway, so the
stack does not need to be released separately.
There is also an issue with this when the process exits via exit(). The
problem is that the task group is released prior to this "up_release_stack()"
call along with the address environment, and trying to free the memory
either causes an immediate crash (no valid addrenv), or frees memory into
another process' heap (addrenv from a different process).
Signed-off-by: Ville Juven <ville.juven@unikie.com>
According to posix spec, this function should never return `EINTR`.
This fixes the call to `pthread_mutex_take` so it keeps retrying the
lock and doesn't return `EINTR`
It takes about 10 cycles to obtain the task list according to the task
status. In most cases, we know the task status, so we can directly
add the task from the specified task list to reduce time consuming.
It takes about 10 cycles to obtain the task list according to the task
status. In most cases, we know the task status, so we can directly
delete the task from the specified task list to reduce time consuming.
