On 12/02/24 14:40, John Paul Adrian Glaubitz wrote: > On Mon, 2024-02-12 at 14:31 -0300, Adhemerval Zanella Netto wrote: >> It really make me to believe it is something related to kernel because running the regression >> program under strace I could not trigger the issue; nor by trying adding a printf just before >> clone call. > If I understood the problem correctly, according to Michael the issue related to the stack allocation > which means that running "strace -f" will let posix_spawn() work properly in this case. > > Adrian > But what I am not fully sure is what ptrace/strace makes the testcase works as expected, since the only think glibc clone implementation does it to allocate a stack frame on the passed stack argument and issuing the syscall. Afaik, the value passed on kernel, in either case (default, strace) would be essentially the same: $ setarch -R strace -o log ./more_clone_attack effective FP in clone() with waste 0 = 7feffffe590 this is 178 64-bit words above the next page boundary [main] clone(0x100000009e0, 0xfff800010002fe80, ...) [main] clone(0x100000009e0, 0xfff800010002fe80, ...) [main] clone(0x100000009e0, 0xfff800010002fe80, ...) [main] clone(0x100000009e0, 0xfff800010002fe80, ...) [...] No problems found $ ./more_clone_attack effective FP in clone() with waste 0 = 7feff81a590 this is 178 64-bit words above the next page boundary [main] clone(0x100000009e0, 0xfff800010002be80, ...) [main] clone(0x100000009e0, 0xfff800010002be80, ...) clone: Bad address Problem detected at 1 pages distance So from userland point of view, which is the requirement regarding stack argument?
