Describe the bug

The flags we get here from the clone exit child are not reliable. At the moment, we are not checking if bpf_probe_read_user succeeds or fails, but experiments show that the flag values could be incorrect even if the return code is 0. This seems related to race conditions in the kernel, the parent process (which owns that memory) may have already modified or freed the args memory location while the child is waking up.

Credit goes to @fremmi for discovering and investigating the issue.

How to reproduce it

1. Run sinsp-example and pring flags of clone3

sudo ./build/libsinsp/examples/sinsp-example -m -a -j -f "evt.type=clone3" -o "%evt.rawarg.flags"

2. Run workload with some processes spawning multiple threads.
3. Verify that in some case you get unexpected flags e.g. 0 or 536870912

Expected behaviour

Clone3 flags extracted should be correct.

Screenshots

Environment

Reproduced with 9.0.0+driver with modern bpf driver, but it probably affects other drivers and previous versions as well.

Additional context