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
- 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"
- Run workload with some processes spawning multiple threads.
- 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
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
clone30or536870912Expected 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