Closed xdqi closed 8 months ago
In QEMU's code handling clone, when clone creates a new thread, it does some QEMU stuff, creates a conditional variable and spawns a new thread. https://github.com/AFLplusplus/qemu-libafl-bridge/blob/99ea52d12369d0bd30717c57e65719a2644b7c68/linux-user/syscall.c#L6647-L6683 The thread fills the data that'll be clone's return value, and trigger the conditional variable. https://github.com/AFLplusplus/qemu-libafl-bridge/blob/99ea52d12369d0bd30717c57e65719a2644b7c68/linux-user/syscall.c#L6544-L6568 When the clone's caller gets unlocked, the info soon gets out of scope. Then if LibAFL hooks are called, it accesses the freed-then-reused stack memory which contains trash.
clone
The patch solves the problem by not using the freed info->tid. Instead, we get TID when there are hooks to be called.
info->tid
Hi, ty you are right
In QEMU's code handling
clone
, whenclone
creates a new thread, it does some QEMU stuff, creates a conditional variable and spawns a new thread. https://github.com/AFLplusplus/qemu-libafl-bridge/blob/99ea52d12369d0bd30717c57e65719a2644b7c68/linux-user/syscall.c#L6647-L6683 The thread fills the data that'll beclone
's return value, and trigger the conditional variable. https://github.com/AFLplusplus/qemu-libafl-bridge/blob/99ea52d12369d0bd30717c57e65719a2644b7c68/linux-user/syscall.c#L6544-L6568 When theclone
's caller gets unlocked, the info soon gets out of scope. Then if LibAFL hooks are called, it accesses the freed-then-reused stack memory which contains trash.