bug: v/84212
Rootcase: The lightweight sched_note_printf function in the NuttX backend does not
perform NULL safety checks for the %s format specifier. Passing a NULL pointer from
hsm_get_state_name leads to a NULL pointer dereference, triggering a data abort
exception on systems with memory protection (MMU/MPU) and causing a system crash.
Solution: This commit addresses the issue by modifying the HSM_SAFE_NAME macro to
use the ternary operator. It now explicitly returns the "None" string literal when
hsm_get_state_name returns NULL, guaranteeing that a valid, non-null C-string is always
passed to the logging function.
Signed-off-by: v-chenghuijin <v-chenghuijin@xiaomi.com>
bug: v/83955
Rootcause: euv_pipe_close records the address of the euv_pipe in the data field of each uv_pipe instance to be closed, which is used to release the euv_pipe instance after the close operation completes.
A scenario exists where calling euv_pipe_close followed by euv_pipe_read_stop or euv_pipe_read_start causes the client pipe's data field to be reset to NULL or the reader's address. This prevents the euv_pipe instance from being released after close completes.
This occurs because euv_pipe_read_stop does not check the uv_pipe's state before directly freeing cli_pipe.data, while euv_pipe_read_start only verifies whether cli_pipe is active. Both functions lack a check for the closing state.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
bug: v/80811
Rootcause: In certain scenarios, users of `euv_pipe` must ensure all UV requests have completed execution before releasing resources. Consequently, it is necessary to notify users that `euv_pipe` has been fully released after its close operation is completed, thereby permitting subsequent operational procedures to proceed. Support for the close callback has therefore been added.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
bug: V/80385
Rootcause: uv_loop_close() marks internal data structures as invalid (e.g., set to -1), but pending callbacks in the queue still reference these invalidated structures. When uv_run() is called later, it processes the queue using corrupted pointers, leading to segmentation faults and crashes. Solution: Introduce a new flag in uv_loop_close() to mark the loop as closed and check it in uv_run() and other loop-related functions to prevent execution of callbacks after closure, ensuring memory safety and avoiding invalid pointer access.
Signed-off-by: v-chenghuijin <v-chenghuijin@xiaomi.com>
bug: v/80592
Rootcause: The creation of the euv_pipe RPMSG Pipe is conditionally compiled based on the RPMSG configuration, whereas the Close behaviour lacks this restriction. Consequently, in certain scenarios, non-existent RPMSG pipes may be released, triggering an exception.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
bug: v/79115
Rootcause: Replace `calloc` with the C standard library function `malloc` to avoid compilation errors.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
bug: v/77699
When the client clears resources, if tasks are still executing in the worker thread at that time, it will lead to a use-after-free issue.
Signed-off-by: liuxiang18 <liuxiang18@xiaomi.com>
bug: v/74823
The current execution time of `on_scan_result_cb` is excessively long. Replace `lib_dumpbuffer` with `BT_DUMPBUFFER` (disabled by default) to reduce callback execution time, thereby preventing watchdog timeouts.
Signed-off-by: liuxiang18 <liuxiang18@xiaomi.com>
bug: v/76708
Rootcause: `uv_close` does not guarantee the order in which close callbacks run.
There is a case where `euv_pipe_close2` and `euv_pipe_close` are called in sequence: if the `uv_close` initiated by `euv_pipe_close` completes first and frees the `euv_pipe_t` instance, `euv_pipe_close2` must access the invaliad address during its execution.
Therefore, add a status flag to ensure the `euv_pipe_t` instance is freed safely.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
bug: v/63976
When adding service data to broadcast data, the data length only includes the length of the type and UUID, without the length of the data.
Signed-off-by: jialu <jialu@xiaomi.com>
bug: v/65152
rootcause: it would leak pipe handle when connect and disconnect many time. client pipe would free pipe handle directly, which does not has handle->data.server pipe would free handle->data(euv connection) first when connected, then free pipe handle when closed.
Signed-off-by: chengkai <chengkai@xiaomi.com>
bug: v/65151
Rootcause: When a pipe connection is successfully established and ready to read data, a reader will be allocated to handle the reading process, and the reader will be associated with the pipe object. When it is necessary to stop reading from the pipe, the reader needs to be released. Specifically, when a pipe disconnection occurs, the allocated reader also needs to be released. However, when a disconnection is initiated by either end of the pipe, the other end may read the EOF symbol from the reader first, causing the pipe to be set to a non-active state. This prevents the current logic of first checking the pipe status before releasing the reader in euv_pipe_read_stop from releasing the reader.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
bug: v/54416
Rootcause: In order to reduce the application's judgment on whether the connection is across cores, the original two types of socket pipe connection methods are encapsulated into one interface.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
bug: v/59638
Move bt_time.h and bt_time.c from service to the common framework path, making
them publicly accessible for reuse. No functional changes were made to the APIs.
Signed-off-by: zhongzhijie1 <zhongzhijie1@xiaomi.com>
bug: v/53158
Rootcause: When using SPP capability in cross-core scenario, it is necessary to perform cross-core communication through RPMSG. Since the Bluetooth service does not know which pipe connection method the application uses when establishing an SPP connection, it waits for the application to connect using both local and RPMSG pipes, and closes the unused pipe after connecting. When not in a cross-core scenario, the Bluetooth service does not use both pipes, which causes the subsequent closing behavior to result in runtime errors, causing the Bluetooth thread to be cleared by the system, thereby stopping the Bluetooth service.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
v-chenghuijin