You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The rt_hw_atomic_load function should successfully perform an atomic load operation on the specified memory address without causing a system failure or timeout during execution. Specifically, when using the syz_thread_delay_ms function, it is expected that the delay will be executed correctly and the syscall will return normally after the specified time has elapsed.
Actual Behavior:
Upon executing syz_thread_delay_ms, the system experiences an unexpected stop with a qemu run instance merger error due to execution timing out. The VM fails to read registers from the localhost port 33427, indicating a connection refusal. This results in a stack trace pointing towards issues within the atomic_arm.c file at line 84 where rt_hw_atomic_load is called. Additionally, there was an inconsistency between the number of calls made (info.Calls) and the actual number of calls expected (ncalls)
Description:
The issue appears to stem from the implementation of the rt_hw_atomic_load function which attempts to perform an atomic load via LDREX/STREX instructions in a loop until successful. However, under certain conditions, this loop does not terminate properly leading to what seems like a deadlock situation. As a result, the emulator running the RT-Thread kernel times out while trying to execute the test case provided by the fuzzer.
__Note:kcov.c main.c common_freertos.h executor.h is a file we wrote ourselves.
Steps to Reproduce:
Set up the Rt-Thread environment with the necessary configurations for fuzz testing.
Compile the RT-Thread kernel with debugging symbols enabled.
Use a fuzzer tool such as syzkaller configured to generate random inputs for syscall testing.
Execute the syz_thread_delay_ms function with (0xe760).
#include<rtthread.h>#include<stdint.h>// Function for thread delaylongsyz_thread_delay_ms(volatileintms) {
if (ms <= 0) {
return-1; // Returns an error, the delay must be positive
}
rt_thread_mdelay((rt_int32_t)ms);
return0; // Success
}
Observe the behavior; if the bug persists, you should see similar logs indicating a timeout and register access failure.
Other additional context
No response
The text was updated successfully, but these errors were encountered:
RT-Thread Version
2f55990
Hardware Type/Architectures
arm32
Develop Toolchain
GCC
Describe the bug
Expected Behavior:
The
rt_hw_atomic_load
function should successfully perform an atomic load operation on the specified memory address without causing a system failure or timeout during execution. Specifically, when using thesyz_thread_delay_ms
function, it is expected that the delay will be executed correctly and the syscall will return normally after the specified time has elapsed.Actual Behavior:
Upon executing
syz_thread_delay_ms
, the system experiences an unexpected stop with a qemu run instance merger error due to execution timing out. The VM fails to read registers from the localhost port 33427, indicating a connection refusal. This results in a stack trace pointing towards issues within theatomic_arm.c
file at line 84 wherert_hw_atomic_load
is called. Additionally, there was an inconsistency between the number of calls made (info.Calls
) and the actual number of calls expected (ncalls
)Description:
The issue appears to stem from the implementation of the
rt_hw_atomic_load
function which attempts to perform an atomic load via LDREX/STREX instructions in a loop until successful. However, under certain conditions, this loop does not terminate properly leading to what seems like a deadlock situation. As a result, the emulator running the RT-Thread kernel times out while trying to execute the test case provided by the fuzzer.Debug Logs:
__Note:
kcov.c main.c common_freertos.h executor.h
is a file we wrote ourselves.Steps to Reproduce:
syz_thread_delay_ms
function with (0xe760
).Other additional context
No response
The text was updated successfully, but these errors were encountered: